Re: [sup-talk] multiple accounts

From: d.t.k <d.t.k@gmx.de>
To: Patrick Totzke <patricktotzke@googlemail.com>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] multiple accounts
Date: Wed, 11 May 2011 12:41:14 +0200	[thread overview]
Message-ID: <1305109172-sup-2288@minibox> (raw)
In-Reply-To: <1305105912-sup-2960@brick>

Hi,

Excerpts from Patrick Totzke's message of Mi Mai 11 11:41:44 +0200 2011:
> I agree: a single send-sink seems totally unnatural.
> In fact, we have the same problem with drafts.
yeah, actually I can think of some more situations in which I would wish for
account specific sources: I'd love to add a :spam_source (e.g. 'Junk') and a :ham_source (e.g. INBOX) where mails
are moved when the 'spam' label is set/removed, so that operation is mapped onto
folders (I use a server side spamassassin to automagically learn from specified
folders)

> I recently mentioned both shortcomings on sup-devel
> (http://rubyforge.org/pipermail/sup-devel/2011-May/001095.html).
> As you say: a quick glance at the code confirms that one can only
> specify one send-sink, as well as draft-sink.
> However, there is some sort of "DraftManager" object. I guess one can
> play with that..
actually, as a dirty hack it shouldn't be too hard to do: message objects know
about their sources. Now we could reference the account a source belongs to in
every source in addition to fields like labels, usual, archived, etc. Et voila.
From the related account we could then get any required sink: draft, sent, spam,
ham, ...

I don't think it's too beautiful if sources know what account they belong to. I
feel like it should rather be the other way around (an acct knows its srcs).
Specifying the sources of an account in the config.yaml might seriously clutter
that file up, though, especially for users with many imap folder. So we could
either reference a file containing the sources for an account in config.yaml
(per account) or name the file by some convention (sources_<account-name>.yaml)
and have it parsed automagically (convention over configuration?).

Thinking about it, if we could correlate mails and accounts (via the source) we
might just store the belonging account in a message field.

> Anyhow, my current solution is to use a local mbox as send-sink
> and use a bcc to myself. Then I use server-side filters to
> mark incoming mails from myself as read and move it to sent.
> offlineimap then syncs the sent folder, which is then included in
> sources.yaml with archived:true and autoadd label:sent.
>
> The problem with this is, that despite different sup's on different
> hosts both can read the send mails wich are stored on the correct
> servers, the sup-instance that was used to compose the mail actually
> displays its local version and somehow skips the one from the server.
> BUT: I cannot prevent my mailhost from adding another signature to the
> mail and therefore, the mail sup stores is different from the one I
> sent! To conclude: different send-sinks for different accounts are
> the sensible solution in my view.
I agree. Your solution may provide a work around for now, but it feels rather
hacky. I'd prefer having account specific sources handled properly (as I have
other applications in mind, see above) as much as I imagine you would.

dtk
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk