On Fri, 14 Dec 2001 16:29:52 -0500, Jason Foster <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
