On Sun, 2007-09-16 at 15:29 +0200, Krzysztof Sobolewski wrote: > 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...
Seems you have pushed successfully to the "experimental" branch. > <snip> > > 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 :) Well in my mind they are not a special case. In tp04 the objects are defined by the server (not in the protocol.xml) hence to be consistent the tp03 objects should be defined elsewhere. <snip> > > 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*) It also works okay with non-dynamic languages. You just need to build the instances out of other instances instead of out of real classes. > > 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. The OrderDesc/ObjectDesc frames are not really the "special" ones. It is the Object/Order frames which are special ones as they are describe by other frames rather then the XML. The XML says these frames are special through the use of <*parameter /> tag. > 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). Yes, this is fairly similar to what libtpproto-py does. When it doesn't have an order/object description, it stores the data away until the description has been received and then is able to decode it. > 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 these *Desc frames. I'm not sure I understand. > The result is something like you described... Oh? > I don't know how it'll work in practice, because I'm not planning to write a > full TP client in Java, infortunately ;) Well, you will need to be able to decode objects if you want to do some more fancy mapping. > I'll push the documents and libtpproto-java repositories in a moment. Still waiting on the libtpproto-java :) Mithro _______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
