Right. libHSPlasma is a library to access PRPs, Plasma fonts, SDL files, etc. It also has some networking functionality (which is what, for example prpl-uruki moulfixer use to do their dirty work). It's designed in such a way that an application built on top of it can add functionality to those purely IO classes.
PlasmaClient uses that capability to add functionality matching (or exceeding) Cyan's, in order to be a compatible with Cyan's datafiles (and in theory servers, but as I've said before, networking is limited to "get startup working"). I have no interest in breaking this compatibility, though I do plan to add additional functionality as I can.
Unfortunately, the implementation here means PlasmaClient's classes are tied pretty tightly to the engine. Cyan avoids this by passing messages everywhere, so if a particular manager isn't in a particular build, it's no big deal. PlasmaClient uses direct access to those manager classes whenever possible, so splitting off the code into a more complete library isn't going to happen anytime soon. My way is, however, much more efficient - that's the sort of tradeoff you have to look at when designing these things.
libHSPlasma and PlasmaClient are both GPL, so you're welcome to make a new project and borrow whatever bits of classes and implementations you need for your project, create bindings to new languages (libHSPlasma has python bindings already, for example), or even fork them and add, change, or remove functionality in your fork... as long as you share your code too. I don't think that's too much to ask given how much effort we've all put in to libHSPlasma, PlasmaClient, and the other public tools and utilities.
_________________ MOULagain KI #: 66990
When I was your age, we rocket-jumped up hill both ways in boiling lava.
|