commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giorgio Gallo <giorg...@overlord.it>
Subject [JELLY] exotic URL protocols
Date Mon, 11 Apr 2005 18:30:02 GMT

I am trying to write a patch to solve issue JELLY-208
(http://issues.apache.org/jira/browse/JELLY-208)

Let me know if you committers prefer to handle this one directly,
because of the fact that URLs contain "/" beeing assumed just about
everywhere in jelly... :)

Also:

Thomas Burns (the issue reporter) mentions a "custom url protocol".

It is not needed for the specific issue to manifest (think of
"file:script.jelly") to have a custom protocol, but it could be the case
 that a protocol does not use the "usual" URL pattern
(protocol://user:password@host:port/path...) and that therefore we (ie:
jelly) cannot resolve relative URLs simply by parsing the string
representation of the base URL and assuming it has more meaning that
protocol:opaquePart...

Besides modifying jelly to ALWAYS use
	new URL(URL, String)
to resolve relative URLs, another fact should/could be addressed: it
could be impossible in some protocols to infer the "parent" URL of a
script from the script's own URL (ie: it's what
JellyContext#getJellyContextURL does)


I see a few options to address this:

1. The "protocol:<opaquePart>" thing above comes from some confused
corner of my head and I have to read RFCs again :)

2. Declare those "exotic" protocols unsupported :)

3. Refactor jelly to use a script's very url (eg:
file:///dir/dir/script.jelly) to resolve relative URLs and remove
auto-detection of "context URLs" altoghether (ie: context-relative URLs
will be resolved against the script URL unless a different context URL
is explicitly specifyed)

4. use null as context url when there are no "/"s and assume the usual
URL pattern if a "/" is present


I would opt for the third possibility (really - can't see any drawback
in it, not at 4:00AM at least).

Please let me know if such a patch would be welcome or, again, if it's
like you committers prefer to handle this on your own.

(please pardon me if my english is not very clear)

rgds,
Giorgio




---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message