* [sup-talk] sent source
@ 2009-05-07 0:02 Ben Walton
2009-05-07 13:23 ` William Morgan
0 siblings, 1 reply; 5+ messages in thread
From: Ben Walton @ 2009-05-07 0:02 UTC (permalink / raw)
Hi All,
I wanted to poll for thoughts on how to handle a generic mbox as the
sent source. My concern is how to deal with file locking...this is
one of the nastier aspects of mbox files.
The cop-out approach is to allow the user to select any mbox source
configured as the outbox and admonish them not to use it for incoming
mail too...that puts us in the same place as ~/.sup/sent.mbox is now.
Doing this does open sup to user error though and the potential for
trashed mboxes.
The next option is to play with locks, but that's not straight forward
at all. Dovecot, as an example, allows a configuration knob for the
admin to set the order in which the different mechanisms are used.
This works as long as all of the mbox consumers use the same sequence.
There is still lots of room for error here (NFS, etc).
Option 3 is to simply limit the mbox sent source to the SentLoader
class which means that 'regular' mbox files available to the user
can't be a destination for sent mail.
None of these solutions is perfect, and all suck compared to their
maildir or imap counterparts (I'm not even going to bother with
ssh+mbox). What do other 'suppers' think about this?
Thanks
-Ben
--
---------------------------------------------------------------------------------------------------------------------------
Ben Walton <bdwalton at gmail.com>
"With or without religion, good people can behave well and bad people
can do evil; but for good people to do evil?that takes religion. "
-Steven Weinberg
---------------------------------------------------------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 5+ messages in thread
* [sup-talk] sent source
2009-05-07 0:02 [sup-talk] sent source Ben Walton
@ 2009-05-07 13:23 ` William Morgan
2009-05-07 21:57 ` Ben Walton
2009-05-09 2:10 ` Ben Walton
0 siblings, 2 replies; 5+ messages in thread
From: William Morgan @ 2009-05-07 13:23 UTC (permalink / raw)
Reformatted excerpts from Ben Walton's message of 2009-05-06:
> The next option is to play with locks, but that's not straight forward
> at all.
This is my favorite option, because sup-sync-back also has to do mbox
locking, so I don't think we can avoid the issue in general.
> Dovecot, as an example, allows a configuration knob for the admin to
> set the order in which the different mechanisms are used. This works
> as long as all of the mbox consumers use the same sequence. There is
> still lots of room for error here (NFS, etc).
Currently sup-sync-back just says, "hey, you can use this program
/usr/bin/dotlockfile if you have it" and pushes the details of locking
to that. I think that's at least a vaguely reasonable approach. Ideally
it would be more configurable, would fall back to other locking
programs, etc., but I think it's significantly better than not doing any
locking at all.
(Eventually these two mbox writers should share the same locking code,
but don't feel obligated to refactor as part of your patch if it's
already getting too hairy.)
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 5+ messages in thread
* [sup-talk] sent source
2009-05-07 13:23 ` William Morgan
@ 2009-05-07 21:57 ` Ben Walton
2009-05-09 2:10 ` Ben Walton
1 sibling, 0 replies; 5+ messages in thread
From: Ben Walton @ 2009-05-07 21:57 UTC (permalink / raw)
Excerpts from William Morgan's message of Thu May 07 09:23:33 -0400 2009:
> Reformatted excerpts from Ben Walton's message of 2009-05-06:
> > The next option is to play with locks, but that's not straight forward
> > at all.
>
> This is my favorite option, because sup-sync-back also has to do mbox
> locking, so I don't think we can avoid the issue in general.
Ok. This is the direction I'll go. This will be the most difficult
part of the whole thing.
> Currently sup-sync-back just says, "hey, you can use this program
> /usr/bin/dotlockfile if you have it" and pushes the details of locking
> to that. I think that's at least a vaguely reasonable approach. Ideally
> it would be more configurable, would fall back to other locking
> programs, etc., but I think it's significantly better than not doing any
> locking at all.
Wouldn't it be nicer to handle this internally?
> (Eventually these two mbox writers should share the same locking code,
> but don't feel obligated to refactor as part of your patch if it's
> already getting too hairy.)
Ok.
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090507/9dcc7d13/attachment.bin>
^ permalink raw reply [flat|nested] 5+ messages in thread
* [sup-talk] sent source
2009-05-07 13:23 ` William Morgan
2009-05-07 21:57 ` Ben Walton
@ 2009-05-09 2:10 ` Ben Walton
2009-05-09 13:01 ` William Morgan
1 sibling, 1 reply; 5+ messages in thread
From: Ben Walton @ 2009-05-09 2:10 UTC (permalink / raw)
Excerpts from William Morgan's message of Thu May 07 09:23:33 -0400 2009:
> Currently sup-sync-back just says, "hey, you can use this program
> /usr/bin/dotlockfile if you have it" and pushes the details of locking
> to that. I think that's at least a vaguely reasonable approach. Ideally
> it would be more configurable, would fall back to other locking
> programs, etc., but I think it's significantly better than not doing any
> locking at all.
...Ok, what about implementing the dotlockfile functionality inside a
LockManager singleton? I'm thinking about something that would accept
a list of required locks before allowing read and write. It would
then provide with_readlock(file, &block) and with_writelock(file,
&block) methods that obtain required locks and yield to the caller to
do the actual work.
> (Eventually these two mbox writers should share the same locking code,
> but don't feel obligated to refactor as part of your patch if it's
> already getting too hairy.)
sup-sync-back could make use of this LockManager too.
Thoughts?
Thanks
-Ben
--
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302
GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://rubyforge.org/pipermail/sup-talk/attachments/20090508/8b72cea9/attachment.bin>
^ permalink raw reply [flat|nested] 5+ messages in thread
* [sup-talk] sent source
2009-05-09 2:10 ` Ben Walton
@ 2009-05-09 13:01 ` William Morgan
0 siblings, 0 replies; 5+ messages in thread
From: William Morgan @ 2009-05-09 13:01 UTC (permalink / raw)
Reformatted excerpts from Ben Walton's message of 2009-05-08:
> ...Ok, what about implementing the dotlockfile functionality inside a
> LockManager singleton? I'm thinking about something that would accept
> a list of required locks before allowing read and write. It would
> then provide with_readlock(file, &block) and with_writelock(file,
> &block) methods that obtain required locks and yield to the caller to
> do the actual work.
That sounds good to me and is very much in the spirit of the current Sup
codebase. I'd like to also have a non-yield mechanism (e.g. #lock and
#unlock methods), similar to the interface Mutex exposes, because
sometimes it's irritating to use the block form, but that's icing on the
cake.
> sup-sync-back could make use of this LockManager too.
Yes, definitely they should all share the same code path.
--
William <wmorgan-sup at masanjin.net>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-05-09 13:01 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-07 0:02 [sup-talk] sent source Ben Walton
2009-05-07 13:23 ` William Morgan
2009-05-07 21:57 ` Ben Walton
2009-05-09 2:10 ` Ben Walton
2009-05-09 13:01 ` William Morgan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox