Firstly, this post and the one below are tangentially related to Volity, but I should emphasise that I don't hack on Volity myself - the hard-working Volity coders being Doug Orleans, Karl von Laudermann & Jason McIntosh.
Secondly, these are just my serialized brainstrikes on how I riff on the whole "XML documents <-> XMPP" shebang, which is my approach to the whole idea of taking the web as a quantum leap in data density, and looking to build on that in line with the whole idea of navigable info/dataspace as an end-target.
I should mention that my next idea is to try and get the whole Gradient system working with an HTML viewport as opposed to SVG.
- I want to get surfable pages that do things like Gradient out there - this is a next-level leap in the capabilities of hypertext systems, and it's possible to do right now - preferably without any client-side installation (see below 'graphs & posts for ideas)
- The JEPs for file transfer via XMPP are, as far as I can see (and someone please correct me if I'm wrong) targeted at P2P use cases, and if one of the XMPP clients becomes a "server" of documents and starts receiving 1000 requests per second, the XMPP server starts to ask questions like "Why God WHY?!", and with good reason.
- Fortunately, we already have HTTP, which scales better than the (admittedly nonstandard) method of inserting an XML document as the child element of an IQ RESULT stanza that I use in Gradient.
- Volity are using HTTP for file transfer, and this is eminently sensible.
- HTTP can't do the kind of things XMPP can do to markup (with the help of Gradient), which why both Volity & Gradient implement two different solutions for doing the interactive & dynamic stuff. Apart from broadcast, server-client RPC is one of the things that is technically possible using some kind of hack to add a callback function on a client using the newly-crossplatform SOAP ECMAScript objects and/or the DOM3 load/save functions, but this is not exactly the most elegant of solutions, to put it mildly.
THEREFORE, and taking into account that we want normal web-pages to be able to enhance themselves using this stuff while remaining accessible to normal users, it seems reasonable to do something like this:
a) Joe loads his HTML page via HTTP.
b.i) (client-side mod) A Mozilla extension either (a) looks for <meta name="gradient" value="user@xmpp-server.example.com/index.html"> or (b) Looks for <gradient:service gradient="http://foo.com/blabla" jid="user@xmpp-server.example.com/index.html">, and upon finding one, connects to the server and does the twist using some as-yet-unspecified-or-standardized XMPP extension.
b.ii) (no installation necessary, not sure if possible) page includes an applet (up: I needn't code C++, down: applets.) that is given a reference to the Document and plays with it like so. Not entirely sure of the security issues, it's all doable.
I know that from the PoV of a web designer, webmaster, information architect or usability engineer that applets suck, admittedly, but imagine a sidebar/frame applet that (a) has a decent dynamic ToC as per the Weblogic 8 admin tool, (b) decent site-search/index as per RoboHelp, (c) IM interface letting you chat/collaborate with other surfers as per Lluna, and enables your currently viewed document to be updatable in realtime etc. etc. etc.
(I know frames also suck in general but this frame is in lieu of a Mozilla sidebar)
So, if this is the grand vision, why did I start muddying the crystalline waters of disco? My somewhat hazy vision of disco was as defining a set of IQ's for querying a hierarchical nodeset. For each page or each site that has this something like this, the client would want to know (e.g.) do we support site chat using the Lluna extensions, do we do MUC, do we have a ToC (which would be a disco tree) for the site, etc. At which point we're kinda blurring the semantics between site "features" and site "services".
Posts
