Subject: [mmox] Third and last proposal for LLSD draft

From: Catherine Pfeffer <[email-masked]>
Date: Wed, 11 Feb 2009 11:54:47 +0100

Hi all,

Someone asked "Why should LLIDL be described in a separate document ?"

I'm relaying this question here.

Best,

P.S. in my messages, xxSD means "LLSD with a more vendor-neutral name, like
VWSD".

-- 
Catherine Pfeffer

---

From: Imaze Rhiano <[email-masked]>
Date: Wed, 11 Feb 2009 16:40:27 +0200

Hi!

Actually LLIDL is same document, but in different chapters and currently 
they seem to be separated entities - or LLIDL is sub-entity of LLSD. 
LLSD/xxSD/xxxx is currently just defining 11 types and conversions 
between types. Then in another chapter is described how LLSD data is 
serialized by LLIDL. Wouldn't it be more logical to combine these 
separated entities under single "simple abstract datatype and interface 
defination" language? I understand that one reason is that LLIDL is 
currently strongly coupled with RESTful architecture, but wouldn't it 
possible to expand it bit and allow it to be more architecture 
independent? For example by adding "component" concept:

     component assets_server
     {
         -> asset_request <- asset_response
         -> asset <- asset_id
     }

or maybe even:

     component assets_server
     {
          asset_response request_asset( asset_request );
          asset_id new_asset( asset );
     }

same as:

     %% assets_server -> asset_request <- asset_response
     %% assets_server -> asset <- asset_id

I support Catherine's idea to have more virtual world oriented language. 
There should have - no must have common defination for 2D/3D vectors, 
rotations, meshes, animations and textures.Thought, these could also be 
separated extension for LLSD/xxxx.

Whatever language we are going to use - and whatever we are going to 
call it - it is going to minor detail in big plan. Should we start 
slowly moving away from LLSD/xxxx and talk about scope of the MMOX - 
identify objects, components and interactions between VWs?

My 0.015447594 Euros :)

Catherine Pfeffer kirjoitti:
> P.S. in my messages, xxSD means "LLSD with a more vendor-neutral name, 
> like VWSD".
>
> -- 
> Catherine Pfeffer
> ------------------------------------------------------------------------
>
> _______________________________________________
> mmox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmox
>

---

From: Meadhbh Hamrick <[email-masked]>
Date: Wed, 11 Feb 2009 09:38:15 -0800

LLSD is envisioned as an abstract type system that happens to be used by 
some people developing virtual worlds protocols. (the authors generally 
think of LLIDL as being part of the LLSD type system... so sometimes 
you'll hear us refer to both the LLSD abstract type system and LLIDL 
using the term LLSD.)

the idea for separating it out into it's own document is we wanted to 
define LLSD independent of any virtual world protocol. OGP was always 
conceived of as being an "application layer protocol." that is... it is 
the protocol that two applications (like a space server and a simulator) 
speak to each other (not that we would want to enforce the concept of a 
space server as being distinct from a simulator, but it's just an 
example.) in the distant future there may be a time when someone would 
want to exchange OGP application layer protocol over different 
transports (like XMPP or even IIOP or BEEP or SMTP or carrier pigeon.) 
separating LLSD into it's own document makes this a lot easier.

and yes.. you're free to create your own specification (VWSD) that 
includes concepts from LLSD or even references LLSD but adds the 
component language.

-cheers
-meadhbh

Imaze Rhiano wrote:
> Hi!
>
> Actually LLIDL is same document, but in different chapters and 
> currently they seem to be separated entities - or LLIDL is sub-entity 
> of LLSD. LLSD/xxSD/xxxx is currently just defining 11 types and 
> conversions between types. Then in another chapter is described how 
> LLSD data is serialized by LLIDL. Wouldn't it be more logical to 
> combine these separated entities under single "simple abstract 
> datatype and interface defination" language? I understand that one 
> reason is that LLIDL is currently strongly coupled with RESTful 
> architecture, but wouldn't it possible to expand it bit and allow it 
> to be more architecture independent? For example by adding "component" 
> concept:
>
>     component assets_server
>     {
> I support Catherine's idea to have more virtual world oriented 
> language. There should have - no must have common defination for 2D/3D 
> vectors, rotations, meshes, animations and textures.Thought, these 
> could also be separated extension for LLSD/xxxx.
>
>> P.S. in my messages, xxSD means "LLSD with a more vendor-neutral 
>> name, like VWSD".
>>
>> -- 
>> Catherine Pfeffer

---

From: Mark Lentczner <[email-masked]>
Date: Wed, 11 Feb 2009 09:22:13 -0800

There are admittedly three distinct things in the draft, but I believe  
they are so closely related that they should remain together:

1) An abstract type system, called LLSD, which defines the data  
semantics and conversions so that when an API defines something like  
"has a string and an integer as arguments, and returns a bool and an  
array of reals", this has clear meaning even in the face of a variety  
of transports and implementation language choices.

2) Serializations so that communicating systems can pass LLSD typed  
data.

3) A specification language, called LLIDL, so that APIs can be  
specified clearly and concisely, both for humans and software. So the  
API definition above can be stated more precisely as:
	%% some_api
	-> { name: string, depth: int }
	<- { preprocessed: bool, soundings: [ real, ... ] }

Please note that LLIDL does not specify the serialization formats,  
just the abstract interface in terms of the LLSD type system.

I believe it takes all three of these things to ensure that  
interoperating virtual worlds can have a clear contract for what is  
being specified by the interfaces. In other standards, often the  
abstract type system and the serialization are collapsed into the  
definition of the wire protocol, and there is no specification  
language at all. Because we anticipate there being on the order of 200  
APIs needed to create a full virtual world experience, having this  
more formal grounding seems appropriate.

	- Mark

Mark Lentczner
Sr. Systems Architect
Technology Integration
Linden Lab

[email-masked]

Zero Linden
[email-masked]

---

From: Morgaine Dinova <[email-masked]>
Date: Thu, 12 Feb 2009 03:29:05 +0000

On Wed, Feb 11, 2009 at 5:38 PM, Meadhbh Hamrick <[email-masked]>wrote:

> you're free to create your own specification (VWSD) that includes concepts
> from LLSD or even references LLSD but adds the component language.
>

There might be some merit in that.  The relationships might be something
like the following (where "MMOP" is the extensible core protocol created by
MMOX:

1) LLSD: defines a foundational ADT definition and an extensible set of
serializations as used by Linden Lab in SL.  This is general purpose and
independent of any application domain, ie. it does not refer to VW conceps
at all.  (It may need to be extended though, in which case the name might
change.)

2) VWSD: defines the set of ADTs (taken from LLSD[-Extended]) that form the
"universe of discourse" for VW interop.  In other words, VWs communicate by
interchange of these elements of data, and no others.  Most importantly,
VWSD defines how VW-specific concepts are mapped onto the chosen ADTs.

3) MMOP: defines how the data elements described in VWSD are used in the
interop protocol.  This is much higher level than VWSD and introduces many
VW semantic elements, but it defines no new data types and uses the VW-ADT
mappings defined in VWSD.

That seems fairly reasonable.  VWSD would provide a very concise definition
of the data used by VWs (the specific bit definitions would be in LLSD), and
people could still use the generic tools that they've developed for LLSD
since VWSD is just a subset of LLSD with extra mapping information.

Does this sound right?

Morgaine.