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 esjewett@gmail.com designates
 209.85.216.179 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=R763dP2zigYaKCoTgTtJR0wiJMn9aemEWTOemj+iPFXMExS8FZEde1cJO1V3IjYexd
         zVXwkDFifQNCSb8I8RpXPb8alJeAt7y96qMZ1vc7+aMz9Kjyh5Z/Hwtn4k4vJWZIICZC
         W8ZpL6tjtUUam/f82Ja7ES62G3m3ZlhB7M5Do=
MIME-Version: 1.0
In-Reply-To: <fa2d9f450912131007g7140e9daue5f3efff840e0b5e@mail.gmail.com>
References: <fa2d9f450912010308m48f51cf2s83ffb875cc4ecd82@mail.gmail.com>
	 <68f4a0e80912121129w1042f115i507726a8e004f7a2@mail.gmail.com>
	 <fa2d9f450912121133k77da7218o486173694bf78e3d@mail.gmail.com>
	 <c7fc82820912130300v7a6b780dk7851dbcc46b19d25@mail.gmail.com>
	 <c7fc82820912130324r780364f7kd8e98e272b078d9c@mail.gmail.com>
	 <fa2d9f450912130421i70962f6ajb63bda6d5a2a1e52@mail.gmail.com>
	 <c7fc82820912130525h6f6505c4qad63b55122b970bc@mail.gmail.com>
	 <fa2d9f450912130550p3b774c8o1007b24b95d419d4@mail.gmail.com>
	 <68f4a0e80912130909n231e47f2v220979dcb971f5d1@mail.gmail.com>
	 <fa2d9f450912131007g7140e9daue5f3efff840e0b5e@mail.gmail.com>
Date: Sun, 13 Dec 2009 14:07:04 -0600
Message-ID: <68f4a0e80912131207x7ae73424h2289aede80b63251@mail.gmail.com>
Subject: Re: 12sprints integration works
From: Ethan Jewett <esjewett@gmail.com>
To: esme-dev@incubator.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

True, this is more bot-like than action-like. I'd still like a regular
expression action :-)

The test would be a regular expression, against which the message
would be evaluated. The matches of the regular expression could be
provided as replacements in the action section (%r1, %r2, etc.).

And I'll also add that I agree with Vassil that feeds or incoming-HTTP
requests are the right way for ESME to get a response out of a system.
The POST action is probably better left as "fire and forget".
Unfortunately, 12sprints provides precious little out-bound
interoperability beyond email, which is something they are saying they
will address, but it's a pretty big issue for integration scenarios
like this one.

Ethan

