On Thursday 15 March 2007 16:10, Tim Ansell wrote: > On Thu, 2007-03-15 at 00:17 +1300, Lee Begg wrote: > > Just a few issues and suggestions.
> > 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).
It doesn't change that. It changes that ID Sequences can have non-existant
objects in it without any indication that this is the case.
> 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?
It gives the client an idea whether all the IDs are current and valid or not
(without remembering the Get 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.
>
> System?
Something like:
0x0F<x><x> (bytes in hex)
The first hex is the position/group (some are defined as mutually exclusive)
The second hex is the number of the filter.
For example:
- 0x0F01 - SSL
- 0x0F31 - gzip compression
- 0x0F32 - bzip2 compression
- 0x0F33 - zip compression
- 0x0F61 - String alignment padding
- 0x0F62 - Oversize frame reporting
(Odd position/group mutually exclusive)
Make sense? Just a way of defining the feature ids with some useful pattern.
> > 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?
If you have objects with two (or more) queues, what id do you put on the later
one? How do you leave enough space (id numbers) for future object's queues?
> > 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.
I meant ... well let's take the example:
(object description)
3, "Production", "Current production capabilities of the planet."
- GRAPH, [], "Workers", "The number of workers in factories",
Linear, "Workers",
Linear, "Production Points per Factory",
[[0,0], [10,5], [20, 7], [30, 8], [40, 9], [50, 10]]
Those points are common to *all* planets. I don't think that was the idea.
> > 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?
A suggestion might be:
<byte position type>
if the position type is 0 then three 64 bit ints follow for free space,
otherwise it's bound.
Just a suggestion.
> > Later
> > Lee
>
> Tim Ansell
Later
Lee
pgpub97kjimdK.pgp
Description: PGP signature
_______________________________________________ tp-devel mailing list [email protected] http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
