[cap-talk] an attempt at web-calculus in a paragraph for hackers

[Tyler Close]

This all looks good. You have a few different options for implementing it:

1. The XSLT associated with the container resource uses XSLT's
document() function to grab the XML for the sub-resources (individual
emails, etc). This XSLT transforms all these separate XML files into a
single HTML file. (This is how the wiki implements transclusion.)

2. The XSLT associated with the container resource generates HTML
containing frames, whose targets are the URLs for the sub-resources.

3. An AJAX style application in which Javascript code grabs the XML
for the sub-resources and renders them.

4. Probably some other ways I haven't thought of.

In all of these options, you have the choice of funnelling all the
user interaction through the container resource, or letting the user
dig down to the sub-resources. I prefer to give the user the ability
to get direct references to the sub resources.

Tyler

On 12/8/05, Sandro Magi <smagi at naasking.homeip.net> wrote:
> Tyler Close wrote:
> > There's another important aspect of the GET operation. In many
> > applications, objects have associations with other objects, in
> > addition to having methods. The Waterken Server also assigns a URL to
> > each association. A GET operation on such a URL retrieves the current
> > target of the association.
>
> For a long time I wondered how rich interfaces could be supported given
> this "linked" style of reflection/navigation. Then you mentioned on the
> wiki that it supports "transclusion", ie. including a page by rendering
> it within another page (have I got that right?) and I got an inkling for
> how it could work. Let's see if I'm close...
>
> I suspect a webmail interface could be constructed by composing a number
> of smaller, self-contained units. For instance, suppose the interface
> consists of a list e-mails in the current folder (default: your inbox),
> a menu of actions (compose, addressbook, folders, etc.).
>
> For the simplest possible implementation: one could create a generic
> component which could fetch a list of e-mails from a mail server, and a
> generic component providing menu options.
>
> These could then be composed by a third component which "transcludes"
> the output produced by the above two into the final webmail front-end
> (kind of like a generic container/panel type in which the other
> components "render themselves"). Further, this "container" component is
> the object the user interacts with. Is this accurate?
>
> Let's see if I'm even close before I ask further questions. :-)
>
> Sandro
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk
>


--
The web-calculus is the union of REST and capability-based security:
http://www.waterken.com/dev/Web/

Name your trusted sites to distinguish them from phishing sites.
https://addons.mozilla.org/extensions/moreinfo.php?id=957