Subject: [sup-talk] on sup

From: [email-masked] (William Morgan)
Date: Fri, 31 Aug 2007 08:31:04 -0700

Excerpts from Magnus Therning's message of Fri Aug 31 04:04:03 -0700 2007:
> Hey!  Sup is absolutely great!

Thanks! Feel free to join the mailing list and tell all your friends.
Especially if they can write Ruby. :)

> Here are some things I'd like to see in sup in the future:
> 
>  - support for using the output of a command as signature (I don't seem
>    to even get the contents of ~/.signature inserted into new emails)

It should be trivial to add a hook for this. By default ~/.signature
should be appended to email (not in the editor, but in Sup's review
screen immediate post editing). If it's not, it's probably that
~/.sup/config.yaml is pointing to a different file.

>  - PGP/GPG support, this is really a show stopper for me at the moment

Yep, I plan to have first-order GPG support (i.e. not just in the hooks
system.) Not for the next release, but possibly the one after. The time
is nigh.

>  - support for choosing where to save sent messages

This I'm a little curious about. Why do you care where they live on
disk, as long as they show up in the index?

Thanks for the feedback,

-- 
William <wmorgan-sup at masanjin.net>

---

From: [email-masked] (Magnus Therning)
Date: Fri, 31 Aug 2007 18:12:34 +0100

>Especially if they can write Ruby. :)

Here I am.  Not very proficient in Ruby myself, but I suppose sup offers
an incentive to check it out.

>~/.sup/config.yaml is pointing to a different file.

Ah, that's slightly confusing behaviour especially after being used to
mutt.  I think I can adapt though :-)

>system.) Not for the next release, but possibly the one after. The time

Is anyone working on it already?

>disk, as long as they show up in the index?

All right, here's some background :-)

I have a fairly extensive configuration of procmail for sorting mails
into maildir folders on a server at a friend's place.  I then
synchronise those folders onto a few different machines.  This way I can
read emails on all machines, both at home and work.  When I'm travelling
I can use the web-based reader hosted on the same server at my friend's.

Given this I want to control where sent mails end up so that I can
access those mails from all those locations.  And I want to keep my
hierarchy of folders so that reading emails is easy also on machines
where I can't install sup and online.

This makes me think of another little detail, it seems sup's idea of
what's read and what's new isn't based on the maildir notion of what's
read and what's new (i.e. sup doesn't move mail from /new to /cur when
it's read and doesn't recognise that mail in /cur is read).

/M

-- 
Magnus Therning                             (OpenPGP: 0xAB4DFBA4)
magnus?therning?org             Jabber: magnus?therning?gmail?com
http://therning.org/magnus

When the people fear their government, there is tyranny; when the
government fears the people, there is liberty.
     -- Thomas Jefferson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://rubyforge.org/pipermail/sup-talk/attachments/20070831/8ae01aa6/attachment-0001.bin

---

From: [email-masked] (William Morgan)
Date: Sun, 02 Sep 2007 16:03:29 -0700

Excerpts from Magnus Therning's message of Fri Aug 31 10:12:34 -0700 2007:
> >By default ~/.signature should be appended to email (not in the
> >editor, but in Sup's review screen immediate post editing). If it's
> >not, it's probably that ~/.sup/config.yaml is pointing to a different
> >file.
> 

The signature selection algorithm is tied to Sup's multiple account
support: the signature file Sup uses is based on the From: address you
select. You can get the simpler mutt-style behavior by specifying
:edit_signature: true in config.yaml, which always takes the signature
of the default account and dumps it into the editor, or you can now
specify more complicated behavior now with the signature hook.

> >Yep, I plan to have first-order GPG support (i.e. not just in the
> >hooks system.) Not for the next release, but possibly the one after.
> >The time is nigh.
> 

There were patches submitted by I think Christian Lee a while ago, but
they never made it into the svn, mostly because I was waiting for
multiple account support to stabilize a bit. Which it now pretty much
has.

> access those mails from all those locations.

Sup stores its sent mail in ~/.sup/sent.mbox by default. I'm not opposed
to making that filename configurable, but the quickest fix might be just
to make that a symlink to the actual destination file.

> it's read and doesn't recognise that mail in /cur is read).

Yeah, Sup doesn't sync back any state changes to the original sources.
The Sup philosophy has been to treat the sources as dumb, which means
Sup doesn't play well with others. I won't turn aside patches which do
sync back (partial) message state to the sources, but I'm not planning
on implementing that stuff myself.

---

From: [email-masked] (jeff covey)
Date: Mon, 03 Sep 2007 08:33:48 -0400

> I have a fairly extensive configuration of procmail for sorting mails

i also want my sent mail sorted by procmail instead of stored in ~/.sup, so
i run it through "formail -s procmail".  below is the script i run at the
end of the day to empty ~/.sup/sent.mbox and file the messages with
procmail; you might try something similar, perhaps by cron if it's on your
friend's machine.

