VWRAP essentials : the event queue

this week on VWRAP essentials, i wanted to talk about the "VWRAP event queue." in the world of second life(tm) viewer development, the term "event queue" has a very specific meaning. it is a set of data structures, functions and UDP message types that communicate events from servers to clients. that's not what we're talking about here.

VWRAP is intended to be an application layer protocol that can be carried over multiple transports. implementers MUST support transporting VWRAP messages over HTTP(S), but there's been a lot of interest in optionally moving some traffic over XMPP and RTP. so defining anything in terms of HTTP is sort of a problem for VWRAP.

instead, we define an abstraction and then define a bunch of ways the abstraction can be reified by network protocols of real software. the VWRAP event queue is an application layer abstraction for a facility that delivers arbitrary, unsolicited messages to a network peer. in other words, the event queue delivers messages from servers to clients without a specific request from the client.

this is a general problem with interactive web applications as well, and a couple solutions have surfaced in the web community. embedding flash or java content in an HTML page is one solution. plugins for these technologies are readily available for popular web browsers. but VWRAP doesn't use HTML, and it certainly doesn't use a web browser.

another popular technique is "the long poll." interactive web apps implement the long poll by using the JavaScript XMLHttpRequest object to query a specific URL on the server. if the server has nothing to say to the client (i.e. - there are no unsolicited server to client messages) the server just waits, leaving the connection open. as soon as it has something to say, it delivers the message to the client. the client processes the event and queries the poll URL again, waiting for the next message. this technique is simple, but can be wasteful of resources in some programming languages.

more importantly, it's a hack. in a RESTful world, where accessing resources of HTTP is supposed to be idempotent, the idea getting something different each time you access a resource seems somehow unclean.

but there's an emerging standard for how servers should push streams of unsolicited data down an HTTP connection. it's called WebSockets. it's not without warts, and will require a little retooling of some of the web's infrastructure. it didn't include every feature that everyone wanted, but there's general agreement that it's "good enough" and is much better than using the long poll.

VWRAP could have defined the event queue in terms of WebSockets, but at the time it wasn't clear WebSockets would become "the" standard. it may also require some amount of tinkering with the infrastructure to implement, so it's not entirely clear WebSockets will work everywhere all at once. it's also possible that some organizations may be behind aggressive firewalls that will block WebSockets,

for all of these reasons, the VWRAP designers decided to create an "abstract" event queue that could be reified by sending messages over long poll or WebSockets.

the current foundations draft only defines the event queue over a HTTP long poll. future versions will describe it's use over WebSockets.