Can be downloaded from ftp://www.crystalballinc.com/pub/vlad/nsmail.tar.gz
That sounds pretty cool. I have two questions: If you've bound the interface to the client library, does that mean that a client can connect to it as Jonathan suggests? Or does it mean that the web server can now treat IMAP servers as a data source?
If it's the former, then I think using IMAP folders could also be a pretty good second option for file-storage. Does that sound possible?
I wouldn't think of this as a replacement for the way file storage does stuff (for large content clearly the way to go is to use the option to map content to the server's file system).
But it would provide a nice layer to write a webmail package on top of, and would make integrating IMAP content and non-IMAP content in a package a snap.
This is all transparent to client packages like file storage.
Implementing CR mapping to IMAP doesn't exclude the possibility of mapping to DAV or whatever.
With the CR mapping to IMAP it would be possible to present seamless file and mail views to the user from file storage, but file storage isn't where the work should be done.
I believe we've got some nomenclature issues in this discussion. Dave W and I were talking about implementing different _front_ ends to be able to browse oACS data... not about changing the storage structure on the back end or bypassing the CR mapping.
Imagine double clicking a folder icon from within Ximian's Evolution and browsing file-storage data, or mounting a WebDAV folder in Windows Explorer that links to the same data.
I misunderstood Vlad's original post and thought that this was possible, but in hindsight my question didn't make sense. Using an IMAP server to proxy file-storage data is probably not worth it and clearly not what Vlad intended.
In general, I find getting to oACS data w/non-browser clients via RSS/WebDAV/NNTP/IMAP/Jabber/etc pretty intriguing, and that motivated my wishful thinking.