Subject: [sup-talk] sent source

From: [email-masked] (Ben Walton)
Date: Wed, 6 May 2009 20:02:26 -0400

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
---------------------------------------------------------------------------------------------------------------------------

---

From: [email-masked] (William Morgan)
Date: Thu, 07 May 2009 06:23:33 -0700

Reformatted excerpts from Ben Walton's message of 2009-05-06:
> 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>

---

From: [email-masked] (Ben Walton)
Date: Thu, 07 May 2009 17:57:22 -0400

> 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.

> programs, etc., but I think it's significantly better than not doing any

Wouldn't it be nicer to handle this internally?

> 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>

---

From: [email-masked] (Ben Walton)
Date: Fri, 08 May 2009 22:10:55 -0400

> programs, etc., but I think it's significantly better than not doing any

...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.

> already getting too hairy.)

sup-sync-back could make use of this LockManager too.

Thoughts?

Thanks
-Ben

-------------- 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>

---

From: [email-masked] (William Morgan)
Date: Sat, 09 May 2009 06:01:04 -0700

> &block) methods that obtain required locks and yield to the caller to

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>