Well, we should not change the spec just because some Java class is broken, and some other not ;-) The question of replacing URLs with URIs came up, however, mainly for the reason that URIs would allow unicode characters in file names etc. That would on the other hand break compatibility with other OGF standards, where filenames are expressed as URLs, not URIs. Anyway, that indeed is still an open point. Cheers, Andre. Quoting [Rob van Nieuwpoort] (Sep 19 2007):
Hi,
In JavaGAT, we use URIs, not URLs... As far as I know, Java URIs do not suffer from any of the problems that Jon mentioned. Maybe that is a good idea for SAGA as well?
Cheers,
Rob
Andre Merzky wrote:
Cools features indeed...
As far as I know, Rob did a couple of fixes to the Java URL class for the JavaGAT - I guess they dealt with those kinds of problems, and, IIRC, also fixed the parsing of absolute/relative paths (http://host/dir/file vs. http://host//dir/file).
Anyway, as you say, thats something which can be done within the implementation - the URL class would still be useful to get the data from application space, and to do parsing and some sanity checks. So, it would not solve problems, but simplify the application code.
Andre.
Quoting [Jon MacLaren] (Aug 30 2007):
Cc: SAGA RG <saga-rg@ogf.org>, Ceriel Jacobs <ceriel@cs.vu.nl>, Rob van Nieuwpoort <rob@cs.vu.nl>, Hartmut Kaiser <hartmut.kaiser@gmail.com>, Ole Christian Weidner <oweidner@cct.lsu.edu> From: Jon MacLaren <maclaren@cct.lsu.edu> Subject: Re: [SAGA-RG] URL class in SAGA? To: Andre Merzky <andre@merzky.net>
But there are problems with the Java URL Class - it has some very odd behavior.
When you create a URL, there is an attempt to lookup the host name. Two URL objects created from the same identical address, e.g.
https://scoop.cct.lsu.edu:9877/ocracoke
...but at different times (e.g. once when the host could not be looked up, once when it could) can produce different hash values. So if you use these objects as keys in a HashMap, they can sometimes fail to lookup properly.
Worse, when invoking equals on two URLs, host lookups are again resolved. If your DNS server is down, the comparison can hang - this depends on the underlying OS's behavior. On Linux this used to hang indefinitely until the server came back!
I've discovered these features over a period of a couple of years. They are horrible.
You should seriously consider using strings in an underlying Java implementation - maybe creating a URL object just to do the format checking, then throwing it away.
Another nice feature, is that Java, by default, will cache DNS lookups forever, i.e. until the application finishes. If this is a Tomcat container, then you won't see legitimate DNS changes until the container is restarted. That could be months at a time. To change that, you have to edit java.security - which is a machine-wide change for all applications.
Nice.
Jon.
On Aug 29, 2007, at 7:41 PM, Andre Merzky wrote:
I seem to remember that the topic of an URL class was, once upon a time, discussed by the group, but I can't find any notes nor mails about it.
From what I remember, the consensus was that several languages do have a native URL/URI class (e.g. Java), and that then the language bindings should allow to use these classes instead or additionally to strings.
However, Ole and Hartmut argued that the C++ bindings should have an URL class, too, as the task of generating and parsing teh URLs would be left as a tedious excercise to the end user.
Now, if we are going to specify URL classes for basically all bindings, then we may as well consider to use a simple URL class in the spec. OTOH, that might be overkill, and the bindings may be just the right place to deal with that topic.
As I am blessed with a very poor memory, I really can't remember if that was discussed already, or if I for example was opposed to an URL class myself :-P Anyway, I'd like to raise the question (again), and would love to hear your opinions.
Thanks, Andre.
PS.: _if_ we would include an URL class in the spec, I'd insist on keeping it as simple and small as possible. No need for fancyness here - setters and getters for the URL elements is all what we basically need, right?
-- "XML is like violence: if it does not help, use more."
-- saga-rg mailing list saga-rg@ogf.org http://www.ogf.org/mailman/listinfo/saga-rg
-- No trees were destroyed in the sending of this message, however, a significant number of electrons were terribly inconvenienced.