Re: Rework of mbox provider

Chris Burdess <[email protected]>
Newsgroups gmane.comp.java.classpath.extensions.javamail
Message-ID <[email protected]>
Countach wrote:
>> In which case it is not the same store.
>
> If I access the exact same "store" both on a local Unix machine, and 
> also via a Windows machine over a Samba mount, why is it not the same 
> "store"?

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. In the same sense, "store" 
in JavaMail simply means "the thing returned when I provided this 
configuration". The W3C's technical architecture group provides good 
explanations of these issues:

   http://www.w3.org/TR/webarch/
   http://www.w3.org/2001/tag/doc/toc

>>> No good. The getURLName function returns the absolute pathname of 
>>> the mbox where it happens to be mounted on this particular machine 
>>> at this particular time.  The getFullName function on the other hand 
>>> is meant to return the name of the folder RELATIVE to the root of 
>>> the hierarchy. This is the string that could be potentially be 
>>> platform independent if it was so designed.
>>
>>
>> You're partially right, but getURLName should also yield a pathname 
>> relative to the root of the hierarchy. Neither of these is currently 
>> the case with the mbox folder, but I will correct both.
>
>
> I don't think this is correct.  If you look at the Java code for the 
> Folder class, you can see that the URL returned is very clearly an 
> absolute URL, not a relative URL. In fact, I'm not even sure if the 
> URLName class supports constructing relative URLs according to the RFC 
> 1808 standard. Relative URLs aren't even really URLs as such.

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

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. Folders are not constrained to reside under 
the root hierarchy of the store, though.

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).
-- 
Chris Burdess
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.