Also spracht Reed Hedges (Thu, 14 Feb 2008 14:23:53 -0500):
> On Thu, Feb 14, 2008 at 07:13:14PM +0000, Lalo Martins wrote:
>> hypervos is already alive and kicking in the form of an Apache mod_vos;
> Ack! Why didn't you email the list! I've been adding stuff to S4
> hypervos (and intend to port them to S5!) And I have many plans for
> further development (see HyperVosIdeas on the wiki)

Heh, sorry.  It's still a bit nebulous, as I'm working on grokking s5 and 
reality-checking the APIs; I thought I'd tell the list about it once it's 
actually possible to build a (web) site, which as I said, is by the end 
of this month.  But if I realised you were actively working on s4 
hypervos, I'd probably have made a different decision.

> Tell me more about mod_vos.

Before I do that, to inform your reading, I guess I should talk about my 
own personal long-term vision for VOS.

For me, there are a few points ahead of a3dl and the Interreality in the 
coolness scale.  I like the whole architecture.  I like that it has 
actual sessions and connections and is stateful.  At the top of the list, 
I love it that the whole structure is object-oriented and fully semantic; 
we're more than a collection of opaque files, each with a type tag, which 
leaves it to the client to sort things out.  This is POWER that shouldn't 
be forgotten, and empowers us to do a lot of things the web has been 
struggling to do in the last few years, with impressive but ultimately 
very poor results.

So my "angle" at VOS development is CONTENT.  What I desire to have, at 
the latest shortly after the Interreality becomes usable (but preferably 
a while before then), is a small, www-like network of interesting, useful 
content.  And I don't mean VR content; VR content of the sort that, say, 
Second Life has by the million, is really interesting, about as much as 
the Web was interesting in the beginning.  And I'm not talking about 
"before web 2.0"; I'm talking before e-commerce, before blogs, 
sourceforge, forums, wikis.  And this, if I may be so bold, is the reason 
I believe Second Life will ultimately fail.

Hypervos is an essential part of my "migration strategy".  Not everybody 
will jump on Interreality as soon as the first alpha is usable, and that 
seriously limits the amount of content we can have on this network.  The 
natural answer is to write web interfaces for this content.  And, why 
not, plain-old-GUI interfaces too; that doesn't take that much extra time.

Hence the big focus on MVC in s5.  Sure, in some situations you'll want 
to "circumvent" it and just build a3dl content.  But my vision has things 
like an "abstract" object of type, say, "/vos/talkative/Hub", which can 
appear on the web as an AJAX chat page, on GUI as an IRC-like thing, and 
on Interreality as a fancy bar (the View class would fetch shapes, 
textures and whatnot from child objects, maybe by casting the Vobject to /

So.  How it works is basically... MVC.  There is a View Context class 
called WebRequest.  (This is in libvos, in case someone wants to write 
another implementation of hypervos, say, stand-alone, IIS, whatever; 
mod_vos subclasses this into ApacheRequest.)  Peter's ViewFactory object 
is a registry of ViewImplementation objects, each of which in turn is 
responsible for (a) examining a (model, context) pair and seeing if it 
can handle it; and (b) if it can, creating a View object for it.

(Now, on my original design, web pages would be "transient views", 
meaning, there is a ViewImplementation that writes to the WebRequest, but 
it never actually returns a View.  This feature has been lost on Peter's 
implementation, but we plan to bring it back later on; just not a very 
high priority.  For now, by not attaching the View to any site, the 
ViewImplementation can make sure it's collected in the next gc cycle.)

And really, it's as simple as that.  The s4 behaviour of generating html/
xml can be reproduced by a ViewImplementation object.  (I have 
intentionally not used the name "hypervos" anywhere, in case you want to 
write just such an object and call it "hypervos".)

You can look at CoreSchema.xod or mvc.hh for the WebRequest API; it's 
pretty well-commented, and by all means please poke me back with 
questions, comments, criticisms, complaints, and suggestions.

The core thing is, of course, the write(s) method.  And it's also the one 
sticking point, or should I say, flaw.  It's actually a symptom of a 
larger s5 problem which we're aware of but not in a hurry to fix.  
Namely, s5 uses UnicodeStrings everywhere; but this is a somewhat "half-
hearted" Unicode support, because at the entry and exit points, there is 
no way to specify encodings.  So, write(s) takes an UnicodeString, but 
there's no way (yet) to specify an encoding (I just default it to 
utf-8).  Worse, there's no way to write plain bytes, so sending eg an 
image is out for the time being.  (That's easy to fix, just a matter of 
adding another method, but I *like* not having it; it reminds me that the 
Unicode issue must be fixed at some point ;-) rather than providing a 

Additionally, more or less on a whim, WebRequest provides two different 
APIs for "page assembly", to help you build a site (as opposed to a 
webpage): Fragments and Portlets.

Fragments are easiest to explain to someone who's already done any web 
development at all.  There is a vector of VOS URL strings (may be 
replaced with symlinks later) which is the "fragment path".  WebRequest 
has a method includeFragment(path), where path is relative to one of the 
objects in the fragment path.  (Ugh, I'm using both meanings of the word 
"path" in the same sentence, that makes it that much less easy to 
understand!)  So let's say fragment path is "/foo/frag;/bar/frag" and the 
path argument is "sidebar"; the call would locate either "/foo/frag/
sidebar" or... you get the picture.  The final object may either have a 
Lambda (callable) "renderFragment", or a String property "fragmentBody", 
in that order.

Portlets are... well, think of a page like iGoogle or Facebook or which is built of discrete "boxes".  In a portlet-based 
application, the ViewImplementation only builds a tree of portlets, and 
then another object (the "master container") puts them together.  I'll 
leave the API details out this time; they're a bit more complicated, and 
I believe (hope) you can figure it out from the schema :-)

Right now, I'm working on a plug-in to provide authentication and 
sessions.  It's compiled separately, and it's not in the VOS source tree 
at all, which is meant to demonstrate (to myself) that the APIs are 
solid.  (Of course, since s5 doesn't *have* authentication, capabilities, 
or principals (users) yet, this will be a "bastard", web-only 
authentication; integration with s5's system will come later.)

                                               Lalo Martins
      So many of our dreams at first seem impossible,
       then they seem improbable, and then, when we
       summon the will, they soon become inevitable.
GNU: never give up freedom    

vos-d mailing list

Reply via email to