Tom wrote:
>99% of the processing power on the internet is on the User's machine, and
>historically, 99% of that machine has been unutilized for the most part. It's
>unfortunate that companies have to buy incredible amounts of hardware and
>software licenses so that presentation (which is the majority of most web
>applications) can be performed on the server side.
Looking through Quilt it seems to me that the only queries that *have*
to be performed by the server are the initial LET and FOR sections.
WHERE and RETURN could all be done by the client.
The problem with Quilt on this front is that it is designed with an ODBC
style bridge to the db in mind (I mean where you just send the query as a
string). We obviously can't palm off work to the client with this
system. But the LET and FOR sections are really just XPath
containers so we could simply define some CORBA/XML/... interfaces
to making XPath queries and let the client parse the entire Quilt
query and have it send the LET and FOR XPaths to the server and perform the
rest itself. Actually, simple URLs would suffice for this.
On another note: I was wondering if a standard API for performing
queries would be within the charter of xml:db? My idea being that if we
are to palm off most of the processing onto the client then it would
make more sense to define some IDL than to have an SQL style syntax.
Obviously the leap wouldn't be that great. LET and FOR could just
be replaced with an XPathQuery() function that returns an
XMLGrove or whatever. We could also have an XMLList data type
via
XMLList list = groveToList(some_grove);
We can then do all of the WHERE, FILTER, BEFORE, AFTER, INTERSECT and
EXCEPT via the standard list processing functions map, foldr, foldl etc.
Strictly speaking we could just treat a grove as a list by just stepping
through each node, but I have a suspicion that it may be usefull to
have two distinct views and convert between them as required.
Does anyone else think this is a good idea? I've gotten a lot of
ideas on how to set this up:
We could define an XML syntax for language independent transfer of
code (So we won't just be tied to Java).
To fit well with XML it would have to be side-effect free and so
on. ie, it would have to be a declarative language - I was thinking
of it primarily being a functional language with some logic
constructs.
Ofcourse, taking this route would mean that we would have to make it more
familiar than general functional languages. eg, replace `\x -> ...'
functions with `forall x {...}'. Do combinators forwards rather than
backwards - we could even call then pipes to make the concept more
familiar. Also, would would probably be able to do without
currying.
--
Matthew Parry Bowerbird Computing
Proprietor "XML tools designed to *your* specifications."
<[EMAIL PROTECTED]> <URL:http://www.bowerbird.com.au/>
ICQ#56864663 PO Box 1280 Nowra, NSW 2541, Australia
-
"There now, didn't I tell you to keep a good count? Well,
there's and end of the story. God knows there's no going on
with it now." - Sancho Panza.
------------------------------------------------------------------
Post a message: mailto:[EMAIL PROTECTED]
Unsubscribe: mailto:[EMAIL PROTECTED]
Contact adminstrator: mailto:[EMAIL PROTECTED]
Read archived messages: http://archive.xmldb.org/
------------------------------------------------------------------
