Re: Re-purposing XSP (was Re: [RT] Rationalizing XSP (was: XSP and aspects))

[Allan Erskine <a....@cs.ucl.ac.uk>]

> All I can say to this is that under AxKit, it is already possible to use
> XSP to generate XML anywhere, provided you can extract the generated code
> (we don't save to a file like Cocoon does). The code is just a simple
> handler function that gets invoked at execution time. The only time it
> becomes uncallable from outside of AxKit is if it makes use of the $cgi or
> $r objects.
>
> Plus AxKit has no concept of Generators and whatnot. That's all YAGTNI to
> us. XSP is just another callable engine in the pipeline.
>

Ricardo's proposal is a move in this direction, with some great looking
structural ideas to back it up.  From what you say here, it looks like a
convergence towards AxKit's way of doing things - so I'd hope you'd share
our expectation that all XSP platforms could have something to gain.


----- Original Message -----
From: "Matt Sergeant" <ma...@sergeant.org>
To: "Ricardo Rocha" <ri...@apache.org>
Cc: "XSPDev" <xs...@xml.apache.org>
Sent: Monday, March 05, 2001 10:12 AM
Subject: Re-purposing XSP (was Re: [RT] Rationalizing XSP (was: XSP and
aspects))


> Again, keeping this off cocoon-dev.
>
> On Fri, 2 Mar 2001, Ricardo Rocha wrote:
>
> > 2) Making XSP a general-purpose factory for server components
> >
> > Probably the most wasteful single mistake in the existing (Cocoon) XSP
> > implementations is limiting code generation to Producers (C1) and
> > Generators (C2).
> >
> > This undesirable "feature" stems from the fact that the last-stage
> > logicsheet applied (the one dealing with the XSP tagset as such) also
> > contains the compilation unit skeleton.
> >
> > If we decouple XSP from the target source program type and the
> > invocation environment (e.g. http/servlet) then the XSP language could
> > be used for building practically any kind of markup-generating program.
>
> I've snipped the rest because it's all cocoon-isms.
>
> All I can say to this is that under AxKit, it is already possible to use
> XSP to generate XML anywhere, provided you can extract the generated code
> (we don't save to a file like Cocoon does). The code is just a simple
> handler function that gets invoked at execution time. The only time it
> becomes uncallable from outside of AxKit is if it makes use of the $cgi or
> $r objects.
>
> Plus AxKit has no concept of Generators and whatnot. That's all YAGTNI to
> us. XSP is just another callable engine in the pipeline.
>
> --
> <Matt/>
>
>     /||    ** Founder and CTO  **  **   http://axkit.com/     **
>    //||    **  AxKit.com Ltd   **  ** XML Application Serving **
>   // ||    ** http://axkit.org **  ** XSLT, XPathScript, XSP  **
>  // \\| // ** mod_perl news and resources: http://take23.org  **
>      \\//
>      //\\
>     //  \\
>