Re: [vwrap] [ogpx] Notes from my parts of the VWRAP session

[David W Levine <[e-mail]>]

Lugging over manually from the ogpx list...

> [image removed] 
> 
> [ogpx] Notes from my parts of the VWRAP session
> 
> Mark Lentczner 
> 
> to:
> 
> ogpx
> 
> 03/24/2010 12:13 PM
> 
> Sent by:
> 
> [e-mail]
> 
> This is what I heard from the community during the face-to-face 
> about the issues I brought up. Most items seemed to have general 
> consensus and understanding, and I will amend the drafts 
> appropriately. A few items needed group input, and those have been 
> marked with double asterisks (**).
> 
> VWRAP Type System Issues
[snip]
> 
> **6) There didn't appear to be clear consensus on if LLIDL needed an
> "event-like" resource type. These would be resources that had a body
> with the request, but expected nothing other than confirmation of 
> receipt in the response.
> 

I have been letting this one sit in my head for a little while. There 
is a clear need for us to describe "events." they are at the heart of 
how regions and clients interact. The problem with events is they 
are messy, especially at he level of an IDL. One could clearly want
to annotate event like messages say (grossly simplifying) 
"Graphical object <uri> is at X,Y,Z moving with a vector of X1,Y1,Z1 
at timestep t0" Indeed it would be quite natural to post such a 
message on a client, as an event.  We don't need an ack, and if 
our events are designed to be nicely idempotent we're pretty
happy. 

My concern is the next level out in description. When can this 
event be expected? Can I discard such events? I'd argue
that "events" imply something dangerously close to a full up notification
framework. Effectively, when a client rezzes an avatar into a region 
on behalf of it's user agent, its subscribing to a set of event sources
and will receive a stream of events and messages. If we're going to allow
nicely diverse clients with different desires as to what they want to 
know about (And do some form of negotiation about what should be sent down
to client) we're now trying to describe not just the single event, but
the context in which the event is expected. 

LLIDL at the moment is purely about the messages a resource can emit
and accept. There's really nothing in LLIDL about the interaction
patterns which combine these messages into services. If we're 
comfortable with events as an obvious extension to that model, and
no more, then it probably makes sense to add the simple events to the
LLIDL notation. If we think that events only make sense in the context
of interaction patterns, then I think it might make more sense to 
do the heavy lifting of starting to describe interaction patterns
and include events as part of that effort. 

I'm leaning to saying "Keep LLIDL simple" and adding the simple event
messages. We can then stick to prose for describing interaction
patterns. I suspect that UML sequence diagrams annotated with LLIDL
in that form and a concise prose description would make for a good
crisp description of the interfaces, and any LLIDL like notation
we would come up with in place of such description 
would be more trouble than it's worth. 

Thoughts? Comments? Brickbats through the window?

- David
~ Zha



[snip]
> 
> - Mark
> 

> Mark Lentczner
> Sr. Systems Architect
> Technology Integration
> Linden Lab
> 
> [e-mail]
> 
> Zero Linden
> [e-mail]
>