I meant to send a message about this a while ago, but life has 
intervened recently.

Anyway, here are my current thoughts on what to do with Hypervos.

I'm still digesting Lalo's plans, need to reread it or talk to you in 
IRC Lalo.  For one thing, I'm not sure I fully understand the general 
need for explicit MVC classes/objects.  To me, MVC has always been 
implicit in VOS.    One set of Vobjects is the Model, the Control is 
implemented by listeners on those Vobjects, which either render the 
'View' directly locally for the user, or manipulate a second set of 
Vobjects to be the View.   You don't need to explictly create some kind 
of "View", it's just there in the second set of Vobjects.   The 
Controllers (listeners) can also be Metaobjects, (so they can be applied 
remotely by users using a UI) and I started doing this in the 
"vostoolbox" library in s4.

Anyway, here's how I was thinking Hypervos could work.

First, is to create a new library to put most of what's currently in the 
vosext_http extension in.  The vosext_http would just be the HTTP 
server, and it would call in to the library to actually render the 
objects.   Other "front ends" could be an Apache module, or simply 
listeners that listen to the entire tree of objects, and write files to 
the disk as things change so another HTTP server can serve static pages 
quickly, or a component of the general UserInterface client to render 
HTML in a pane in the UI.

The hypervos "engine" in the library would then do the work of walking a 
vobject tree assembling them into the output document.  Right now, this 
is just done in a big ugly function in httpserver.cc.  This should be 
changed so that all hypervos and xml object types have actual Metaobject 
components for them.  The "engine" would call "render(request, 
outputstream)" on these Metaobjects, where request is an object 
containing information about the HTTP request.  The base metaobject 
class implementation of render() would be just to return the XML/HTML 
tags to the output stream, write property data, etc. and return.

In the s4 httpserver ("vos" bzr branch) I've added a collection of 
little hacks for special hypervos types that make it easier to represent 
  certain HTML constructs like links and images, and I've also started 
to play with adding things like editing controls, contols to display 
metadata about vobjects, etc.   Right now these are all just added 
ad-hoc to the big ugly rendering function, but these could be seperated 
into Metaobjects/components specific to the special hypervos types.   We 
would do the same thing for templates.  In the future, it will be easy 
to add new "widgets" like this by writing the metaobject/component 
implementations more quickly in Python or another scripting language.

So it would work something like this.

-- HTTPServer front end:

HTTP GET request
   HTTPRequest request (includes info about client, URL, CGI parameters, 
HTTP headers, cookies);
   meta_cast<HypervosObj>(findObject()) => rootVobject
   rootVobject.render(request, ostream);

-- Hypervos Metaobject Library

Base HypervosObj render(request, ostream):
    ostream << startTag << render(children) << endTag;

link widget render(), for example:
    ostream << "<a href=" + linkTarget " ...>" + render(linkContents) + 

template render():


Now, this is all pretty web specific.  If you have some objects that 
don't have the XML/web types, you would need to set up listeners that 
can generate XML/Web documents from your other objects, like I described 
above.  However, this process is general to VOS and not specific to 
Hypervos, so we don't need to address it in Hypervos per se.

I also want to implement CGI calls as a way to directly generate VOS 
messages.  This will let us implement all the stuff like forms, 
commenting, online Vobject editing (by mapping the "post" button CGI 
call to a factory message that creates the new post/comment).  Plus I 
have many more ideas.  See http://www.interreality.org/HyperVosIdeas .

Finally, what I'd love to see eventually is a web page that updates in 
real time to changes in VOS (using ajax techniques, and something like 
cometd.)  Doing this requires doing an initial render() as above, but 
then creating listeners that send messages back to the browser as things 
change, and deleting those listeners when the browser session ends.



vos-d mailing list

Reply via email to