[Verse-dev] Bitmap layer ids

[Emil Brink]

[semantics of "create"]
> The rules in my mind are very simple, they are:
>
> 1: If the server receives command that creates data in an unused id (and
> is not a polygon or vertex id). it picks the lowest possible id and
> creates the data (node, layer, bone, fragment, buffer or what ever).

Is this something that should be in the spec using words to that
effect? I mean, is it a specified requirement of a server that IDs
are always picked to be as numerically low as possible? This has not
been my impression so far, and if it is I really think it must be
mentioned.

> 2: if the server receives a command that creates a new polygon or vertex
> in an unused id if the id is LOWER then the highest existing poly/vertex
> id + x (in my implementation x = 8192) it creates that vertex poly and
> gives it the user assigned id.

The number 8,192 here is very arbitrary. I was not aware of the
"window", and it seems to have been 256 in recent code (still is, in
CVS).

It feels kind of problematic, since this limit controls how many
vertex/polygon creations can be sent "ahead", but is not known by
clients.

Should the number be a hard specification, so clients can rely on it?
Or should it be somehow possible to ask a server what its geometry
creation window size is? Or something? It doesn't feel quite right to
just have a magic number in there...

> 3: if the server receives a command that creates a new polygon or vertex
> in an unused id if the id is HIGHER then the highest existing
> poly/vertex id + x (in my implementation x = 8192) it ignores the command.

Right.

> 4: if the server receives a command using ids referencing to already
> existing data, the command modifys the  existing state. If the change
> changes the type of under lying data that is cleared. (if you change the
> type of a geometry layer, the layer data is cleared)

Is changing the type of a node a supported operation?

*Reads reference server code*.

Nope, doesn't look like it... Should it be?

> Due to the rules 1 and 4 it makes sense to create data using ids that
> the user is sure the server wont pick as layer ids.

Yes, but one can't be "sure" about the numbers, even if using IDs
from the top. It's rather easy to fool it, and I personally would
much prefer something a bit more robust.

This goes back to my first message about invalid IDs; I would love it
if the event compression code could somehow recognize that some value
of the ID, it might be 0 or it might be ~0, is not equal to any other
value of the ID, including the value itself of course.

This would change the semantics to mean "a create sent with id ~0 is
always a create, and never needs to look for an existing node/layer/
buffer/fragment" before doing the create.

Regards,

/Emil