[Verse-dev] Connection phase in the spec

[Emil Brink]

Daniel Bünzli wrote:
> Hello,
> 
> I'm sorry but I see I won't find the time to read the spec in details 
> any soon.
> 
> These are some notes I started, you may find them useful.

Absolutely, thanks a lot!

> o Data model.
> The geometry model should be defined more precisely. While I agree with 
> the notion of best effort _rendering_, I think all clients should have 
> the same _spatial_ interpretation of geometry (e.g. this would be 
> essential for CAD applications). Thus a precise algorithm (or a 
> reference to) should be given to define the way subdivision and creasing 
> is done. This would guarantee that surfaces are understood the same way 
> by every client.

Yes, I agree. The problem for me as the spec author, I guess is simply that
I'm not educated enough when it comes to subdivision. I have never attempted
to implement it myself. The algorithm we use is Catmull-Clark with creases,
which is fairly standardized I think. For instance RenderMan supports it,
although Verse's requirements of the algorithm might be a bit more specific
since we require *many* levels of creasing, not just smooth or sharp. This
is, as far as I've understood, an optional feature in RenderMan.

> o Resend mechanism.
> I find it conceptually unclean the fact that ack and nack are commands. 
> This should be properly layered. The resend mechanism is something that 
> is orthogonal to the stream of commands provided to the application. The 
> formulation is even absurd since if ack and nack are really commands you 
> put them in the command history and end up acking the acks which results 
> in an infinite exchange of messages even though no worthfull information 
> is exchanged. The comment in description of the command is suspect in 
> itself : "It is not exposed in the reference API, but instead handled 
> under the hood for the application programmer."

Well, they are commands technically, but they are handled very specially.
I'm pretty sure (again, this is an area that Eskil really knows best) they
are not put in the history system. Also, a *certain* amount of "ping-pong"
is desirable, since it keeps the connection from timing out. This is, as
far as I know, a designed-in behaviour though, and uses a timer to only send
a packet once every few seconds or something (real ack/nak resend is done as
quickly as possible, of course).

Perhaps the spec is wrong to talk about these as being commands, since it
is (obviously) confusing. Or perhaps it's just not well enough written. :/
There's little concrete I can do about this at the moment, sorry.

> o Event compression.
> Why call this "event" compression ? It is the only place in the spec 
> were you use this terminology, command compression seems fine to me.

Good question. I believe the term was picked up from an external source,
that when we described the way commands are optimized out said "aha, you
do event compression". The term then stuck with us (this was ~5 years ago,
or something like that). Perhaps it should be changed, I don't have any
strong feelings about it myself. Eskil?

> o Packet format.
> It should be clearly stated that a command cannot be split in two packets.

Nothing can be split into two packets, since doing so introduces latency.
But sure, perhaps it should be clearer. Fixed by adding a paragraph to
section 3.5.2. I will try to get a new build of the spec published during
the day.

> o Tags.
> The supported types for tags seem artificial to me. Why can I store a 3d 
> vector but not 4d one or a matrix ? Why is this different from object 
> node method parameter types ?

Yes, this is slightly annoying, since it effectively means we have two
of the same thing (type enumerations). I'm not sure why it ended up like
that, really. Care to comment, Eskil?

> o string16
> This is too short. E.g. I cannot even use my email address as a 
> username. Japanese and chinese in utf-8 takes 3 bytes per code point.

I would agree, it is rather short. Eskil?

> o Text node.
> I would replace this by a general purpose blob node with a mime type.

Oh? Hm ... Hadn't thought about that, but I guess it could be useful of
course. I think we kind of favor text since it's more human-readable and
less opaque. Any change here would have to be cleared by Eskil.

Regards,

/Emil