cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett McLaughlin <>
Subject Re: Easy to maintain Web applications?
Date Wed, 15 Dec 1999 23:50:05 GMT
Greg Wolff wrote:
> Stefano,
> Thanks for the reply.  I'm more confident now that we can find some way to
> work together.  It is taking longer than expected to understand what are the
> real technical differences in our approaches and what is just a difference
> of terminology.
> Stefano Mazzocchi <> writes:
> > [... ]
> > No, at this stage, a complete web-site using Cocoon is a management
> > nightmare. We have to define that damn sitemap... yes, Donald, I'll
> > trade the xml-ized SQLproc docs with a sitemap proposal :)
> >
> We keep configuration information local to a directory (in an XML file, of
> course) and allow properties and other configuration information to be
> inherited from parent directories.
> > [... ]
> > There was a sentence on the PIA web site (I could not find it anymore,
> > maybe you guys removed it) that said something like "we want to separate
> > code from pages, unlike Apache's proposed XSP which continue the process
> > of including code with content."
> This may have come from a draft of our white paper.   We do think that
> embedding arbitrary program code in XML documents detracts from
> maintainability and makes security very much harder.  With our approach, you
> can define a "safe" tagset (e.g. no active tags that side effect the
> file system) to use in processing documents of uncertain origin.  My
> understanding of XSP is that, like JSP, arbitrary Java code could be
> embedded in XML documents.

Ummm, not to be rude, but have you actually read the XSP Layer 1
Specification?  You really should, as I think you aren't understanding
how it works.

Again, not to be rude, but you should really read this before you try to
guess at what it does.  Makes it lots easier ;-)  The "arbitrary" Java
code is defined in XSL/XSP style sheets (called logicsheets), not XML
documents.  There is nothing in an XSP document that is not 100% 1.0 XML
compliant.  The example looks like:

<?xml version=1.0?>

  <para>You have been here <count/> times.</para>

That's it.  No code, nothing to let anyone know what else is going on.

> In a nutshell, here's the difference:
> PIA:
> <define element="foo" handler="org.risource.dps.handler.Foo">
>    <doc> The action for foo the specified in a java class called Foo </doc>
> </define>
> XSP:
>   <xsp:foo language="java">
>    <xsp:logic>
>     private static int counter = 0;
>     private synchronized int currentCount() {
>       return ++counter;
>     }
>    </xsp:logic>
>   </xsp:foo>

Your XSP here is in a logicsheet, separate from content.  I actually
think this is an even better approach, because if there was ever a need
for C/C++/Perl/whatever, an appropriate stylesheet could be created with
that code in it, and the XML document is absolutely untouched.  If you
have problems with code in the stylesheet/logicsheet, then I think you
are in the wrong market - a stylesheet changes a _lot_, every time the
HTML spec changes, every time look/feel changes, etc.  It is meant to be
malleable, because your nice clean XML document is still unchanged.

Maybe you thought the xsp namespace tags were in the XML itself?  No.

> The Foo class referenced above might very well have exactly the same logic
> as the xsp:logic tag, but keeping it separate allows it to be treated like
> other (dangerous) code.  It can be edited and compiled with normal Java
> development tools, can be maintained by the system administrator, and
> doesn't require that the developer has the ability to execute arbitrary
> code in the server process in order to operate properly.

Same for a logicsheet, except the logicsheet can be compiled and cached
completely, without having to check anything but itself to see if a
change has occurred.  Over time, your PIA methodology has to continually
check a .class file, which is more (albeit not much, but still more)
overhead and less performance than the stylesheet.  IMHO, XSP takes the
good from JSP and discards the bad (the language dependence in the
actual document).

> > Than you claimed that "XSP was not a
> > serious approach to ease of web-app maintenance".
> >
> I don't think we ever claimed that.  In any case, it is a serious
> misunderstanding that I would like to apologize for.
> > It's no secret that I got pissed off big time about that sentence. Ask
> > Brian that was proposing me to peer-review the PIA native port for
> > SourceXchange.
> >
> > On the other hand, your kind question changed all this: I'll be more
> > than willing to collaborate with you guys, and explaining why the
> > proposed XSP design ideas are very similar to yours.
> >
> Happy to hear that.
> > XSP is separated into levels. [... ]
> I may need to see some basic examples before I understand how these levels
> are meant to work together.

Again, you should _really_ read the spec.  If you have, maybe re-read
it, as it helps here a lot.

> >
> > Yes, I totally admit Cocoon's embedding of PIs to link one part to the
> > other sucks big time.
> >
> > Any help in this direction is _very_ appreciated.
> >
> In our case, actions are bound to individual tags in a tagset, and tagsets
> are bound to documents (usually based on the file extension) in a
> configuration file.  I think the rough equivalent in cocoon would be to have
> a configuration file that lists the processors which should operate on a
> class of documents.
> Note that this ability to easily change the processing applied to particular
> documents (without modifying the documents) comes in very handy.  For
> example, we use it to pretty-print the underlying XML when someone wants to
> view-source.

This is just a change in processor instruction in Cocoon, also I think
very easy, and getting easy with the improved 2.0 model.

> [... ]
> > Greg,
> >
> > I've been in close contact with Brian about this and I repeat to you
> > directly what I told him. I modestly think the native port of a XML
> > publishing framework written in Java is today a waste of time for the
> > following reasons:
> I appreciate the frankness and agree that porting the entire framework would
> not be productive.  However, the barriers to deploying Java in embedded
> devices are more numerous than I care to list here.  We're primarily
> interested in having a C based module that can process and serve
> the kinds of XML pages we use in our PIA based Web applications.
> Eventually this might expand into a full publishing framework, but the goal
> is to have something that works well enough to deploy today.

I agree with Stefano here, but good luck... :-)

> We don't plan to abandon the Java version of the technology.
> > [... ]
> > So, I picture you spending time in porting to native, while we spend
> > time improving our speed and flexibility and by the time you reach the
> > stability point you want, you are behind and you loose all the power you
> > have today to influence this new field.
> >
> Well, the reason for doing it through sourceXchange is so we can spend our
> time on the fun stuff :-)
> > [... ]
> > I think that it makes a lot of sense, at this point, to confront and
> > help each other, given that Cocoon itself is already enough flexible to
> > stand major architectural changes with small impact on his components.
> >
> > Am I making sense at all?
> More than most.
> -Greg


View raw message