[Q] Is IMAP being put into next version of MH?

[Ken Yap]

Sometime ago there was talk amongst volunteers of developing the next
verison of MH. How is that going? I lost the mailing list address.
Will IMAP support be there? I'd love to use exmh from dialup instead of
pine. Nothing against pine, it's a great UA when all you have is a
telnet connection but if you have X-Windows running...

Thanks, Ken

[Steinar Bang]

>>>>> k...@syd.dit.CSIRO.AU (Ken Yap):

How well does the mh model map to IMAP? An IMAP connection works
best, if you keep the connection open for longer periods.

Frequent opening and closing IMAP connections, negates many of the
efficiency advantages of IMAP (I think...). And that's what you have
to do with a trivial implementation in MH.

Hmm... is having an "MH IMAP client daemon" that keeps the connection
open, and updates MH folders as needed, a possible solution? Or is
this too complex?

- Steinar

[Kimmo Suominen]

My first approach would be to simply make inc talk imap and transfer
all the mail just like it does with pop.

+ Kim

Steinar Bang <s...@norne.metis.no> writes:

--
,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
( Kimmo Suominen "That's what I think" )
( Trans-Atlantic Communications k...@tac.nyc.ny.us )
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''

[Ken Yap]

In article <DxMu...@tac.nyc.ny.us>:

|My first approach would be to simply make inc talk imap and transfer
|all the mail just like it does with pop.
|
|+ Kim

But that defeats the advantage of IMAP which is access to remote
folders. If I had wanted POP I would use POP.

[Kyler Laird]

Steinar Bang <s...@norne.metis.no> writes:

>Hmm... is having an "MH IMAP client daemon" that keeps the connection
>open, and updates MH folders as needed, a possible solution?

Definitely. That was my first thought. I'm not sure about
"updates MH folders as needed," though. I would rather
handle all requests as they're made. (MH should make this
easy.)

BTW, I'm not advocating (for now) a permanently-established
daemon. I was thinking of one that gets started if no other
daemon is detected (via a PID file) on demand. Perhaps it
would even kill itself after a timeout period.

>Or is
>this too complex?

Sure it's complex, but I think it's worth the complexity.

Managing local-only folders on multiple machines is *too*
complex. Writing good software to take care of it using
IMAP shouldn't be.

--kyler

[Justin Sheehy]

>>>>> "Kim" == Kimmo Suominen <k...@tac.nyc.ny.us> writes:

Kim> My first approach would be to simply make inc talk imap and
Kim> transfer all the mail just like it does with pop.

Well, there's no work necessary to do that, as most IMAP servers can
already talk POP.

However, POP!=IMAP.

IMAP allows someone to run their mail client on their home machine
without taking all of the mail off the server (among other things).
This means that you can use your IMAP client at home to read your
mail, then go to work the next day, and use an IMAP client there to
access the same mail.

You can't do that with POP.

--
-Justin

[R. Smith]

In article <vndn2yu...@k2.ccs.neu.edu>, Justin Sheehy wrote:
>IMAP allows someone to run their mail client on their home machine
>without taking all of the mail off the server (among other things).
>This means that you can use your IMAP client at home to read your
>mail, then go to work the next day, and use an IMAP client there to
>access the same mail.
>
>You can't do that with POP.

Right. And since some IMAP daemons (the one PINE ships with, for instance)
support mh folders via IMAP, a suite of IMAP-aware MH programs would allow
some really beautiful transparent remote handling of mh folders.

This would be...very cool.

-R

--
Russ Smith
16i9477F24BA6E9E2C7[d64%P64/d0<y]sylyx

[Jerry Peek]

On 11 September, Ken Yap <k...@syd.dit.csiro.au> wrote:
> Sometime ago there was talk amongst volunteers of developing the next
> verison of MH. How is that going?

