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 Fri, 17 Dec 1999 15:39:54 GMT
"Stephen R. Savitzky" wrote:
> 
> Stefano Mazzocchi <stefano@apache.org> writes:
> 
> > 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 :)
> 
> You might want to look at what we've done in the PIA for this (after we get
> it documented...).  It involves an optional XML description file in every
> subdirectory of the site, rather than a single massive site map.  You could,
> in theory, use a single massive DOM tree to represent the map internally,
> but for large sites that would probably be a disaster.

The Sitemap discussion will start right after this, so welcome on board:
we need all the help we can possibly get :)
 
> > > 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.
> 
> It's no surprise.  Sounds like something either Greg or I might have written
> based on an earlier, very sketchy and superficial analysis.  I just looked
> for that passage myself (using find and grep) and can't find it, either, so
> it was probably in an earlier draft of something.  I apologise for both of
> us.

No need to apologize, this was probably due to lack of communication and
this is something that is always bad. I'm really happy we can discuss
things together, now.
 
> > 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.
> 
> [detailed explanation omitted -- many thanks!]
> 
> Our approach to implementation is also layered, but differently: the idea
> was to build a complete scripting language using XML syntax and a minimal
> set of primitives, then use _that_ to build the other layers.

Yes, this is the key different and I must be brutally honest to you: I
don't like it at all, probably as much as you don't like to mix code
with XML.

But I have a big point on my side: it's possible to write a complete XML
mapping to a turning complete progamming language in XSP, any supported
programming language. PIA approach, in a wide sense, is a special case
of the XSP approach.

I'm not saying your approch doesn't make sense, not at all, I do see
uses for it, but I would do it on top of XSP with a logicsheet. Nothing
changes from a user perspective, but it's a lot easier to maintain the
development given the very clear separation of contexts.

> > 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.
> 
> There's a certain amount of history involved.  The PIA, in its various
> incarnations, has been around since before the XML spec came out, and it's
> already been through several major rewrites.  The first version was in
> PERL, and the Java version of the document processor has been totally
> rewritten once, and extensively revised several times after that.
> 
> As I've mentioned, our idea was to build a small, solid processing engine
> that implements a complete language, then build on top of that -- in XML.
> Once you get above the base layer, the language you used to implement the
> processing engine shouldn't matter.  (Any LISP hackers reading this?  If so,
> you'll find the basic idea very familiar.)

In a perfect world that would be the truth. Unfortunately...
 
> > 2) All the major XML/XSL tools are written in Java. Porting all of them
> > is an _incredible_ effort.
> 
> ... but of course, it _does_ matter if you want to integrate it with
> existing tools.  As you say, most of the XML tools are being written in Java
> these days, but a lot are being ported to C and C++, too.  And there's a
> long tradition of SGML tools, including Expat and SP, in C and C++.

Sure. That's my point: use the language that fits your needs best. I
find Java to be that language today, but I might change my mind later
on.
 
> Furthermore, C is a lot easier to integrate with Apache.

with Apache 1.3? totally. With Apache 2.0? things might change.
 
> That said, and as Greg also mentions (in a message he apparently sent while
> I was working on this one), we have _no_ intention of abandoning the Java
> version.  Ideally, we'd end up with a small XML-based language that we can
> drop into _lots_ of different systems, no matter _what_ language they're
> implemented in.

Cool.
 
> > 3) JVMs are getting faster every day. Hotspot-based or native-compiling
> > JVMs do reduce the speed issues.
> 
> They do a lot less to reduce the space problems, and some of the
> applications we're considering are on very small embedded machines (for
> which, in some cases, no JVM exists).

True. Great point. I totally admit I haven't considered that market :)
 
> > 4) there are no SAX API for other languages rather than Java and
> > incremental operation is the key for scalable XSL engines.
> 
> A C++ version is being discussed in xml-dev.  Kind of moot, because the PIA
> doesn't normally use SAX -- it uses a parser that has the API of a parse
> tree traverser.

For us APIs are vital since we are lazy, we don't get paid and we want
to reuse what's around. I won't move where there's no solid API since I
don't want to rewrite stuff I already use :) (also, it's very
appreciated the ability to plug in your favorite parser/processor and I
love that too)
 
> > 6) everyone is moving toward java for web apps, going the other
> > direction just for speed is nonsense.
> 
> Not just for speed, and not just for size, either.  It's a mixture of both,
> plus the ability to integrate with other software that _isn't_ in Java yet,
> and may never be.  And I don't think _everyone_ is moving toward Java, only
> the ones who are trying to get away from C++ (myself included).  I'm getting
> really good comments about Python, and Squeak is pretty nice, too.

Oh, yes. Sorry, my focus in on web apps for web sites. Also, I didn't
want to put down any other language, but the power of java are its
portability, code availability and most important API. The strong APIs
are the winning part, IMO, against other "web languages". but I'm biased
so just dicard my comments when I confront java with other languages :)
 
> > 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.
> 
> If you're doing that I'm impressed, but I don't think it's necessary in most
> cases -- it might be sufficient to do all your stylesheet compilation
> offline, and relink the server once in a while.  Going in the other
> direction, there are some languages where on-the-fly compilation is even
> easier to do than in Java: Perl, Python, Smalltalk, and LISP for example.

True, that's why we have multi-language support for XSP in the first
place :)
 
> On the other hand, if the basic processing engine is sufficiently fast, you
> might be better off ``compiling'' pages and stylesheets to parse trees or
> specialized byte codes.  That's where I see the PIA heading: a really fast,
> dead-simple processing engine that doesn't require compiled pages for its
> efficiency.  I think it would be hard to do an XSL transform engine with
> that degree of efficiency, but the PIA's language is a lot simpler.

You mean your pages will output HTML directly? with no further
transformations? I hope I have misunderstood you.
 
> > 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.
> 
> We're clearly aiming toward the same goal here -- I want to be able to write
> my entire web application in XML.  And I'm quickly learning what, as you
> say, everyone on this list already knows.

Good.
 
> > 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.
> 
> I think that may only be true if you insist on keeping the XSL engine in
> Java.  But I could be wrong, too -- that's why we're spinning off the
> processing-engine port as a SourceXchange project.

Good point. Anyway, there is already a C++ XSLT engine in Mozilla
(written by an old time Cocoon friend and developer Keith Visco) and
Lotus has one that will be donated to xml.apache. We'll evaluate the
possibility to use JNI to a native processor if that gives enough
performance improvement.
 
> > 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.
> 
> I agree.  I think our projects have a lot to give to each other, and I'm
> looking forward to spending a happy couple of months trying to figure out
> where they fit together.  I'll admit that I was pretty skeptical before I
> joined this list -- I'm very glad I did.

I am too. :)

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