#------------------------------------------------------
#!/bin/sh

ruby='ruby -I lib -w'

cd ~/tmp/sup/trunk

tmpfile=~/tmp/sup-sent/sup-sent-`/bin/date +%F-%T`.mbox

mv ~/.sup/sent.mbox $tmpfile
touch ~/.sup/sent.mbox

echo "processing messages..."
formail -s procmail < $tmpfile

$ruby bin/sup-sync --changed sup://sent 

echo "original sup sent mbox in $tmpfile"

#------------------------------------------------------

this assumes that the resulting destinations for sent messages are checked
by sup in its poll for new messages, so they show up in sup's index again.

sincerely,

-- 
jeff covey
http://jeffcovey.net/

---

From: [email-masked] (Magnus Therning)
Date: Wed, 05 Sep 2007 08:48:03 +0100

> specify more complicated behavior now with the signature hook.

Ah, cool.  That all makes sense.  I think I like the flow of things as
they are.

> > >hooks system.) Not for the next release, but possibly the one
> > >after.  The time is nigh.
> > 

I wouldn't mind to be a beta-tester for that.  Let me know if you merge
it, or share the changes in another branch or something.

After thinking a little about this I think it's the receiving of
encrypted/signed emails that's cumbersome to deal with at the moment.
If I'm not completely daft it seems like sending is infinitely flexible
through the hooks system.

> > what's read and what's new isn't based on the maildir notion of
> > what's read and what's new (i.e. sup doesn't move mail from /new to
> > /cur when it's read and doesn't recognise that mail in /cur is
> > read).
> 

I'll see if I can't get my head around this red-corundum language you're
using and take a stab at adding this.  ;-)

One more question, is there anything "site specific" in the state data
sup maintains?  Would I run into problem if I use rsync/unison to
synchronise sup's state to several machines?

What if I don't want to obey the laws? Do they throw me in jail with
the other bad monads?
     -- Daveman

---

From: [email-masked] (William Morgan)
Date: Wed, 05 Sep 2007 08:27:14 -0700

Excerpts from Magnus Therning's message of Wed Sep 05 00:48:03 -0700 2007:
> If I'm not completely daft it seems like sending is infinitely
> flexible through the hooks system.

The hooks would be an option, but I'm actually planning to stick it in
the code directly. What I'm thinking is that decoding will just hide the
attachment and display a little message at the top of the message saying
"signature verified", or a big nasty message if not. For encoding, I
would like to have some nice way of choosing sign/sign&encrypt/nothing
on a per-message basis, but I'm not sure what the best UI for that is. I
was originally thinking something like the reply-mode options, but then
how would the two interact? I could also make each option correspond to
various keyboard combinations, but that seems a little obtuse. I don't
really like the mutt-style prompt at the bottom on the screen (the
"minibuffer", as I style it).

> synchronise sup's state to several machines?

Sup uses sources.yaml to map between integer source ids (which are
stored in the index) and the source URIs, which for mbox files are
absolute pathnames. So if you're using local mbox files and the paths
differ between machines, you'll have to tweak sources.yaml to reflect
that. If the source URIs are the same, then as long as sources.yaml is
synchronized along with the ferret/ directory, you should be fine.

Beyond that, Sup uses Ferret to store all state, so if the different
sites have different architecture, it's going to be up to Ferret as to
whether the indexes are portable. I'm not sure of the answer on this
one.

---

From: [email-masked] (William Morgan)
Date: Wed, 05 Sep 2007 14:55:38 -0700

Excerpts from Magnus Therning's message of Wed Sep 05 00:48:03 -0700 2007:
> > Yeah, Sup doesn't sync back any state changes to the original
> > sources.  The Sup philosophy has been to treat the sources as dumb,
> > which means Sup doesn't play well with others. I won't turn aside
> > patches which do sync back (partial) message state to the sources,
> > but I'm not planning on implementing that stuff myself.
> 
> I'll see if I can't get my head around this red-corundum language
> you're using and take a stab at adding this.  ;-)

What little Sup currently does in the way of pushing state information
back into sources, it does through sup-sync-back, which is meant to push
a batch of state changes back to one or more sources in one go. Right
now that's restricted to deleting messages marked as deleted or spam
from mbox sources, but it would be the natural place to push the
new/read state back as well, at least if you were happy with batch
operation.

---

From: [email-masked] (Magnus Therning)
Date: Thu, 06 Sep 2007 07:50:33 +0100

Excerpts from William Morgan's message of Wed Sep 05 22:55:38 +0100 2007:
[..]
> back into sources, it does through sup-sync-back, which is meant to
> push a batch of state changes back to one or more sources in one go.
> Right now that's restricted to deleting messages marked as deleted or
> spam from mbox sources, but it would be the natural place to push the

I'm more than happy with batch operations.  I suspect that doing this
outside of sup proper also keeps the main program itself a little
simpler.

I did look at the sup-sync-back tool and noticed that it performs some
mbox operations on its own.  Operations that I feel really belong in the
mbox source class itself.  I feel sup-sync-back would become simpler if
polymorphism was put to use a bit more.  So, do you have any
philosophical problems with a `delete` method being added to the
sources?  (It would probably be followed by a `mark_as_read` in the
future.)

---

From: [email-masked] (Magnus Therning)
Date: Thu, 06 Sep 2007 08:02:27 +0100

Excerpts from William Morgan's message of Wed Sep 05 16:27:14 +0100 2007:
> > encrypted/signed emails that's cumbersome to deal with at the
> > moment.  If I'm not completely daft it seems like sending is
> > infinitely flexible through the hooks system.
> 
> the code directly. What I'm thinking is that decoding will just hide
> the attachment and display a little message at the top of the message
> saying "signature verified", or a big nasty message if not. For
> encoding, I would like to have some nice way of choosing
> sign/sign&encrypt/nothing on a per-message basis, but I'm not sure
> what the best UI for that is. I was originally thinking something like
> the reply-mode options, but then how would the two interact? I could
> also make each option correspond to various keyboard combinations, but
> that seems a little obtuse. I don't really like the mutt-style prompt
> at the bottom on the screen (the "minibuffer", as I style it).

Yes, the UI will be hard to get right on this.  What about adding an
extra screen with extra options for sending (encryption/signing might
only be one set of options that are needed).  That would push the
problem to being one of making sure that good, fairly powerful default
behaviours are in place.  These are the default behaviours I'd like to
see:

 - Don't sign, don't encrypt
 - Sign all out-going messages, don't encrypt
 - Sign all replies to signed messages, don't encrypt
 - Sign all replies to signed messages, encrypt replies to encrypted
   messages
 - Sign all out-going messages, encrypt all messages to recipients with
   a known public key

I hope that covers more usage so that visiting that extra screen won't
be necessary in most cases.

Making sure that it all works on emails with multiple recipients
shouldn't be too difficult.  (Signing isn't a problem, and encryption
only happens if _all_ recipients have a known public key.)

---

From: [email-masked] (William Morgan)
Date: Tue, 11 Sep 2007 13:48:55 -0700

Excerpts from Magnus Therning's message of Wed Sep 05 23:50:33 -0700 2007:
> mbox operations on its own.  Operations that I feel really belong in
> the mbox source class itself.  I feel sup-sync-back would become
> simpler if polymorphism was put to use a bit more.  So, do you have
> any philosophical problems with a `delete` method being added to the

I don't have a philosophical problem with that, certainly.  Sup-sync-
back was written in that way because I was fleshing out a lot half-baked
ideas about how things should work at the time, and it will definitely
be necessary to move that code to Mbox::loader before it can support
other source types.

In order to support batch operations, I think there should be two
methods per source, really: #delete and #write_deletes_to_disk (or
whatever), with the semantics that #delete may or may not do something
but you're guaranteed that deletions have happened after a call to
#write_deletes_to_disk. Then Maildir, IMAP, etc can delete immediately,
and mbox can defer (presumably building up an array of offset to be
deleted, and then doing the batch deletion as it does currently.)

(There are actually a couple other things that need to happen to
 mbox---it shouldn't keep the file pointers open all the time, it should
 wrap deletion and new message scanning with a call to dotlockfile, and
 the bizarre division of labor between loader, sshloader, and the source
 superclass has become a classic example of how not to use inheritance.
 Luckily, none of those things really affect this issue.)

What do you think?

---

From: [email-masked] (William Morgan)
Date: Tue, 11 Sep 2007 15:08:34 -0700

Excerpts from Magnus Therning's message of Thu Sep 06 00:02:27 -0700 2007:
> These are the default behaviours I'd like to see:
> 

I think you've convinced me to hold off any an UI changes and just have
a set of behaviors for signing and encryption, configurable in
config.yaml, that are sophisticated enough to minimize the need for
per-message actions. That should be pretty easy to do.

---

From: [email-masked] (Magnus Therning)
Date: Wed, 12 Sep 2007 00:04:15 +0100

>per-message actions. That should be pretty easy to do.

Now I know this might not be a very user friendly idea and probably not
ideal for the long run.  It might be a good first step to simply have a
hook like this:

 crypto_hook sender, recipient, reply_to_signed?, reply_to_encrypted? ->
 dosign, doencrypt

(Apply your mad Ruby skills to make it Ruby-esque, but you get the idea.)

That'd buy you some time to come to a conclusion, while still making sup
a lot more useful for early adopters (like me :-).

/M
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://rubyforge.org/pipermail/sup-talk/attachments/20070912/91e2358f/attachment.bin