esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Jewett <esjew...@gmail.com>
Subject Re: 12sprints integration works
Date Sun, 13 Dec 2009 17:09:18 GMT
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> wrote:
>> 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.html).
>  Right 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.  This works with the current HTTP
>>> 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 ESME
>>> 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 HTTP
>>> 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=[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?
>>
>

Mime
View raw message