RE: [RT] i18n in Cocoon and language independent semantic context s

[Paul Lamb <pa...@oil-law.com>]

BTW, Stephano, what's your native language? Your command of english is
better than most of the college gradutes that I've been interviewing lately
here in the U.S.

> 
> Also, how can we simplify the sitemap evolution without 
> compromising the
> rest of the system?

Or, "How can we design both the sitemap and the engine to expect
evolutionary changes? What about revolutionary ones?"

I've been thinking for a while now about how put cocoon and a web/servlet
server into a cohesive whole; and have wondered more than once if this
question or evolution ever came up in the servlet 2.2 spec discussions.
IMHO, web.xml just doesn't have the simple elegance of either the currently
proposed cocoon2 sitemap or ant build.xml files.

> 
> I think a possible solution is sitemap pluggability and compilation.
> 
> You could think at the sitemap like a big XSP taglib that is 
> responsible
> to drive directly the execution of the resource creation pipelines.
> 

This reminds me of going to the doctor about something and him saying, it's
no big deal, you won't even need surgery to fix that. And then you go back
the next week, and he's looking at your test results and says, we may have
to think about surgery. And then about a week later his nurse calls and
wants to know when you want to schedule the surgery.

You've done a great job over the last couple weeks of helping convince most
of us that we should stick to a fairly straight-forward declaritive sitemap.
BUT, I'd really like to see this idea develop further.

It seems to me if we are going to have a pluggable sitemap then we need to
define the engine interfaces that connects it to the sitemap component. Once
you've done this, then having either sitemap design becomes "just an
implementation detail". The first thought that comes to mind here, is
something like a valve pattern, like Craig's done with catalina.

> It would also increase performance, since matching could be optimized
> and what not.

I'd need some more info before I used this as a selling point. If one
created their own sitemap as opposed to compiling one via something like
xsp, I can see some possibilities for performance increases.

> 
> It would also allow different sitemap schemas to be developped. In
> theory, you could create your own sitemap schema.
> 

IMHO this would be great! I would love to see a dozen or more sitemap
implementations. You could have the one that passes the "girl friend test"
and at the other end of the spectrum ones that compete in the "obfuscated"
sitemap competition.

> Well, this collection of RT is admittedly wild.
> 
With the number of great ideas that happen on this list, I'm really hoping
that get wilder.

Paul Lamb

Re: [RT] i18n in Cocoon and language independent semantic contexts

[Stefano Mazzocchi <st...@apache.org>]

Paul Lamb wrote:
> 
> BTW, Stephano, what's your native language? 

Oh, gee, this is a lost cause... my name is Stefano, pronounced as
"Stéh-fan-o" NOT "Ste-phà-no", grrrr

My native language is italian.

> Your command of english is
> better than most of the college gradutes that I've been interviewing lately
> here in the U.S.

Uh, that's a big compliment, thanks a lot.

I learned American English in the US during my exchange student year (in
Florence, OR), but I improved it by orders of magnitude during my last
three years of continuous open source involvement.

> > Also, how can we simplify the sitemap evolution without
> > compromising the
> > rest of the system?
> 
> Or, "How can we design both the sitemap and the engine to expect
> evolutionary changes? What about revolutionary ones?"

Ouch, touched a nerve here.
 
> I've been thinking for a while now about how put cocoon and a web/servlet
> server into a cohesive whole; and have wondered more than once if this
> question or evolution ever came up in the servlet 2.2 spec discussions.
> IMHO, web.xml just doesn't have the simple elegance of either the currently
> proposed cocoon2 sitemap or ant build.xml files.

Cocoon introduced a big improvement over the Servlet API: an elegant
component model.

The sitemap is just the final arrival of many different tries to drive
this component model and web.xml was designed too early, but the changes
in the servlet api would be too big to address all the things Cocoon
added to the servlet model.

In some sense, Cocoon is a web server where its modules are created by
pipelines of components and transport between components is event-based.

What's the best way to integrate it? Apache should become a native
version of Cocoon? Should Tomcat? Should Catalina?

I have no idea, but I'm doing something.

I do plan to use Catalina-specific hooks when it becomes mainstream.
(Catalina is the codename for what many believe it will be Tomcat 4.0)
This would allow us to use sitemap.xml "instead" of web.xml for
cocoon-based applications.

I talked with the Apache guys to add SAX capabilities to Apache 2.0
Layered I/O architecture (even if most of them don't have a clue of what
I'm talking about!). This would allow to create a native Cocoon clone
directly into Apache.

I proposed the addition of direct SAX I/O for the Servlet API 2.3. This
would allow Cocoon to postprocess JSP or use regular servlets as XML
generators.

> > I think a possible solution is sitemap pluggability and compilation.
> >
> > You could think at the sitemap like a big XSP taglib that is
> > responsible
> > to drive directly the execution of the resource creation pipelines.
> >
> 
> This reminds me of going to the doctor about something and him saying, it's
> no big deal, you won't even need surgery to fix that. And then you go back
> the next week, and he's looking at your test results and says, we may have
> to think about surgery. And then about a week later his nurse calls and
> wants to know when you want to schedule the surgery.

Am I the doctor or the disease? :)
 
> You've done a great job over the last couple weeks of helping convince most
> of us that we should stick to a fairly straight-forward declaritive sitemap.
> BUT, I'd really like to see this idea develop further.
> 
> It seems to me if we are going to have a pluggable sitemap then we need to
> define the engine interfaces that connects it to the sitemap component. Once
> you've done this, then having either sitemap design becomes "just an
> implementation detail". The first thought that comes to mind here, is
> something like a valve pattern, like Craig's done with catalina.

Exactly.

A sitemap is, in fact, a servlet. You just have to implement one method:

 service(Request, Response, Context);

what I'm proposing is to create code around this so that you can write
your sitemap using simple XML markup instead of writing complex java
code.

Also, keeping all the juicy logic into general components or pipeline
components.
 
> > It would also increase performance, since matching could be optimized
> > and what not.
> 
> I'd need some more info before I used this as a selling point. If one
> created their own sitemap as opposed to compiling one via something like
> xsp, I can see some possibilities for performance increases.

In theory, you could directly program your sitemap in Java code. It
would turn out something like

 if (matcher.matches(request.getURI(), "/news/today") {
   call(newsGenerator, request, response);
   call(xsltFilter, newsXsltFilterParameters, request, response);
   call(htmlSerialiser, request, response);
 } else if (...) {

and so on.

And incredibly boring and error prone task.

We might provide the equivalent of XSP functionality to resource
componentization and matching. So the above can be written as

 <process uri="/news/today">
  <generator type="news"/>
  <filter type="xslt">
   <param name="stylesheet" value="news.xslt"/>
  </filter>
  <serializer type="html"/>
 </process>

which is _much_ easier to write, understand and maintain, but doesn't
add interpretation overhead since the whole sitemap is already compiled
and the JVM can optimize hotspots.
 
> > It would also allow different sitemap schemas to be developped. In
> > theory, you could create your own sitemap schema.
> >
> 
> IMHO this would be great! I would love to see a dozen or more sitemap
> implementations. 

I honestly don't :)

> You could have the one that passes the "girl friend test"
> and at the other end of the spectrum ones that compete in the "obfuscated"
> sitemap competition.

Hmmm, this will create pain in Cocoon users that need to choose what
sitemap schema to use before having played with the technology.

I think of this more as a "last resort" type of thing and mainly for
ourselfs developers: to simplify development of the sitemap interpreter.
 
> > Well, this collection of RT is admittedly wild.
> >
> With the number of great ideas that happen on this list, I'm really hoping
> that get wilder.

:-)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------