Quoting Donald Ball <[EMAIL PROTECTED]>:
> On Tue, 29 May 2001, giacomo wrote:
>
> > > > The context and resource protocols should match the semantics for
> > > > file and jar:
> > > >
> > > > context://relative/path/from/context/root
> > > > resource://path/to/packaged/resource
> > >
> > > why don't we go ahead and enumerate all of the extra protocols
> recognized
> > > by c2 and their semantics, and stick them in a document for
> reference.
> > > i'll take a stab:
> > >
> > > context urls point to xml resource pipelines relative to the root of
> the
> > > current sitemap. the same context url in two seperate sitemaps can
> resolve
> > > to two seperate pipelines. format: context://{path}
> >
> > The context protocol point into the file system and not to resource
> > pipeline. But yes, the same context url in two seperate sitemaps can
> > resolve to two seperate files. format: context://{path}
>
> and it's always relative to the location of the current sitemap's map
> file?
Sorry, yes, it's how it should be but am not sure if the implementation respects
this (IIRC it always resolves to the root of the servlet context). The early
design decision was that the EntityResolver represented by the Environment
object should take care of this but recent changes has deluted that approach.
That's why the Environment interface has methods like setPrefix etc. to make it
able to resolve correctly in case of sub sitemap mounts. I'm unsettle if
I should fighting for old design decision because I don't remember exactly why
this or that decision has been taken and it can truly be that I'm wrong today,
so, do what you think is correct here.
> > > cocoon urls point to xml resource pipelines relative to the root of
> the
> > > current webapp. the same cocoon url in two seperate sitemaps always
> > > resolves to the same resource pipeline. format: cocoon://{path}.
> >
> > Not sure here. As your first isn't how you thought which one is
> relative
> > to the current sitemap and wich one is not. As this protocol is not
> > implemented yet we can model it in the way we like it.
>
> what is it's intended purpose then? if it's _not_ what i've described,
> i think we need to add something to do what i've described - maybe the
> webapp:// protocol?
The main problem is that all custom protocol served by the URLFactory so far
resolve into a byte stream but the special cocoon:// protocol should resolve
into a SAX stream for performance reasons. If you find a common interface for
the URLFactory which combines both worlds your a real smart guy :)
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
