Subject: [mmox] LLSD, VWSD and MMOP

From: Catherine Pfeffer <[email-masked]>
Date: Thu, 12 Feb 2009 15:53:10 +0100

> Indeed, if LL is willing to update LLSD regularly with every new data type
> that we require, this situation could continue indefinitely, ie. LLSD
always
> defining the low-level bits in an application-agnostic manner.

Ah OK, now I understand what you meant.

I'm quite confident that, with the introduction of more scalar types,
apparition of new species (Hi, Darwin!) of data types would stop there.
After all, Second Life works rather well currently with the reduced set of
data types that is currently in LLSD.

And even if more data types appear to be necessary later on (hum, like a
date and time elementary format), there's nothing wrong with going back
to xxSD draft and adding provision for the missing data type. As long as it
is a draft, nothing is engraved into stone and it is okay that xxSD and
whatever is built on top of it enrich themselves mutually.

But what you propose is okay too. It's just a different way of organizing
the standard. Personally I prefer something a bit simpler, like the current
draft, that's all.

-- 
Cathy

---

From: Morgaine Dinova <[email-masked]>
Date: Thu, 12 Feb 2009 15:41:27 +0000

> the standard. Personally I prefer something a bit simpler, like the current

Well I was just trying to find a way for us to move forward.

LLSD is in production use in Second Life, so LL wants to keep its name on
LLSD and to be in control of the LLSD spec, which is natural.
Unfortunately, we in MMOX need the flexibility to modify our foundational
ADT, which we cannot do if LL controls it.  So I was trying to find a happy
medium in which LL can still control their RFC spec (not a MMOX standard)
while we put everything that deviates from it into VWSD.

It's not ideal, but I was just trying to live within the current situation.

Fortunately that separation is quite nice (and can be justified as a
technical decision) if VWSD contains only the mappings from VW data to LLSD
data.

Morgaine.