esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <>
Subject Re: 12sprints integration works
Date Sun, 13 Dec 2009 13:50:54 GMT
On Sun, Dec 13, 2009 at 2:25 PM, Vassil Dichev <> 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:,
 Right now we are looking at primarily the creation-related REST API

> 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?

View raw message