Re: [Nmh-workers] What is MH ? (was: exciting new stuff for 2.0 (IMAP proposal))
Ken Hornstein wrote: I have mail stored on an IMAP server. I think it's perfectly reasonable that I should be able to do scan +IMAP:inbox (or however you want to indicate that a particular folder is on an IMAP server; I Why not extend that to +mbox:inbox for mbox folders? Seriously, though, perhaps you could consider extending msh to support IMAP. At least in msh, users don't expect their scripts to work. have no strong feelings on the matter), and I have yet to see anyone offer a reason why this is _not_ a useful objective. Yeah, an I don't contend that this wouldn't have it's uses but I would argue that a user-space filesystem would be far more useful. Typically, the usefulness of software is a function of the number of interconnections between components (or features) and not a function of the number of components. Integrating IMAP breaks with the original concepts behind MH. And, like Robert, I have many scripts used in conjunction with MH. Without similar IMAP support in these, MH doing IMAP would be of limited use to me. If someone is determined to implement it then I don't want to stop them but don't expect me to be particular enthusiastic. FUSE may only support Linux but it is a relatively new addition (kernel 2.6.14 or thereabouts). If proved a success and given time, it (or a similar interface) would make its way into Darwin/Solaris/what have you. An IMAP filesystem will have wider uses which could mean that non-MH people may help us with it. We may not care if they add a mount option to export Maildir format messages but they could also help debug other areas. And if someone beats us to it, we could take their filesystem and hack it to support MH. As a point of interest, kmail uses a kioslave (a KDE specific virtual filesystem) for accessing mail. I think you can use imap:// URLs in konqueror to access this. Oliver This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] What is MH ? (was: exciting new stuff for 2.0 (IMAP proposal))
Robert Elz wrote: I can't speak to your comfort level, but accessing the files directly is necessary for some usages, and definitely part of what MH offers. aye, laddie (doing my best Cmdr. Montgomery Scott impression) when i had to implement a mandatory document retention policy for MH users i came very close to touching files directly, but i managed to get everything done with some shell scripts and a .mh_profile that intercepted a number of things. without the rich interception points in the MH commands, i would have had to do more direct messing with things - as it was, i squeaked by. but knowing i had enough rope if i ran out of luck was critical - the alternative was moving off MH because of DoJ requirements on a very tight deadline. when it came to delivering the retained emails to Them What Must Get Them, a tar in the right place slurped-up everything, neat and tidy, unlike the horrorshow that ensued with people using other email clients. of course, i did get the question about Why isn't this a Windows zip file? my unrmm command (shell script) does mess with files directly, though, but it was written eons ago - maybe today the intercepts would be rich enough, but i don't have to care!! (it would be useful if the delete prefix character were available for the asking, rather than having to wire it in - maybe it should be specifiable in .mh_profile and logically retrievable from there?) as for flame war, as KRE can attest, this discussion is nowhere close to a genuine flame war. i will note in passing that a legend tells of the early email behavior of an IMAP luminary as being the reason the verb to flame was coined. the person has since grown into considerable wisdom (he was very young at the time) so the name need not be repeated. and as with all legends, it might not be true, but it is a great legend. cheers, -mo ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] What is MH ? (was: exciting new stuff for 2.0 (IMAP proposal))
This is flamebait, shame on you. I disagree; I thought it was relatively straightforward, and not intended as flamebait at all. I have mail stored on an IMAP server. I think it's perfectly reasonable that I should be able to do scan +IMAP:inbox (or however you want to indicate that a particular folder is on an IMAP server; I have no strong feelings on the matter), and I have yet to see anyone offer a reason why this is _not_ a useful objective. Yeah, an integrated MUA may do that better ... but I guess I don't see that as a reason to not add a feature to MH. If we start using that as a metric for not adding features to MH, we might as well pack it up now and go home, because everyone is going to realize that most other MUAs do the things that they want better and nmh development will wither and die. Note that this has almost happened several times already. Using your argument, shouldn't the initial developers of mh just have used the commonly available mbox format then? There are certain things gained from the mh folder format, the people who cooked it up knew what they wanted. Um, no, I don't think that follows from my argument at all. My argument was, Hey, I would find this feature useful, why should it not be added? I fail to understand what this discussion is all about. I agree that it would be nice if inc could suck mail from imap, but how is having the command line tools understand imap not outside of the scope of mh? This sounds like it could make a fine fork from the mh code, but I fail to see how such an addition can be classified as a part of mh. What is gained? Does this even solve a problem? It solves the problem of me wanting to access my IMAP mailbox via the MH tools I'm used to. I think that's a useful problem to solve; obviously not everyone agrees. This could enable things like exmh having IMAP support (I admit, it would require some significant work to make this happen from exmh's perspsective, but it would make it a lot easier). I don't see nmh living for much longer unless things change. Most projects would be considered dead at this point, but somehow nmh is hanging on. I see this discussion as wasted energy. Who is going to add these features, then who is going to maintain it? Right now I don't think you could add such a feature to nmh without causing its death. The code is already mostly unmaintainable, adding something this complex would make it worse. Note that I have said several times; people interested in IMAP support should just do it, rather than talk about it. And while I share the concern about nmh dying, I have a completely different perspective: I think new features are the way to keep it alive! --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] What is MH ? (was: exciting new stuff for 2.0 (IMAP proposal))
I have mail stored on an IMAP server. I think it's perfectly reasonable that I should be able to do scan +IMAP:inbox (or however you want to indicate that a particular folder is on an IMAP server; I Why not extend that to +mbox:inbox for mbox folders? If someone wanted to do that, more power to them. Seriously, though, perhaps you could consider extending msh to support IMAP. At least in msh, users don't expect their scripts to work. I'd personally be happy with msh supporting IMAP. That would solve my problem. I don't contend that this wouldn't have it's uses but I would argue that a user-space filesystem would be far more useful. I have two technical concerns with a user-space filesystem. One is that right now it's rather unportable. The second is that if you want to use something like Kerberos (or anything that involves accessing credentials from a user's context) it is technically challenging to make the user's credentials available to the process performing the IMAP access. Both of those are solvable problems, but they're a lot of work. And, like Robert, I have many scripts used in conjunction with MH. Without similar IMAP support in these, MH doing IMAP would be of limited use to me. But given that MH doesn't support IMAP now, it's not exactly a functionality loss, is it? But to be fair ... if your scripts used mhpath, then I think it would be relatively easy to do the right magic to make them work. Anyway, I've said my peace. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] What is MH ? (was: exciting new stuff for 2.0 (IMAP proposal))
In message [EMAIL PROTECTED], Igor Sobrado writes: Why is specifying more than one folder concurrently not possible? Is it a security feature? In other words, I believe that I am asking about using a more flexible getopt(3)-like function with support for the + syntax. I suppose that there is a good technical reason for not allowing more than one folder at same time, but I would like asking for this feature if it is possible. Best regards, Igor. ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] What is MH ? (was: exciting new stuff for 2.0 (IMAP proposal))
Ken Hornstein wrote:
I have mail stored on an IMAP server. I think it's perfectly
reasonable that I should be able to do scan +IMAP:inbox (or
however you want to indicate that a particular folder is on an IMAP
server; I
Oliver Kiddle [EMAIL PROTECTED] wrote:
Why not extend that to +mbox:inbox for mbox folders?
Ugh. This syntax is not generic or transparent and diverges to how MH
currently works. A command-line switch or a configuration file would
be more appropriate if we are going to support multiple email
storage/access formats. I certainly believe that we should provide
the ability to specify the location of the graft folder for IMAP
access. This *will* require additional configuration file commands
and/or an additional configuration file to map local cache folders to
the backend storage, which is much cleaner than trying to change the
meaning of the folder UI.
Seriously, though, perhaps you could consider extending msh to
support IMAP. At least in msh, users don't expect their scripts to
work.
Good point. However, mh commands should be able to provide cached
messages in a manner compatible with current mh paradigms. mhpath,
for example, may report the message lives at /tmp/42987hjklj16h or
~/mail/folder/3. The interface is already proven to work well. If
you need to access an IMAP hosted message for annotation, editing,
viewing, then the mh commands should provide a cached copy for these
operations and synchronize (push) the message when the changes are
complete.
You may need to add commands to synchronize local changes to email
messages with their backend storage, i.e. mhcache {push|pull|sync}.
Integrating IMAP breaks with the original concepts behind MH. And,
like Robert, I have many scripts used in conjunction with MH.
Without similar IMAP support in these, MH doing IMAP would be of
limited use to me.
Unless IMAP support is crafted in such a way where you can still use
these scripts. Imagine the use of two additional tools and one
configuration extension. mhagent for saving credentials and possibly
keeping persistent client-server connections open and mhcache for
maintaining synchronous copies of the message in the local filesystem.
Neither would have to operate continuously in the background, but
having a daemon function would speed up access.
The last is the ability to graft folders into the path without using
symlinks or other filesystem tricks, specifying the graft location and
how to access the file in a configuration file. For example, a
Maildir folder exists in ~/Maildir/folder. Being able to graft that
in to the MH interface might involve editing .mh_profile to have:
# Recognized as +folderpath
graft-maildir-folderpath: actualpath
# Recognized as +folderpath2 and 3
graft-imap-folderpath2: imaps://[EMAIL PROTECTED]:hostname/INBOX
graft-imap-folderpath3: imaps://[EMAIL PROTECTED]:hostname/mail/folderpath3
It should be entirely possible to do without breaking current MH
design principles. The ability to synchronize local Maildir/MH files
with an IMAP server is provided in a python2.3 program called
offlineimap by John Goerzen. I've tried to use it before, but had
some tough to debug issues with duplicate and missing messages.
Rather than dig into it, I simply continue to use fetchmail/procmail
on my local workstation. He uses a clever trick of annotating each
message with a unique identifier header to help track individual
messages. It's something the person implementing IMAP support should
look in to.
As a point of interest, kmail uses a kioslave (a KDE specific
virtual filesystem) for accessing mail. I think you can use imap://
URLs in konqueror to access this.
Yes, plenty of prior art to help us out here.
--
Chad Walstrom [EMAIL PROTECTED] http://www.wookimus.net/
assert(expired(knowledge)); /* core dump */
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] What is MH ? (was: exciting new stuff for 2.0 (IMAP proposal))
The suggestion to make an IMAP filesystem (as linux centric as the original suggestion was) is clearly the direction that would allow MH and IMAP to work together properly. Embedding IMAP knowledge into show, next, scan, pick, refile, ... just fails to meet almost any useful objective. With all due respect to kre, who has forgotten more about Unix than I will ever know ... I cannot disagree more. I have mail stored on an IMAP server. I think it's perfectly reasonable that I should be able to do scan +IMAP:inbox (or however you want to indicate that a particular folder is on an IMAP server; I have no strong feelings on the matter), and I have yet to see anyone offer a reason why this is _not_ a useful objective. Yeah, an integrated MUA may do that better ... but I guess I don't see that as a reason to not add a feature to MH. If we start using that as a metric for not adding features to MH, we might as well pack it up now and go home, because everyone is going to realize that most other MUAs do the things that they want better and nmh development will wither and die. Note that this has almost happened several times already. Yes, it breaks your csh script if you want to use it with an IMAP server. I guess I don't see why that's necessarily bad. I view it as something new you can do with the tools you have gotten used to. Clearly you would never use it, so it wouldn't impact you at all. And if you really wanted to make everybody's scripts work with MH, you could do some work with mhpath to pull down messages as they were needed. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] What is MH ? (was: exciting new stuff for 2.0 (IMAP proposal))
The suggestion to make an IMAP filesystem (as linux centric as the original suggestion was) is clearly the direction that would allow MH and IMAP to work together properly. Embedding IMAP knowledge into show, next, scan, pick, refile, ... just fails to meet almost any useful objective. With all due respect to kre, who has forgotten more about Unix than I will ever know ... I cannot disagree more. This is flamebait, shame on you. I have mail stored on an IMAP server. I think it's perfectly reasonable that I should be able to do scan +IMAP:inbox (or however you want to indicate that a particular folder is on an IMAP server; I have no strong feelings on the matter), and I have yet to see anyone offer a reason why this is _not_ a useful objective. Yeah, an integrated MUA may do that better ... but I guess I don't see that as a reason to not add a feature to MH. If we start using that as a metric for not adding features to MH, we might as well pack it up now and go home, because everyone is going to realize that most other MUAs do the things that they want better and nmh development will wither and die. Note that this has almost happened several times already. Using your argument, shouldn't the initial developers of mh just have used the commonly available mbox format then? There are certain things gained from the mh folder format, the people who cooked it up knew what they wanted. I fail to understand what this discussion is all about. I agree that it would be nice if inc could suck mail from imap, but how is having the command line tools understand imap not outside of the scope of mh? This sounds like it could make a fine fork from the mh code, but I fail to see how such an addition can be classified as a part of mh. What is gained? Does this even solve a problem? Making this happen is going to require a lot of work. Making it work in a way that isn't just bolting a bag a manure onto the side of the current code will be a miracle. I don't see nmh living for much longer unless things change. Most projects would be considered dead at this point, but somehow nmh is hanging on. I see this discussion as wasted energy. Who is going to add these features, then who is going to maintain it? Right now I don't think you could add such a feature to nmh without causing its death. The code is already mostly unmaintainable, adding something this complex would make it worse. If someone has interest in actually doing this work, not just talking about it, help me clean up the code. There would be no reason nmh couldn't have something like a folder plugin architecture, so those of you who want imap support can have it, while people like me who have no need for it don't have to worry about bugs in imap breaking anything else. -- JB ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] What is MH ? (was: exciting new stuff for 2.0 (IMAP proposal))
Date:Mon, 09 Jan 2006 11:15:38 -0600 From:Chris Garrigues [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] | 1) If the MH community has nothing to do with the implementation, |what's going to assure that the IMAP filesystem looks like something |that MH can use easily. Easily being the operative word there - if it were done, and messages turned into files, then MH would be able to use it - if the directory structure happens to look just like MH wants, that would be easier, if it doesn't, it could still be handled, with a little more difficulty. | It seems unlikely to me that such a filesystem will be implemented | unless the MH community is involved. Unless people who care about MH, and use it are involved, yes, that's most probably completely true. But it doesn't have to be the same group, and almost certainly shouldn't be - it takes almost no knowledge of e-mail formats to make something like this, so those people in the MH community who are there to help make sure that the e-mail formats are properly maintained, and parsed, wouldn't need to be involved. On the other hand, there are lots of file system details, that MH normally has no knowledge of, nor any need to understand, and so a project like this would need assistance from people who have nothing in particular to do with MH I'd expect. I'd also expect that the IMAP community (or some part of it) would have an interest. So, certainly I'd expect this to be something that many (or at least several) of the people who participate on the MH list would get involved with, I'd be horrified if the MH mailing list suddenly started talking about VNODE operations, and how to implement the right ones for an IMAP filesystem. kre ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] What is MH ? (was: exciting new stuff for 2.0 (IMAP proposal))
The relevance of this to the current dicsussion, is that unless the plan to integrate IMAP means treat an IMAP server like a POP server (that is: fetch mail from where the MTA stored it and move it into the MH folder structure), which would be an OK (and easy) thing to do, then you aren't finished until you have the IMAP part of your MH folders just as accessible to all of these add-on shell commands as to the (much smaller) set of commands that are distributed in nmh-whatever.tgz. I think you're confusing interface a little with implementation. Certainly I agree that what makes MH special is its UNIXy non-monolithic interface, but that stands even without direct access to the storage of messages. I, for one, am never comfortable accessing the storage directly, and use things like show -noshowproc to process the data raw. Besides, doesn't MH already have support for alternative storage formats? Adding IMAP support for each and every MH operation is sufficient for many, if not most, add-on shell commands that might be mixed in. Cheers, - Joel ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] What is MH ? (was: exciting new stuff for 2.0 (IMAP proposal))
On Mon, 09 Jan 2006 20:13:56 +0700, Robert Elz said: The suggestion to make an IMAP filesystem (as linux centric as the original suggestion was) is clearly the direction that would allow MH and IMAP to work together properly. Embedding IMAP knowledge into show, next, scan, pick, refile, ... just fails to meet almost any useful objective. The Obviously Correct Way to approach this would be (on a Linux system anyhow) a back-end for a FUSE filesystem. http://fuse.sourceforge.net/ Doing this would be a *lot* more sensible than trying to hack IMAP function into the nmh source tree. The basic idea is that you'd do something like: fusermount imapserver:userid ~/Mail/imap_dir and then if you did 'scan +imap_dir/folder3 last', the FUSE code would see all the references to ~/Mail/imap_dir/folder3/* and issue the correct IMAP calls behind the scenes... And of course, 'grep -i foo23 ~/Mail/imap_dir/folder3/*' will behave as expected as wel. pgpgATwQDc3Pr.pgp Description: PGP signature ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] What is MH ? (was: exciting new stuff for 2.0 (IMAP proposal))
Using your argument, shouldn't the initial developers of mh just have used the commonly available mbox format then? There are certain things gained from the mh folder format, the people who cooked it up knew what they wanted. That's an interesting idea, and it'd be nice to hear more. Feel free to reply just to me if you think it'd just be noise on the list. I fail to understand what this discussion is all about. I agree that it would be nice if inc could suck mail from imap, but how is having the command line tools understand imap not outside of the scope of mh? This sounds like it could make a fine fork from the mh code, but I fail to see how such an addition can be classified as a part of mh. What is gained? Does this even solve a problem? Surely all the arguments that apply to using IMAP in the first place for any email at all also apply to MH+IMAP. I can use MH from a number of different machines because my home directory is NFS mounted within a small network, but NFS is not appropriate for all situations. Making this happen is going to require a lot of work. Making it work in a way that isn't just bolting a bag a manure onto the side of the current code will be a miracle. I'll admit I haven't looked thoroughly at the IMAP spec, but from what I've seen so far the mapping from MH commands to IMAP requests looks pretty good. I don't see nmh living for much longer unless things change. Most projects would be considered dead at this point, but somehow nmh is hanging on. It's hanging on because there are still command-line users out there. MH is the only command-line and shell oriented MUA that I know of. Cheers, - Joel ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] What is MH ? (was: exciting new stuff for 2.0 (IMAP proposal))
Seems like a lot of energy going into nonproductive arguing here. A few thoughts, in no particular order. I want to keep using the mailing list; wiki's are nice for some things, but not ongoing discussions. I hate having to reread all sorts of stuff in wikis to find the new stuff, and I like a linear history of things. I think that some work needs to be done on cleanup before any major changes are made. In particular, the library stuff needs to be scrubbed, and I notice that Josh is doing some of that. I think that this is important so that the foundation doesn't keep shifting as new stuff is built on top. I hope to find some time to do some work there soon. (Any opinions on using mmap? Would make all of the header processing much simpler to just mmap the first few k of each message and then run pointers through it.) I use mh because it's one of the few things left that still pretty much follows the unix philosophy that I learned as a teenaged summer student at BTL in the early 70's. I like having a set of commands that each do one thing so it's easy to add new commands that do new things. I like the one-message-per-file structure which makes it easy to apply the rest of the unix toolset to mail. I would like any major changes to mh to follow the original non-monolithic, one message per file philosophy. I'd like to avoid changing mh into something as complex as most of the monolithic packages that are out there today. In general, I don't see much point to the currently discussion which seems to be escalating towards a flame war. If you want to do something, lay out a proposal, let's toss it around, and then get to work. Jon ___ Nmh-workers mailing list Nmh-workers@nongnu.org http://lists.nongnu.org/mailman/listinfo/nmh-workers
