From: bwalton@artsci.utoronto.ca (Ben Walton)
Subject: [sup-talk] sent_source - singular or per-account?
Date: Thu, 02 Jul 2009 10:02:56 -0400 [thread overview]
Message-ID: <1246542975-sup-7239@ntdws12.chass.utoronto.ca> (raw)
In-Reply-To: <f4cc59760907020314o60100e01r1a1f8af4d354030a@mail.gmail.com>
Excerpts from Jim Cheetham's message of Thu Jul 02 06:14:23 -0400 2009:
> Almost; what I (could have) said was that I wanted to write to a
> different source depending on which account is in use for the
> current message; I wasn't fixating on the From address itself,
> although with a better understanding of the code you might declare
> that they are effectively the same anyway :-)
Ok. I _think_ that difference would come out in the wash, unless I'm
overlooking a subtlety. Thanks for clarifying your needs/wants
though.
> > ?You'd either need to make a separate config entry in each account
> > that gets setup (similar to the sendmail that you note) or provide
> > the ability for the user to select the sent box in some other way.
>
> Yes; and in either case I think we can't just override the current
> global sent_source, because this is being used to read messages from,
> in order to include them in the threads.
As long as sup is configured with all sources that might be returned
from the hook, including the default source, it should be ok. It'll
still poll all sources and thread messages appropriately.
> Mmm, I think the hook route would expose you to a lot of change,
> because whenever a 'new' source (i.e. one not known about as load
> time) is declared in the hook, you'll have to remember it so it can be
> included in the index, and be available next time sup starts too.
My take on this is that the hook would be constrained to return only
existing sources. On the other hand, aside from an initial import of
any existing mail in a new folder, I'm not sure that adding new
sources on the fly would be that bad.
> Whereas requiring sent_sources to be declared at load time only means
> they can be added as sources just like the current singular one is.
I was picturing the hook return value to be a uri suitable for passing
to Index.source_for. If that method call failed, the default would be
used. There are of course other (maybe better) ways to do this, but
that's what I was thinking last night. Using this technique, you're
limited to existing sources and you also have an easy way to back out
of a 'hook gone wild.'
> I've been browsing the source this evening, I don't have a very good
> grasp of Ruby idiom but I do find it to be very readable in general
> :-) However, I've come to a halt in SentManager.write_sent_message,
It is a beautiful, expressive language! :)
> because I haven't figured out how @source.store_message relates to my
> store URI, and therefore the relevant store_message function. I mean,
> if :sent_store: is configured, how does @source get created from
> @source_uri?
At startup, SentManager is initialized with a URI. This is either the
value of :sent_source: from config.yaml or the default (special) value
sup://sent. A little later on, after the Index has been initialized,
it is asked for the source that corresponds to the URI value passed to
SentManager. If this source is found in the Index, it is assigned to
the @source value. Otherwise, the SentManager.default_source method
is triggered.
So, when one of the message modes calls write_sent_message, it has
either a specific source or the default ready to go. Sources usable
by SentManager are constrained such that they must respond to
store_message. This excludes ssh+mbox URI's from being a valid sent
mail source.
> If we have multiple sent_sources, that contradicts the singleton
> SentManager, unless @source becomes a hash keyed off from_email ... at
> which point I'm pushing my Ruby skills too far for the evening.
I don't think it precludes it from being a singleton, but it would
require some heavy reworking of the initialization logic for it.
I just popped into sent.rb and was all set to knock out a patch to add
the hook and I discovered that my memory of this wasn't what I
thought. SentManager doesn't ever _see_ the message. It simply
facilitates calling the store_message method of whatever source is
configured and that source object in turn provides an object that acts
like an IO object to the edit-message-mode call site. This
complicates either approach discussed here since the determination of
which source to use can't be constrained to SentManager...presently,
it would end up in edit-message-mode, which wouldn't be the right spot
for the logic, I don't think.
More thinking required, I believe.
-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/20090702/9f959f68/attachment.bin>
next prev parent reply other threads:[~2009-07-02 14:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-01 9:48 Jim Cheetham
2009-07-01 19:39 ` Ben Walton
2009-07-02 2:30 ` Jim Cheetham
2009-07-02 3:17 ` Ben Walton
2009-07-02 10:14 ` Jim Cheetham
2009-07-02 14:02 ` Ben Walton [this message]
2010-01-04 18:55 ` Bryan Richardson
2010-01-05 21:51 ` William Morgan
2010-01-06 19:18 ` Bryan Richardson
2010-01-06 19:29 ` William Morgan
2010-01-06 21:04 ` Tero Tilus
2010-01-06 21:23 ` William Morgan
2010-01-07 15:58 ` Tero Tilus
2010-01-08 16:00 ` Bryan Richardson
2010-01-09 22:47 ` Tero Tilus
2010-01-12 21:38 ` Bryan Richardson
2010-01-12 23:10 ` Tero Tilus
2010-01-04 20:50 ` Tero Tilus
2010-01-08 23:06 ` Kevin Riggle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1246542975-sup-7239@ntdws12.chass.utoronto.ca \
--to=bwalton@artsci.utoronto.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox