* [sup-talk] sent_source - singular or per-account?
@ 2009-07-01 9:48 Jim Cheetham
2009-07-01 19:39 ` Ben Walton
2010-01-08 23:06 ` Kevin Riggle
0 siblings, 2 replies; 19+ messages in thread
From: Jim Cheetham @ 2009-07-01 9:48 UTC (permalink / raw)
It looks like there is only one place that outbound mail can be stored
-- sent_source in config.yaml specifies it globally.
I'd like to be able to save outgoing email into the mailstore for the
matching account; can anyone suggest some way to do this? Hacking code
is an option, although I'd appreciate some pointers ...
^ permalink raw reply [flat|nested] 19+ messages in thread
* [sup-talk] sent_source - singular or per-account?
2009-07-01 9:48 [sup-talk] sent_source - singular or per-account? Jim Cheetham
@ 2009-07-01 19:39 ` Ben Walton
2009-07-02 2:30 ` Jim Cheetham
2010-01-04 20:50 ` Tero Tilus
2010-01-08 23:06 ` Kevin Riggle
1 sibling, 2 replies; 19+ messages in thread
From: Ben Walton @ 2009-07-01 19:39 UTC (permalink / raw)
Excerpts from Jim Cheetham's message of Wed Jul 01 05:48:30 -0400 2009:
> I'd like to be able to save outgoing email into the mailstore for the
> matching account; can anyone suggest some way to do this? Hacking code
> is an option, although I'd appreciate some pointers ...
This is an interesting idea. I think the best way to do it might be
to implement a sent_source hook that can override the global default.
It would be wise to either a) not use mbox or b) have dedicated mboxes
for this purpose...until I finally get around to finishing the lock
manager to make shared access safe.
The other gotcha with a hook to pick the source for message storage is
that not all sources are capable of storing mail presently (mbox,
maildir and imap are the only supported types, which admittedly should
cover most people).
I think this would be quite simple to add.
I've also toyed around with the idea of 'patterned' sources so that
you could specify a source as maildir:///u/bwalton/Maildir/inbox-%Y%m
and have new sources picked up automatically as they're created
(possibly by procmail doing autofiling, or something).
-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/20090701/64c4a100/attachment.bin>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [sup-talk] sent_source - singular or per-account?
2009-07-01 19:39 ` Ben Walton
@ 2009-07-02 2:30 ` Jim Cheetham
2009-07-02 3:17 ` Ben Walton
2010-01-04 20:50 ` Tero Tilus
1 sibling, 1 reply; 19+ messages in thread
From: Jim Cheetham @ 2009-07-02 2:30 UTC (permalink / raw)
On Thu, Jul 2, 2009 at 7:39 AM, Ben Walton<bwalton at artsci.utoronto.ca> wrote:
> Excerpts from Jim Cheetham's message of Wed Jul 01 05:48:30 -0400 2009:
>> I'd like to be able to save outgoing email into the mailstore for the
>> matching account; can anyone suggest some way to do this? Hacking code
>> is an option, although I'd appreciate some pointers ...
>
> This is an interesting idea. ?I think the best way to do it might be
> to implement a sent_source hook that can override the global default.
'best' or 'simplest'?
There already exists logic for determining which account a given
outgoing message belongs to, because that's how the :sendmail: target
is being used.
If you are arguing that having a different sent_source per (outgoing)
message is useful, then perhaps a hook makes sense; but the simpler
case probably doesn't need it.
> It would be wise to either a) not use mbox or b) have dedicated mboxes
> for this purpose...until I finally get around to finishing the lock
> manager to make shared access safe.
Certainly the sent_source mbox shouldn't be subject to something
inconvenient like delivery of new mail while we're updating it :-) but
I'm not sure that mbox people would be unhappy having sent mail in a
separate file ... ?
-jim
^ permalink raw reply [flat|nested] 19+ messages in thread
* [sup-talk] sent_source - singular or per-account?
2009-07-02 2:30 ` Jim Cheetham
@ 2009-07-02 3:17 ` Ben Walton
2009-07-02 10:14 ` Jim Cheetham
0 siblings, 1 reply; 19+ messages in thread
From: Ben Walton @ 2009-07-02 3:17 UTC (permalink / raw)
Excerpts from Jim Cheetham's message of Wed Jul 01 22:30:25 -0400 2009:
> On Thu, Jul 2, 2009 at 7:39 AM, Ben Walton<bwalton at artsci.utoronto.ca> wrote:
> > Excerpts from Jim Cheetham's message of Wed Jul 01 05:48:30 -0400 2009:
> >> I'd like to be able to save outgoing email into the mailstore for the
> >> matching account; can anyone suggest some way to do this? Hacking code
> >> is an option, although I'd appreciate some pointers ...
> >
> > This is an interesting idea. ?I think the best way to do it might be
> > to implement a sent_source hook that can override the global default.
>
> 'best' or 'simplest'?
Both?
> There already exists logic for determining which account a given
> outgoing message belongs to, because that's how the :sendmail:
> target is being used.
>
> If you are arguing that having a different sent_source per (outgoing)
> message is useful, then perhaps a hook makes sense; but the simpler
> case probably doesn't need it.
I'm not arguing anything, and perhaps using sent_source as the
(hypothetical) hook name was a bad choice...
If I'm understanding you correctly, you want to write to a different
source depending on which address is used in the From. 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.
In the 'simpler' case where the decision is made based on account
used, you've got a chunk of static code making the choice and
defaulting as it would now. The hook would simply take the place of
the static decision maker. The decision has to be made per message
regardless of how it's implemented, so doing it in a hook is a better
option, imo. The Hook route would be slightly slower, since there are
extra activation records on the stack for the function calls, but it
should be negligible.
The other advantage to a Hook is that the decision could be made based
on more than simply the From:. Maybe other users would prefer to
store mail based on who it was sent To...or a combo of From/To?
I'm interested in William's thoughts on this. It's not a feature I'd
use, but I do think it's a good feature to have.
I hope this explains my thinking more clearly.
-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/20090701/eb941c06/attachment.bin>
^ permalink raw reply [flat|nested] 19+ messages in thread
* [sup-talk] sent_source - singular or per-account?
2009-07-02 3:17 ` Ben Walton
@ 2009-07-02 10:14 ` Jim Cheetham
2009-07-02 14:02 ` Ben Walton
0 siblings, 1 reply; 19+ messages in thread
From: Jim Cheetham @ 2009-07-02 10:14 UTC (permalink / raw)
On Thu, Jul 2, 2009 at 3:17 PM, Ben Walton<bwalton at artsci.utoronto.ca> wrote:
> Excerpts from Jim Cheetham's message of Wed Jul 01 22:30:25 -0400 2009:
> If I'm understanding you correctly, you want to write to a different
> source depending on which address is used in the From.
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 :-)
> ?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.
> In the 'simpler' case where the decision is made based on account
> used, you've got a chunk of static code making the choice and
> defaulting as it would now. ?The hook would simply take the place of
> the static decision maker. ?The decision has to be made per message
> regardless of how it's implemented, so doing it in a hook is a better
> option, imo. ?The Hook route would be slightly slower, since there are
> extra activation records on the stack for the function calls, but it
> should be negligible.
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.
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'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,
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?
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.
Any comments or specific code pointers welcomed! I'd be happy to
attempt a patch for this, but I may need a little help ...
-jim
^ permalink raw reply [flat|nested] 19+ messages in thread
* [sup-talk] sent_source - singular or per-account?
2009-07-02 10:14 ` Jim Cheetham
@ 2009-07-02 14:02 ` Ben Walton
2010-01-04 18:55 ` Bryan Richardson
0 siblings, 1 reply; 19+ messages in thread
From: Ben Walton @ 2009-07-02 14:02 UTC (permalink / raw)
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>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sup-talk] sent_source - singular or per-account?
2009-07-02 14:02 ` Ben Walton
@ 2010-01-04 18:55 ` Bryan Richardson
2010-01-05 21:51 ` William Morgan
0 siblings, 1 reply; 19+ messages in thread
From: Bryan Richardson @ 2010-01-04 18:55 UTC (permalink / raw)
To: sup-talk
[-- 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
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sup-talk] sent_source - singular or per-account?
2009-07-01 19:39 ` Ben Walton
2009-07-02 2:30 ` Jim Cheetham
@ 2010-01-04 20:50 ` Tero Tilus
1 sibling, 0 replies; 19+ messages in thread
From: Tero Tilus @ 2010-01-04 20:50 UTC (permalink / raw)
To: Sup users
Digging up old stuff...
Excerpts from 's message of july 01 22:39:57 +0300 2009:
> I think the best way to do it might be to implement a sent_source
> hook that can override the global default.
If I didn't get it wrong nobody wanted that much of control. For the
presented usecases per account (and global default) sent source would
be enough.
I'd prolly use configurable sent source (filing sent to imap server
where I pull incoming from) if sup had one. Anybody else need this,
or per account sent config?
--
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sup-talk] sent_source - singular or per-account?
2010-01-04 18:55 ` Bryan Richardson
@ 2010-01-05 21:51 ` William Morgan
2010-01-06 19:18 ` Bryan Richardson
0 siblings, 1 reply; 19+ messages in thread
From: William Morgan @ 2010-01-05 21:51 UTC (permalink / raw)
To: sup-talk
Reformatted excerpts from Bryan Richardson's message of 2010-01-04:
> 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.
Not AFAIK.
--
William <wmorgan-sup@masanjin.net>
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sup-talk] sent_source - singular or per-account?
2010-01-05 21:51 ` William Morgan
@ 2010-01-06 19:18 ` Bryan Richardson
2010-01-06 19:29 ` William Morgan
0 siblings, 1 reply; 19+ messages in thread
From: Bryan Richardson @ 2010-01-06 19:18 UTC (permalink / raw)
To: William Morgan; +Cc: sup-talk
[-- Attachment #1.1: Type: text/plain, Size: 660 bytes --]
On Tue, Jan 5, 2010 at 2:51 PM, William Morgan <wmorgan-sup@masanjin.net>wrote:
> Reformatted excerpts from Bryan Richardson's message of 2010-01-04:
> > 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.
>
> Not AFAIK.
> --
> William <wmorgan-sup@masanjin.net>
> _______________________________________________
> sup-talk mailing list
> sup-talk@rubyforge.org
> http://rubyforge.org/mailman/listinfo/sup-talk
>
I'd take a stab at it if a Sup guru would give me a few pointers as to where
to start... :)
[-- Attachment #1.2: Type: text/html, Size: 1226 bytes --]
[-- Attachment #2: Type: text/plain, Size: 140 bytes --]
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sup-talk] sent_source - singular or per-account?
2010-01-06 19:18 ` Bryan Richardson
@ 2010-01-06 19:29 ` William Morgan
2010-01-06 21:04 ` Tero Tilus
0 siblings, 1 reply; 19+ messages in thread
From: William Morgan @ 2010-01-06 19:29 UTC (permalink / raw)
To: sup-talk
Reformatted excerpts from Bryan Richardson's message of 2010-01-06:
> I'd take a stab at it if a Sup guru would give me a few pointers as to
> where to start... :)
SentManager.write_sent_message is the method you want to play with. For
hook stuff, take a look at how any of the current hooks are defined and
called (git grep 'hook' or something). Ben Walton's posts on this
thread are also very useful.
The simplest approach might be to just have the hook return a source
that's used (if supplied) instead of the default source, and leave it up
to the hook writer to interact with SourceManager or whatever to acquire
the Source object they want.
--
William <wmorgan-sup@masanjin.net>
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sup-talk] sent_source - singular or per-account?
2010-01-06 19:29 ` William Morgan
@ 2010-01-06 21:04 ` Tero Tilus
2010-01-06 21:23 ` William Morgan
0 siblings, 1 reply; 19+ messages in thread
From: Tero Tilus @ 2010-01-06 21:04 UTC (permalink / raw)
To: sup-talk
William Morgan, 2010-01-06 21:29:
> The simplest approach might be to just have the hook return a source
Does it really need to be a hook? I haven't seen a single use case
justifying hook over simply having per-account sent_source in
config.yaml.
--
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sup-talk] sent_source - singular or per-account?
2010-01-06 21:04 ` Tero Tilus
@ 2010-01-06 21:23 ` William Morgan
2010-01-07 15:58 ` Tero Tilus
0 siblings, 1 reply; 19+ messages in thread
From: William Morgan @ 2010-01-06 21:23 UTC (permalink / raw)
To: sup-talk
Reformatted excerpts from Tero Tilus's message of 2010-01-06:
> Does it really need to be a hook? I haven't seen a single use case
> justifying hook over simply having per-account sent_source in
> config.yaml.
No, I don't care which it is. But you will be responsible for helping
the first person who wants to automatically choose their sent source
based on the body of the message. :)
--
William <wmorgan-sup@masanjin.net>
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sup-talk] sent_source - singular or per-account?
2010-01-06 21:23 ` William Morgan
@ 2010-01-07 15:58 ` Tero Tilus
2010-01-08 16:00 ` Bryan Richardson
0 siblings, 1 reply; 19+ messages in thread
From: Tero Tilus @ 2010-01-07 15:58 UTC (permalink / raw)
To: sup-talk
William Morgan, 2010-01-06 23:23:
> Reformatted excerpts from Tero Tilus's message of 2010-01-06:
> > Does it really need to be a hook? I haven't seen a single use case
>
> No, I don't care which it is. But you will be responsible for helping
> the first person who wants to automatically choose their sent source
> based on the body of the message. :)
So be it it, if you (in the other scenario) are willing to help those
who simply want per-account sent_source and are afraid of Ruby. :)
--
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sup-talk] sent_source - singular or per-account?
2010-01-07 15:58 ` Tero Tilus
@ 2010-01-08 16:00 ` Bryan Richardson
2010-01-09 22:47 ` Tero Tilus
0 siblings, 1 reply; 19+ messages in thread
From: Bryan Richardson @ 2010-01-08 16:00 UTC (permalink / raw)
To: sup-talk
So... I take it I would still look at SentManager.write_sent_message
for this? Are all the configuration options from config.yaml gobbled
up into an object somewhere when Sup is started?
I guess the first question I should really ask is if Tero is going to
take a stab at this or if I should... :)
On Thu, Jan 7, 2010 at 8:58 AM, Tero Tilus <tero@tilus.net> wrote:
> William Morgan, 2010-01-06 23:23:
>> Reformatted excerpts from Tero Tilus's message of 2010-01-06:
>> > Does it really need to be a hook? I haven't seen a single use case
>>
>> No, I don't care which it is. But you will be responsible for helping
>> the first person who wants to automatically choose their sent source
>> based on the body of the message. :)
>
> So be it it, if you (in the other scenario) are willing to help those
> who simply want per-account sent_source and are afraid of Ruby. :)
>
> --
> Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
> _______________________________________________
> sup-talk mailing list
> sup-talk@rubyforge.org
> http://rubyforge.org/mailman/listinfo/sup-talk
>
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sup-talk] sent_source - singular or per-account?
2009-07-01 9:48 [sup-talk] sent_source - singular or per-account? Jim Cheetham
2009-07-01 19:39 ` Ben Walton
@ 2010-01-08 23:06 ` Kevin Riggle
1 sibling, 0 replies; 19+ messages in thread
From: Kevin Riggle @ 2010-01-08 23:06 UTC (permalink / raw)
To: sup-talk
Excerpts from Jim Cheetham's message of Wed Jul 01 05:48:30 -0400 2009:
> It looks like there is only one place that outbound mail can be stored
> -- sent_source in config.yaml specifies it globally.
>
> I'd like to be able to save outgoing email into the mailstore for the
> matching account; can anyone suggest some way to do this? Hacking code
> is an option, although I'd appreciate some pointers ...
Coming wicked late to the party, and it's a bit of a kludge, but -- I solve
this problem with a before-edit hook which BCCs my account, and all the
information necessary to choose the appropriate account in a multi-account
setup should be present in that hook. Sup's automatic duplicate suppression
means they never actually show up in my inbox view, but they are nevertheless
silently and appropriately added to my remote mailstore.
- Kevin
--
Kevin Riggle (kevinr@free-dissociation.com)
MIT Class of 2010, Course VI-3 (Computer Science)
http://free-dissociation.com
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sup-talk] sent_source - singular or per-account?
2010-01-08 16:00 ` Bryan Richardson
@ 2010-01-09 22:47 ` Tero Tilus
2010-01-12 21:38 ` Bryan Richardson
0 siblings, 1 reply; 19+ messages in thread
From: Tero Tilus @ 2010-01-09 22:47 UTC (permalink / raw)
To: sup-talk
Bryan Richardson, 2010-01-08 18:00:
> I guess the first question I should really ask is if Tero is going
> to take a stab at this or if I should... :)
Make your choise and take your stab. I'll be a happy user of
sent_source selection, be it hook or conf based.
I've already got a long enough backlog of features I want to hack
with.
--
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sup-talk] sent_source - singular or per-account?
2010-01-09 22:47 ` Tero Tilus
@ 2010-01-12 21:38 ` Bryan Richardson
2010-01-12 23:10 ` Tero Tilus
0 siblings, 1 reply; 19+ messages in thread
From: Bryan Richardson @ 2010-01-12 21:38 UTC (permalink / raw)
To: sup-talk
On Sat, Jan 9, 2010 at 3:47 PM, Tero Tilus <tero@tilus.net> wrote:
> Bryan Richardson, 2010-01-08 18:00:
>> I guess the first question I should really ask is if Tero is going
>> to take a stab at this or if I should... :)
>
> Make your choise and take your stab. I'll be a happy user of
> sent_source selection, be it hook or conf based.
Would someone be nice enough to tell me when/where the source gets set
in SentManager? I've grepped the heck out of the code and can't find
it anywhere. Also, where's the code that checks the front of the
sent_source uri for 'maildir' in order to know to create a new Maildir
source object?
>
> I've already got a long enough backlog of features I want to hack
> with.
>
> --
> Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
> _______________________________________________
> sup-talk mailing list
> sup-talk@rubyforge.org
> http://rubyforge.org/mailman/listinfo/sup-talk
>
--
Thanks!
Bryan
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [sup-talk] sent_source - singular or per-account?
2010-01-12 21:38 ` Bryan Richardson
@ 2010-01-12 23:10 ` Tero Tilus
0 siblings, 0 replies; 19+ messages in thread
From: Tero Tilus @ 2010-01-12 23:10 UTC (permalink / raw)
To: sup-talk
Bryan Richardson, 2010-01-12 23:38:
> Would someone be nice enough to tell me when/where the source gets
> set in SentManager?
Look at bin/sup lines 157-161.
> Also, where's the code that checks the front of the sent_source uri
> for 'maildir' in order to know to create a new Maildir source
> object?
That would be only in bin/sup-add.
If you look inside sources.yaml, you see that source classes are
stored there (together with instance attributes) and thats how
SourceManager#load_sources (actually YAML::load_file inside it) knows
what source classes to instantiate.
--
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2010-01-12 23:10 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-07-01 9:48 [sup-talk] sent_source - singular or per-account? 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
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox