[Waterken-server] Re: [cap-talk] YURLs. What is the model of development?

[Sandro M. <sm...@na...>]

(cross-posting to waterken-server list since we're getting slightly OT 
for cap-talk)

Tyler Close wrote:
> Think of your application as a persistent graph of Java objects. The
> waterken server assigns capability URLs to the references in this
> graph, enabling traversal of the graph via GET operations, or mutation
> of the graph via a POST operation to a particular object method. As
> the graph is changed, or grown through the addition of new objects,
> these changes are automatically persisted to disk by the waterken
> server.

I've actually been wondering how this would interact with typical n-tier 
web-app design in which objects/data is persisted in a relational 
database (either directly or through an O/R layer). Unless I'm mistaken, 
the waterken db doesn't have an RDBMS's query capabilities, so an RDBMS 
still seems necessary in many circumstances. How does this "persistent 
object graph" approach interact with objects loaded from an RDBMS? Is 
there perhaps a useful pattern that covers this scenario?

> In response to a GET operation, the waterken server will
> render the identified part of this graph in XML format. The waterken
> server will also turn XML rendered POST arguments into Java objects
> and deliver them to your object methods. You Java code is oblivious to
> the existence of this XML marshalling.

Just out of curiosity, is the object-to-XML transformer easily 
replaceable? While XML is fairly ubiquitous and flexible, I can imagine 
some applications might warrant some alternate output format; YAML is 
gaining popularity for instance.

> If the client software is a browser, the linked to XSLT file will be
> used to transform the XML into HTML.

I imagine client-side XSLT is preferable to reduce server load because 
of this. Have you ever found the ubiquitous XSLT transformations to be a 
performance problem?

Sandro