Re: [Fwd: Re: Questions about IMAP and sequences]
What provision in RFC 2060 treats flags as a scarce resource? I missed that in my reading. It might just be my reading of the specification - there is a fair amount of text regarding the limits w.r.t. permanent flags. I know of no IMAP server in common use which does not support arbitrary flags. The issue is which PERMANENTFLAGS they support; I'm not sure of the answer to that question. Right ... sequences and annotations aren't much good if they aren't permanent :-) --Ken
Re: [Fwd: Re: Questions about IMAP and sequences]
On Wed, Sep 13, 2000 at 12:02:52AM -0400, Ken Hornstein wrote:
Maybe he's talking about the ability of the UW imapd to access the MH
folders you have on the server? I've used it before (in 'pine' to
access a folder "{SYSTEM_NAME}#mh/lists/foo", for instance) to do just
that. These days, I would just ssh in to the box and use nmh
directly.
Was that a feature of UW imapd, or just pine could read mh mailboxes?
I always thought it was the latter (a feature of the c-client library,
I think).
But it was able to do it remotely (via a client/server style
connection, not just an NFS mount or some such). I just don't
remember what the communications mechanism was - I remember being
under the impression that it was the imapd doing it...I don't THINK it
was rsh or anything like that, but it's been a while, so I'm not
positive. And I don't have an easy way to test it out at the moment.
--
Scott Blachowicz
Re: [Fwd: Re: Questions about IMAP and sequences]
Ken Hornstein [EMAIL PROTECTED] writes: IMO, it's rare because people these days don't think of being able to do it; they're used to GUI mail front-ends that don't allow (?) this kind of thing. Use an IMAP client recently? Well, he made it clear that he hadn't. Lots of us nmh folks appear to be a bit ignorant about the intracacies of IMAP since, well, we use nmh for our mail. "Shared" mailboxes are already part of the IMAP specification. Most reasonable ones deal with them just fine. This is why I'm writing my tomes ;-) about not losing nmh flexibility with IMAP, wherever it's reasonable to keep it. Well, the real crux of the problem is that there are some things that you simply cannot _do_ within the context of IMAP. The big one that comes to mind is annotations (there really isn't a way to modify messages on the server, from my reading of the specification). Ouch, that really bites. That was one of the first questions that popped into my mind when I first started hearing about IMAP, but I've been too lazy to find out if you could do that or not. The fact that messages are individual text files is one of the biggest wins of nmh for me. With all the crappy mail clients out there that do things like force line wrapping even if it breaks a long URL, I often find myself reformatting mails. I know you can get much of the same advantage by forwarding the mail to yourself and editing it then, but then the From: is wrong and such (too bad you can't edit a dist'ed mail). If there's no way to replace a message on the server with a local version, then if nmh does local caching of IMAP messages, modification of those messages will definitely be an issue. --- Dan Harkless | To prevent SPAM contamination, please [EMAIL PROTECTED] | do not post this private email address SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
Re: [Fwd: Re: Questions about IMAP and sequences]
If there's no way to replace a message on the server with a local version, then if nmh does local caching of IMAP messages, modification of those messages will definitely be an issue. See the APPEND IMAP4rev1 command: append: http://andrew2.andrew.cmu.edu/rfc/rfc1730.html#sec-6.3.10. It appears that append will add an RFC-822 compliant message to the current folder. Although this is a poor solution, one could fetch the old message, munge it, delete the server version, and upload the new one. I don't know if you can restore the sequencing, though I think message caching will not be the best distribution of resources for a first go at IMAP support. once we have a shell of imap interface commands, we can start doing message-optimization, be it local caching, etc. Shantonu
Re: [Fwd: Re: Questions about IMAP and sequences]
See the APPEND IMAP4rev1 command: append: http://andrew2.andrew.cmu.edu/rfc/rfc1730.html#sec-6.3.10. Yeah, I had look at this, but it really doesn't work - you can't _replace_ an old message, you can only add a new one to a folder. You can set a system-defined flag called \Answer that signifies whether or not you've replied to a message (which I guess helps out on the "-" you have in the scan listing), but it's a poor substitute. Also means that things that reorder the mailbox, like "sortm" won't be possible in the conventional sense. And "folder -pack" is a no-op (unless we want to forgo using IMAP message sequence numbers and simply use UIDs and maintain a local mapping. Icky). --Ken
Re: [Fwd: Re: Questions about IMAP and sequences]
Hi, Well, the real crux of the problem is that there are some things that you simply cannot _do_ within the context of IMAP. The big one that comes to mind is annotations (there really isn't a way to modify messages on the server, from my reading of the specification). Ouch, that really bites. That was one of the first questions that popped into my mind when I first started hearing about IMAP, but I've been too lazy to find out if you could do that or not. The fact that messages are individual text files is one of the biggest wins of nmh for me. Me too. I reformat crappy emails with lines 120 chars long, delete large HTML duplicates that add nothing if I want to keep the mail, etc. Couldn't nmh develop into having multiple back-ends for different formats and cope with some formats not allowing some operations? Then anno on IMAP would gracefully fail. Ralph.
Re: [Fwd: Re: Questions about IMAP and sequences]
Are we making this too complex? If we really wanted to use IMAP, we wouldn't be using 'nmh'. I can see two possible roles for IMAP for the dedicated 'nmh' user: (1) As a pipe, to download messages into your nmh folders. You would really be using it much as you use POP3. You might want IMAP support either because your ISP does not support POP3, or because support for IMAP is better. As an example of the latter, your ISP might support some sort of encrypted authentication for IMAP, but only support plain text passwords sent over the wire for POP3. (2) When away from your main system, you might want to be able to use IMAP to access your nmh folders from a remote site. It seems to me that neither of the above require fully featured support for nmh commands over imap. -NWR
Re: [Fwd: Re: Questions about IMAP and sequences]
Ralph Corderoy [EMAIL PROTECTED] writes: Well, the real crux of the problem is that there are some things that you simply cannot _do_ within the context of IMAP. The big one that comes to mind is annotations (there really isn't a way to modify messages on the server, from my reading of the specification). Ouch, that really bites. That was one of the first questions that popped into my mind when I first started hearing about IMAP, but I've been too lazy to find out if you could do that or not. The fact that messages are individual text files is one of the biggest wins of nmh for me. Me too. I reformat crappy emails with lines 120 chars long, delete large HTML duplicates that add nothing if I want to keep the mail, etc. Couldn't nmh develop into having multiple back-ends for different formats and cope with some formats not allowing some operations? Then anno on IMAP would gracefully fail. Well, anno might be implementable via the IMAP "tags" facility, no? --- Dan Harkless | To prevent SPAM contamination, please [EMAIL PROTECTED] | do not post this private email address SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
Re: [Fwd: Re: Questions about IMAP and sequences]
John Reinhagen [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED], also sprach "Dan Harkless": The last time I remember IMAP support coming up was quite awhile ago, and the commentary (from Richard Coleman??) was that IMAP support probably wouldn't be forthcoming because IMAP would probably spell the eventual death of [n]mh. I don't recall a lot of posts disagreeing with that view, though I suspect if the subject were brought up again people would disagree. I certainly would. [...] Oops. I see you did send your email to nmh-workers as well. The duplicate copy you sent me didn't have a "cc: [EMAIL PROTECTED]" so didn't realize this. In any case, no need to send duplicate copies of mailing list posts. --- Dan Harkless | To prevent SPAM contamination, please [EMAIL PROTECTED] | do not post this private email address SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
Re: [Fwd: Re: Questions about IMAP and sequences]
clemensF [EMAIL PROTECTED] writes: Yeah, your thoughts really make it clear how much potential work is here. Sounds like most of the issues arise from cache handling, though. Perhaps a first implementation could do everything live on the IMAP server. whenever making copies... that's a generalisation of malloc and garbage collection. Even across multiple invocations? --- Dan Harkless | To prevent SPAM contamination, please [EMAIL PROTECTED] | do not post this private email address SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
Re: [Fwd: Re: Questions about IMAP and sequences]
On 11 September 2000 at 15:01, "Dan Harkless" [EMAIL PROTECTED] wrote: multiple users sharing a single nmh folder (with unique sequences) has to be a pretty darn rare situation IMO, it's rare because people these days don't think of being able to do it; they're used to GUI mail front-ends that don't allow (?) this kind of thing. For instance, I've done that in two different companies where I worked in groups that used MH for bug tracking and etc. We'd have central folder(s) of bug reports that everyone accessed (and had their own current message, sequences of messages they were working on, etc.). We could use "anno" to make annotations that everyone could see (like assigning a bug and tracking its state). We could use the "mark" command to maintain our own sequences (by priority, "do today", etc.). "pick" was great for searching bugs and finding out who was working on which bugs. We had a central "bin" directory of scripts to make this easier -- and, of course, individual workers could write their own scripts. A central maintainer actually owned the bug folders, inc'ed new reports into them, refiled messages into archive folders when a bug was fixed, and so on. (Directory modes were set so only the maintainer could move messages out of the folders, but group-write file permissions let everyone in the group make annotations on the messages.) Etc. etc. Sure, there are more sophisticated bug tracking systems that do a lot more, but that's not my point. The point is that the flexibility in nmh makes seamless integration between "email apps" and "other apps" easy to do. In GUI environments -- especially ones that glop all the messages into a single file -- this sort of integration is a lot harder. This is why I'm writing my tomes ;-) about not losing nmh flexibility with IMAP, wherever it's reasonable to keep it. Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: [Fwd: Re: Questions about IMAP and sequences]
Neil W Rickert [EMAIL PROTECTED] writes: That brings up another point (perhaps a bug?) Msg-Protect: 664 (from my '.mh_profile') is ignored on "Fcc:". Thus if a folder is shared between users, messages recorded by "Fcc:" are not shareable -- they get 600 permissions, which is probably the compiled default Msg-Protect). Likewise, if 'refile' of a message crosses partition boundaries, so that the file must be copied, the refile message does not honor Msg-Protect, and does not preserve the original message filemode. It apparently gets the original filemode masked by the umask. Both of these problems would hinder sharing a folder. Incidently, MH appears to have the same problems, so this is not new to nmh. Perhaps the existence of these bugs is evidence that Dan is right in his opinion that shared folders are rarely used. For me the bugs are only a minor inconvenience. I used shared folders, but I share them with myself (administrative account and personal account). Well, considering how hosed the Folder-Protect handling (affecting the single-user case too) was before I took a whack at it some time back, the existence of Msg-Protect bugs may not prove *too* much. --- Dan Harkless | To prevent SPAM contamination, please [EMAIL PROTECTED] | do not post this private email address SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
Re: [Fwd: Re: Questions about IMAP and sequences]
IMO, it's rare because people these days don't think of being able to do it; they're used to GUI mail front-ends that don't allow (?) this kind of thing. Use an IMAP client recently? "Shared" mailboxes are already part of the IMAP specification. Most reasonable ones deal with them just fine. This is why I'm writing my tomes ;-) about not losing nmh flexibility with IMAP, wherever it's reasonable to keep it. Well, the real crux of the problem is that there are some things that you simply cannot _do_ within the context of IMAP. The big one that comes to mind is annotations (there really isn't a way to modify messages on the server, from my reading of the specification). What I've been trying to say all along is that all of the essays in the world won't change the fact that you can't do everything you want to do with IMAP that you are currently doing with nmh. So there might not be a lot of point to writing them. --Ken
Re: [Fwd: Re: Questions about IMAP and sequences]
"Chris Garrigues" writes: : --==_Exmh_-118578032P : Content-Type: text/plain; charset=us-ascii : : From: Iain MacDonnell [EMAIL PROTECTED] : Date: Fri, 08 Sep 2000 20:39:19 +0100 : : Jerry Peek writes: : : On 8 September 2000 at 20:05, Iain MacDonnell [EMAIL PROTECTED] w : rote: : : I'm just saying that an : : IMAP imeplementation could ignore sequences except for "unseen". : : : : I haven't thought a lot about internals here... but couldn't an IMAP : : implementation just store its sequences in the context file (by : : default, ~/Mail/context)? This is what commands like "mark -nopublic" : : do. All nmh commands can access these sequences. : : Does IMAP actually have any concept of sequences, though? I thought that was : left up to the client... time to get out that RFC :) : : I think that's why Jerry was suggesting to put them there. nmh *is* the : client in this case. I missed the middle of this thread, due to being too busy with other things. It sounds like my idea of IMAP support in nmh doesn't completely coincide with everyone else's; I had envisaged an IMAP server which would implement the nmh commands as an interface to the "message store", but the client side would be left open to "anything that supports IMAP". That would enable me to use, say, Netscape Messenger, when I'm away from the office, and exmh when I'm not. I future step could be to implement IMAP in exmh, which could make support for sequences more pertinent, but raises raises another concern; how would sequences be handled when talking to an IMAP server that wasn't our "nmh-ified" one? Wouldn't it be more correct to just stick to the IMAP standard? Just thinking out loud *flame-guards up:)* ~Iain
Re: [Fwd: Re: Questions about IMAP and sequences]
Then there's the question of a "session": doesn't IMAP have the idea of "logging on" or "connecting" to an IMAP store for some period of time, and preserving the state of that session while the user is logged on? "Not really". You can have multiple simultaneous connections, and your clients have to be able to deal with that. I wish I knew more about the intricacies of IMAP; I've only used it in "clueless mode" ;-) from a GUI front-end and hacked it with JavaMail. And sorry if this is obvious; I'm not trying to "talk down" to anyone! I'm just trying to share my (almost) 20 years of experiences with MH. My "gut feel" is that there may not be a perfect one-to-one mapping between nmh/exmh and IMAP. Some things may have to bend. I just hope that the implementation can preserve most of the strengths and flexibility of nmh: it's the only email system with all this power, and it'd be sad for the de facto IMAP implementation to hobble nmh. Argh. You've got it BACKWARDS! _Not_ having IMAP support is hobbling nmh. That's part of the reason it's being relegated to the dustbin of history (the other part is that the stalled development at UCI made it difficult to port to new systems; finally, that's been corrected, but the damaage lingers on). When I first met Eric Allman, the very first question he asked me was, "When the hell is exmh and mh going to support IMAP?" I really don't see why not supporting all of the features of nmh in IMAP is bad; as long as we have something that works, there's a chance of pulling out of the nmh "death spiral"; it's not like we're getting a whole lot of new [n]mh users. When I talk to people about this, the #1 reason I hear for not using nmh is lack of IMAP support; instead they're all using pine or mutt or xfmail; MUAs which all lack the power of nmh, but support IMAP (they're not exactly given a choice on how to access their mail spools). Sure, we should support as many nmh features as possible, but the (IMHO) ridiculous desire for 100% MH compatibility has been what has doomed previous efforts. --Ken
Re: [Fwd: Re: Questions about IMAP and sequences]
In message [EMAIL PROTECTED], also sprach "Dan
Harkless":
The last time I remember IMAP support coming up was quite awhile ago, and
the commentary (from Richard Coleman??) was that IMAP support probably
wouldn't be forthcoming because IMAP would probably spell the eventual death
of [n]mh. I don't recall a lot of posts disagreeing with that view, though
I suspect if the subject were brought up again people would disagree.
I certainly would. My guess is that Richard Coleman thought of MH's
existing mapping between folders and directories/messages and text files to
be a central feature. While that is a convenient way to deal with local
storage, it doesn't seem central to me. To me, the central feature of [n]mh
is that it does away with the monolithic mail client environment in favor of
command- and script-driven environments, and IMAP support wouldn't
compromise this. (I admit that this reverses my position as stated on
comp.mail.mh.)
If not, is there any objection to a Mail::NMH Perl package that provided
such a capability via extension?
I don't quite understand the relation between nmh and your proposed Perl
package, but I'm sure there'd be no objections to any useful extensions to
nmh.
I'll explain in better detail. I intend to implement various nmh entities
-- folders, messages, context (including sequences), profile -- as Perl
objects. Any Perl-aware front end could then use and manipulate those
objects, and one could write a good mail client using such an approach. (A
GTK-Perl nmh client would be a nice thing to have.)
Thanks to OO, I can specify a storage class for each instance of a {Folder,
Message, Sequence} object, and I can make calls to that storage class to
fetch, move, etc., the object. Thus, local objects get treated like classic
nmh entities, while IMAP objects implement the same functionality through other
means.
The advantage of this approach is that it doesn't depend on nmh support for
IMAP. The disadvantage is that it might discourage the implementation of
such support unless some Perl-hater was motivated to correct the
situation...but then they'd probably just implement the same objects in
Python/Java/C++/whatever. nmh would not likely get IMAP support either way.
If there's an existing intention to put IMAP support in nmh, I'll hold off
on putting it in my Perl objects; I'd really rather handle it all through
nmh anyway. However, if that's not likely to happen, I will design the
objects to make this possible, and will implement it as time permits.
JCR
--
Observed by Jeff Cooper:
"Headline in the _Arizona Republic_:
247 POUNDS OF COCAINE SEIZED: TWO HELD
(Cheap! Ten percent is little enough.)"
Re: [Fwd: Re: Questions about IMAP and sequences]
Shantonu Sen [EMAIL PROTECTED] writes: How do IMAP's subfolders differs from nmh's, e.g. `refile +inbox/tasks'. Or are you just saying nmh's IMAP support would include IMAP's subfolders? I'm saying we have lots of options: IMAP folder on Local nmh host mail.foo.com folder - - work/ ~/Mail/IMAP:[EMAIL PROTECTED]/ with `work' sequence work/ ~/Mail/IMAP:[EMAIL PROTECTED]/work work/junk ~/Mail/IMAP:[EMAIL PROTECTED]/ with `work/junk' sequence work/junk ~/Mail/IMAP:[EMAIL PROTECTED]/work with `junk' sequence work/junk ~/Mail/IMAP:[EMAIL PROTECTED]/work/junk So, do IMAP folders and subfolders map directly to nmh folders, or do we use an alternate scheme, as was earlier suggested with sequences? Seems like a one-to-one mapping would be the most natural, the easiest to implement, etc., no? --- Dan Harkless | To prevent SPAM contamination, please [EMAIL PROTECTED] | do not post this private email address SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
Re: [Fwd: Re: Questions about IMAP and sequences]
In message [EMAIL PROTECTED], also sprach Iain MacDonnell: Jerry Peek writes: : On 8 September 2000 at 20:05, Iain MacDonnell [EMAIL PROTECTED] wrote: : I'm just saying that an : IMAP imeplementation could ignore sequences except for "unseen". : : I haven't thought a lot about internals here... but couldn't an IMAP : implementation just store its sequences in the context file (by : default, ~/Mail/context)? This is what commands like "mark -nopublic" : do. All nmh commands can access these sequences. Does IMAP actually have any concept of sequences, though? I thought that was left up to the client... time to get out that RFC :) IMAP does not directly support sequences, but the IMAP standard does allow arbitrary tags and practically all IMAP implementations support them. One could mark a message as being part of a sequence with such a tag. I'm not sure how well that'd work, but it's one way. It's certainly how any implementation of the unseen sequence would have to work. Storing IMAP sequences in one's local filesystem, as Jerry Peek appears to be suggesting, is another approach, but it has problems. There are some trivial annoyances -- IMAP folders can't have the same name as local folders, for example. However, there's a more fundamental bug: The entire advantage of IMAP lies in storing parts of one's email environment -- unseen messages, etc. -- on a central server that one can access from anywhere. Storing sequences on local filesystems violates that idea to the extent that people consider sequences to be a part of their email environment. I submit that people would so consider. JCR -- Observed by Jeff Cooper: "Headline in the _Arizona Republic_: 247 POUNDS OF COCAINE SEIZED: TWO HELD (Cheap! Ten percent is little enough.)"
Re: [Fwd: Re: Questions about IMAP and sequences]
The last time I remember IMAP support coming up was quite awhile ago, and the commentary (from Richard Coleman??) was that IMAP support probably wouldn't be forthcoming because IMAP would probably spell the eventual death of [n]mh. I don't recall a lot of posts disagreeing with that view, though I suspect if the subject were brought up again people would disagree. I've always felt that _that_ particular view, was in a word, "crap". The opposite is probably true; eventual lack of IMAP support might be the death of nmh! I've heard all of the naysayer arguments before, but really, it wouldn't be _that_ hard. Well, okay, I can see some features being lost, but most of the stuff would just sort of fall out once you wrote the glue for the backend functions. The only other thing I remember from that discussion was that there were IMAP implementations out there that used [n]mh as a back-end. I know of a few that use the storage format (one message per file, each folder a directory), but I don't think that there are any that actually use any code or tools from nmh. --Ken
Re: [Fwd: Re: Questions about IMAP and sequences]
Are you thinking of an nmh backend to an imap server or nmh ans an imap client? I'd love to see the actual storage used in nmh 'virtualized', so we can have the same powerful command line interface and different storages (mh files, mbx, mbox, imap, ...) /Anders [EMAIL PROTECTED] said: Is there a plan to implement IMAP connectivity in nmh? If so, who's working on it and when might it be out? If not, is there any objection to a Mail::NMH Perl package that provided such a capability via extension? PGP signature
Re: [Fwd: Re: Questions about IMAP and sequences]
John Reinhagen [EMAIL PROTECTED] writes: Is there a plan to implement IMAP connectivity in nmh? If so, who's working on it and when might it be out? I haven't heard of anyone working on that, but unfortunately nmh developers often have a tendency not to announce what they're working on, so it's possible that someone is. The last time I remember IMAP support coming up was quite awhile ago, and the commentary (from Richard Coleman??) was that IMAP support probably wouldn't be forthcoming because IMAP would probably spell the eventual death of [n]mh. I don't recall a lot of posts disagreeing with that view, though I suspect if the subject were brought up again people would disagree. The only other thing I remember from that discussion was that there were IMAP implementations out there that used [n]mh as a back-end. If not, is there any objection to a Mail::NMH Perl package that provided such a capability via extension? I don't quite understand the relation between nmh and your proposed Perl package, but I'm sure there'd be no objections to any useful extensions to nmh. --- Dan Harkless | To prevent SPAM contamination, please [EMAIL PROTECTED] | do not post this private email address SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
[Fwd: Re: Questions about IMAP and sequences]
Good gracious, how silly of me; I forgot to put the proper -cc switch in my .mh_profile for the repl command. :) Forwarded to the mailing list, with apologies for my momentary chuckleheadedness. --- Forwarded Message To: Jerry Peek [EMAIL PROTECTED] Subject: Re: Questions about IMAP and sequences In-Reply-To: Your message of "Wed, 30 Aug 2000 10:33:15 PDT." [EMAIL PROTECTED] Date: Mon, 04 Sep 2000 11:05:47 -0500 From: John Reinhagen [EMAIL PROTECTED] In message [EMAIL PROTECTED], also sprach Jerry Peek: More info that might help, John: MH and nmh both do sorting and duplicate elimination when they process a string of message-number arguments. Excellent! This implies that sequences can be handled quite easily via IMAP using arbitrary tags. I don't see any other potential problems, except the big one: MH makes a pretty strong assumption that one's file/message hierarchy is reflected by one's local directory/file hierarchy. Disregarding that, there's no problem. :) Is there a plan to implement IMAP connectivity in nmh? If so, who's working on it and when might it be out? If not, is there any objection to a Mail::NMH Perl package that provided such a capability via extension? JCR - -- Observed by Jeff Cooper: "Headline in the _Arizona Republic_: 247 POUNDS OF COCAINE SEIZED: TWO HELD (Cheap! Ten percent is little enough.)" --- End of Forwarded Message
