[Verse-dev] Bitmap layer ids

[Eskil Steenberg]

Hi

>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.
>  
>
Yes there should be some thing about this in the spec. but i think that 
lowest possible is a little hard. It should be low, i dont know how low 
but perhaps not higher then twice the number of existing ids, or 
something like that.

(a scenario with big gaps can still occur since people can delete 
layers, o having a stringent rules that clients can cont on is not very 
useful. What the spec should intend to mean is: storing your data in 
arrays is a good idea because the the host will attempt to peep it 
reasonably short.)

>  
>
>>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).
>  
>
No its not very arbitrary, its twice the number of the send slots. this 
would minimize the risk of loss due to packet loss.

>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...
>
>  
>
Let me think about how this should be expressed in the spec.

>Is changing the type of a node a supported operation?
>
>*Reads reference server code*.
>
>Nope, doesn't look like it... Should it be?
>  
>
Yes and no. The server doesnt have to, but a client does.

If a node id is deleted and the re-used quickly. the two comands may 
come out of order so the client must be able to handle this. (humm 
perhaps someting i should fix in enough...)

>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.
>  
>
We defenetly agree that a reserved id is something we need. how about 
reserving the last 16 or 256 ids? then -2, -3 wont be a problem either 
even if one has many many layers?

E