cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Easy to maintain Web applications?
Date Wed, 15 Dec 1999 13:40:13 GMT
Greg Wolff wrote:
> 
> Are there any good examples of applications built on cocoon that can be
> easily customized?  

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 :)

> I'm trying to understand how this technology works in
> practice, for example in a workflow system, to see whether we might be able
> to contribute to the coccon development effort.

This is great news.
 
> We have developed a technology with seemingly similar goals -- making it
> easier to build and maintain Web applications.  Our focus has been on
> smaller scale applications that might be maintained and customized by
> non-programmers, but our solution has some of cocoon's qualities.  PIA
> Applications consist mainly of pure XML documents processed by a server side
> engine written in Java.  This software (with the decidedly inferior name of
> PIA "Platform for Information Applications") is available as open source
> from www.RiSource.org with a live demo server at
> http://pia.rsv.ricoh.com/Tutorial/home.xh

I've already reviewed that.

> The eventual goal of RiSource.org is to facilitate the development of Web
> applications that can be customized and evolve to meet changing user needs
> without substantial IT support.  Developing a suitable application platform
> was seen as a necessary first step.  The PIA does this by effectively
> separating development (defining the set of active tags) from
> customization/maintenance (editing and extending the XML pages based on
> those tags) without imposing barriers between the two.  The technology has
> been used for several internal applications and we continue to refine the
> feature space.
> 
> Rather than separate technologies, a single standard approach would be much
> preferred and we would seriously consider ways of integrating our platform
> with the cocoon effort if the goals are compatible and the technical issues
> can be resolved.  Before submitting an actual proposal, we need to
> understand more about the current and future directions of the project
> (hence the leading question).

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." Than you claimed that "XSP was not a
serious approach to ease of web-app maintenance".

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.

> For those who might be interested, here's a brief summary of some of the
> technical differences (from a naive cocoon perspective):
>         XML processing model -- the PIA defines active tags which are
> processed in an event based manner similar to what is described in the XSP
> working draft except that tags can be defined either in terms of other tags
> or Java "handlers."  

XSP is separated into levels. Each level provides some basic and
separated funtionality. This is done to parallelize development and to
allow easier implementation. Each level works using the level below.

Level 1 (which is the only one specified, at this time) provide the
basic machinery to allow you to mix logic and content. It's complete and
it works in practice. It's implementation is under way and will be
available for the end of the year.

Level 2 will allow the creation of namespace-driven taglibs (somehow
following the JSP idea of taglibs but associating the namespace pattern
matching). This part is also in place, even if we didn't yet define it
in the spec.

Level 3 wil provide data binding facilities with what we call XBeans
(also following the Sun JCP proposals for XML bean bindings and adding
bean XML exposition of their internal content, with Schema exposition).
This part will need feedback from the users of the previous levels as
well as the JSP JCP, we'll see how this goes.

> In the latter case, the tag definition (itself part of
> an XML document) has an attribute that points at the appropriate java class.
> Documents can be streamed through without necessarily constructing a parse
> tree/DOM object in memory and could, in principle, be compiled.  In
> contrast, XSLT uses explicit application of templates, requires full DOM
> construction, and defines a fixed set of possible operations on the XML.
> Processors can perform arbitrary processing on the document.

This sounds very similar to our approach.

>         Configuration -- PIA applications consist of a set of XML documents,
> tagsets (XML documents that define the actions associated with tags), and
> configuration files (also XML) that map tagsets to documents (and URL's to
> "virtual documents").  This allows the same document to be processed in
> different ways depending on the context.  Cocoon embeds the style sheet and
> processing instructions in a document.  (A site configuration proposal has
> been mentioned on the mailing list.)

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.

>         State/context management -- the PIA allows arbitrary XML elements to
> be assigned to entities where they can be manipulated and referenced.
> Entities are arranged into hierarchical "namespaces," some of which are
> specific to the current document (e.g. &FORM:input; references the value of
> the variable named "input" in the query string of a GET or POST request) or
> persistent across documents (e.g. &MYAPP:mystate; might reference a
> namespace "MYAPP" defined in the applications configuration file).

Never thought of this: I thought that providing XSLT variables made more
sense, but I didn't really spend much brain cycles.
 
> More information on the PIA can be found on http://www.RiSource.org/PIA
> We also have a couple of RFP's on www.sourceXchange.com for developers who
> might be interested in porting the PIA processing engine to C or developing
> customizable Web applications.  (Depending on how those projects go and
> where this discussion leads, we might consider sponsoring future work on a
> more integrated/standardized platform.)

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:

1) this is bleeding edge technology, one must be able to redesign,
rewrite, reinvent fast and quick. Java gives you that ability.

2) All the major XML/XSL tools are written in Java. Porting all of them
is an _incredible_ effort.

3) JVMs are getting faster every day. Hotspot-based or native-compiling
JVMs do reduce the speed issues.

4) there are no SAX API for other languages rather than Java and
incremental operation is the key for scalable XSL engines.

5) all the XML/XSL tools have _not_ undergo substantial profiling,
expecially XSLT which just got standardized.

6) everyone is moving toward java for web apps, going the other
direction just for speed is nonsense.

7) page and stylesheet on-fly compilation is extremely harder in other
languages, expecially given the lack of a portable dynamic-binding
facility. I hope you guys don't want to reinvent that also for all
operating systems.

Please, note that I said "porting of an XML publishing framework", not
an XSLT processor. Everyone on this list knows the difference between
Cocoon and XT servlet mode: while XT servlet mode allow you to call XT
via browser instead of via command line, Cocoon aims to give you a tool
to write your complete web apps with. Big difference.

I do see the birth of a native mod_xslt for apache, but only when
layered I/O arrives in Apache 2.1 (that will not happen anytime soon!).
It would be way cool to XSL-transform you XML page generated with Perl
or PHP, but the architecture is not there in Apache to allow you to do
that.

On the other hand, a full Apache-based native XML publishing framework
would require so many architectural changes in Apache that this will
happen only when the design issues about XML web publishing have
solidified. And this will not happen anytime soon.

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.

It makes much more sense, IMHO, to unify our efforts and integrate our
ideas and see how they combine, overlap, or don't fit. And doing this,
confront our visions of web-app creation and maintenance (there is
people on this list already thinking of porting other Apache web-apps
tools like Turbine and JetSpeed under Cocoon) also, I'll be involved in
defining the next generation Servlet API and JSP spec at Sun since they
are very interested in making them useful for these kind of complex
operations.

Cocoon needs substantial improvements on speed and usability to be able
to scale on a real-life XML web site. The Cocoon2 document on the web
site outlines all this. Also, close integration and cooperation with the
other xml.apache projects is a great resource we have.

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?

--
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche



Mime
View raw message