[vwrap] thinking about LLIDL and the future

[Meadhbh Hamrick <[e-mail]>]

hey peeps,

i've been pondering LLIDL for a bit now, and there are some things
about it that really stick in my craw. i put together a blog post
about it, but wanted to replicate it here on the list.

from http://blog.meadhbh.org/2010/07/abstract-resource-definitions-vs-llidl.html

so i've been noodling on LLIDL and LLSD for a couple years now, and i
think i've figured something out. i like the concept of an "abstract
resource definition" a lot more than i like an "interface description
language." (if you have no idea what i'm talking about, you may want
to read my previous blog post "VWRAP Essentials : an abstract type
system? hunh?." advanced students can take a look at the internet
draft: draft-ieft-vwrap-type-system-00.)

the background

the objective of the abstract type system is simple and well defined:
it provides system independent type semantics for structured data
developed by protocol designers. that is, it defines types that are
common to popular implementation languages. and it does it in a way
that developers know the details of the types. like whether integers
are 32 or 64 bits and whether radix 10 is supported in floats and so
forth. the LLSD abstract type system describes how a small set of
fundamental types work so implementers know how their "concretized"
implementations should behave. and this is a good thing.

the problem

but after having mulled LLIDL around, i'm starting to see some issues
with it. the main problem i have with it is that the interface is
hopelessly entangled with the resource it describes. that is, you
can't define an abstract resource without defining a method of access.
for example, the current spec describes a way to say something like
this:

&info = {
  name : string,
  status_uri : uri
  enroll_uri : uri
  login_uri : uri
}

%% site_info << &info

in this example, the &info named type describes a structure that
includes a string and three URIs. but the only context you can use the
&info named type in is when you use a HTTP GET to access it. i think
this is wrong.

it's wrong because it links the declaration of the structure of a
resource with the transport used to access it. i have no problem with
accessing resources over HTTP(S), but i do have a problem with ONLY
accessing them over HTTP(S).

i think there's sufficient interest in the VWRAP working group to
support the concept of making resource definition and access
orthogonal. i would personally want to be able to have the option of
using XMPP and (S)RTP when characteristics of those protocols are
advantageous. but i don't want to have to create a new data definition
language every time i want to go access a resource over a new
transport.

furthermore, there are still open questions regarding content
negotiation over HTTP(S). suzy deffeyes, john hurliman and i have
reached a rough consensus on how to handle content negotiation, but we
need to put it in an internet draft so other people can comment on it
and implement it without having to refer to random email archives and
IRC logs.

a proposed solution

i propose we layer an abstract resource definition on top of the
abstract type system. the abstract resource definition can then be
used to describe a transfer syntax (aka serialization scheme) for
resources. we can then describe how each transport (HTTP(S), XMPP,
etc.) carries serialized resource data. we can then describe
interaction semantics independent of resource definition.

the benefit of this is it makes it easier to create systems that are
transport-neutral. some of the lessons we learned from Second Life™
and the Linden Lab Legacy Protocol are that there's a LOT of stuff
that's not "real time" data. I suspect that moving forward, we'll
discover there are a lot of interactions that are modeled with the
request-response pattern. i am proposing a solution that would offer
deployers and protocol designers the ability to describe a resource
without describing the method in which it is accessed.

more details

this proposal describes five components: the abstract type system, the
abstract resource definition, the transfer syntax, the abstract
interaction definition and the transfer mapping.

abstract type system

as mentioned above, the abstract type system defines a core set of
types and type behavior. types are intended to be "concretized" in
programming languages like C, Java, Python, whatever. we create an
"abstract" type system so we're free to define the type behavior we
want while not being tied to type behavior of a particular
implementation language. individual implementers are responsible for
ensuring that type semantics are consistent with the spec.

for example, imagine you were developing an application using an
embedded 8 bit microprocessor and there was a protocol flow that
involved incrementing an integer. a client might send you a 32 bit
integer, assuming you would increment it. you would be responsible for
modeling the behavior of a 32 bit integer despite the fact your
micro-controller probably only natively knows about 16 bit ints.

abstract resource definition

the abstract resource definition is sort of like the abstract type
system for collections. we define a resource as being either an
individual item (a boolean, integer, etc.) or we define it as being a
map or an array. the abstract resource definition system allows
protocol developers to define the "shape" of resources. but because
they are dynamic, implementations must allow for the type of a
resource to differ from it's definition and for elements in map to be
added and removed.

for example, you may want to define the following resource to describe
an user logged into a system:

  RESOURCE agent {
   name string,
   identifier uri,
   current_location uri
 }

the abstract resource definition is used to group named data elements
together into a dynamic structure. these structures will later be used
by the abstract interaction definition.

transfer syntax (aka serialization scheme)

these are basically the three serialization schemes defined in the
type-system draft: XML, JSON and Binary. they define how structured
data is serialized into an octet string in preparation for
transmission across a network. for example, the resource defined above
might be serialized like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE map PUBLIC "+//IDN meadhbh.org//xxdsd 0.1//EN"
"http://home.meadhbh.org/xml/xxdsd/0.1/xxdsd.dtd">
<map>
 <key>name</key>
 <string>Meadhbh Oh</string>
 <key>identifier</key>
 <uri>http://world.secondlife.com/resident/6e7477a7-2de5-4660-bc83-4a47096a18f0</uri>
 <key>current_location</key>
 <uri>http://world.secondlife.com/place/65f385f0-691c-5755-9ef0-15f3bb05c8b7</uri>
</map>

abstract interaction definition

LLIDL currently defines access verb sets that are tied to HTTP verbs.
if we want to be able to access resources using multiple transports,
this is wrong. i propose we define an abstract interaction description
"language" that is later mapped to a particular transport.

i propose we have five "abstract" verbs: CREATE, READ, UPDATE, DELETE
and EVENT. the first four should be pretty straight forward. They're
used to create resources, read and write them and then maybe delete
them. the last verb, EVENT, is used to define a resource an entity may
receive without requesting it. things like object updates, incoming
message session requests, etc.

transport mapping

the transport mapping maps abstract verbs from the abstract
interaction description language to concretized protocol flows in the
transport. so, for instance, you may use this to say that CREATE
abstract access methods map to a POST verb in HTTP or that an EVENT
message is delivered via the HTTP event queue.

conclusion

i'm going to wrap as much of this as i can into an internet draft and
create some example code. but i figured i would get this idea out
there so people can comment on it. just lemme know what you think...

--
meadhbh hamrick * it's pronounced "maeve"
@OhMeadhbh * http://meadhbh.org/ * [e-mail]