incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <esjew...@gmail.com>
Subject Re: Posting response messages from HTTP Post actions
Date Tue, 15 Dec 2009 13:44:50 GMT
I agree, I think we need something else. Based on the previous
discussion, I wouldn't want to see the patch I submitted in my
codebase.

Probably we need to at least send the response to the pool it came
from and have a flag that enables the response posting (it should not
be the default).

I did think about the idea of sending the responses to a specified
pool. I think this introduces a real danger of facilitating messages
escaping their pools (since most responses will include all or part of
the posted message).

Ethan

On Tue, Dec 15, 2009 at 7:04 AM, Anne Kathrine Petter√łe
<yojibee@gmail.com> wrote:
> I agree with you Vassil. We need to keep the default timeline as clean as possible and
let the users chose what they want to see.
> +1 to both of the points suggested.
>
> /Anne
>
> On 15. des. 2009, at 11.10, Richard Hirsch wrote:
>
>> I'd like to blog about 12sprints integration today if possible and
>> that means using Ethan's change as an interim solution.
>>
>>> * have a way to specify whether we post the response or not
>>> * post the response to a pool so we don't pollute the timeline of others
>>
>> I agree to both points. The ideal solution would be to have some flag
>> "pool=[poolname]" that is added to the action. If is present, the
>> response is returned. If not, then the response is ignored.
>>
>> What about sending the response to the pool in which the trigger
>> message was located?
>>
>>> create bots in the long term. And, who knows, someone might contribute
>>> XMPP integration, which would make interaction much easier ;-)
>>
>> This would of course be very cool.
>>
>> D.
>>
>> On Tue, Dec 15, 2009 at 10:59 AM, Vassil Dichev <vdichev@apache.org> wrote:
>>>> I wanted to integrate the open patches today and wanted to discuss
>>>> whether I should commit Ethan's change or not.
>>>>
>>>> Any reason why I shouldn't commit it. I think it is good interim
>>>> solution but not the final one.
>>>>
>>>> This could also help with our integration with akibot.
>>>
>>> Depends on how fast we need the integration scenarios working. I would
>>> prefer if we do either or both:
>>>
>>> * have a way to specify whether we post the response or not
>>> * post the response to a pool so we don't pollute the timeline of others
>>>
>>> The biggest problem here is not only that there's too much noise in
>>> your timeline, but that all of your followers would have to either put
>>> up with these responses or create a filtering action themselves. Long
>>> term we have to make the defaults as clean as possible.
>>>
>>> So, the question is: how fast do you want this repost feature?
>>>
>>> As an aside, specifically for the integration scenarios we could
>>> create bots in the long term. And, who knows, someone might contribute
>>> XMPP integration, which would make interaction much easier ;-)
>>>
>
>

Mime
View raw message