* [sup-talk] on sup
[not found] <1188557360-sup-7369@bryma>
@ 2007-08-31 15:31 ` William Morgan
2007-08-31 17:12 ` Magnus Therning
0 siblings, 1 reply; 12+ messages in thread
From: William Morgan @ 2007-08-31 15:31 UTC (permalink / raw)
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>
^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] on sup
2007-08-31 15:31 ` [sup-talk] on sup William Morgan
@ 2007-08-31 17:12 ` Magnus Therning
2007-09-02 23:03 ` William Morgan
2007-09-03 12:33 ` [sup-talk] saving sent mail to places other than the default jeff covey
0 siblings, 2 replies; 12+ messages in thread
From: Magnus Therning @ 2007-08-31 17:12 UTC (permalink / raw)
On Fri, Aug 31, 2007 at 08:31:04 -0700, William Morgan wrote:
>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 I am. Not very proficient in Ruby myself, but I suppose sup offers
an incentive to check it out.
>> 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.
Ah, that's slightly confusing behaviour especially after being used to
mutt. I think I can adapt though :-)
>> - 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.
Is anyone working on it already?
>> - 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?
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] on sup
2007-08-31 17:12 ` Magnus Therning
@ 2007-09-02 23:03 ` William Morgan
2007-09-05 7:48 ` Magnus Therning
2007-09-03 12:33 ` [sup-talk] saving sent mail to places other than the default jeff covey
1 sibling, 1 reply; 12+ messages in thread
From: William Morgan @ 2007-09-02 23:03 UTC (permalink / raw)
Excerpts from Magnus Therning's message of Fri Aug 31 10:12:34 -0700 2007:
> On Fri, Aug 31, 2007 at 08:31:04 -0700, William Morgan wrote:
> >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.
>
> Ah, that's slightly confusing behaviour especially after being used to
> mutt. I think I can adapt though :-)
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.
>
> Is anyone working on it already?
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.
> Given this I want to control where sent mails end up so that I can
> 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.
> 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).
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.
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] saving sent mail to places other than the default
2007-08-31 17:12 ` Magnus Therning
2007-09-02 23:03 ` William Morgan
@ 2007-09-03 12:33 ` jeff covey
1 sibling, 0 replies; 12+ messages in thread
From: jeff covey @ 2007-09-03 12:33 UTC (permalink / raw)
Excerpts from Magnus Therning's message of Fri Aug 31 13:12:34 -0400 2007:
> > > - 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?
>
> 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/
^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] on sup
2007-09-02 23:03 ` William Morgan
@ 2007-09-05 7:48 ` Magnus Therning
2007-09-05 15:27 ` William Morgan
2007-09-05 21:55 ` William Morgan
0 siblings, 2 replies; 12+ messages in thread
From: Magnus Therning @ 2007-09-05 7:48 UTC (permalink / raw)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Excerpts from William Morgan's message of Mon Sep 03 00:03:29 +0100 2007:
> Excerpts from Magnus Therning's message of Fri Aug 31 10:12:34 -0700 2007:
> > On Fri, Aug 31, 2007 at 08:31:04 -0700, William Morgan wrote:
> > >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.
> >
> > Ah, that's slightly confusing behaviour especially after being used to
> > mutt. I think I can adapt though :-)
>
> 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.
Ah, cool. That all makes sense. I think I like the flow of things as
they are.
> > >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.
> >
> > Is anyone working on it already?
>
> 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.
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.
> > 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).
>
> 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. ;-)
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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFG3l8kiMWTaatN+6QRAmP1AJ9ynvIgglFT4z1ku8LyjfeIoNOxoQCffjey
bnjeItGmOKF/TOVTIBtWmF8=
=zyyx
-----END PGP SIGNATURE-----
--
Magnus Therning (OpenPGP: 0xAB4DFBA4)
magnus?therning?org Jabber: magnus?therning?gmail?com
http://therning.org/magnus
What if I don't want to obey the laws? Do they throw me in jail with
the other bad monads?
-- Daveman
^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] on sup
2007-09-05 7:48 ` Magnus Therning
@ 2007-09-05 15:27 ` William Morgan
2007-09-06 7:02 ` Magnus Therning
2007-09-05 21:55 ` William Morgan
1 sibling, 1 reply; 12+ messages in thread
From: William Morgan @ 2007-09-05 15:27 UTC (permalink / raw)
Excerpts from Magnus Therning's message of Wed Sep 05 00:48:03 -0700 2007:
> 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.
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).
> 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?
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.
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] on sup
2007-09-05 7:48 ` Magnus Therning
2007-09-05 15:27 ` William Morgan
@ 2007-09-05 21:55 ` William Morgan
2007-09-06 6:50 ` Magnus Therning
1 sibling, 1 reply; 12+ messages in thread
From: William Morgan @ 2007-09-05 21:55 UTC (permalink / raw)
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.
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] on sup
2007-09-05 21:55 ` William Morgan
@ 2007-09-06 6:50 ` Magnus Therning
2007-09-11 20:48 ` William Morgan
0 siblings, 1 reply; 12+ messages in thread
From: Magnus Therning @ 2007-09-06 6:50 UTC (permalink / raw)
Excerpts from William Morgan's message of Wed Sep 05 22:55:38 +0100 2007:
[..]
> 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.
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.)
--
Magnus Therning (OpenPGP: 0xAB4DFBA4)
magnus?therning?org Jabber: magnus?therning?gmail?com
http://therning.org/magnus
What if I don't want to obey the laws? Do they throw me in jail with
the other bad monads?
-- Daveman
^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] on sup
2007-09-05 15:27 ` William Morgan
@ 2007-09-06 7:02 ` Magnus Therning
2007-09-11 22:08 ` William Morgan
0 siblings, 1 reply; 12+ messages in thread
From: Magnus Therning @ 2007-09-06 7:02 UTC (permalink / raw)
Excerpts from William Morgan's message of Wed Sep 05 16:27:14 +0100 2007:
> Excerpts from Magnus Therning's message of Wed Sep 05 00:48:03 -0700 2007:
> > 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.
>
> 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).
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.)
--
Magnus Therning (OpenPGP: 0xAB4DFBA4)
magnus?therning?org Jabber: magnus?therning?gmail?com
http://therning.org/magnus
What if I don't want to obey the laws? Do they throw me in jail with
the other bad monads?
-- Daveman
^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] on sup
2007-09-06 6:50 ` Magnus Therning
@ 2007-09-11 20:48 ` William Morgan
0 siblings, 0 replies; 12+ messages in thread
From: William Morgan @ 2007-09-11 20:48 UTC (permalink / raw)
Excerpts from Magnus Therning's message of Wed Sep 05 23:50:33 -0700 2007:
> 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.)
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?
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] on sup
2007-09-06 7:02 ` Magnus Therning
@ 2007-09-11 22:08 ` William Morgan
2007-09-11 23:04 ` Magnus Therning
0 siblings, 1 reply; 12+ messages in thread
From: William Morgan @ 2007-09-11 22:08 UTC (permalink / raw)
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:
>
> - 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 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.
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 12+ messages in thread
* [sup-talk] on sup
2007-09-11 22:08 ` William Morgan
@ 2007-09-11 23:04 ` Magnus Therning
0 siblings, 0 replies; 12+ messages in thread
From: Magnus Therning @ 2007-09-11 23:04 UTC (permalink / raw)
On Tue, Sep 11, 2007 at 15:08:34 -0700, William Morgan wrote:
>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:
>>
>> - 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 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.
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
--
Magnus Therning (OpenPGP: 0xAB4DFBA4)
magnus?therning?org Jabber: magnus?therning?gmail?com
http://therning.org/magnus
-------------- 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
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2007-09-11 23:04 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <1188557360-sup-7369@bryma>
2007-08-31 15:31 ` [sup-talk] on sup William Morgan
2007-08-31 17:12 ` Magnus Therning
2007-09-02 23:03 ` William Morgan
2007-09-05 7:48 ` Magnus Therning
2007-09-05 15:27 ` William Morgan
2007-09-06 7:02 ` Magnus Therning
2007-09-11 22:08 ` William Morgan
2007-09-11 23:04 ` Magnus Therning
2007-09-05 21:55 ` William Morgan
2007-09-06 6:50 ` Magnus Therning
2007-09-11 20:48 ` William Morgan
2007-09-03 12:33 ` [sup-talk] saving sent mail to places other than the default jeff covey
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox