[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pine-info
Subject:    Re: remote folder management
From:       Steve Hole <steve () edm ! isac ! ca>
Date:       1993-05-27 0:44:49
[Download RAW message or body]


On Wed, 26 May 1993 14:49:04 -0600 Terry Gray wrote:

> In a nushell: for both Unix Pine and PC-Pine there will be a notion of
> "folder-collections" (and also "news-collections") that are defined in the
> .pinerc file.  You can think of those as directories, (though they could
> conceivably be a subset of a directory or some set unrelated to a
> directory). 

We are doing fundamentally the same thing with ECSMail, except 
that we call the "folder collections" "Message Services".    The idea
is to connect to a "service" that will provide access to different message
collections called "folders".    We played with the idea of calling them
Message Stores, but figured that Joe Average Person wouldn't 
get the terminology.   Besides, I'd hate to elevate Mark's blood
pressure over something like X.400 terminology :-)   

Message Services have a number of key attributes:

 1.  Type of service:  "Mail" or "Bulletin Board".
 2.  Service host.
 3.  Authentication information.   Basically the userid and password 
  which is authorized to connect to the message service.

Each Message Service is assigned a logical name (like Terry has
done with Pine I see), and is always referred to by that name.

Within a Message Service a user is allowed to subscribe to a number 
of folders.    For bulletin board services (News), folders correspond to 
individual boards, sigs or newsgroups.    Note that the underlying 
bboard type is completely transparent to the user.     It is up to the 
*server* to decide what type of services it will offer and how they
are accessed on the server host.   

Because ECSMail is a GUI based interface, we are able to do some
interesting things with association of names to services and opening
and closing services.    I think that it will be very user friendly and
easy to understand.

Once the IMSP reference implementation becomes available, we'll
be able to add more direct Message Service management support 
to the interface.    I am quite looking forward to that. 

> In this case, all of the collections except the last one are remote.
> Note that the path syntax is whatever is right for the OS storing
> the collection, so watch the direction of your slashes when mixing DOS 
> and Unix collections.  Many people will have a single collection on
> a timesharing host.  Those who use a timesharing host for dialin and
> PC-Pine on their desk will typically have at least two.  I find the
> Folder Collections paradigm useful for organizing things, so I tend to
> have many.

I am interested as to why you maintained "path syntax" at all in
your configuration.     Something that I have thought for some time
is that the client should really have no say at all as to where on 
the server messages are stored or accessed from.    The server
should decide all of that based on the Message Service attributes
that I defined above.    We have tried to be careful to hide
that server OS information from the user and require only the 
Message Service "attributes".    It works fine so far as all the user
folders have to be in a standard place defined by the server.

It does make sense to have a server configuration file that specifies
what folders and message services are provided by that server
host.    Specifically, Joel King and I have thought for some time that
it would be nice if the imapd server could be runtime configured to
identify where user folder, inboxes and News configuration sat.    That
would allow a mail adminstrator to reorganize folder and mailbox
directories and manage storage better.      

Once the Kerberized version of imapd is available, I would like
to do away with the concept of having a UNIX account define
a user's authentication and mail storage.    If authentication is
handled by the Kerberos (or some other) authentication service,
then the physical location of the inbox and user folders is up to
the imapd server.    Of course any MTA delivering to an inbox
would also have to be able to locate the inbox for delivery.    I 
have already begun modifications to the Z-mailer MTA to be 
able to deliver to a user mailbox based on information held
in an authentication service (Kerberos).    

The one interesting question that can be raised is: If I can't 
specify the path for my folders, then how can I organize my mail.  
Easy - support hierarchical folder models.    ECSMail will do so in 
version 3.00 (end of Sept).    It appears that most of the functionality
we need is already in the c-client, we just need to make some
modifications to the MH driver and build a nice GUI graphical 
representation on the front.    It should provide a very nice 
abstraction for the user that is also very useable and powerful.

> Note also that the MailNews collection is defined to be the subset of 
> available folders (newsgroups) that have the string "mail" in their name.
> 
> It will also be possible for the default-fcc to be a remote folder.
> 
> In order to be able to *append* to an existing remote folder (i.e. Save),
> or *create* a new remote folder, you will need a new version of IMAPd,
> to be released *soon* with PC-Pine.  Without the extended IMAPd you can 
> access remote folders, but not append to or create them.

The alpha ECSMail v2.00 uses imapd 2.4 which supports News and 
remote folder management functions very nicely.    It works quite well,
and we can happily drag and drop between local and remote folders.    
This is really a fine piece of work Mark!

I hope I didn't ramble on too much.    I think that this is important
because it really emphasizes the power of the remote mail access
protocol model over file based solutions.    It is definitely the 
right solution for large organizations or organizations with highly
mobile individuals.        

Cheers.

[prev in list] [next in list] [prev in thread] [next in thread]