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:
ostream;
HTTP GET request
|
V
HTTPRequest request (includes info about client, URL, CGI parameters,
HTTP headers, cookies);
meta_cast<HypervosObj>(findObject()) => rootVobject
rootVobject.render(request, ostream);
|
V
-- Hypervos Metaobject Library
Base HypervosObj render(request, ostream):
ostream << startTag << render(children) << endTag;
link widget render(), for example:
ostream << "<a href=" + linkTarget " ...>" + render(linkContents) +
"</a>";
template render():
...
etc.
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.
Reed
--
http://interreality.org/~reed
_______________________________________________
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
