cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: Context:// issue
Date Tue, 29 May 2001 21:12:48 GMT
Giacomo Pati wrote:

> Quoting Donald Ball <balld@webslingerZ.com>:
> 
> 
>>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 :)
> 


XMLByteStream as could be produced by XMLByteStreamCompiler if slightly 
modified to deliver a ByteStream could do. On the other side of the url, 
of course, a slightly modified XMLByteStreamInterpreter should be used.

While it has a slight performance cost, it would keep ByteStreams in 
protocols and allow remote connections (so don't drop the host:port part 
yet). I have versions of those classes that do precisely this, and also 
correct a very unlikely bug I found there.

Did I earned something? I had to bend myself quite a lot to see it.


> Giacomo
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 
> 




---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message