On Sun, Dec 13, 2009 at 2:25 PM, Vassil Dichev <[email protected]> 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? >
