nnimap RFC2342 support (IMAP4 Namespace)

nnimap RFC2342 support (IMAP4 Namespace)

[Steven E. Harris]

When I've had to move folders around on different IMAP servers, I've
run into problems with nnimap's treatment of folder
names. Specifically, nnimap requires the user to specify the folder
name *as it's implemented* on the IMAP server, rather than as a more
abstract path. As an example, where I once had

  nnimap+speakeasy:mailing-lists/gnus-ding

my ISP changed servers and I had to manually move that to

  nnimap+speakeasy:INBOX.mailing-lists.gnus-ding

while MS Outlook just figured out the change without trouble. (Sorry
to hold Outlook up in a positive light.)

Today I stumbled upon RFC2342¹ - IMAP4 Namespace - that looks like it
addresses this exact problem. Has anyone taken a look at this to see
how hard it would be to add support to nnimap?


Footnotes: 
¹ http://www.rfc-editor.org/rfc/rfc2342.txt

-- 
Steven E. Harris        :: steven.harris@tenzing.com
Tenzing                 :: http://www.tenzing.com

Re: nnimap RFC2342 support (IMAP4 Namespace)

[Simon Josefsson]

On 31 Jan 2001, Steven E. Harris wrote:

>   nnimap+speakeasy:mailing-lists/gnus-ding
>
> my ISP changed servers and I had to manually move that to
>
>   nnimap+speakeasy:INBOX.mailing-lists.gnus-ding
>
> while MS Outlook just figured out the change without trouble. (Sorry
> to hold Outlook up in a positive light.)

Hm, what does "figured out the change" mean?  When a IMAP mailbox name
change, everything a mail clients knows about the mailbox must be
discarded.  Everything else would be asking for trouble...

What would a good solution be?  Gnus automatically detect when a
group has gone missing, and tries to see if various combinations
of the name has magically appeared?  I probably don't understand what
Outlook really does here.

> Today I stumbled upon RFC2342¹ - IMAP4 Namespace - that looks like it
> addresses this exact problem. Has anyone taken a look at this to see
> how hard it would be to add support to nnimap?

imap.el implement NAMESPACE, but I never found a way to make use of
it in nnimap.  Suggestions welcome.  The point is that Gnus probably
need to grok this concept for things to work.  I'm not sure I see
how NAMESPACE [1] would solve your problem, but re-reading my rants
above I probably didn't understand the problem.

One way to support NAMESPACE would be to connect backends with
topics.  So you would have this group topology populated automatically:

[nnimap:foobar]
  [private mailboxes]
  nnimap+foobar:INBOX.ding
  [shared mailboxes]
  nnimap+foobar:bb.dong
  [newsgroups]
  nnimap+foobar:#news.dang

but I'm not sure that's really an important feature.  The
nnslashdot<->topic coupling has made the idea a little more
interesting, but when I suggested it a long time ago, most
people thought they'd like to organize their own topics.

Hm, re-reading an old discussion on NAMESPACE [2] indicate
NAMESPACE could be nice in *server* buffer, I think this is the
most interesting prospect this far.

Ah well, enought rants. :)  What do you think?

[1] NAMESPACE is only a way for the server to indicate what kind of
mailbox hierarchies there are.  All it does is saying "All your
private mailboxes begin with INBOX", "All your newsgroups begin with
#news", "All shared folders on this server begin with bb."

