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 /
interreality3d/a3dl/Scene).
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
work-around.)
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
plone.org 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.)
best,
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.
-----
http://lalomartins.info/
GNU: never give up freedom http://www.gnu.org/
_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
