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 <[email protected]> wrote: > 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? >> >