[2] http://vic20.blipp.com/extundo/.nnimap-list/199810/msg00041.html
    (No, that's probably not the best URL for it :-))

Re: nnimap RFC2342 support (IMAP4 Namespace)

[NAGY Andras]

To be honest, I have no idea what the IMAP NAMESPACE thing is good
for.  But it would be a really nice feature (however implemented) if I
could say "on this (cyrus) server all but one of the mailboxes have a
name starting with `INBOX.'.  I don't like this, so please let me name
my mailboxes whatever I want, and prepend this prefix automatically,
at low level, when sending it to the server, and remove it on the way
back.  Do this on all the mailboxes except for the special one
`INBOX'."


Andras

Re: nnimap RFC2342 support (IMAP4 Namespace)

[NAGY Andras]

NAGY Andras <nagya@inf.elte.hu> writes:

> To be honest, I have no idea what the IMAP NAMESPACE thing is good
> for.  But it would be a really nice feature (however implemented) if I
> could say "on this (cyrus) server all but one of the mailboxes have a
> name starting with `INBOX.'.  I don't like this, so please let me name
> my mailboxes whatever I want, and prepend this prefix automatically,
> at low level, when sending it to the server, and remove it on the way
> back.  Do this on all the mailboxes except for the special one
> `INBOX'."

One little addition after reading the NAMESPACE RFC:

This prefix could be figured out by issuing a NAMESPACE command, so
the user could say "the prefix for my personal mailboxes" instead of
"INBOX.".

Nnimap could introduce the `nnimap-prefix' paramter, containing either
a string (the prefix itself) or a symbol (personal, other, shared)
indicating a namespace class from which the prefix should be obtained.
Of course, the latter would yield an error if the namespace class in
question contains more or less than one namespace.


Andras

Re: nnimap RFC2342 support (IMAP4 Namespace)

[Steven E. Harris]

NAGY Andras <nagya@inf.elte.hu> writes:

> But it would be a really nice feature (however implemented) if I
> could say "on this (cyrus) server all but one of the mailboxes have a
> name starting with `INBOX.'.  I don't like this, so please let me name
> my mailboxes whatever I want, and prepend this prefix automatically,
> at low level, when sending it to the server, and remove it on the way
> back.  Do this on all the mailboxes except for the special one
> `INBOX'."

That's exactly what I was asking for. Additionally, there should be a
way to abstract folder "nesting." As my example showed, one server
allowed/permitted slashes, while the other required dots as
separators. On one server, private user folders can live alongside
INBOX. On the other server, those folders must be under the
INBOX. Conceptually, the folders are in the same place, though. I
thought RFC2342 enables that abstraction. The user thinks only of
INBOX, and a folder tree. The actual syntactic representation of that
tree may be server-specific, but RFC2342 allows the proper translation
to happen.

Maybe I'm projecting more hope into than it deserves. It just seems
that Outlook is able to maintain this single representation as far as
the user interface goes. Perhaps Gnus could do something similar.

-- 
Steven E. Harris        :: steven.harris@tenzing.com
Tenzing                 :: http://www.tenzing.com

Re: nnimap RFC2342 support (IMAP4 Namespace)

[NAGY Andras]

NAGY Andras <nagya@inf.elte.hu> writes:

> To be honest, I have no idea what the IMAP NAMESPACE thing is good
> for.  But it would be a really nice feature (however implemented) if I
> could say "on this (cyrus) server all but one of the mailboxes have a
> name starting with `INBOX.'.  I don't like this, so please let me name
> my mailboxes whatever I want, and prepend this prefix automatically,
> at low level, when sending it to the server, and remove it on the way
> back.  Do this on all the mailboxes except for the special one
> `INBOX'."

Are there any chances that this will be implemented?  Besides Outlook,
which may not be normative for you :), both Pine and Mutt allow the
user to specify some kind of `root path' (prefix) along with the IMAP
server, and access their mailboxes without the INBOX prefix.


Andras

Re: nnimap RFC2342 support (IMAP4 Namespace)

[Steven E. Harris]

Simon Josefsson <jas@extundo.com> writes:

> [1] NAMESPACE is only a way for the server to indicate what kind of
> mailbox hierarchies there are.  All it does is saying "All your
> private mailboxes begin with INBOX", "All your newsgroups begin with
> #news", "All shared folders on this server begin with bb."

Well, not quite. It also lets you know what the hierarchy delimiter
is. Given that, Gnus could see that

  foo/bar

is really the same as

  INBOX.foo.bar

on another server, provided that it stores these paths as lists rather
than literal strings. That, or it remembers the hierarchy delimiter so
that it could split, then reassemble a folder name on a new server
with a different delimiter. Here's some experimental code I was
playing around with:

==================================================
(defconst sep-display ":")
(defconst sep-orig "/")
(defconst sep-new ".")

(defun tokenize-string (str start sep)
  (if (string-match sep str start)
      (cons (substring str start (match-beginning 0))
	    (tokenize-string str (match-end 0) sep))
    (list (substring str start))))

(defun pedantic-replace (str sep-old sep-new)
  (mapconcat 'identity
	     (tokenize-string str 0 sep-old)
	     sep-new))

(defun get-current-ns-sep ()
  sep-orig)

(defun get-new-ns-sep ()
  sep-new)

(defun make-folder-display-name (folder)
  (pedantic-replace folder (get-current-ns-sep) sep-display))

(defun migrate-folder-name (folder)
  (pedantic-replace folder (get-current-ns-sep) (get-new-ns-sep)))



(make-folder-display-name "foo/bar/baz")
(migrate-folder-name "foo/bar/baz")
==================================================

The `pedantic-replace' function isn't the most efficient way to
replace one string with another, but it shows that we could be storing
the IMAP folder hierarchy as a list that can be split and joined
without much trouble.

I didn't take masking the leading "INBOX" into account, but I imagine
this would involve storing some special symbol at the beginning of the
list that would have a corresponding string (possibly
empty) for each server.

Also, note the `make-folder-display-name' function, which would let
the user concoct her own way of showing a folder name, independent of
the underlying server's representation.

-- 
Steven E. Harris        :: steven.harris@tenzing.com
Tenzing                 :: http://www.tenzing.com