Re: [mmox] LLIDL or schemas?

[Veikko Eeva <[e-mail]>]

> Jon said:
>  > I propose that the data structure
>  > definition language be moved to some XML schema.
> 
> Yes, LLIDL makes no sense in the XML world, where there are schemas (or 
> DTDs) for that.
> 
> That's another example of technical compromise needed by this "three 
> serializations" scheme.
> 
> My suggestion would be: "do only one serialization, but do it well"...
>  - If XML has an angle bracket tax that is too expensive to pay, 
> especially on limited capability devices, then let's stick to a binary 
> format only.
>  - If XML is the way to go because it's more flexible, human-readable, 
> and because there's already a bunch of tools for it, then go for it 
> only, but do it using all the possibilities of the XML technology.
> 
> My opinion is that doing an 1:1 transposition of a binary format is just 
> like automatically translating French into English word per word, it 
> gives bad (although sometimes really funny) results.
> 
> Anyhow, who is asking for a choice between three serializations? Is 
> there a use case for that?
> 
> Don't take it bad, Infinity. I'm just trying to put my engineering 
> knowledge at the service of realistic and long-term decisions, not to 
> destroy Linden Lab's vision of the future.

I joined the list just recently and I haven't read through all the messages in 
detail, so forgive me if this issues has been handled already... But is there 
an issue concerning (efficient) protocol encoding between prospective current 
and future virtual worlds?

 From an engineering stand-point I'd say the issue in this case is pretty much 
that we don't know what kind of fields are there needed in the protocol. So, in 
order to alleviate that, a more dynamic, expandable approach would be good. And 
we are in luck, since such protocols have been devised in the past and there 
are plenty of parsers and libraries to use. One such approach is TLV encoded 
messages (http://en.wikipedia.org/wiki/Type-length-value) that allow to carry 
both binary and XML data and allow addition of new and even proprietary fields 
with no problems.

Mandating an XML-based protocol feels grossly inefficient (if not a general TLV 
solution being one already) that drops probably all game-like soft realtime 
applications out of reach. What comes to parsing in general, if someone is good 
enough to define the protocol in some sensible fashion, i.e. formal manner 
(EBNF, Schema, SDL etc.), there are automatic tools and libraries to create the 
needed code. Or even something like Google Protocol Buffers ("think XML, but 
smaller, faster, and simpler", 
http://code.google.com/intl/fi/apis/protocolbuffers/)

So, I would say the "transport protocol" issue seems to be a solved one. We 
should just pick the most efficient one that allows expanding the pay-load, 
like TLV. Instead the focus should be what those fields should be. That is, 
there should focus on the content of the protocol: property rights and all 
things like that. Even the actual type of transferred resources can be agreed 
on later, e.g. if all content should be COLLADA 
(http://en.wikipedia.org/wiki/COLLADA) and SVG or something.

If the issues is synchronising real-time actions between worlds, I strongly 
suspect it shall not work. Games and simulations use prediction and all kinds 
of protocol gimmicks in order to sustain immersion. The most plausible approach 
to take would that there's a handshaking phase in agreeing a common approach 
(e.g. High Level Architecture (HLA)) that will take place. But this is 
something I believe cannot be decided here and now.


Engineering thoughts cordially,
Veikko E.