cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [C2] Sitemap revised again
Date Wed, 21 Jun 2000 22:37:19 GMT
Giacomo Pati wrote:
> 
> Stefano Mazzocchi wrote:
> >
> > Giacomo Pati wrote:
> > >
> > > --- Stefano Mazzocchi <stefano@apache.org> wrote:
> > > >
> > > > Now, I propose to use the java.net.URL method to do this.
> > >
> > > Can we make the URLConnections classes pluggable as CocoonComponents (to define
a protocol like
> > > sap://sapmachine.my.org") without restarting the JVM? If so, they should be
plugged in into
> > > cocoon.xconf and not in sitemap.xmap because of security reasons.
> >
> > Hmmm, not sure if we can use the java API URL subsystem.... I'm afraid
> > we have to clone our own to be able to have multiple cocoon instances in
> > the same JVM and stand the classloading problems.... but I didn't get
> > deep enough to answer on Java2. (for java1.1 this was definately not
> > possible)
> 
> Ok, cloning URLConnection of standard protocols and writing new ones for
> protocols not supposted by Java (ie CVS), right?

Yes. Hopefully calling what already exists. The HTTPURLConnection is a
real pain in the ass to write... while the FileURLConnection (on both
1.1 and 1.2) doesn't implement the last-modified-time call and this
forced me to use both File and URL in Cocoon1 (which ended up having to
cast Objects to one or the other in different cases... yuck...)

Also there are protocols I could not find a reason for.... for example
"verbatim:"??? what the hell is this? what's the difference between
"doc:" and "file:"?

All these things sounds like HotJava leftovers. The problem is they are
_NOT_ part of the standard Java API so we might break things if we run
on non-Sun-based JVMs like Kaffe or Japhar (not that I really care given
their quality... but worth considering).
 
> > > Now we have more than one Factory which generates or compiles code the next
question is "should we
> > > compile the hole Sitemap"? I remember this was metioned some times ago.
> >
> > Not a big deal, the sitemap can be compiled into one class and each test
> > into other classes.... the sitemap is compiled to call these other
> > classes thru proxies that compile the tests when needed...
> 
> Why you propose to compile the tests when needed? Shouldn't they be
> compiled when the sitemap will be regenerated and compiled?

How? the matcher/choosers are pluggable, and they are the only one that
_know_ the semantics of the test/patterns they use. How can we compile
those tests if we don't know the logic behind them?

The code factories I proposed generate code for the entire class....
yes, they could generate code for a single method just as well...
hmmmm.... I'm afraid of creating too many contracts between the sitemap
and the matchers....

Ricardo, any comment about code generation compilation of
sitemap/matchers/choosers?
 
> >
> > I know, kind of complex, but we need to take speed into serious
> > consideration...
> 
> I can imagine thatthe complexity of the Sitemap class itself could be
> reduced when it is generated into a java source.

Oh totally. In fact, if I had to write a sitemap interpreter, I'd write
a sitemap "class" that hardcodes the XML sitemap then create a XSLT
stylesheet to transform the XML into the code. This is _way_ much easier
than creating all the "sitemap interpreting" code and tune it for speed.

Maybe it's becoming the golden hammer for me, but I'm so lazy that XML +
XSLT + javac are much better at writing interpretation software than I
am :)

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



Mime
View raw message