Re: [vwrap] thinking about LLIDL and the future

[Morgaine <[e-mail]>]

I agree with the main thrust of Meadhbh's proposal.

Defining the "Method Access Delimeters" of LLIDL resources in terms of HTTP
operations directly was not generic nor forward looking.  The type system
draft uses highly HTTP-centric language in the LLIDL section, for example: "
*A LLIDL "Resource" represents information or state maintained by a remote
system, accessed via HTTP(S).*"  Clearly this is wrong, if our intention is
to be transport-agnostic.

Likewise, defining the "Method Access Delimeters" of LLIDL in terms of HTTP
operations was quite wrong, not to mention that it gave us rather ugly
syntax too ("<>" for GET/PUT, "<x>" for GET/PUT/DELETE, and "->" and "<-"
for POST).  If we're putting LLIDL resources on a sounder,
transport-agnostic footing, this is a good opportunity for cleaning up the
syntax while we're at it, and making it more flexible.

I support the suggestion that we define the 4 CRUD "abstract verbs" CREATE,
READ, UPDATE and DELETE as terminals in the LLIDL grammar.  This is highly
readable, and it is also semantically clean because CRUD operations are
disjoint.  Note that in client-server protocols, each CRUD operation is
usually implemented as two messages, a request message and a response
message --- this is relevant below.

The proposed 5th verb "EVENT" is more problematic, and I think it's actually
incorrect, as it seems to have confused the concepts of "verb" and
"message".  The reality is that messages received outside of a 2-part
synchronous request-response pair usually carry some kind of type
information that activates an operation handler at the receiving end.  Such
operation is enabled by a prior CRUD verb that sets up the session to allow
asynchronous messages to be sent and received subsequently.  In other words,
EVENT isn't a verb or operation at all, it's an asynchronous response
message to a prior verb.

This is the situation as I see it:  VW protocols are almost always
message-based, and they are almost always request-response in nature but the
"response" can comprise an unlimited sequence of response messages, zero or
more.  The reason I see it this way is that a truly unsolicited message is
actually spam, or worse, an attack packet.  All other messages (including
asynchronous ones) *were* solicited by some previous request which enabled
the sending of asynchronous messages in the first place.

This is why I don't see "EVENT" as a resource operation.  It's a deferred
response message that was emitted after being enabled by some previous CRUD
request, and it carries data in response to one of the 4 CRUD operations
within it, either implicitly or explicitly.

As an example, a client should not receive scenegraph update messages unless
it has first requested them using a CRUD verb on the appropriate region
resource(s).  Once it has requested them, they become valid and are
processed by the client scenegraph handlers, but if it has not requested
them then they are invalid and should never be sent nor received.  Indeed,
if they *are* received without being requested then they should be processed
by the error handler.  In a text-only client for example, there probably
wouldn't even be any scenegraph handlers present in the code.

"EVENT" then is not itself a verb that acts on resources.  It's an
asynchronous response message, part of a sequence of zero or more such
messages, and this potentially unlimited sequence of messages is started by
one CRUD operation and stopped by another CRUD operation.

Notice that the EVENT message can also be a container for CRUD request
messages in the reverse direction, but even such container messages obey the
above rule that they are started by one CRUD verb and stopped by another.

In summary, EVENT is not a resource verb  but an *asynchronous transport
property* of a resource, and if that property is enabled by a CRUD
operation, then EVENT messages are emitted under control of that resource.

Apart from EVENT, I think that this is a great proposal.  Regarding EVENT, I
suggest that we analyze this area further and find a clean way of
integrating EVENTS into our resources-based scheme.  I'm very interested in
this topic.


Morgaine.





=================================

On Thu, Jul 15, 2010 at 10:01 PM, Meadhbh Hamrick <[e-mail]>wrote;wrote:

> 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]
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>