Re: [Classpathx-javamail] Rework of mbox provider

[Countach]

Chris Burdess wrote:

> This argument is specious. I can share a directory /home/dog/Public 
> over DAV such that it is can be accessed via 
> http://10.112.20.32/Public/, http://127.0.0.1:8080/~dog/, or 
> file:///home/dog/Public. Does that make all these the same "thing"? 
> No, they're all mediated in some way: some may be more or less 
> accessible depending on where you are and who you are.


Yes, network protocol resources can be considered to be "mediated". 
However one doesn't usually consider file system resources to be 
mediated. Files exist on bits of media. You put them on memory sticks 
and put them in your pocket. You then plug them into some random 
computer of unknown architecture, and you expect Java Mail to keep your 
folder names the same as what they were on some other architecture. If 
all you wanted to do is be subject to local OS directory conventions, 
then you would just open each mbox file separately, instead of letting 
JavaMail give you the illusion that a directory structure is actually a 
"store", and buying you OS and respository independence.

> Relative URLs /are/ really URLs, but I'm not talking about that (and 
> they are not modelled by javax.mail.URLName).


As far as I see, to be sensible, absolute URLs _have_ to be absolute, 
and relative URLs _have_ to be relative. And since URLName does not 
model relative URLs, then getURLName() should return an absolute URL. 
Absolute not just in form, but in fact.

> In the code for the Folder class you can see that the path component 
> of the URLName returned by getURLName is, by default, simply the full 
> name of the folder -  which means it should be relative to the root of 
> the store /if/ getFullName is. 


Yes, but in the Folder class it will include the host, port etc etc, so 
there is nothing "relative" about such a URL.

> Folders are not constrained to reside under the root hierarchy of the 
> store, though.


That is the clinching argument then. You cannot make URLNames relative 
or they would be ambiguous. If you have two directories "/foo" and 
"/home/mail/foo" and you open "/home/mail" as a store, thenyou have no 
way of knowing if mbox://foo   means a folder that is absolute, or 
relative to the store.

> I actually feel this is a bit of a weakness in the design of JavaMail. 
> Ideally you want the URLName to be absolute, so that you can get to a 
> particular folder given just a URLName, instead of a URLName plus 
> potentially other configuration information (store URLName, specific 
> session properties).


I'm not sure I see the point, what session properties one would needed 
if you make the URLName absolute.