Subject: mail_append()

From: Laurence Lundblade <[email-masked]>
Date: Tue, 8 Sep 1992 10:02:39 +0200 (IST)

I'm starting to work on mail_append() for the c-client driver I'm
writing here. Don't quite know who all's on this list so I'll mention
that this corresponds the the APPEND command in an upcoming version
of IMAP2bis. 

What I'm trying to figure out is how to decide what driver to call.
Mail_append() is a bit of a new thing in that it is not an operation on
an already open mailbox, the format of which known, and therefor the
driver is known. I'm planning on passing mail_append the mailbox name
and a string which contains the RFC-822 message. Seems like the choices
are: 

- Just pass it the mailbox name and the message and let it decide on the
  format of the mailbox either based on a default, or based on the format
  of the existing mailbox if it exists. Would have to default if it didn't
  exist. 

- Pass it a stream of some other open mailbox to serve to indicate the
  format of the mailbox.

- Some other way, indicate the format of the mailbox

I'll probably pick #2 for now since it's easy and there's not much code
involved in any of these options. I'm mainly sending this message to see
if anyone has any immediate ideas or plans. 

Thanks,

LL

---

From: Mark Crispin <[email-masked]>
Date: Wed, 9 Sep 1992 09:49:50 -0700 (PDT)

Laurence -

     I have already decided to add a `driver type' string to the driver
dispatch table, and make those functions which create a mailbox use that.  In
the case of an existing mailbox, it should use the format of that mailbox.

     I haven't gotten around to it yet because I've been tied up with lots of
other stuff.

-- Mark --

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 10 Sep 1992 14:30:54 +0200 (IST)

Hi Mark,
  I don't quite know what you mean. Are you adding the "driver type" to
each entry in the dispatch table (the "DRIVER" defined in mail.h) or are
you adding on type to the whole dispatch table to act as a default type. 

  I've thought about this a little bit and concluded that we don't really
have to support multiple different mail formats for mail_find(),
mail_append() and such since 99% of all users will only have mail in one
format. I know we all enjoy a challenge, but it seems a reasonable
simplification to support one driver at a time for the active mail, and
other drivers in case the fellow wants to occasionally browse a mailbox
in some other format. Phrased another way, it seems much more important to
get things like net news, subscribe/unsubscribe, fancy searching, and
append running than it does to support some fellow who wants to have his
mail in three different formats and operate freely between them because
the searching and news are what the users will care about.
 
  Based on this I suggest that mail_append(), mail_find(), mail_rename(),
mail_delete() and mail_create() only operate on the first driver that is
lunk in with mail_link(). Seems it will make our lives much easier.

LL

---

From: Mark Crispin <[email-masked]>
Date: Thu, 10 Sep 1992 10:27:09 -0700 (PDT)

Laurence -

     The `driver type' will be a string in the dispatch table, a single entry
such as "mbox", etc.  So you can get a `name' of the type of mailbox.  The
idea then is that you can do something like:
	mail_create (name,"tenex");

     Of course, there *will* be defaulting.  I haven't thought all of this
through since, as you noted, there are other things that are much higher on
the queue to do.

-- Mark --

---

From: Laurence Lundblade <[email-masked]>
Date: Fri, 11 Sep 1992 20:22:37 +0200 (IST)

Sounds great Mark! It give us the option to do what we want. I was worried
about things like the ambiguity of mailboxes of the same name in different
formats and naming mailboxes in formats like mh where the the mailbox
isn't a particular file. This sounds like it will take care of things just
fine. 

Bill,
 What I was thinking about the mail_link() calls, was that you have
control at run time as to which driver you link first. You could have
command line flags that cause the drivers to be linked in various orders,
though it's true that you'll only get to create, delete and append for
that one driver. Mark's solution is much better. 

LL