Tim Ansell pisze: > Okay, this email is going to be a bit long as it is going to cover a lot > of your stuff. > > Could you push your changes to the document repository to a branch? This > would let us see your changes easier.
Ah, branches, forgot about them ;) Let's see how it works... > --- > > Firstly, some rational about my thoughts, > > TP04 does not need any "extra" objects file as the objects are > dynamically defined by the server in the same way orders are. > > As TP03 has no way to define objects dynamically it needs a static way > to define them. Static object descriptions only effects TP03. > > As we had always planned dynamic object description we decided to split > the protocol definition documents into to separate files (protocol3.php > and objects.php). > > Hence, I don't believe that actual object descriptions belong in > protocol*.xml files. This makes sense. My rationale is that TP03 objects separated create a special case and I'd like to avoid that. It is possible to define objects in TP03 as "parameters", so I used this possibility :) > ---- > > Next, I think that the way object and order descriptions work should be > very similar (as it allows us to write once for both cases). How does > this description stuff work? Well you can think of it in "object > orientated" sense. They are both "parameters", so if I make code generation for parameters, both object and order descriptions are done... > Object (or order) descriptions are the equivalent of "classes" and > actual objects (or orders) are the equivalent of "instances". > > The classes are defined at the server. So for a client to be able to > understand what information the instances contains, they have to ask the > server for class definition - this is what OrderDesc and ObjectDesc > frames are. As you noted before, this is fine for dynamic languages (to dynamically create a class), but isn't that easy in Java (I believe it could be done by some classloader magic, but I don't want to go there... *shudder*) > ---- > (snip) > > ObjectDesc objects would then have a vector of ParameterBase's while > Objects would have a reference to ObjectDesc vector of > ParameterInstance's. I'm a little slow today, it seems, but I *think* I'm doing something like this, with some variations. First of all, the generator can't know from the XML alone that OrderDesc/ObjectDesc frames are "special". They are treated just like any other frame; list and group properties are converted to a List of static inner types and so on. The usual stuff. Now there's the Order frame, which only has an id of this "custom class". Prior knowledge of structure of this class is necessary, but not readily available. So in code generated by my generator I just suck in the bytes to an array (they're always at the end so I can take everything until the end of frame) and decode it later, in a getter method (which has a "template" parameter which is an OrderDesc/ObjectDesc frame). That's why I said it "requires user intervention" - to get this *Desc frame :) And the description in a typefield attribute tells the generator how to get parameter ids from thise *Desc frames. The result is something like you described... I don't know how it'll work in practice, because I'm not planning to write a full TP client in Java, infortunately ;) I'll push the documents and libtpproto-java repositories in a moment. -- KS "To an engineer, everyone looks like a chimp" - Dilbert
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
