[Verse-dev] Bitmap layer ids

[Emil Brink]

On Tue, 17 Aug 2004, Marcus Hoffmann wrote:

> Emil wrote:
> > > And another thing: What if a second user that is creating offline a
> geometry
> > > using first his internal client IDs. Then he starts to upload the hole
> > > scene. And he has one or more layers with his internal IDs that
> correspond
> > > to IDs on the server.......
> >
> > 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.
>
> If you think this scenario to the end this will lead to the point, that
> every client HAS to get the hole server world first!

Theoretically, yes. But since it's almost always OK to just assume
that the top part of the ID space is unused, i.e. that the node
doesn't actually contain more than 65,000 layers, Eskil's method of
using ~0, ~1 etc works in practice with the reference server.

*I* sure agree that this is ugly, and would greatly prefer a
known-invalid ID, as stated several times.

> Then it has to parse all the ids it got from the server, and
> finally the client has to change its offline-created ids so that no
> ID exists twice.

Well... I guess that's one way of doing it, but it's easier to just
use a dynamic mapping, so that the content-creating client maps its
local layer to whatever actual numerical ID got assigned to it by the
server. This is fairly easy, in my experience.

> After all that processing it loads its new nodes up to the server
> and the server has to look for every new id sent with the create
> command if this id is still existing in the system, becaus we could
> have a change request and not a create request.

For every addressed object, the server needs to look it up to see if
it exists, that in itself should be a very cheap operation.

> And then you talk about realtime? Imagine the server runs 3 days
> and 50 people loaded 100000 or more nodes to the server..... And
> now every one who's connecting has to parse these 100000 ids... and
> me as server while getting the upload too - so we do the same
> lookup on client and server!

Well, again assuming that the top of the numerical space is not
used, you don't need to have the server's contents in order to create
a new layer.

When this assumption doesn't hold, however, you do. Eskil seems to
often take a "that's not going to happen" view of this situation,
which can annoy me a bit... Again, I would greatly prefer if this was
resolved by simply reserving an ID.

> This all could be avoided if the create command just creates... then any
> client could give me ids as it wants - even if they all would be 0 - i would
> create one valid ID on the server and send it back to the client and thats
> it! No time wasting searches - not at the server and not at the client.

Well. The number of actual creation calls is almost insignificant
when compared to the content-setting calls, for which the server
needs to do the very same kind of lookup, so I'm starting to fail to
see the point here.

> I agree with thorsten that its not a big deal to introduce a change
> command... then it can be simply integrated and these two operations would
> be separated. This is not about changing the verse system, just improving it
> for easier use and maybe better performance!

True. It would, however, add quite a few new commands, and the 8-bit
command space is a limited resource. Granted, there is still room to
spare so I guess this is not a very poweful argument.

> We are in an early state of development, so better do such
> discussions now and solve it then in 1 year...

It's all relative, I guess. The Verse protocol is roughly five years
old, although the current implementation ("Verse2") is younger of
course, and there have been significant changes from the old days.

Oh well.

/Emil