Good points. We also have to remember that the user of an action isn't a developer but a normal user who wants to quickly add simple logic to his message processing.
Maybe we should have some rule concerning the return value of the HTTP post action - if you need to access the response then an action is probably the wrong choice for an integration. A bot is more likely the optimal integration method. How does that sound? >Another option would be to provide a regular expression matcher for actions, What would this look like? Maybe it is a feature for a later release. D. On Sun, Dec 13, 2009 at 6:09 PM, Ethan Jewett <[email protected]> wrote: > 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? >>> >> >