That effort died when the 6.8.4 patch was (pre-)announced. A couple of
months after 6.8.4 came out, I posted a message to mh-workers saying
that I'd found a fair number of bugs in 6.8.4 and asking if anyone was
interested in starting development (maybe cooperatively with UCI).
I got almost no answers. So I gave up and started building the MH
patch archive (which is online now, http://www.gw.com/mail/mh/patches/
and ftp://ftp.gw.com/mail/mh/patches/).

About IMAP: Does Pine do IMAP? Pine handles MH folders, at least.
--
Jerry Peek, jp...@jpeek.com, http://www.jpeek.com/~jpeek/

[Matthew James Marnell]

:>About IMAP: Does Pine do IMAP? Pine handles MH folders, at least.

Actually, I believe that Pine is the reason why IMAP is so popular,
if not the reason for it's existance. Mark Crispin is the author,
as far as I can tell, of the 3 new* IMAPv4 I-D's that are going to be
published as RFCs in the near future, one as a proposed standard
and 2 as Informational. Mark Crispin is also one of the implementors
of pine, isn't he?

Matt

* I didn't bother to look through the RFCs to much, but the drafts
update some former Crispin written RFCs as well. The three new
I-D's haven't actually been published as RFCs yet, but were the
subject of an IETF Protocol Action on the 28th of August, so should
be given number sometime in the near future.

[R. Smith]

In article <3146.84...@rubble.west.ora.com>, Jerry Peek wrote:
>About IMAP: Does Pine do IMAP? Pine handles MH folders, at least.

Indeed it does, and quite well, at that. Presently, I occasionally read
my MH folders from my linux box at home using Pine via IMAP.

[Soren Dayton]

Kimmo Suominen <k...@tac.nyc.ny.us> writes:

>
> My first approach would be to simply make inc talk imap and transfer

> all the mail just like it does with pop.

Well, one thought would be to do something like the trick with
MHFD. Then there would be no overhead. So you could do something like

$ exec startimap
$ inc

Thoughts?

Soren

[Soren Dayton]

marn...@portia.portia.com (Matthew James Marnell) writes:

>
> :>About IMAP: Does Pine do IMAP? Pine handles MH folders, at least.
>
> Actually, I believe that Pine is the reason why IMAP is so popular,
> if not the reason for it's existance.

Well, I think the reason is that IMAP is a `good idea'.

> Mark Crispin is the author,
> as far as I can tell, of the 3 new* IMAPv4 I-D's that are going to be
> published as RFCs in the near future, one as a proposed standard
> and 2 as Informational. Mark Crispin is also one of the implementors
> of pine, isn't he?

yeah

Soren

[Kyler Laird]

Soren Dayton <csda...@mach.uchicago.edu> writes:

>$ exec startimap
>$ inc

>Thoughts?

Yeah: why bother?

What advantage does IMAP offer when used with inc?

--kyler

[Steinar Bang]

>>>>> la...@pier.ecn.purdue.edu (Kyler Laird):

>> Thoughts?

> Yeah: why bother?

See, sonny, there's this thing called networks, that are different
from working on your local disk...

[Soren Dayton]

la...@pier.ecn.purdue.edu (Kyler Laird) writes:

>
> Soren Dayton <csda...@mach.uchicago.edu> writes:
>
> >$ exec startimap
> >$ inc
>
> >Thoughts?
>
> Yeah: why bother?
>
> What advantage does IMAP offer when used with inc?

Well, you might have noticed the comment about maintaining an open
connection. then inc would just get a list of things and incorporate
them into folders on the server.... You know, IMAP?

Soren

[Rune Eidhammer]

The question is of course(if it's not obvious), how to combine the
best of mh and IMAP? The problem is that mh is assuming that mail
manipulation and organization is a local matter. IMAP clients do not,
more like the opposite. There's a lot of talk about mh in the context
of folders. IMAP allows serverbased folder organizations, we don't need
mh particulary for that.

What's mh's greates advantage? Unless your life depends on exmh, you know
that - it's flexibility. That's what I want. What about IMAP? Yeah, give
one of that too. Then what? For instance:

Instead of $> scan +folder

perhaps like this $> scan +folder +<host>

where a host might just be a default value so you don't have to enter it.
Loss of efficency? Have you ever used exmh? Have you experienced exmh sucking
up all you 128 MB memory during MIME-traversing just to take a look at some
5 MB picture? In that case you know what "loosing time" is.

and what about - $> pick -from <sender> -seq list;scan list
where host is either specified or we can search transparantly through both
server and local machine? The user doesn't have to know the difference.
But can we make the imap-server search like a local mh?

MIME? $> mhn -list <msgid> . Just give me the parts I want. I don't care
where it is(of course, low bandwith or a heavy loaded server might give me a
a clue).

How is this for a start? That would make mh really take advantage of IMAPs
functionality.

--
Real name: Rune H. Eidhammer "God is dead"
Email: ru...@cc.uit.no -Nietzsche
Talk: ru...@apache.cc.uit.no "Nietzche is dead"
tlf. +47 77 64 62 56, EDB-Sentret, UiTř -God

[R. Smith]

In article <whwwxt1...@norne.metis.no>, Steinar Bang wrote:
>>>>>> la...@pier.ecn.purdue.edu (Kyler Laird):

>
>> Soren Dayton <csda...@mach.uchicago.edu> writes:
>>> $ exec startimap
>>> $ inc
>
>>> Thoughts?
>
>> Yeah: why bother?
>
>> What advantage does IMAP offer when used with inc?
>

>See, sonny, there's this thing called networks, that are different
>from working on your local disk...

You miss the point entirely. The interesting advantage of IMAP over
POP is the ability to handle multiple folders (and, I would venture to
say, one frequently prefers to do so leaving the folders remote);
inasmuch as inc's entire purpose is to slurp down the contents of one
folder, it kind of throws that out the window.

In order for IMAP to be interesting integrated into MH, it would have to
be integrated into the various manipulating programs (show, rmm, refile,
etc etc).

[rep...@jeeves.net]

On Tue, 17 Sep 1996 15:47:54, Soren Dayton previously wrote:
> la...@pier.ecn.purdue.edu (Kyler Laird) writes:
>
> >
> > Soren Dayton <csda...@mach.uchicago.edu> writes:
> >
> > >$ exec startimap
> > >$ inc
> >
> > >Thoughts?
> >
> > Yeah: why bother?
> >
> > What advantage does IMAP offer when used with inc?

> Well, you might have noticed the comment about maintaining an open

> connection. then inc would just get a list of things and incorporate
> them into folders on the server.... You know, IMAP?

So, what you are looking, then, for is a new mail client, not a new
protocol over which inc has to work? IMHO, MH is based around the type
of flexibility that comes from storing the mail on the client, not on the
server (disk is cheap!), and thus would have to be almost completely
re-designed to accomplish this type of IMAP activity.

Why bother? Especially with all of the things that you can do with MH,
you would murder servers if you started supporting any useful number of
users using MH-IMAP!

-rob

[rep...@jeeves.net]

On Tue, 17 Sep 1996 15:51:15, Soren Dayton previously wrote:
> rep...@jeeves.net said:
> well, this is, of course, the problem. It is not necessarily an
> attractive thing to do unless the IMAP stuff operations can be mapped
> onto the functionality that MH offers.

> >Why bother? Especially with all of the things that you can do with MH,
> >you would murder servers if you started supporting any useful number of
> >users using MH-IMAP!

> I do not think that it would be any more murderous than using pine or
> something like that.

Of course it would, because MH functionality > Pine Functionality. More
operations are allowed by MH, and more costly operations are allowed by
MH, things like filtering messages in folders with almost anything in a
pipe, like annotating mail messages, things like arbitrary searches on
anything in the message body or headers, like arbitrary numbers of
sequences, arbitrary operations on sequences (if you can do it to a
message, you can do it to a sequence or a part of a sequence). All of
these are things that (at least last I knew) Pine doesn't do. I don't
know if all of these map to IMAP, but I do know that except in the case
of a very optimized (for these operations) server implementations, most
of these would murder almost any server hardware with a reasonable number
of users; where reasonable number is some number supportable with POP.
-rob

[rep...@jeeves.net]

On 17 Sep 1996 08:09:45, Steinar Bang previously wrote:
> >>>>> la...@pier.ecn.purdue.edu (Kyler Laird):

>
> > Soren Dayton <csda...@mach.uchicago.edu> writes:
> >> $ exec startimap
> >> $ inc
>
> >> Thoughts?
>
> > Yeah: why bother?
>
> > What advantage does IMAP offer when used with inc?
>

> See, sonny, there's this thing called networks, that are different
> from working on your local disk...

Still doesn't explain why you think the behavior of inc would change just
because the underlying protocol changed. It doesn't seem that a
functional change was what was requesed, it seemed that only support for
the underlying protocol change was requested.

-rob

[Kimmo Suominen]

Actually, you don't have to delete messages via POP from your mailbox.
If you don't delete them, they'll be there even the next day.

But I can see that what really would be desirable is to have all your
folders etc. handled by the IMAP server.

+ Kim

dwo...@k2.ccs.neu.edu (Justin Sheehy) writes:

| >>>>> "Kim" == Kimmo Suominen <k...@tac.nyc.ny.us> writes:
|
| Kim> My first approach would be to simply make inc talk imap and
| Kim> transfer all the mail just like it does with pop.
|
| Well, there's no work necessary to do that, as most IMAP servers can
| already talk POP.
|
| However, POP!=IMAP.
|

| IMAP allows someone to run their mail client on their home machine
| without taking all of the mail off the server (among other things).
| This means that you can use your IMAP client at home to read your
| mail, then go to work the next day, and use an IMAP client there to
| access the same mail.
|
| You can't do that with POP.
|

| --
| -Justin

[Kyler Laird]

Steinar Bang <s...@metis.no> writes:

>> Soren Dayton <csda...@mach.uchicago.edu> writes:
>>> $ exec startimap
>>> $ inc

>>> Thoughts?

>> Yeah: why bother?

>> What advantage does IMAP offer when used with inc?

>See, sonny, there's this thing called networks, that are different
>from working on your local disk...

Well, Dad, perhaps you should get your head in front of your
monitor and check out MH's current offerings. Among them is
POP support.

Know what that is? It uses this thing called a "network"...

Back to your question...if you knew about the advantages of
networks over local-only disks, you should have realized
that using IMAP with inc is a stupid thing to do.

--kyler

[Kyler Laird]

ru...@apache.cc.uit.no (Rune Eidhammer) writes:

>perhaps like this $> scan +folder +<host>

I'd like to be able to associate a host with a folder in a
less manual (more permanent) way. Seems like the profile
would be a fine place for this, but maybe something clever
could be done in a directory (folder) to indicate that the
data is to be manipulated on another host (via IMAP).

(I also like the syntax above, though.)

--kyler

[Kyler Laird]

Soren Dayton <csda...@mach.uchicago.edu> writes:

>> What advantage does IMAP offer when used with inc?

>Well, you might have noticed the comment about maintaining an open

>connection. then inc would just get a list of things and incorporate
>them into folders on the server....

Where are we getting this "list of things"? The remote host, right?

Where are we incorporating them into folders? The remote host, right?

WHY?!?! That's a "refile" if anything.

>You know, IMAP?

Sounded more like POP.

--kyler

[Ken Yap]

|> Well, you might have noticed the comment about maintaining an open
|> connection. then inc would just get a list of things and incorporate

|> them into folders on the server.... You know, IMAP?
|
|So, what you are looking, then, for is a new mail client, not a new
|protocol over which inc has to work? IMHO, MH is based around the type
|of flexibility that comes from storing the mail on the client, not on the
|server (disk is cheap!), and thus would have to be almost completely
|re-designed to accomplish this type of IMAP activity.

You miss the point too. It's not just about disk space, but about
flexible access to mail. Say I have a laptop and I have mailboxes
around the place. Now with POP I'd have to take all the mail or leave
it on the server. If I keep all my mail on the laptop there's the space
issue and the backup issue. If I leave it on the server, there's the
consistency issue. IMAP allows me to have a unified view of my
mailboxes from anywhere with flexible tradeoffs.

All this is covered in the discussion document at the Pine site.

|Why bother? Especially with all of the things that you can do with MH,
|you would murder servers if you started supporting any useful number of
|users using MH-IMAP!

But there lies the challenge. I don't need exmh to scan through every
mail item to find embedded URLs. I'm happy to get the headers and fetch
the body on demand.

[rep...@jeeves.net]

I would rather it be the same as the POP syntax for remote hosts:

scan -host <hostname> [+folder] [msgs] [switches]

Of course, this could be done with .mh_profile entries.

-rob

[Jerry Peek]

On 17 September, Kyler Laird <la...@pier.ecn.purdue.edu> wrote:
> ru...@apache.cc.uit.no (Rune Eidhammer) writes:
>
> >perhaps like this $> scan +folder +<host>
>
> I'd like to be able to associate a host with a folder in a
> less manual (more permanent) way. Seems like the profile
> would be a fine place for this,

I haven't used IMAP. But from the sounds of it, maybe a "current host"
(like the current message and current folder) would do the job? The MH
context file would be a good place for this info; it already stores
the current folder, folder stack, and private sequences. Once you'd
set a current host, all commands would use it until you changed the host
(or the connection timed out...)

I'm not sure if the angle brackets in Rune's +<host> were supposed to
be literal or not. They'd always need to be escaped so the shell
wouldn't treat them as file-redirection characters. Seems like an
option with an argument (like -imap-host foo.bar.com , which could
be abbreviated to -im host or whatever) might be short enough?

On 17 September, Kyler Laird <la...@pier.ecn.purdue.edu> wrote:
> Steinar Bang <s...@metis.no> writes:
> >> Soren Dayton <csda...@mach.uchicago.edu> writes:

...

> >> What advantage does IMAP offer when used with inc?
>

> >See, sonny, there's this thing called networks, that are different
> >from working on your local disk...
>
> Well, Dad, perhaps you should get your head in front of your
> monitor and check out MH's current offerings.

I really don't see the point of this "sonny"/"Dad" stuff. The MH group
has been blissfully free of name-calling and other talk designed only
to insult and irritate. Though this list doesn't have a moderator to
cut off useless flame wars, I hope that we can limit this discussion to
technical topics and *helping* each other. Thanks.

[Chris Hanson]

Kimmo Suominen wrote:
> Actually, you don't have to delete messages via POP from your mailbox.
> If you don't delete them, they'll be there even the next day.

The advantage of IMAP is that most clients don't download *anything* to
local disk. Great for lab situations...

Also, I know someone here at CMU (where we're replacing our custom mail
system with IMAP) that's been working on an MH for IMAP in his spare time.
I'll point him towards the discussion.

TTFN,
Chris

[Steinar Bang]

>>>>> la...@pier.ecn.purdue.edu (Kyler Laird):

> Back to your question...if you knew about the advantages of
> networks over local-only disks, you should have realized

> that using IMAP with inc is a stupid thing to do.

At least using the straightforward implementation. Follow the thread
back to the start.

There's sort of an "impedance mismatch" at work here, between the
often restarted MH utilities, and IMAP (who would work best with
session long connections).

The reason for adding IMAP support to MH, is to preserve the
investements people have in the MH user interface. This means the
user interface in the wider sense (higher level user interfaces
relying on MH: exmh, mh-e, mew), and scripts people have written, that
rely on the MH utiltities.

For instance: I would like to be able to use mh-e against an IMAP
server. The questions then are
1. is it possible?
2. how good is the solution?

- Steinar

[Steinar Bang]

>>>>> ru...@littlewood.math.okstate.edu (R. Smith):

> In order for IMAP to be interesting integrated into MH, it would
> have to be integrated into the various manipulating programs (show,
> rmm, refile, etc etc).

I know.

[Kyler Laird]

Alan Shutko <a...@hubert.wustl.edu> writes:

>CH> The advantage of IMAP is that most clients don't download
>CH> *anything* to local disk. Great for lab situations...

...and for those of us who use more than one computer...

>And the great advantage of MH is that everything is downloaded to
>local disk, in one file/msg so you can operate on it however you
>like. Shell scripts, etc.

I don't download my messages to my local disk now (I
use NFS.) on my Unix box and I can do all that I need
to do with MH.

Fortunately, IMAP can be made to be even more efficient
than NFS for MH-type operations.

--kyler

[Soren Dayton]

Alan Shutko <a...@hubert.wustl.edu> writes:

> And the great advantage of MH is that everything is downloaded to
> local disk, in one file/msg so you can operate on it however you
> like.

I do not think that this is entirely true. I think that the advantage
of MH is the abstraction of the operations on a message or group of
messages into things that can be done from a command line or a shell
script. There is no reason to need local disk for that.

> Shell scripts, etc. If you don't want it on local disk, you
> suddenly lose everything that is cool about mh and simply have a
> command-line interface to IMAP.

No. People have been talking about keeping MH and giving it an
alternative backend... If it can be done, no one should care about how
it works....

Soren

[Ken Hornstein]

In article <3146.84...@rubble.west.ora.com>,
Jerry Peek <jp...@jpeek.com> wrote:
>On 11 September, Ken Yap <k...@syd.dit.csiro.au> wrote:
>> Sometime ago there was talk amongst volunteers of developing the next
>> verison of MH. How is that going?
>
>That effort died when the 6.8.4 patch was (pre-)announced.

It probably wouldn't have died if people hadn't sent mail to nmh-workers
saying, "Disband, you silly fools! MH developement is still alive and well!
See, we have this patch to upgrade to 6.8.4 and the real version of 6.8.4
will be out any day now".

Sheesh.

--Ken

[Steinar Bang]

>>>>> "Chris Hanson" <c...@cyrus.andrew.cmu.edu>:

> Also, I know someone here at CMU (where we're replacing our custom
> mail system with IMAP) that's been working on an MH for IMAP in his
> spare time. I'll point him towards the discussion.

I, for one, would be very interested in hearing what is architectural
approach is. Does he start some kind of daemon, that keeps the IMAP
connection up? If so: how does this daemon communicate with the MH
programs?

- Steinar

[Rahul Dhesi]

I log in from different places but have no trouble reading my mail with
MH. Because my mail server lets me fire up MH directly. Because
when I configure a mail server, it does what I want.
--
Rahul Dhesi <dh...@rahul.net>
"please ignore Dhesi" -- Mark Crispin <m...@CAC.Washington.EDU>

[rep...@jeeves.net]

On 19 Sep 96 10:31:26, Chris Hanson previously wrote:
> Kimmo Suominen wrote:
> > Actually, you don't have to delete messages via POP from your mailbox.
> > If you don't delete them, they'll be there even the next day.
>

> The advantage of IMAP is that most clients don't download *anything* to

> local disk. Great for lab situations...

And, the disadvantage to IMAP is that it *doesn't* download anything to
local disk! If I read a message twice within five minutes, I have to
download it from the server again. That is a good design? Seems like
that is *exactly* what kills network performance in those same labs, not
to mention is *awful* performance over a WAN or dialup link. -rob

[Dave Barr]

In article <1996092014...@illodium-q36-explosive-space-modulator.jeeves.net>,

>And, the disadvantage to IMAP is that it *doesn't* download anything to
>local disk! If I read a message twice within five minutes, I have to
>download it from the server again. That is a good design? Seems like
>that is *exactly* what kills network performance in those same labs, not
>to mention is *awful* performance over a WAN or dialup link.

Whoopee. There's nothing preventing clients from doing caching.
There's also nothing preventing clients from downloading the mail
files a la POP, either. That's not the fault of IMAP -- only the
fault of the assumptions put there by the IMAP client.

--Dave

[John McClary Prevost]

Steinar Bang <s...@metis.no> writes:

> I, for one, would be very interested in hearing what is architectural
> approach is. Does he start some kind of daemon, that keeps the IMAP
> connection up? If so: how does this daemon communicate with the MH
> programs?

I'm one of the two people working on this right now. Our model is a
daemon that keeps the connection up and basically maintains the state
needed to be efficient in IMAP-land. This is doubly important for us
at CMU because we use Kerberos for security, and the setup for a
kerberos authenticated and encrypted connection is slightly slower
than a standard password/userid login. (Of course, if you go the
other way, you are faster, but send your pw and userid across the net
many times.)

For the MH programs part, we've been working first on a set of tools
that provide a sort of MH-like functionality, without being MH. Sort
of as a proof of concept. We have kept the model to selecting
folders, reading messages, and listing folders so far, and are working
on stabilizing the back end (we are -not- using the C-client from UW).

Our next step is to take what we have and start working it together
with MH proper as much as possible. We've been thinking mostly along
the lines of IMAP as the one-and-only thing which this would support,
since the Andrew mail system is going to IMAP and the model of
store-nothing-on-local-disk is important here (really important), but
the talk about having IMAP and local-disk folders coexistant interests
me, so who knows where we'll go now.

In any case, I will continue to follow this group. Some good
questions we hadn't really thought about.

John.

[Justin Sheehy]

>>>>> "Kim" == Kimmo Suominen <k...@tac.nyc.ny.us> writes:

Kim> Actually, you don't have to delete messages via POP from your
Kim> mailbox. If you don't delete them, they'll be there even the
Kim> next day.

I didn't say you had to delete them, just that you had to get them
from the server, as opposed to just manipulating and reading them on
the server.

Also, with POP, you have two choices:

delete the messages
leave the messages

You cannot modify the messages, or do something like delete the first
and third, while leaving the second alone and putting the fourth in a
different folder. That kind of flexibility just isn't in POP.

-Justin

[Kyler Laird]

rep...@jeeves.net writes:

>> > Actually, you don't have to delete messages via POP from your mailbox.
>> > If you don't delete them, they'll be there even the next day.
>>
>> The advantage of IMAP is that most clients don't download *anything* to
>> local disk. Great for lab situations...

>And, the disadvantage to IMAP is that it *doesn't* download anything to

>local disk! If I read a message twice within five minutes, I have to
>download it from the server again. That is a good design?

Sounds like a bad design. It also sounds like you're confusing
the IMAP *protocol* with some stupid non-caching *implementation*.

I looked through the IMAP protocol spec and I didn't see any
mention of IMAP clients being forbidden to cache messages.

(Synchronization *might* become a problem, but not in most
instances - those where only one person is manipulating a
folder.)

--kyler

[John McClary Prevost]

la...@pier.ecn.purdue.edu (Kyler Laird) writes:

> Sounds like a bad design. It also sounds like you're confusing
> the IMAP *protocol* with some stupid non-caching *implementation*.

Actually, I'd say the IMAP protocol is designed in a way that promotes
caching. Because information is server-driven (i.e. the server can
tell you anything it wants to whenever it wants to, nearly), you tend
to set up data structures that reflect the current server state, and
treat commands which you send as ways of synching yourself up.

> I looked through the IMAP protocol spec and I didn't see any
> mention of IMAP clients being forbidden to cache messages.
>
> (Synchronization *might* become a problem, but not in most
> instances - those where only one person is manipulating a
> folder.)

Sychronization is an issue in IMAP in a different way as well. Some
people have been working on detached operation, so that you can say,
download all your mail to a laptop, do stuff with it, have thing
happen on the server whil youi're away (like messages arrive, or are
deleted), and synchronize when you come back. So some not
insignificant thought has been put into synchronization.

John.

[Ken Yap]

|On 19 Sep 96 10:31:26, Chris Hanson previously wrote:
|> Kimmo Suominen wrote:

|> > Actually, you don't have to delete messages via POP from your mailbox.
|> > If you don't delete them, they'll be there even the next day.
|>
|> The advantage of IMAP is that most clients don't download *anything* to
|> local disk. Great for lab situations...
|
|And, the disadvantage to IMAP is that it *doesn't* download anything to
|local disk! If I read a message twice within five minutes, I have to

|download it from the server again. That is a good design? Seems like
|that is *exactly* what kills network performance in those same labs, not

|to mention is *awful* performance over a WAN or dialup link. -rob

Gee, Web browsers have solved this kind of problem with things called
caches and conditional fetch.

[Steinar Bang]

>>>>> Rahul Dhesi <dh...@rahul.net>:

> I log in from different places but have no trouble reading my mail with
> MH. Because my mail server lets me fire up MH directly. Because
> when I configure a mail server, it does what I want.

What kind of setup do you have? Machines, OS'es, software? What do
you mean by "mail server"?

Please be specific.

[Rahul Dhesi]

In <whohixg...@norne.metis.no> Steinar Bang <s...@metis.no> writes:

>What kind of setup do you have? Machines, OS'es, software? What do
>you mean by "mail server"?

The "mail server" is a Sun machine that runs a POP server for those who
prefer to use POP, but also runs MH for those who prefer to run MH.

What prevents people from doing a telnet to their mail server, logging
in, and firing up MH directly? Site policy? An operating system that
does not let MH compile or run? Overloaded machine with insufficient
processing power for MH? All these are site-specific problems and the
solution lies in solving them locally, not in forcing MH to go over
IMAP.

IMAP was never designed to emulate a filesytem. MH was designed to make
direct advantage of the filesytem structure. There is no compatibility
between the two. By the time IMAP is revised enough to support MH you
will have reinvented NFS.

There *is* scope for redesign here, though. It would be nice to have a
single-user filesystem. Create a binary telnet session to the
filesystem server, log in as yourself, and then over that session run a
filesystem protocol. Normal filesystem protections at the other end
will be sufficient for all permissions checking, so the filesystem
protocol would need to do no other permissions checking. The question
of whom to export directories to would go away: They are exported to
whoever completes a successful login, and accessible to the user if he
would be able to access them on the server as his login id. You could
even use challenge-response for the initial login, coupled with
ssh-based encryption, so you automatically have a secure filesystem
without even trying.

IMAP is too restricted in its scope to be easily modifiable to emulate
such a filesystem. It would have to be a redesign from scratch.

[Steinar Bang]

>>>>> Rahul Dhesi <dh...@rahul.net>:

> What prevents people from doing a telnet to their mail server, logging
> in, and firing up MH directly? Site policy? An operating system that
> does not let MH compile or run? Overloaded machine with insufficient
> processing power for MH?

In my case: running mh-e in emacs, using MH over NFS mounted disks,...
or running emacs/mh-e on the mail server, displaying on my
machine. Both of these works, neither is very network efficient.

I could also telnet in, and run emacs/mh-e in a telnet session, but I
don't find this a satisfactory solution.

I would like to keep my MUA, but have it support IMAP.

Thus, the wish for having IMAP support in MH.

- Steinar

[rep...@jeeves.net]

On 23 Sep 1996 08:39:52, Rahul Dhesi previously wrote:
> In <whohixg...@norne.metis.no> Steinar Bang <s...@metis.no> writes:
>
> >What kind of setup do you have? Machines, OS'es, software? What do
> >you mean by "mail server"?

> What prevents people from doing a telnet to their mail server, logging

> in, and firing up MH directly? Site policy? An operating system that

Site security policy for an ISP-type operation, or a college campus will
almost *never* allow for *all* users to log into the mail server. With
almost *any* medium to large site, there are very good reasons for not
necessarily trusting all users with a server as vulnerable as most mail
servers are.

> does not let MH compile or run? Overloaded machine with insufficient

> processing power for MH? All these are site-specific problems and the
> solution lies in solving them locally, not in forcing MH to go over
> IMAP.

Fixing the above problem (security policy) by opening security holes in
the setup is not an acceptable solution for those who have very good
reasons for their security policies. Applications should be flexible
enough to work through such policies, not dictate such policies. I know
that POP does allow MH to work in such an instance, but if adding IMAP to
it will make it more flexible, that is a Good Thing (tm).

> IMAP was never designed to emulate a filesytem. MH was designed to make
> direct advantage of the filesytem structure. There is no compatibility
> between the two. By the time IMAP is revised enough to support MH you
> will have reinvented NFS.

> There *is* scope for redesign here, though. It would be nice to have a
> single-user filesystem. Create a binary telnet session to the
> filesystem server, log in as yourself, and then over that session run a
> filesystem protocol. Normal filesystem protections at the other end
> will be sufficient for all permissions checking, so the filesystem
> protocol would need to do no other permissions checking. The question
> of whom to export directories to would go away: They are exported to
> whoever completes a successful login, and accessible to the user if he
> would be able to access them on the server as his login id. You could
> even use challenge-response for the initial login, coupled with
> ssh-based encryption, so you automatically have a secure filesystem
> without even trying.

That type of discussion, while a good suggestion, is probably best
handled outside of mh-users.

> IMAP is too restricted in its scope to be easily modifiable to emulate
> such a filesystem. It would have to be a redesign from scratch.

How about making suggestions for IMAP-changes to that group?

-rob

[Rahul Dhesi]

In <long-message-id> rep...@jeeves.net writes:

>Site security policy for an ISP-type operation, or a college campus will
>almost *never* allow for *all* users to log into the mail server. With
>almost *any* medium to large site, there are very good reasons for not
>necessarily trusting all users with a server as vulnerable as most mail
>servers are.

??? I don't think mail servers are any more or less vulnerable than
machines that don't deliver mail.

In any case, this can be addressed much, much more easily than revising
IMAP to act like a filesystem. If nothing else, just let the mail
server(s) export filesystems to other machines on which MH may be run.
Or deliver mail into home directories on multiple machines and dispense
with the single mail server model.

The basic point remains that site-specific shortcomings are best
addressed locally.

[Ken Yap]

In article <527dtg$q...@bug.rahul.net>:

|??? I don't think mail servers are any more or less vulnerable than
|machines that don't deliver mail.
|
|In any case, this can be addressed much, much more easily than revising
|IMAP to act like a filesystem. If nothing else, just let the mail
|server(s) export filesystems to other machines on which MH may be run.

Not every sysadmin wants to export filesystems and open up that can of
security worms. Not every machine capable of running an IMAP client may
be able to import filesystems. (I know MH doesn't run on small
machines.)

|Or deliver mail into home directories on multiple machines and dispense
|with the single mail server model.

A user may have multiple home directories and be able to use IMAP.
IMAP also allows multiple mail servers and the clients just see a
collection of folders, not mail servers.

|The basic point remains that site-specific shortcomings are best
|addressed locally.

And some people's needs span more than one site. Is it only the lucky
people who work for big corporations, travel around and have maildrops
everywhere? Some of us have accounts with ISPs. Why shouldn't I be able
to use the same mailtool to access all my mail from all sites? I should
be able to just click on a folder icon representing my mailbox on my
ISP account and view it.

It's been said in this forum that MH depends a lot on local files.
Let's approach this thing scientifically and see which commands need
just the header and which commands need the body, and even those that
do, can they accept the body incrementally?

Sure you won't be able to do stuff with backquotes, but that
sort of stuff is not needed by 99% of users.

A side effect of such mods would be the ability to read news as the
header/body split model is used in NNTP.

If we take the pessimistic view that MH cannot evolve then it will get
replaced by other mail agents, no matter what the merits of MH.

Ken

[Rahul Dhesi]

In <527mq9...@degas.syd.dit.csiro.au> k...@syd.dit.CSIRO.AU (Ken Yap) writes:

>I should
>be able to just click on a folder icon representing my mailbox on my
>ISP account and view it.

Perhaps I am misunderstanding. if you want to click on a folder icon,
why would you bother with MH? Programs that let you click on icons are
a dime a dozen. They require no filesystem support the way MH does.

>It's been said in this forum that MH depends a lot on local files.
>Let's approach this thing scientifically and see which commands need
>just the header and which commands need the body, and even those that
>do, can they accept the body incrementally?

>Sure you won't be able to do stuff with backquotes, but that
>sort of stuff is not needed by 99% of users.

With sufficient effort you could find a subset of MH functionality that
could be implemented without filesystem support. With sufficient effort
you could add functionality to IMAP to support the above MH subset.

The result would be neither IMAP nor MH. If you don't need MH, I have
no argument with you about implementing over IMAP what you do need. I
do think that an attempt to implement MH, as opposed to just a crippled
subset of MH functionality, over IMAP, is doomed to failure.

[rep...@jeeves.net]

On 24 Sep 1996 01:35:44, Rahul Dhesi said:
> ??? I don't think mail servers are any more or less vulnerable than
> machines that don't deliver mail.

I disagree, of course this depends on local configuration, so let that be
as it may. > In any case, this can be addressed much, much more easily

than revising > IMAP to act like a filesystem. If nothing else, just let
the mail > server(s) export filesystems to other machines on which MH may

be run. > Or deliver mail into home directories on multiple machines and

dispense > with the single mail server model.

NFS has it's own (security and other) problems, so we really don't need
to go into that. A really flexible network mail-sharing protocol is just
a really Good Thing(tm) no matter how you slice it. Too many other
protocols have been poorly designed to make efficient use of network
resources the way this type of protocol might.

> The basic point remains that site-specific shortcomings are best
> addressed locally.

The point of this entire debate, I believe, is that POP is not a
site-specific shortcoming. -rob

[Jerry Peek]

One easy place to start with IMAP support *might* be the msh command
(part of the standard MH distribution). It lets you use MH commands on
MMDF-style mailbox files. Those are the mailbox files with messages
separated by ^A^A^A^A instead of "From " lines. The latest versions
of msh are amazingly good at emulating MH.

Since I haven't used IMAP, this is just a wild guess.

[Timothy J Showalter]

Rahul Dhesi <dh...@rahul.net> writes:
> The result would be neither IMAP nor MH. If you don't need MH, I have
> no argument with you about implementing over IMAP what you do need. I
> do think that an attempt to implement MH, as opposed to just a crippled
> subset of MH functionality, over IMAP, is doomed to failure.

What do you think can't be implemented?

(I know of a few things that IMAP can't do that MH wants, but we've got
some ideas to solve those problems).

Tim

--
TIM SHOWALTER
brea...@cmu.edu

[Ken Yap]

|>It's been said in this forum that MH depends a lot on local files.
|>Let's approach this thing scientifically and see which commands need
|>just the header and which commands need the body, and even those that
|>do, can they accept the body incrementally?
|

|With sufficient effort you could find a subset of MH functionality that
|could be implemented without filesystem support. With sufficient effort
|you could add functionality to IMAP to support the above MH subset.

Ok, let me be more explicit. For a start I will be happy with a subset
of MH that supports what I do with exmh.

|The result would be neither IMAP nor MH. If you don't need MH, I have

Is this the let's keep MH pure argument? :-)

|no argument with you about implementing over IMAP what you do need. I
|do think that an attempt to implement MH, as opposed to just a crippled
|subset of MH functionality, over IMAP, is doomed to failure.

But will it really be crippled? Let's get down to details. What cannot
be done in MH with IMAP and can they be fixed?

Ken

[Rahul Dhesi]

In <0mG36e200...@andrew.cmu.edu> Timothy J Showalter
<brea...@CMU.EDU> writes:

>What do you think can't be implemented?

Impossible, slow, or awkward:

refile -link +<folder>
refile +<same folder>
<anything> -annotate
grep "pattern" `mhpath first:900`
vi `mhpath .`
mark
scripts that get pathnames from pick + mhpath
inc -file
sortm
folder -pack
comp -draftfolder
find MH -type f -<conditions> -xargs more
cd MH/inbox; mkdir RECOVER; mv #* RECOVER/.; echo whew!

If you find yourself saying, "but why would you want to do that...",
then my point is made. MH's strength *is* that it lets you do things
about which people say "but why would you want to do that". If you
can't do those things any more it's not MH any more. Maybe we could
call it CMH (crippled MH). Then I would have no objections.

[R. Smith]

In article <52as2e$p...@bug.rahul.net>, Rahul Dhesi wrote:
>If you find yourself saying, "but why would you want to do that...",
>then my point is made. MH's strength *is* that it lets you do things
>about which people say "but why would you want to do that". If you
>can't do those things any more it's not MH any more. Maybe we could
>call it CMH (crippled MH). Then I would have no objections.

If I live to be 100, I will never understand the line of argument "this
functionality would not provide everything, therefore we must not let
it provide anything".

Nobody's suggesting a version of MH that ONLY does IMAP. It would merely
be convenient to be able to do some reasonable operations on remote
folders as well as your local ones.

So what's the grievance?

-R

--
Russ Smith
16i9477F24BA6E9E2C7[d64%P64/d0<y]sylyx

[John McClary Prevost]

Rahul Dhesi <dh...@rahul.net> writes:

Not hard:
> refile +<same folder>
> inc -file
> mark
> comp -draftfolder

Harder:

> grep "pattern" `mhpath first:900`

> find MH -type f -<conditions> -xargs more

These two aren't too hard, because IMAP does server-side searching.
The search mechanism is substring based for text search, but also
allows comparisons on many other attributes. (Age, etc.)

Nearly impossible:
> refile -link +<folder>

Doing links would be difficult, yes. I don't think IMAP has any
capability for having a single message in multiple folders.

> vi `mhpath .`
> <anything> -annotate

IMAP messages are immutable--so editing one isn't an option. I
believe someone is working on an annotation extension.

> folder -pack

> scripts that get pathnames from pick + mhpath

> cd MH/inbox; mkdir RECOVER; mv #* RECOVER/.; echo whew!

> sortm

These features have two problems in an IMAP situation--first, some of
them rely on the messages being in the local filesystem. Second,
others assume that the mail client is allowed to do low-level message
management. (packing the folder, sorting messages, etc.) There are
other ways of doing this sort of thing, but it is correct that it
won't be "the same".

> If you find yourself saying, "but why would you want to do that...",
> then my point is made. MH's strength *is* that it lets you do things
> about which people say "but why would you want to do that". If you
> can't do those things any more it's not MH any more. Maybe we could
> call it CMH (crippled MH). Then I would have no objections.

(Our original name -was- cmh, but the acronym was different. ;)

I understand that all of this is important to you--but it is not
necessarily what we're after in our project. (Our project is, by the
way, called fmh, for various reasons. You can think of it as the "far
mail handler".)

What we want is a tool for users of IMAP so that they are not limited
to bogus mail clients like Pine and Simeon. Our motivation in trying
to be MH-like at all was that MH allows you to use arbitrary shell
commands with the mailer. It's true that file-system manipulation
will no longer be possible, but a large number of other things will
be.

We are also not trying to replace MH, but rather trying to provide
something new. Die-hard fans of MH may not want to switch to our
tool. We are certainly not advocating that every MH user give up the
ability to use the local file-system for mail and switch to IMAP
servers! We write in an environment which will be switching over to
IMAP as a standard in the course of the next few years. Because of
the size of the local user community, it makes sense for the
university's academic computing group to support a single mail method.
In fact, they have for a long time, and let me tell you, AMS is not
better than IMAP, even if it is stored in the file system.

We are going to try to make the commands for fmh as close to those of
MH as possible, but there will be numerous differences. With luck,
tools made for working with MH will work with fmh as well, and users
of IMAP and people who have no choice in the matter will be glad to
have another tool.

John.

[Daniel Wang]

I think IMAP and MH can coexists without much problem. If you view your set
of MH folders on a local disk as a persistent cache of the IMAP server's set
of personal folders then I think you can get the best of both worlds of IMAP
and MH. "inc" reduces to synchronizing your local cache with the IMAP
server.

Some magic "cache size" profile flag could be set to "unlimited" which would
basically mean your cache will be a redundent copy of the IMAP server's
view. If you decide to access the IMAP server with some other MUA and make
changes the next invocation of "inc" would then synchronize with the server
and keep your view consistent. Having a duplicate copy would let you grovel
around in your cache/MH folders and do the same sorts of things you could
with normal MH.

If you limit the cache size to "none" or some small number than all the MH
commands would talk directly to the server and not cache all your mail
locally. Since this local cache is persistent just caching the last few
"hot" messages will keep you from having to talk to the IMAP server at all.

Of course "just synchronizing" may not be as easy as it sounds, but I'm
pretty sure it's doable with the IMAP protocol and some meta-data on the MH
end perhaps.

[Rahul Dhesi]

In <slrn54ijk...@littlewood.math.okstate.edu>
ru...@littlewood.math.okstate.edu (R. Smith) writes:

>Nobody's suggesting a version of MH that ONLY does IMAP. It would merely
>be convenient to be able to do some reasonable operations on remote
>folders as well as your local ones.

To reiterate:

- MH over IMAP is impsosible.
- GCMH (greatly crippled MH) over IMAP is possible.
- MH over GRIMAP (greatly revised IMAP) is possible.
- SCMH over SRIMAP (slightly crippled MH over slightly revised IMAP) is
possible.

[Rahul Dhesi]

In <m3lody5...@olivier.pc.cs.cmu.edu> John McClary Prevost
<visi...@olivier.pc.cs.cmu.edu> writes:

>Harder:
>> grep "pattern" `mhpath first:900`
>> find MH -type f -<conditions> -xargs more

>These two aren't too hard, because IMAP does server-side searching.
>The search mechanism is substring based for text search, but also
>allows comparisons on many other attributes. (Age, etc.)

I used grep and more only as examples. Generalize to:

<command> `mhpath first:900`
find MH -type f -<conditions> -exec <command> \;

>I understand that all of this is important to you--but it is not
>necessarily what we're after in our project. (Our project is, by the
>way, called fmh, for various reasons. You can think of it as the "far
>mail handler".)

And to that I have no objection and wish you luck.

[Lance A. Brown]

Ken Yap <k...@syd.dit.CSIRO.AU> writes:

> Not every sysadmin wants to export filesystems and open up that can of
> security worms. Not every machine capable of running an IMAP client may
> be able to import filesystems. (I know MH doesn't run on small
> machines.)

Define small machines? MH doesn't run on PCs or MACs if that is what
you mean. If you are talking about "small" unix boxes it runs just
fine on just about any version of UNIX extant. You have to hack on it
a bit sometimes but it runs.

--
Lance A. Brown

[R. Smith]

In article <52ctvh$c...@bug.rahul.net>, Rahul Dhesi wrote:
>In <slrn54ijk...@littlewood.math.okstate.edu>
>ru...@littlewood.math.okstate.edu (R. Smith) writes:
>
>>Nobody's suggesting a version of MH that ONLY does IMAP. It would merely
>>be convenient to be able to do some reasonable operations on remote
>>folders as well as your local ones.
>
>To reiterate:
>
>- MH over IMAP is impsosible.

Let's review the logic and semantics being used here.

1. POP only has sensible application to inc.
1a. Ergo, inc is the only MH program that will access POP.
1b. Ergo, MH over POP is impossible.

In the way way that MH currently includes impossible partial utility to
POP, some people are interested in impossible partial utility to IMAP
being done.

I hope this clears everything up.

Yours impossibly,
-R

[Amos Gouaux]

Folks are pondering putting IMAP into MH, and yet the Cyrus IMAP server
from CMU internally uses the MH format. Interesting twist.

[Timothy J Showalter]

Amos Gouaux <am...@utdallas.edu> writes:
> Folks are pondering putting IMAP into MH, and yet the Cyrus IMAP server
> from CMU internally uses the MH format. Interesting twist.

:-) Not quite, but the format is comparable. I can't remember what the
exact technichal differences actually are, but the obvious ones are that a
lot of the information MH uses to maintain state about the messages
internally is fairly different from what Cyrus does. I belive the overview
files are different in Cyrus as well. You can't just run mh on a Cyrus
server; it's meant to be sealed.

[Kyler Laird]

bro...@niehs.nih.gov (Lance A. Brown) writes:

>MH doesn't run on PCs or MACs if that is what
>you mean.

Damn! Now I won't be able to read all of my folders when
I get home to my lowly PC.

I just hate it when I'm perfectly happy doing the
impossible and then someone goes and ruins it by telling
me...

--kyler

[Bradley Ward Allen]

FWIW, my biggest deal with MH is that I have tens of thousands of
messages stored in MH folders, and I'd like an IMAP *server* based on
MH, so that I may access my already-existing MH file system via new
IMAP clients whereever I'm at.

What interface those clients use I really don't care just as long as
they are reliable and don't crash (i.e., not Netscape or Elm/Pine or
something).

If IMAP already has MH-like organization metaphorically, then perhaps
people like me would be happy to have an MH-to-IMAPserver folder
conversion tool, and then use the new IMAP clients, and just stop
using MH. Mind you, I love the simplicity of MH and really have a
hard time finding mail systems that are better that I can get my hands
on. I am just trying to demonstrate my biggest needs.

In regards to MH as client, I would love to see the MH interface
extended to recognize a number of ideas:

* Designate different storage sites for different folders.
* Be able to allow local folders to be caches -- i.e., not usable
by themselves without lossage, but a great performance win (garbage
collection should be automatic). This feature can be done last really.

Ideas of storage locations:

* Traditional MH folders (directory/numbered MH message file)
* Traditional USENET filesystem files (i.e. /var/spool/news, etc.)
* NNTP
* IMAP
* other IMAP-like things (POP)
* some of the above on FTP (this is getting a little ((X)Emacs) GNUSish,
but extremely useful if e.g. alt.dcom.telecom is on a remote site you can
ftp to but not NNTP to)
* Others? This sort of covers it really ...

Okay, I'll stab. One could make MH IMAPable by just delving into the
code most likely. I bet that most commands deal with headers-only
most of the time but find times they need some body. I don't think
a command exists that doesn't need headers.

Exclusively environment commands (all commands are environment commands):
ali, mhparam
Folder commands:
folder, folders, mark, mhpath (uhoh), msgchk, packf, refile, rmm
Mostly-header commands:
scan, pick (has many times it accesses body), anno (needs to modify head),
mhl, sortm
Header+Body commands:
show, next, prev, mhn, repl, burst, comp (stores a draft message), dist,
forw, inc (for converting files into one's IMAP server), mhmail, send, whom
Are these applicable?:
mhook, rcvstore, slocal
New commands or all-commands options needed:
-localfile - leave copy of file locally somewhere
perhaps mhpath should do this, or a new command like "mget".
This is so I can manipulate the file locally (e.g.
munpack/uudecode/pgp/patch/etc.)

Ideas:

Perhaps seperating MH into an IMAP server and an IMAP client would work out
pretty well. Or, perhaps those functional ideas can be well laid out in
programming, but the server only uses the filesystem-like library functions
and the client commands use both the filesystem-like and client commands.
For cacheing, the clients would definately need sophistication in this
regard.

Things MH doesn't have that I'd like:

* Deal with message-id's better
* Run faster on really big folders (indexes)

Ideas of how to accomplish these last two things I want:

* Turn INN into a superset of NNTP & IMAP, and make it a nice backend
to a MH-like client, with its filesystem being similar to USENET/MH
* put overchan hooks into MH.
* Have all MH commands do a bit more tracking (e.g. maintaining a
message-id database that will be up to date with a "sortm", and a command
to resync database indexes (like imagine % rm inbox/5722; reindex +inbox)

I like all this discussion. I think while we're discussing it we should be
sure to figure out what we really need. I love the concept of an IMAP
server that stores all my mail. I also run my own mail host since I
don't trust my ISP to store my mailbox the way I want them to. I'd be
happy to run my own IMAP server. I already have loads and loads of MH
folders filled. What are others' needs for IMAP? That's mine, I'm
sure we'll all have different needs.

Who has time to do any of this? I'm about to die doing free work so not me :(

[Bradley Ward Allen]

>- MH over IMAP is impossible.

>- GCMH (greatly crippled MH) over IMAP is possible.
>- MH over GRIMAP (greatly revised IMAP) is possible.
>- SCMH over SRIMAP (slightly crippled MH over slightly revised IMAP) is
> possible.

Not that I knew it before, but yes thank you this is a very good way
to organize discussion of these principles.

My idea of how much I personally need the above:

MH over IMAP:
Don't need it now. Would be nice to know I could. Don't forsee need.
Seems more useful than MH over GRIMAP or SCMH over SRIMAP if I'm
attempting to access a remote box.
GCMH over IMAP:
Don't need it now. Would be nice to know I could. Don't forsee need.
What features of IMAP would I be missing if I needed to use IMAP
or wanted to? This seems more useful if I have to access an IMAP box,
but why'd I want to do that?
MH over GRIMAP:
I would love the GRIMAP to have an MH folder filesystem backend:
This would be superb! Question is, what could the GRIMAP server
do for an IMAP client? I think this is an interesting approach
worth thinking about (and doing).
SCMH over SRIMAP:
Don't need it now. Would be nice to know I could. Don't forsee need.

Another thing:

GCMHIMAPSERVER (Greatly Crippled MH IMAP server): for IMAP
clients to access existing MH folder filesystems.

What I didn't know is that IMAP was inferior in functionality needed
for MH. I know MH has some nice features and misses a few too. I've
always seen MH as a nice simple set that one can build on top of like
I do. Like sometimes I'll take an entire MH folder and turn it into a
newsgroup. It takes an "expireover -a -f /tmp/reducedactivefile" and
a "makehistory" but what the hell. (There's one BIG gotme:
crossposted messages. I *REALLY* want a way to solve this problem
(many of just said crossposted messages go into both my mail system
and my USENET system seperately even though they started as one, and
tend to be the most important messages (not the spam)); wish MH could
link news messages into its folders automatically and update the news
messages as need be (Xref: etc.) - yealch.) Other things I used to do
when ISPs were really unreliable is have my emails go to multiple
locations, kinda like USENET! That had lots of worms I needed canned:
* duplicate messages
* reliable distribution
* handling the many versions of the state of the folders
(I wanted my changes to be propogated automatically)

How much would we rather program a better mail system that has lots of
great new and solid features to handle these needs, and design it with
converting MH folders to the new system in mind? (So all the features
of MH would convert over intact, and everyone running MH could just
upgrade to this new wonderful system.)

More thoughts ...

[ul...@q.net]

la...@puritan.ecn.purdue.edu (Kyler Laird) writes:

> >MH doesn't run on PCs or MACs if that is what you mean.
> Damn! Now I won't be able to read all of my folders when
> I get home to my lowly PC.

Good point ... I've been using MH on Macintoshes, VT100s, adm3as, IBM
PCs, and Linux Pentiums for ages without problems, and still can. It
used to be called "ATDT", "port selector", "rsh", "telnet", etc., but
these days it's usually just "show" with some "ssh", "telnet" and
"ATDT" thrown in there for good measure (and an occasional "exmh").
Now, MIME audiovisual via an adm3a to my MH mailbox -- that would be
some software package!

Seriously, this brings up an interesting point: do we *want* MIME to
be displayed on front ends we use with our MH-like folders when we're
remote from our mail drops? Various methods come to mind: X Windows
with some sound enhancements (rplay?), WWW browser MIME-extension
enhancements (really this seems interesting -- a WWW front end to
IMAP/MH?), or IMAP clients in general.

I'm liking my idea of an improved IMAP server that uses an improved MH
file folder system more and more. Do we want to enhance the
functionality of the standard MH package to work well as the
filesystem for an IMAP server just so we can have our Unix commands
and our GUI IMAP clients and eat our cakes too?

[Timothy J Showalter]

If the demand is a server that handles MH folders over an IMAP connection,
the UW IMAP server does this. (It's the one that comes with Pine, or it's
avalible seperately from ftp.cac.washington.edu.)

What I personally want, and what I am personally working on, is a bunch of
shell commands that open a connection to an IMAP server and act like MH
(whenever possible). The reasons for this approach have to do with the
local computing facilities -- they provide an IMAP server, and I want a
different client to talk to it. I don't want to maintain my own mail
server, although I've considered it.

--
TIM SHOWALTER
brea...@cmu.edu

[John McClary Prevost]

ul...@panix.com (Bradley Ward Allen) writes:

> Okay, I'll stab. One could make MH IMAPable by just delving into the
> code most likely. I bet that most commands deal with headers-only
> most of the time but find times they need some body. I don't think
> a command exists that doesn't need headers.

Uh. I suspect you haven't actually looked at the MH source. Tim and
I took a look the other day, and my considered opinion is that there's
very little that's at all salvageable from the mess. Three things
caught my.. uh... eye.

1) Each command does argument parsing separately. This was important
to Tim and I because if we could steal the arg parsing code first,
that guarantees commands take at least the same set of arguments.
But--well, there's no central body of code to do it.

2) There is no abstraction layer between the programs that manipulate
mail and the mail itself. I was looking at one of the programs, and
the first thing it did after parsing options was to stat a file. Not
an easy thing to search out and replace with IMAP/NNTP/etc calls.

3) The formatting code would be a nice thing to steal, since it's sort
of hairy, and it would be easier to copy than to rewrite.
Unfortunately, I was turned from this course by the presence of some 6
or 8 multi-line macros, some multiply defined inside #ifdefs, taking
up on the order of eight pages total.

At this point, I'd much rather do a complete rewrite from scratch than
try to salvage anything, no matter what the benefits of code re-use.

John.

[Jerry Peek]

On 6 October, John McClary Prevost <visi...@olivier.pc.cs.cmu.edu> wrote:
> ... I suspect you haven't actually looked at the MH source. Tim and

> I took a look the other day, and my considered opinion is that there's
> very little that's at all salvageable from the mess.

A lot of MH is almost 20 years old. It was written in the days when
things like mucking around with the internals of stdio routines was
done to squeeze more speed out of the code. I'm not an MH developer,
so I won't try to explain or defend the source code. I just wanted to
give some context here, FWIW.

--
Jerry Peek, jp...@jpeek.com, http://www.jpeek.com/~jpeek/

Violence is the last refuge of the incompetent. -- Salvor Hardin

[Bret J. Musser]

You can. Just specify your folder as #mh/foldername in your IMAP client,
assuming that you are running an IMAP server based on the U Washington (?)
httpd.

The server can read MH folders, but it can't write to them (except to delete
messages, although it doesn't "delete" messages by renaming them with a
comma).

bjm

In article <531um3$q...@panix2.panix.com>, you wrote:
>FWIW, my biggest deal with MH is that I have tens of thousands of
>messages stored in MH folders, and I'd like an IMAP *server* based on
>MH, so that I may access my already-existing MH file system via new
>IMAP clients whereever I'm at.
>

--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Bret J. Musser -- Univ. of Minn. -- School of Statistics -- b...@stat.umn.edu
http://stat.umn.edu/~bjm/ -- PGP-encrypted e-mail welcome
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=