From mboxrd@z Thu Jan 1 00:00:00 1970 Received: by 10.213.13.12 with SMTP id z12cs1221728ebz; Mon, 4 Jan 2010 11:14:42 -0800 (PST) Received: by 10.224.52.83 with SMTP id h19mr11423744qag.221.1262632481275; Mon, 04 Jan 2010 11:14:41 -0800 (PST) Return-Path: Received: from rubyforge.org (rubyforge.org [205.234.109.19]) by mx.google.com with ESMTP id 9si20582741qyk.95.2010.01.04.11.14.40; Mon, 04 Jan 2010 11:14:41 -0800 (PST) Received-SPF: pass (google.com: domain of sup-talk-bounces@rubyforge.org designates 205.234.109.19 as permitted sender) client-ip=205.234.109.19; Authentication-Results: mx.google.com; spf=pass (google.com: domain of sup-talk-bounces@rubyforge.org designates 205.234.109.19 as permitted sender) smtp.mail=sup-talk-bounces@rubyforge.org; dkim=neutral (body hash did not verify) header.i=@gmail.com Received: from rubyforge.org (rubyforge.org [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 974681779943; Mon, 4 Jan 2010 14:14:40 -0500 (EST) Received: from mail-yw0-f183.google.com (mail-yw0-f183.google.com [209.85.211.183]) by rubyforge.org (Postfix) with ESMTP id F38CA185828E for ; Mon, 4 Jan 2010 13:55:45 -0500 (EST) Received: by ywh13 with SMTP id 13so34893813ywh.29 for ; Mon, 04 Jan 2010 10:55:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type; bh=kKuhlSTaBhvQ4AKkZ3y2r+XiPB5JjYi3PyS/YeHTqHA=; b=uCEe17nupysbT/VDS2WBgHblo6XKuXGfMdVKlnLMQdOhUnhnGoMbsbUtTUTpEDWja3 EyydrGFcPgxPa1jRPAwiP9sVYb9cVAVpqoMnEhyiHN9tsq3NEm3RFeU1/Qi3MAXPeXC2 5PzOArfnMJFLXtTz7gZ3txvPC8ebatTEx/Qls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=nzNv3Zg5xqYYOgBJOPYdQJh0A5Zic0fwgPpKnzwkr64gY8so/8RebY6UxKG5I+Y8jn 7eP9Zed5it+IhzA366VutPBSm4GzXCD2vd0MMwTeYWrYgwgv96Lv+GjX8oWw/ntH+z+X 0KEg16H70WJtZ8A51dHJ8b+6WwGanqjzuKsRQ= MIME-Version: 1.0 Received: by 10.91.18.5 with SMTP id v5mr3084973agi.62.1262631344909; Mon, 04 Jan 2010 10:55:44 -0800 (PST) In-Reply-To: <1246542975-sup-7239@ntdws12.chass.utoronto.ca> References: <1246476925-sup-5046@ntdws12.chass.utoronto.ca> <1246502666-sup-1295@ntdws12.chass.utoronto.ca> <1246542975-sup-7239@ntdws12.chass.utoronto.ca> Date: Mon, 4 Jan 2010 11:55:44 -0700 Message-ID: <3f81a4241001041055t443931c6vbbe1e7a44599d4f1@mail.gmail.com> From: Bryan Richardson To: sup-talk Subject: Re: [sup-talk] sent_source - singular or per-account? X-BeenThere: sup-talk@rubyforge.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: User & developer discussion of Sup List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0227740528==" Sender: sup-talk-bounces@rubyforge.org Errors-To: sup-talk-bounces@rubyforge.org --===============0227740528== Content-Type: multipart/alternative; boundary=001485f89b28cbb191047c5b4456 --001485f89b28cbb191047c5b4456 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Jul 2, 2009 at 7:02 AM, Ben Walton 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 --001485f89b28cbb191047c5b4456 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thu, Jul 2, 2009 at 7:02 AM, Ben Walton = <bwalton= @artsci.utoronto.ca> wrote:

> 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. =A0I _think_ that difference would come out in the wash, unless I= 'm
overlooking a subtlety. =A0Thanks for clarifying your needs/wants
though.

> > =A0You'd either need to make a separate config entry in each = account
> > that gets setup (similar to the sendmail that you note) or provid= e
> > 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,<= br> > in order to include them in the threads.

As long as sup is configured with all sources that might be returned<= br> from the hook, including the default source, it should be ok. =A0It'll<= br> 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 l= oad
> time) is declared in the hook, you'll have to remember it so it ca= n 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<= br> existing sources. =A0On 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<= br> > 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 passin= g
to Index.source_for. =A0If that method call failed, the default would be used. =A0There are of course other (maybe better) ways to do this, but
that's what I was thinking last night. =A0Using 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 ver= y 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,<= br> > if :sent_store: is configured, how does @source get created from
> @source_uri?

At startup, SentManager is initialized with a URI. =A0This is either = the
value of :sent_source: from config.yaml or the default (special) value
sup://sent. =A0A little later on, after the Index has been initialized,
it is asked for the source that corresponds to the URI value passed to
SentManager. =A0If this source is found in the Index, it is assigned to
the @source value. =A0Otherwise, 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. =A0Sources usable
by SentManager are constrained such that they must respond to
store_message. =A0This excludes ssh+mbox URI's from being a valid sent<= br> 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 woul= d
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. =A0SentManager doesn't ever _see_ the message. =A0It 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. =A0This
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<= br> 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 wor= k and personal email, and when responding to personal email I'd like th= e response to be saved in a different source.

--
Thanks!
Bryan
--001485f89b28cbb191047c5b4456-- --===============0227740528== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ sup-talk mailing list sup-talk@rubyforge.org http://rubyforge.org/mailman/listinfo/sup-talk --===============0227740528==--