Re: [vwrap] thinking about LLIDL and the future

[Meadhbh Hamrick <[e-mail]>]

okay. i think i understand you and dzonatas well enough to go out and
write another, completely unofficial, possibly experimental draft for
the group. then maybe a little bit of PHP and JavaScript to
demonstrate a few of the features.

again, thanks for the comments (and this is by no means the end of the
commentary on my extended type system.) i think it's just easier for
me to have a conversation about it after having real documents and a
sample implementation to look at.

i'm going to probably drop out of the conversation for a week as i go
off and work on this stuff. i'll keep a lookout for additional
comments, and try to address them in my next draft. but i probably
won't have bandwidth to discuss them for a week or so.

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



On Fri, Jul 16, 2010 at 10:41 PM, Morgaine
<[e-mail]> wrote:
> That's correct, I was describing flows at the capability level, not at the
> transport level.  The transport is exactly as you deduced, namely with
> separate transports for capability request-response and for asynchronous
> event messaging.
>
> When you send an ENABLE to the capability that controls a particular
> asynchronous event stream, you receive back the normal capability OK
> response on the same channel as the request (as expected), but the event
> messaging that this enables occurs on a distinct channel at the transport
> level.
>
> This makes a lot of sense for practical implementations, because event
> messaging requires high bandwidth and low latency and so it is best handled
> on a separate transport and using the most efficient form of serialization.
>
> As an implementation example, the OK response from the request to the
> capability could return the IP address and port of the event messaging
> source host, the client would open a TCP stream to it, the source host would
> send events asynchronously down the pipe, and the client's event listener
> would dispatch the event frames to appropriate event handlers as the
> messages arrive.
>
> Different event-generating capabilities could choose to return different
> IP:port pairs to harness dynamic load-balanced server pools and to provide
> parallel pathing, or they could choose to share a common event transport ---
> these would be simple site configuration choices.
>
> Note that this is highly scalable, since it allows any number of servers to
> participate in event generation and distribution.  No longer do updates have
> to come from a single, horribly overloaded and totally non-scalable
> simulator host.
>
> Consistent with David's regular exhortations, nothing in the above precludes
> this model from working in the legacy deployment architectures of SL and
> Opensim:  single simulator operation is still supported by the design, but
> it offers additional capability for more scalable deployments.
>
>
> Morgaine.
>
>
>
>
>
> =====================================
>
> On Fri, Jul 16, 2010 at 7:45 PM, Meadhbh Hamrick <[e-mail]>
> wrote:
>>
>> 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
>>
>
>
> _______________________________________________
> vwrap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/vwrap
>
>