classpathx-javamail
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Classpathx-javamail] Rework of mbox provider


From: Chris Burdess
Subject: Re: [Classpathx-javamail] Rework of mbox provider
Date: Thu, 28 Apr 2005 19:47:23 +0100

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]