cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Russell <p...@luminas.co.uk>
Subject Re: Proposal: URL Protocols
Date Tue, 30 Jan 2001 17:25:03 GMT
* Berin Loritsch (bloritsch@apache.org) wrote :
> Paul Russell wrote:
> > * Berin Loritsch (bloritsch@apache.org) wrote :
> > > I want to run something by the list regarding the way
> > > Cocoon uses URLs to get references to files and such.
> > > This _does_ affect both versions, and it refers to the
> > > naming of the protocols.  The way Servlet 2.2+ specifies
> > > to get files from the WAR file is the context.getResource()
> > > method.  All resources are relative to the context root.
> > > This is separate and distinct from Classloader Resources.
> > > My proposal is to specify the following Resource protocols:
> > > "resource:" This gets a ClassLoader resource, loaded by
> > >             the Cocoon ClassLoader.  This is what it already
> > >             does.
> > > "context:"  This gets a Context resource, pulled by the
> > >             Context.getResource() method.
> > Yep. Works for me. +1. How do you propose implementing this? Using the
> > standard URI api I assume?
> That would be the long term plan.  The alternative would be to do
> what is already done in the NetUtils class.  Anyone have experience
> creating URL Handlers?

Nope, but I know a little about it. From what I know, I suspect the
main sticking point is getting Java to use the darned things. There
are two ways to automatically use them - one is to put them in a
specific package (um. sun.net.www.url.<protocol>? Can't remember),
and the other is to set a system property to point at a particular
package of URL handlers (org.apache.cocoon.url?) and place them in
there. I'd rather we used the second if that doesn't cause any
problems elsewhere, because namespace pollution is always a bad thing,
and I don't remember being a sun employee ;)

> > > The only section that would require any file:// urls is the
> > > XSP architecture.
> > For the code generation and compilation, I assume? God I'd like a
> > java compiler than can take streams to compile with. (better still,
> > parse trees <grin>)
> Yep.  My definition of the dream compiler:
> Ability to use the loaded ClassPath (no more parsing of the classpath
> attributes), ability to use streams (java input stream, and class
> output stream).
> That way we won't need the repository at all (except for debugging
> purposes)--as we can directly serialize the XSP java stream into
> the compiler and directly load the class by stream into the
> classloader.

Via a cache living in a Store, obviously <grin>.

> The less we have to operate with the filesystem the better.  I would
> love to see the Jikes people add a JNI interface that would allow
> use to do just that!  We would get speed and elegance.

Yeah.

Are there any compilers out there that have this kind of power? I've
done a fair bit of compiler theory, and it taught me one thing above all
else: don't write compilers if you don't have to :)


Paul.

-- 
Paul Russell                                 Email:   paul@luminas.co.uk
Technical Director                             Tel:  +44 (0)20 8553 6622
Luminas Internet Applications                  Fax:  +44 (0)870 28 47489
This is not an official statement or order.    Web:    www.luminas.co.uk

Mime
View raw message