Re: [sup-talk] sent_source - singular or per-account?

From: Bryan Richardson <btricha@gmail.com>
To: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] sent_source - singular or per-account?
Date: Mon, 4 Jan 2010 11:55:44 -0700	[thread overview]
Message-ID: <3f81a4241001041055t443931c6vbbe1e7a44599d4f1@mail.gmail.com> (raw)
In-Reply-To: <1246542975-sup-7239@ntdws12.chass.utoronto.ca>

[-- Attachment #1.1: Type: text/plain, Size: 5212 bytes --]

On Thu, Jul 2, 2009 at 7:02 AM, Ben Walton <bwalton@artsci.utoronto.ca>wrote:

> 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.
>
> _______________________________________________
> sup-talk mailing list
> sup-talk@rubyforge.org
> http://rubyforge.org/mailman/listinfo/sup-talk
>
>
Hello,

Just curious if this ever got implemented... I use Sup at work to check both
work and personal email, and when responding to personal email I'd like the
response to be saved in a different source.

--
Thanks!
Bryan

[-- Attachment #1.2: Type: text/html, Size: 6434 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

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