Re: [vwrap] thinking about LLIDL and the future

[Morgaine <[e-mail]>]

Considering asynchronous messages to be emitted in response to a CRUD
operation on an appropriate resource fits in perfectly with the notion of
Capabilities though.  They ARE solicited, by a request to a resource.

As in my earlier example of the text-only client, the CRUD operation
UPDATE(scenegraph_updates_capability, ENABLE) was not invoked by the client
(or it was invoked with the argument DISABLE), and hence that resource saves
time and bandwidth by not sending the unwanted scenegraph updates.  If
instead the resource were set to ENABLE, those update messages would
certainly be appearing in response to the ENABLE request, so it's a natural
interpretation.  And of course it's very helpful to have such events
controlled by a capability.

The alternative model in which events are considered normal CRUD operations
on an event queue in the reverse direction is actually incorrect, because
then those operations would require responses themselves, and that's not
what we want.  Events don't fit the synchronous request-response model,
because they're not synchronous, and are ill-suited to a 2-way
request-response paradigm for every event message.

That's why I prefer the unidirectional model in which events occur as a
sequence of zero or more messages in response to a normal CRUD operation.
It's a clean model because the responses travel in the reverse direction
perfectly naturally (since they're responses) and do not themselves require
further ACKs.  It's also justified because, after all, we will require a
means of enabling / disabling updates and other asynchronous event
notifications.  This model kills two birds with one stone, and it's a
natural fit for capabilities.


Morgaine.




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

On Fri, Jul 16, 2010 at 5:09 PM, Meadhbh Hamrick <[e-mail]>wrote;wrote:

> > 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.
> >
>
> hmmm.... okay... point taken. true enough, EVENT describes not a verb,
> but a message type.
>
> my motivation here is to identify unsolicited messages. i think it's
> unrealistic to assume that EVERY message will be properly modeled as a
> request / response. consider the situation when someone wants to open
> a chat session with you? is it better to model that interaction as an
> unsolicited message (like you receive an event saying: "hey. someone
> wants to open a chat session with you") or as a response to the
> request (like "this is my request that you alert me on my event queue
> when someone wants to chat with me.")
>
> so yeah, i agree that EVENT is not a verb in the way CRUD verbs are,
> but i don't agree that EVERY interaction in a virtual world is a
> synchronous request / response, which is why the EVENT was added.
>
> we could, however, say that the model implies a reverse client-server
> relationship over an event queue and in that case, things that were
> events would wind up being resources the server accesses using normal
> CRUD message types.
>
> it still doesn't help us if we want to model an object update with the
> abstract resource definition or interaction definition scheme.
>
> i think we're dealing not only with whether a message is synchronous,
> but also dealing with whether the message has been solicited. i think
> REQUIRING interactions to be both synchronous and solicited is a big
> mistake, cause it means we can't use the system to model object
> updates.
>
> -cheers
> -meadhbh
> --
> meadhbh hamrick * it's pronounced "maeve"
> @OhMeadhbh * http://meadhbh.org/ * [e-mail]
>