Mailing-List: contact esme-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: esme-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of hirsch.dick@gmail.com
 designates 209.85.218.210 as permitted sender)
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:content-transfer-encoding;
        b=RTcUzRdLUsl6nfGGnEddteaDyoxZUhoXd++cO4WAZlTMWLhgfB7H/7FKkijijTHDdQ
         INCOwmXIw3Ahnmzn7XZmAzy5O0H1yS0F6KHSvOPgqcgjP7Uq49k4rXWYhnpXFWOmtA3g
         JUVaFwiB4Tu15eXsACT25hguxuU5cu5+d/0nw=
MIME-Version: 1.0
In-Reply-To: <68f4a0e80912150544j348cb319yafa62694ad4c16ee@mail.gmail.com>
References: <fa2d9f450912150107q6fcbe5fan1358eaae163d7fb1@mail.gmail.com>
	 <c7fc82820912150159r49f0bf5eke413c9eabe58f9a9@mail.gmail.com>
	 <fa2d9f450912150210u15cc793aq83675f0e6be45f8b@mail.gmail.com>
	 <02375A0D-5782-41C0-8503-DC85629402C1@gmail.com>
	 <68f4a0e80912150544j348cb319yafa62694ad4c16ee@mail.gmail.com>
Date: Tue, 15 Dec 2009 15:10:07 +0100
Message-ID: <fa2d9f450912150610gaa57165sc243605e9109a152@mail.gmail.com>
Subject: Re: Posting response messages from HTTP Post actions
From: Richard Hirsch <hirsch.dick@gmail.com>
To: esme-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I agree that response messages should just be posted to the pool that
the original message came from.  I'm assuming that might not be too
difficult.

The more difficult question is how do you turn the response posting on
and off. Somehow the flag belongs in the action part of the action.
What format do we use - "responserepost=3Dtrue"?

On Tue, Dec 15, 2009 at 2:44 PM, Ethan Jewett <esjewett@gmail.com> wrote:
> 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=F8e
> <yojibee@gmail.com> wrote:
>> I agree with you Vassil. We need to keep the default timeline as clean a=
s 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 othe=
rs
>>>
>>> I agree to both points. The ideal solution would be to have some flag
>>> "pool=3D[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> wr=
ote:
>>>>> 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 othe=
rs
>>>>
>>>> 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 ;-)
>>>>
>>
>>
>