Subject: Re: [sup-talk] Maildir support

From: Damien Leone <[email-masked]>
Date: Tue, 12 Apr 2011 09:34:45 +0200

Hi,

Excerpts from dtk's message of lun. avril 11 23:44:51 +0200 2011:
> why is that? I thought the way a MUA is supposed to work with a maildir is
> rather straight forward[0]?

Well, yeah, but not sup. :)

> Thanks for the hint!!
> I am a bit suspicious, though :| I don't know much about git, but doesn't that
> essentially mean that the branch is always stuck behind the features in master
> until the new features have manually been merged in?
> And that for every release of master a manual release of the 'maildir' branch
> has to be made?

I keep the maildir-sync branch up to date. If you want the latest
version of sup and the maildir synchronization support then use the
branch maildir-sync-next from my repository.

> Additionally, I consider this a very basic feature. What happens, if there is
> another basic feature that is maintained in _another_ branch? How will I ever be
> able to use them together?

Other features usually get merged faster.

> You know, I'm just wondering why this feature isn't merged in upstream. Are
> there any reasons why anyone would _not_ want proper maildir handling? Or is this
> just a political decision (scared, since I've seen a few of those pull down cool
> projects :/)?

I think it will be merged for the next version although I didn't have
any confirmation from William yet. I don't see any reason why that
wouldn't be the case, as you said there are a lot of people interested
in this feature.

The reason why it is not merged yet is that the code has been finished
a few weeks ago and needs some more testing (even if I've been using
it for 9 months without trouble as well as other people from this
list).

-- 
Damien Leone <[email-masked]>

GPG: 0x82EB4DDF
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk

---

From: Matthieu Rakotojaona <[email-masked]>
Date: Tue, 12 Apr 2011 23:43:10 +0200

On Tue, Apr 12, 2011 at 10:41 PM, dtk <[email-masked]> wrote:
> Although I still wonder a bit
> why this feature hasn't been built in right from the beginning
My two cents, which are only worth one :

The syncing model (often used through IMAP) is based on an old
file-centric idea : POP is a sum of all your mails, IMAP is a folder
for each of your "group" of mail.

But this approach allows one mail to be only in one folder, or at
least that's the way it was thought in the beginning.

Yet, Sup approach, which is just like GMail, is mail-centric : a
single mail can be in different folders. But instead of copying it in
different folders, you can do much better: this single mail can be
tagged as being part of different "groups"; theses groups are
differentiated by labels. This way you can make it be in different
"groups" much more easily than with older systems.

Heliotrope's (Sup next iteration) README :
> Heliotrope provides all the features you actually want in a modern email
> client:
>
> - fast, full-text search over all messages
> - automatic threading
> - arbitrary labels
> - a sophisticated query language
> - support for signed and encrypted email
> - an extensible JSON-over-HTTP API

So, to sum up, with sup, one mail has multiple labels, and with
Maildir/mbox, one folder( ~ one label) has multiple mails.

So, when you apply labels to mails with sup, you have to copy them to
all the folders in the maildir format. But you also have to check for
all the folders where the mail could be, ... which is not so trivial.

Even though, I totally agree with you : I'd love to see my mails being
synced back. Not proposing it in the main branch makes it a little bit
closed. But I have no excuse to complain, because I'm not
contributing. So, I'm just waiting patiently (and use GMail) =]

Waiting on the heliotrop/turnsole projects !

-- 
Matthieu RAKOTOJAONA

---

From: dtk <[email-masked]>
Date: Wed, 13 Apr 2011 00:18:36 +0200

> My two cents, which are only worth one :
Au contraire! I highly appreciate your thoughts and opinion!

> all the folders where the mail could be, ... which is not so trivial.
I have to admit I wasn't very precise when asking for 'proper' maildir
handling. In fact, I didn't intent to ask for a solution that maps the complete
label concept (which as you stated is way more powerful) onto the old-fashioned
directory based approach. What I rather had in mind was a subset like the
exception that is made for sent mail for the other standard directories. Sent
mail is already being copied into a specified source to be kind of backwards
compatible with the classical maildir structure. And I would feel it to be a
natural extension to do so for spam, deleted, read mail as well.

> Waiting on the heliotrop/turnsole projects !
Thanks for the hint. Since two very well respected colleagues of mine are using
'not much' right now, you might want to add that one to your list in case you
don't mind using emacs.

l8r
dtk

---

From: dtk <[email-masked]>
Date: Tue, 12 Apr 2011 22:41:29 +0200

Hi Damien,
thanks for your patient reply!

> Well, yeah, but not sup. :)
yeah, I did already recognize. not impressed :|

> it for 9 months without trouble as well as other people from this
actually, this soothes my concerns quite a bit. Although I still wonder a bit
why this feature hasn't been built in right from the beginning, not being merged
upstream due to being brand new is about the best explanation I can imagine.

