Subject: [mmox] Google Protocol Buffers as MXP extension mechanism

From: Tommi Laukkanen <[email-masked]>
Date: Sat, 28 Feb 2009 10:34:29 +0200

We have applied Hurlimans Google protocol buffers suggestion succesfully in
MXP OpenSimulator adoption effort. XML was switched to Google Protocol
Buffers to gain easier data manipulation and in wire efficiency. You can
read about MXP extension mechanism here:

http://www.bubblecloud.org/msd

The open simulator specific Google Protocol Buffers schema can be viewed
here:

http://www.bubblecloud.org/msd/-/wiki/mxml/Open%20Metaverse

The work is in process and but the general idea can be easily seen.

After using this approach I can report that it is very much practical
engineering solution without immediate shortcomings. My opinion is now that
XML is suitable for HTTP related messaging due to lower performance
requirements but for real time state synchronisation I recommend binary
encoding on all layers according to the idea of Google Protocol Buffers.
Google Protocol Buffers generated message specific value objects are
convenient to use compared to for example DOM tree. The binary encoding /
decoding of GPB beats in performance SAX/DOM parsers.

I find Stefan Anderssons vision of encoding world content with different
parametrisation schemes to MXP extensions very intriguing. For example
objects could be parametrised the way SL does primitives or they could
contain reference to 3d mesh which can be downloaded from asset server. As
stefan argued to me the other day all these different schemes are needed and
will continue to exist. The situation is analogous to web with many kind of
image formats counting in both bitmap and vector image types.

best regards,
Tommi Laukkanen

---

From: Morgaine <[email-masked]>
Date: Sat, 28 Feb 2009 10:53:57 +0000

Tommi, the practical engineer in me supports your perspective on this
completely.  Whatever higher levels of abstraction are used to make the
design, management and evolution of a system more effective, at runtime the
controlling metric is efficiency (correctness being an implicit requirement
and not a metric).

The measure of our success or failure will be whether we can reconcile the
requirements at the highest and lowest levels of our work while still being
helpful to very diverse worlds.  I think that we can, because I see that
LLSD with its separation of IDL, ADT and serializations has taken a good
stab at it already.

Improving on the model of LLSD is what we've already started to discuss
here, and I think we're making very effective progress.   Your work in
Opensim provides a sterling example of a viable direction for us to take.  I
would be very interested to hear how the upper levels of your scheme work,
to avoid world programming being coupled to chosen serialization.

Morgaine.

On Sat, Feb 28, 2009 at 8:34 AM, Tommi Laukkanen <
[email-masked]> wrote:

> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>
>