incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vassil Dichev <vdic...@apache.org>
Subject Re: 12sprints integration works
Date Sun, 13 Dec 2009 13:25:15 GMT
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?

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.

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. I'm not sure
that complex workflows with several steps like this are suited for our
actions.


> 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