Well, I guess I'll just check out your branch these days and hold my breath that
it makes it into the next release ;)

Thanks again
dtk

---

From: Ruthard Baudach <[email-masked]>
Date: Mon, 11 Apr 2011 15:05:09 +0200

> === dtk schrieb am 2011-04-11 10:08: === <

> So I enjoy being able to efficiently organize my mail when working from my box,
> but everytime I am away from it and I therefor have to use another client, I am
> presented with a mailbox that not only intermingles my legitimate mail with the
> occasional spam getting through and the mail I already dismissed (deleted), it
> not even has the mails I already processed marked as read.
> This is a pretty huge deal for me.
> 
> I do imagine though that quite a few of you are using a similar setup. Can you
> please tell me how you handle the situation? Why doesn't my sup add the correct
> maildir flags? Am I holding it wrong? -.-

Thou shalt not have another e-mail client beside of sup -- because sup
does not change the e-mail sources, and if other mail clients change
sources, sup won't be able to find the emails any longer.

There are some workarounds for this, I installed sup on a PC I can
access via dyndns, run sup there and log in with ssh to read my mail
from different locations.
Disadvantage: I cannot view attachements where I need a framebuffer
device.

Well -I could reconfigure my mailcap to use X-programs to view
attachments and use ssh with X-forwarding, might work.

William Morgan is working on a server - client based solution that will
solve this problem, but I don't dare to try it yet - being not work in
progress, but yet in development.

Greetings,

Ruthard

---

From: dtk <[email-masked]>
Date: Mon, 11 Apr 2011 10:08:52 +0200

Hi all,

I've been using sup for a few days now, and I have to say, I'm absolutely in
love with the concept!! I'm only getting used to archiving threads immediately
and trusting sup to bring it back up when something new happens, but my mail
processing has never been that efficient. Thank you very much!

There is one niggle though, that bothers me. I am using offlineimap to sync an
IMAP server with the local maildir that sup works on. That works rather nicely
for one direction (IMAP -> local), but when I work on my local maildir (read
mails, delete them, mark them as spam), changes don't get propagated back to the
server.
I think this might be due to the fact that my sup doesn't seems to move mail
from the new/ to the cur/ dir of mein mailbox and therefor never any flags
(Seen, Thrashed) are added?
This is quite unpleasant to me, since that means that the inbox on the mail
server (that other clients like a web mailer and a thunderbird at work use)
stays cluttered with the usual bunch of mails arriving.
So I enjoy being able to efficiently organize my mail when working from my box,
but everytime I am away from it and I therefor have to use another client, I am
presented with a mailbox that not only intermingles my legitimate mail with the
occasional spam getting through and the mail I already dismissed (deleted), it
not even has the mails I already processed marked as read.
This is a pretty huge deal for me.

tia for you support!
dtk

---

From: dtk <[email-masked]>
Date: Mon, 11 Apr 2011 23:44:51 +0200

Hi Damien,

Excerpts from Damien Leone's message of Mon Apr 11 11:22:09 +0200 2011:
> By default sup doesn't modify the sources at all.

> There is a branch
> that allows backward synchronization, you will find more informations
> at the following address:
>
> http://www.mail-archive.com/[email-masked]/msg00983.html
Thanks for the hint!!

Anyway, thanks for your fast reply!
dtk

----------
[0]http://en.wikipedia.org/wiki/Maildir#Technical_operation

---

From: Damien Leone <[email-masked]>
Date: Mon, 11 Apr 2011 11:22:09 +0200

Hello,

By default sup doesn't modify the sources at all. There is a branch
that allows backward synchronization, you will find more informations
at the following address:

Cheers,

GPG: 0x82EB4DDF

---

From: dtk <[email-masked]>
Date: Mon, 11 Apr 2011 23:58:26 +0200

Hi Ruthard,
thanks for your explanation!

> sources, sup won't be able to find the emails any longer.
hmm, that feels like a rather basic ability of a MUA. Or am I mistaken? :/

> from different locations.
yeah, obviously many people use mutt that way, running in a screen. But that
really ruins the whole offline reading thingy for me... ;P

> progress, but yet in development.
k, I have to admit that I don't quite get yet why we need a distributed
architecture to properly flag our mails (ok, maybe solving that problem is just
a byproduct), but it sure sounds nice. Thunderbird, Claws, mutt et al make do
without tough, me thinks :|
I am just wondering if merging aforementioned branch into master wouldn't make
for a proper, fast and low-effort solution till the server-client refactoring
has been put together and been thorougly tested?

Or am I missing something?
Thanks for your help!
dtk
_______________________________________________
sup-talk mailing list
[email-masked]
http://rubyforge.org/mailman/listinfo/sup-talk