[Verse-dev] Bitmap layer ids

[Thorsten Jordan]

Emil Brink wrote:
> 
> It seems to work fairly well in Eskil's reference server code, or at
> least the code is not huge or so.
that may be because Eskil's server just transports the commands, while 
Marcus' server also builds up an representation of the scene internally...


>>How will i know the users intention?? What if he wants to create two
>>layers???
> The above example does not include timing information, so it's a bit
> hard to parse. If both commands are to be emitted at once, then the
> client needs to "fool" the event compression system by using differ-
> ent IDs, as mentioned earlier. If the commands happen with "long"
> time inbetween, then event compression won't be a problem and the
> command will act as a rename. This sounds more complicated than it is
> in practice.
well it sounds a bit screwed up to me. If i have to fool up a system of 
the server/API then it is a workaround for an bug, because the system is 
not working properly. Event compression may be a good idea, but not for 
these events. It would help me a lot (and i think i'm not alone here) if 
the API would just not compress create calls, so that the user can 
always choose 0 as node_id and wait for the server to send a valid id back.
If i have to fool the system, the system isn#t designed properly - in my 
eyes.

> Hm.. If you create data intended for Verse offline, then of course
> you must use some kind of mapping scheme between whatever layer IDs
> you need in the static (offline) data and the ones assigned to the
> layers by the server once the data "goes live". The "VNF" simplistic
> file format and loader tool used in Verse1 had a simple name-based
> scheme for this.
this gives an extra layer of difficulty. i have external data with own 
ids (a 3d data file) and just want to get some nodes created by the 
server - but how can i be sure that exactly the number of nodes or 
vertices will be created, when i have to use special schemes to fool the 
system?

> The ID in a layer (or node) creation command that comes from a client
> is used to check if the layer already exists, in which case the
> command becomes a rename (or possibly type-change, depending on the
> node). If it does not exist, then the command is in fact a "true"
> creation, and the server will create the layer and pick a new ID to
> use in the subsequent notification to subscribers of the node.
it is more pain (also for clients) to look if a node already exists, 
that was just named in a received "create"-command than to just create a 
new node then. If create means create, the code would be more uniform. 
And - you mentioned it - a type change would be even worse. I would have 
to search my node storage, and move objects around, because they're now 
of another type - which ends in destructing the node and creating a new 
one. Nothing is lost by introducing seperate commands here - but much to 
win.

-- 
Greetings, Thorsten