On Thu, 2007-03-15 at 00:17 +1300, Lee Begg wrote: > Just a few issues and suggestions. > > I have already emailed about the long name/short name issue in the > meta (location) protocol.
Fixed. > Changes to Get ID Sequence base frame > > This change drastically changes the way these frames work. Also the symmetry > between what is sent and what is received is broken (the receiver has to > remember whether there are deleted objects in the list or not). I'm not sure > if it's worth adding extra frame types for the new change list fetch frames, > or just to add the timestamp to the ID Sequence frame. I'm not quite sure how it's changing how frames work? The protocol has always been a "request -> response" (with a few extra async frames). The fact that once the client sends off the Get ID Sequence it is already in a totally different code path. When sending with a "changes from" time, it is doing an "update" of an existing cache of the universe. When sending without a "changes from" time, it is doing a full universe download. I can't see what changing the ID Sequence frame gives? > Filter Negotiation "inner/outer most" > > The filter negotiation description sounds fine. Can I suggest that it's > reasonably obvious the order of the filters (SSL has to be the closest to the > network, string alignment furtherest.) Here is a list of all the filters I > can think of: > - SSL (TLS) > - compression (many, mutually exclusive) > - string alignment/padding > By setting the feature id's with some system it should be obvious which > class/location the filter is in. Please add any other filters you can think > of. System? > Object Parametrisation/Last seen - Default order queue id > > The Default order queue will only be used as a transition mechanism. A client > implementing should not assume that the default order queue has the same id > as the object. I think it should be permanently this way. Is there any reason not to do this? > Async Frames > > I would rather have a set list too! Is a list really necessary? What would be the reason for needing one? > Object Common Fields > > Your list is fine by me. Nash had suggested having a "parent" field for the > object that contains the current one. Will reply in his thread. > Object Descriptions > > Keep in mind that descriptions are per object *type* not per object (check > the > note explaining groups). A list of a list could get interesting, > particularly since the inner list is variable size (and potentally has > another list inside it?) Both objects and object descriptions have a description field. I've made the titles in the document a little bit clearer to see if that is what is causing the confusion. > Position Object Parameter Type > > The current description only allows an object to be free or bound and not > change between them. I think we will need to be able to do that... Can you think of a good way to do this? > Fail Frame > > Nash mentioned that he finds the current fail frame too limiting. Maybe > adding > a list of GRS (General Reference System) references might help? Another > (maybe even two) failure codes might be needed for filter negotiation. This is why the Fail Frame is in the modified list. Just yet to describe it. Should be in their nowish... > Just some ideas. I'm sure more will come. Research/technology is a big thing > to be looked at too. Yes. I don't think it's as big as we think it is. The biggest problem is describing the tech tree - IE the dependencies, anti-dependencies, etc. > Later > Lee Tim Ansell _______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