On Sun, Dec 13, 2009 at 12:07 PM, Richard Hirsch <hirsch.dick@gmail.com> wr=
ote:
> Good points. We also have to remember that the user of an action isn't
> a developer but a normal user who wants to quickly add simple logic to
> his message processing.
>
> Maybe we should have some rule concerning the return value of the HTTP
> post action - if you need to access the response then an action is
> probably the wrong choice for an integration. =A0A bot is more likely
> the optimal integration method.
>
> How does that sound?
>
>>Another option would be to provide a regular expression matcher for actio=
ns,
>
> What would this look like? =A0Maybe it is a feature for a later release.
>
> D.
>
> On Sun, Dec 13, 2009 at 6:09 PM, Ethan Jewett <esjewett@gmail.com> wrote:
>> I've thought about this a bit now and I'm also not comfortable with
>> the idea of an sending post responses as messages in the way that
>> Richard and I have implemented it (which I think should be taken as a
>> prototype).
>>
>> I see a few major issues:
>>
>> 1. It is really really easy to create infinite loops
>> 2. Most people won't want posted messages showing up in their timeline
>> 3. We can't really do much subsequent processing on messages when they
>> come back. (Limitation of actions, currently)
>> 4. It's tough to set up the action properly so that it works at all.
>> (It took me about 45 minutes, not including putting in Dick's code to
>> expand %t in the URL.)
>>
>> Just to be completely clear, the use case is something like this:
>>
>> 1. Some message shows up that we have decided means that an activity
>> needs to be created in 12sprints (or a Tweet, or whatever)
>> 2. Activity is created successfully
>> 3. Message shows up saying "Activity 23ikcjas successfully created in
>> 12sprints! Use tag #12sprints:23ikcjas to send messages to this
>> activity."
>>
>> Then a couple of things can happen:
>>
>> 1. Users can see this message and create messages in ESME that are
>> posted to the 12sprints activity (if they have created the proper
>> action, or someone else has created said action - maybe a utility
>> user)
>> 2. A technical system that is integrated with ESME can see the message
>> (a BPM system, possibly?) and configure itself so that updates to the
>> BPM activity (that initially triggered the ESME message that was
>> turned into a 12sprints activity) will have the tag
>> #12sprints:23ikcjas
>>
>> I'm convinced that this is a very powerful use case, but I'm also
>> convinced that the way we have things set up now won't work for this
>> use case. It's just too complicated. To meet the use-case, we probably
>> need
>>
>> 1. A way to specify that a post action will return a message based on
>> the response (and possibly the format of the message) - this will
>> address issue 2 and partially issue 1
>> 2. A way to catch these responses in a fine-grained way and do
>> something about them. I'm talking about something more fine-grained
>> then simple tag matching. I think there are a couple of options here:
>> Match multiple tags and then provide a replacement syntax for these
>> tags in the same order they are matched. (e.g. Match "#12sprints &
>> #askjfew", and put %t1 and %t2 into my post request, which are
>> "#12sprints" and "#askjfew" respectively.) Another option would be to
>> provide a regular expression matcher for actions, which would actually
>> be quite awesome, come to think of it. This will address issue 3.
>> 3. (later) A wizard for creating actions, especially complex actions
>> like HTTP POST and RSS/ATOM actions. This will address issue 4.
>>
>> With regards to issue 1, I don't see a clear way out of the maze.
>> Perhaps an action could attach the action-id to the "via/from"
>> metadata of the message, then not act on messages that it created.
>> This solves the 1-level-of-indirection part of the problem, which is
>> probably 99% of it.
>>
>> Ethan
>>
>> On Sun, Dec 13, 2009 at 7:50 AM, Richard Hirsch <hirsch.dick@gmail.com> =
wrote:
>>> On Sun, Dec 13, 2009 at 2:25 PM, Vassil Dichev <vdichev@apache.org> wro=
te:
>>>> The HTTP POST action already has a somewhat complicated syntax, so
>>>> introducing more special cases are going to make both parsing and
>>>> understanding more difficult.
>>>>
>>>> Regarding duplicated messages, there is already a mechanism for
>>>> avoiding infinite messages when fetching feeds- the Atom feed, for
>>>> instance, already has unique ids, so only messages with unique new ids
>>>> are sent to the timeline. Does 12sprints offer RSS/Atom feeds of
>>>> activities?
>>>
>>> Don't know if it uses RSS feeds for activities - good idea though .
>>> (although there is a REST API call that monitors activity events:,
>>> https://beta.12sprints.com/api/Get_all_events_for_a_specific_activity.h=
tml).
>>> =A0Right now we are looking at primarily the creation-related REST API
>>> calls.
>>>
>>>>
>>>> The best chance of eliminating duplicate messages and loops is to have
>>>> some unique metadata, which differentiates messages. If any such
>>>> metadata is lost, the best chance we got is matching the text strings,
>>>> and this has too many disadvantages to use as a general solution.
>>>
>>> But this doesn't solve the problem that is also present with non
>>> ATOM-RSS feeds. You can create an action that resends a message to
>>> ESME under a different user id. The action test is messages that
>>> contain the string "20". If you follow the second user, then you will
>>> create an infinite loop.
>>>>
>>>> Anyway, if I understand correctly, if the user needs to create an ESME
>>>> action for each new unique 12sprints activity manually, that's
>>>> probably more overhead than going to the 12sprints UI.
>>>
>>> No - the idea is that after the first activity is created, you take
>>> the activity id that was returned in the response and use it as a tag
>>> for messages related to that activity. Then you use the %t to create
>>> the REST API call that is activity-specific.
>>>
>>>>
>>>>> The integration is between ESME and 12sprints which is tool that
>>>>> assists in making decisions. The idea is the user creates an activity
>>>>> in 12sprints based on a message in ESME. This message should be sent
>>>>> to 12sprints via a HTTP Post action. =A0This works with the current H=
TTP
>>>>> Post action. The problem is that the response from the 12sprints REST
>>>>> call includes the activity id. This activity ID is necessary for all
>>>>> other activity-related REST API calls. Of course, the user could open
>>>>> up the 12sprints UI find out the ID of the activity and return to ESM=
E
>>>>> but we were trying to avoid this overhead. That is the idea behind
>>>>> sending the HTTP Post action response as a message.
>>>>>
>>>>> Of course, it would ideal to add further logic to processing this HTT=
P
>>>>> Post response but I think this would make things too complicated for
>>>>> the normal user.
>>>>>
>>>>> The ideal use case would be where the user could decide whether the
>>>>> HTTP Post response is resent and into which pool.
>>>>>
>>>>> Of course, this would either mean that the UI would have to be
>>>>> enhanced or that new tags could be added to the action. For example,
>>>>> "responseTarget=3D[poolname]". This flag wouldn't be sent to the HTTP
>>>>> Post. If the flag is absent, then the response is not resent. If the
>>>>> pool is empty or the user is not part of that pool, then the message
>>>>> is sent to the public pool.
>>>>>
>>>>> Regarding the infinite loop, this can happen with the current
>>>>> implementation as well. The question is how to avoid it?
>>>>
>>>
>>
>