The comp.mail.imap newsgroup is not for IMAP protocol discussions. It is
not for advocacy of changes to any particular implementation. If you
really want to do so in a public forum, please use the appropriate
newsgroup or mailing list. In the case of the c-client based imapd
(a.k.a. UW imapd), that is the c-client mailing list.
> When client requests a list of mailboxes, he is not interested in arbitrary
> file on server - after all, IMAP is not file managing protocol.
Actually, IMAP works quite well as a simple file retrieval protocol.
Quote:> The client
> is interested in *mailboxes*. And only files, which have special format, are
> valid mailboxes with UW imapd. (Speaking on source code level, only files,
> for which mail_valid() returns a valid, non-dummy, driver, are mailboxes).
If that's what you want, try the following experiment:
In imapd.c, rewrite routine mm_list() to be:
void mm_list (MAILSTREAM *stream,int delimiter,char *name,long attributes)
DRIVER *d = mail_valid (stream,name,NIL)
if (d && strcmp (d->name,"phile")
Be sure to call special attention to your work to the guy who has a few
thousand files in his home directory tree and/or links to source
directories. Let him know that you're responsible for the new behavior of
imapd. Make a special effort to get him to use clients that use the "*"
Be sure that your life insurance policy covers "being *d by a
user because you made ill-thought-out changes to system software."
Quote:> What is the reason for such behaviour?
If you look at the code, you'll see that it was very obviously designed to
work the way that you advocate, and that considerable effort was made to
make it NOT work that way. That must mean that either the programmer is
an idiot or he had a very good reason.
Here's what the idiot has to say was his reason:
"Well, once upon a time, it worked the way that you advocate. It was
changed for a reason. A very good reason.
"It slows down LIST to well beyond the point of unusability. LIST
is already very slow because of the necessity of doing a stat() per entry,
but we're talking much worse.
"We're talking tens of minutes, and in one extreme case over an hour.
And we're talking back when imapd had only two local file drivers instead
of the eight that it has now.
"The bottom line is that it isn't feasible. It doesn't scale for
anything more than the very smallest user directories."
Quote:> It may be nice to see file contents
> over IMAP, but it definitly not, what IMAP is for.
Why do you say that?
-- Mark --
* RCW 19.149 notice: This email address is located in Washington State. *
* Unsolicited commercial email is NOT welcome at this email address. *
Science does not emerge from voting, party politics, or public debate.