Giacomo Pati wrote:
> 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 :)
>
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: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
