Just a few issues and suggestions. I have already emailed about the long name/short name issue in the meta (location) protocol.
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. 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. 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. Async Frames I would rather have a set list too! Object Common Fields Your list is fine by me. Nash had suggested having a "parent" field for the object that contains the current one. 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?) 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... 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. Just some ideas. I'm sure more will come. Research/technology is a big thing to be looked at too. Later Lee
pgppiaFGkaMkp.pgp
Description: PGP signature
_______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
