Re: [vwrap] thinking about LLIDL and the future

[Dzonatas Sol <[e-mail]>]

Meadhbh Hamrick wrote:
> 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.

A little more for us to think about... from actual usage...

The simple queries that Icesphere puts together are something like: GET 
http://host:port/abc/def/uuid. If it finds many of these simple queries 
found in the queue, then it combines them all into a single complex 
query: POST http://host:port/abd/def/s. Technical detail on transport, 
the single letter "s" is a false UUID to denote a list of UUIDs in the 
request.

Due to such automatic query transition above, you can probably guess at 
reasons why Icesphere avoids the event queue resource, as described in 
VWRAP. I look at VWRAPs event queue as another possible transition and 
technical detail on transport.

When I mentioned bidirectional earlier, I actually meant fully 
bidirectional and not just simply request/response. For example, in 
Icesphere, the client sends a query to load an asset for an inventory 
item, which returns HTTP_OK|HTTP_ACCEPTED status. The resource is 
released after that status. When the server has the asset, it send a 
query that the asset is loaded to the client, as a separate resource. 
That is a capability that is obviously not active for those that don't 
support full bidirectional queries due to possible firewall that only 
allow unidirectional queries.

I think I rather go with QUERY rather then request/response mainly to 
make direction more significant and to make the request/response a 
technical detail of the transport.

I started to type lots of detail here, yet my coffee pot is empty.

To expand you usage of EVENT into a QUERY we just need to know the 
pivotal data for transitions, like UUIDs.