cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <ovi...@cup.hp.com>
Subject Re: [RT] Managing Flow and Resources
Date Fri, 14 Dec 2001 22:46:43 GMT
On Fri, 14 Dec 2001 16:29:52 -0500, Jason Foster <jafoster@uwaterloo.ca> wrote:

> <snip content="a lot of good discussions that seem to have reached 
> tentative conclusions"/>
> 
> So an incomplete summary of what is currently being proposed is as follows:
> 
> -------
> Sitemap
> -------
>    Role: handles stateless needs (identified by URI)
>    Semantics:
>    Syntax:
>    Implementation:
> -------
> Flowmap
> -------
>    Role: handles statefull needs (identified by URI with statefull encoding)
>    Semantics: procedural programming
>    Syntax:
>    Implementation: continuations
> -------
> Pipemap
> -------
>    Role: handles the resources needed to construct a pipe
>    Semantics:
>    Syntax:
>    Implementation:

This is a good summary! This is also the way I see things happening.

> Currently I would argue that the Sitemap uses the semantics of procedural 
> programming, with the only difference being that the entry points are 
> defined as procedural matchers instead of as fixed function names.
> 
> Stefano, Berin, etc., could you fill in some of the blanks to help put 
> together a complete picture?  Thanks!
> 
> I am still trying to find the time to demonstrate that logic-based 
> programming is the right way to handle assembling pipelines.  My notion is 
> something very roughly like:
> 
> "/cocoon/hello.html"
>     requires "html-serializer(hello.html)"
> 
> "html-serializer(X)"
>      requires "converted-to-html(X)"
> 
> "converted-to-html(X)"
>      requires "load-from-disk(X)"
>      requires "xslt-apply(tabular-format.xsl)"
> 
> When a request comes in an inference engine would connect the stages 
> together to form the completed pipeline.  The reason I like this is that it 
> avoids having a single individual responsible for hooking everything 
> together and making sure that all of the appropriate parameters are present,
>   variables set, etc.  As a component developer all I have to do tell the 
> sitemap maintainer what my preconditions are and everything else is 
> automatic.
> 
> At least that's how I think it would work :)
> 
> Check out http://www.geocities.com/jiprolog/JIPConsole.html for a working 
> Java Prolog implementation.

For the model you described above, you don't need Prolog to implement
it. Since there's no backtracking involved, you can model the
resources as a dependency graph, aka a directed graph. To resolve the
dependencies, just sort it topologically and traverse it
postorder. This is exactly the same mechanism implemented by the Unix
make or Jakarta's Ant.

Prolog is useful for more complex activities, that require
backtracking, but I'm not sure how practical this option is in a Web
environment, considering the fact that backtracking means essentially
throwing away computation done to resolve a dependency.

Did I miss anything?

Best regards,
-- 
Ovidiu Predescu <ovidiu@cup.hp.com>
http://orion.rgv.hp.com/ (inside HP's firewall only)
http://sourceforge.net/users/ovidiu/ (my SourceForge page)
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message