Subject: A few possibilities for the future?

From: "Julian Hall" <[email-masked]>
Date: Wed, 23 May 2001 16:01:11 +0100

Well, I'm rather new here so I should introduce myself I guess :-)

My name's Jules, and you might remember me from the NASM assembler project.
I'm rather new to the area of the c-client library and IMAP in general, but
have worked with e-mail systems in the past so I'm not entirely clueless!

I was wondering a couple of things that might or might not have been thought
of before and dismissed, or might be vaguely original thoughts (however
unlikely that is).

Firstly, as I note has been a source of constant discussion on this list, in
order for C-Client & WU IMAPD to support folders containing both messages
and folders (ie, an object that is both a mailbox and a directory) under
UNIX & other similar systems is to use one of the directory based mail
folder formats, which are discouraged due to performance issues.  I wonder
however, is there not a possibility to create a driver that creates a
directory with the name of its mailbox, and then stores the messages in a
suitably named file inside that directory (eg '.messagestore')?  I would
have thought that this would solve this problem and mean that the various
clients that expect to be able to do this (I have found several!) won't
break horribly.

Out of interest, while on the subject of how this problem breaks clients, I
have found the following from my brief survey of potential clients (under
Windows):
    Netscape Messenger 4.7
        this program allows you to create subdirectories using the
        'dir/name' syntax, and shows the directories as not being
        able to accept messages.  However, deleting mailboxes
        does not work (it tries to move the mailbox to Trash/name,
        which fails because Trash already exists).
    Outlook Express 5
        Doesn't allow you to create subdirectories, because it
        isolates '/' as a reserved character and won't let you use it.
        Doesn't recognise that the directories can't contain messages.
        Deletion is fine, as long as you remember to switch to a
        different mailbox first!

I haven't had time yet to fully evaluate any other clients.  Do any of the
others interoperate better than this?

The second point I wished to raise was the possibility of creating a driver
that supports compressed messages.  I note that discussions of performance
have recently centered on I/O bandwidth as the bottleneck; in this case a
suitably designed compression algorithm could actually
speed up operation, as well as saving disk space!

Any comments?  Any reason either of these can't be done?  Any advice on how
I could go about implementing either of these if I find the time to do so?

Jules

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: "Julian Hall" <[email-masked]>
Date: Thu, 24 May 2001 11:50:24 +0100

Indeed - I had thought of bz2 as the obvious choice of compression, although
it may be slightly slower than would be desirable.  Its a shame Unisys hold
the patent on LZW (although I understand that they may only hold it for
applications to raster images...?)

----- Original Message -----
From: OMTGW - Tracy Ta <[email-masked]>
To: Julian Hall <[email-masked]>
Sent: Wednesday, May 23, 2001 5:14 PM
Subject: Re: A few possibilities for the future?

> Hi Julian,
> Compression will be great. One suggestion is to look at Bzip2 , using the
buff
> to buff compress
> routine. Bzip2 is free and is located at http://source.cygnus.com/bzip2
> If you have the time to do it. It will be useful for everybody.
> Tracy