On Thu, Jul 2, 2009 at 7:02 AM, Ben Walton <[email protected]>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 > [email protected] > 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
_______________________________________________ sup-talk mailing list [email protected] http://rubyforge.org/mailman/listinfo/sup-talk
