Re: [vwrap] thinking about LLIDL and the future

[Meadhbh Hamrick <[e-mail]>]

Interesting. I had been thinking that the message semantics would require a
response on the same channel as the request. What you're talking about seems
to be a little higher level than what I'm pitching. (Thx for pointing out I
wasn't clear about this)

So.. the way I'm modeling it is that you have message interactions that are
tied to the same transport session. So if you ask for something with
http(s), you get it back via http(s) on the same connection.

But it's definitely true that an application layer entity can coordinate
messages, only I think we should make a "virtual" connection that spans
actual connections.

But I still think it's advantageous to think of interaction patterns in
terms of message flows over specific connections, otherwise we have to start
adding application layer transaction id's to correlate responses to
requests. Also, since trust seems to be associated with connections (by way
of (D)TLS), it's probably a good idea to not cross trust boundaries in
interactions across connections, otherwise we would have to model that in
the application layer as well.

At the end of the day, we have message patterns that look like:

* send, no reply expected
* request, response expected
and
* unsolicited message.

The first two can be modeled with request/response, but the last one has
unique characteristics that must be modeled.

-cheers
-meadhbh

On Jul 16, 2010 11:05 AM, "Morgaine" <[e-mail]> wrote:

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:
>
> > EVENT is not a...

_______________________________________________
vwrap mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/vwrap