Is this actually a problem for mail? Typically there is one user per
account. It's not like I'm going to be manipulating my mail from my
phone and from nmh simultaneously. I don't have that many hands. Maybe
I'm not being sufficiently imaginative.
My computers manipulate my mail
Hmm.. so 'anno' is a complete loss then? I'd be screwed if I didn't have
a way to add 'Replied:' headers
Two solutions pop to mind:
- IMAP defines message flags that can be changed on a per-message basis.
Some are system defined and can substitute for things like sequences
(\Seen).
On Oct 28, 2013, at 8:35 AM, valdis.kletni...@vt.edu wrote:
Hmm.. so 'anno' is a complete loss then? I'd be screwed if I didn't have
a way to add 'Replied:' headers
With a basic 3501 server, yes.
However, if the IMAP server supports the ANNOTATE extension (RFC5257), it
should be
On Mon, 28 Oct 2013 14:32:17 -0700, Lyndon Nerenberg writes:
On Oct 28, 2013, at 8:35 AM, valdis.kletni...@vt.edu wrote:
Hmm.. so 'anno' is a complete loss then? I'd be screwed if I didn't have
a way to add 'Replied:' headers
With a basic 3501 server, yes.
However, if the IMAP server
On Oct 28, 2013, at 2:43 PM, Alexander Zangerl e...@bin.snafu.priv.at wrote:
and there's always the possibility of using APPEND to upload
modified mails back to the server, which is less than lovely
as you have to upload the complete mail.
You also have to delete the original message. This
On Oct 26, 2013, at 7:11 PM, Ken Hornstein k...@pobox.com wrote:
Beyond that, email messages are generally large (compared to calendar
entries, anyway) collections of text. Changes to messages mostly involve
small deltas to metadata.
Note that messages in IMAP are immutable; we don't have
On 26 Oct 2013, at 20:05, Lyndon Nerenberg lyn...@orthanc.ca wrote:
On Oct 26, 2013, at 7:11 PM, Ken Hornstein k...@pobox.com wrote:
Beyond that, email messages are generally large (compared to calendar
entries, anyway) collections of text. Changes to messages mostly involve
small deltas
On 26 Oct 2013, at 22:18, chad yand...@mit.edu wrote:
It's been a long time since I learned or implemented a network protocol from
an RPC,
See, I can't even spell `RFC' anymore! :-)
~Chad
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
Thus spake Ken Hornstein:
I will note that I've been doing shared calendars using iCloud with my
wife for a while, and the algorithm there seems to be:
a) pick a winner
b) let everyone know what the winning data is
Seems to work out fine in practice.
Is this actually a problem for
On 25 Oct 2013, at 00:41, Joel Uckelman uckel...@nomic.net wrote:
Is this actually a problem for mail? Typically there is one user per
account. It's not like I'm going to be manipulating my mail from my
phone and from nmh simultaneously. I don't have that many hands. Maybe
I'm not being
Thus spake Ken Hornstein:
So, I just found out about this:
http://offlineimap.org
It seems like it's close to what people are interested in. The big wrinkle
is that right now the local store is Maildir; it occurs to me that it
should be straightforward to add nmh folder support to
It seems to me there are two IMAP-related things people have wanted:
1) Have nmh commands act on IMAP-stored messages.
2) Expose an nmh folder via IMAP.
#1 would let you use nmh against arbitrary IMAP accounts. #2 would
let you access your existing nmh storage over IMAP. I think both would
On Oct 24, 2013, at 11:35 AM, Joel Uckelman uckel...@nomic.net wrote:
I looked this over a bit and wasn't able to satisfy myself as to what
OfflineIMAP would do.
For many years now my primary email engine has been IMAP. The driving force
behind this is that I need to access my mail folders
But that describes a simple 1:1 mapping case. Nothing there says the
proof extends to the 1:n mapping case (i.e. multiple clients).
Fair enough ... I'm just trying to imagine exactly a) what conflicting
clients would be doing, exactly, to conflict, and b) what SHOULD happen
when a conflict
On 24 Oct 2013, at 18:17, Ken Hornstein k...@pobox.com wrote:
But that describes a simple 1:1 mapping case. Nothing there says the
proof extends to the 1:n mapping case (i.e. multiple clients).
Fair enough ... I'm just trying to imagine exactly a) what conflicting
clients would be doing,
On Oct 24, 2013, at 6:17 PM, Ken Hornstein k...@pobox.com wrote:
But that describes a simple 1:1 mapping case. Nothing there says the
proof extends to the 1:n mapping case (i.e. multiple clients).
Fair enough ... I'm just trying to imagine exactly a) what conflicting
clients would be
Wouldn't a FUSE IMAP layer largely solve the problem of conflicts
by working on the live data store? Perhaps a customization of
something like:
http://imapfs.sourceforge.net/
http://www.sr71.net/projects/gmailfs/
___
Nmh-workers mailing list
On Oct 24, 2013, at 7:22 PM, Jerrad Pierce belg4...@pthbb.org wrote:
Wouldn't a FUSE IMAP layer largely solve the problem of conflicts
by working on the live data store? Perhaps a customization of
something like:
No. nmh works in many places FUSE will never enjoin.
It's mostly about refile and delete, in the IMAP-MH case. Client
A deletes message 1. Client B moves it to folder foo. Who wins?
Especially when B syncs after A, thus message 1 is no longer in place on
the server. (These are *very* simple examples of what you have to deal
with ...)
It looks
On Oct 24, 2013, at 7:24 PM, Ken Hornstein k...@pobox.com wrote:
Of course, the question really should be: what SHOULD happen in that
case?
Like I said, it gets complicated.
The internet calendaring folks are still having ulcers over this.
___
Wouldn't a FUSE IMAP layer largely solve the problem of conflicts
by working on the live data store? Perhaps a customization of
something like:
Well, I note this from the FUSE IMAP web page:
Note: My project is old and has a lot of unresolved issues and design
problems. Please don't try to
have to manage the mapping between MH message numbers and IMAP messages,
which involves a synchronization process. Also, it just seems like to
Yeah, if I were doing it I'd probably not support all of MH's numbering
and sequence goodness... for simplicity/sanity's sake. Just allow basic
sortm to
have to manage the mapping between MH message numbers and IMAP messages,
which involves a synchronization process. Also, it just seems like to
Yeah, if I were doing it I'd probably not support all of MH's numbering
and sequence goodness... for simplicity/sanity's sake. Just allow basic
sortm to
For anyone who's looking to implement something new, I think that
git's internal architecture might be a good starting place, written
in C. In slightly related news, I looked at notmuch recently, and
it made me miss MH.
I've heard that before, but I don't see how looking at git helps
anything
24 matches
Mail list logo
