I was going to bring up a similar discussion so I will just comment inline. On Feb 11, 2013, at 9:12 AM, Summers Pittman <supittma(a)redhat.com&gt; wrote: > We have three JIRA's[1] to add a cancel method to Pipe. > > In Android (and presumably iOS and to a lesser extent JS) Pipes are shared among multiple threads and each request exists in its own scope. (IE multiple threads can have multiple requests running at one time). > > When a "cancel" is called, which request is cancelled? This is the exact issue I was going to bring up. Since JS uses promises, the straight forward way to cancel the request is to call the abort() method already available in the jqXHR returned by a call to read(), save(), remove(). That said, I would really rather not add a method to JS for this since it would be nothing more than an extra layer around that abort method, and also not something that would be available on the pipe itself but the object returned by a call to one of its methods. Another issue is that it would need to be clearly documented that calling cancel() (or abort() or what ever) has no effect on the server so if you do a save() or remove() and then call cancel(), that action will still take place on the the server. > I've attempted to address this (and some larger issues) here: https://github.com/aerogear/aerogear.org/blob/pipe_spec/docs/specs/aeroge... > > > Summers > > 1: (898,901,895) > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

On Mon, Feb 11, 2013 at 4:12 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: > We have three JIRA's[1] to add a cancel method to Pipe. > > In Android (and presumably iOS and to a lesser extent JS) Pipes are shared > among multiple threads and each request exists in its own scope. (IE > multiple threads can have multiple requests running at one time). > > When a "cancel" is called, which request is cancelled? When calling cancel on a pipe, I'd assume that all enqueued/running requests, for that particular pipe, are canceled.

-Matthias > I've attempted to address this (and some larger issues) here: > https://github.com/aerogear/aerogear.org/blob/pipe_spec/docs/specs/aeroge... > > > Summers > > 1: (898,901,895) > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev

On 02/14/2013 02:31 AM, Matthias Wessendorf wrote: > On Mon, Feb 11, 2013 at 4:12 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >> We have three JIRA's[1] to add a cancel method to Pipe. >> >> In Android (and presumably iOS and to a lesser extent JS) Pipes are shared >> among multiple threads and each request exists in its own scope. (IE >> multiple threads can have multiple requests running at one time). >> >> When a "cancel" is called, which request is cancelled? > When calling cancel on a pipe, I'd assume that all enqueued/running > requests, for that particular pipe, are canceled. -.15 I don't like it but 99% of the time there will only be one call in the Pipe.

What happens on the callbacks? I would assume either onError would be called with an appropriate object/message(+1)

or we add an onCancel method(-1). Summers > > -Matthias > > >> I've attempted to address this (and some larger issues) here: >> https://github.com/aerogear/aerogear.org/blob/pipe_spec/docs/specs/aeroge... >> >> >> Summers >> >> 1: (898,901,895) >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Hi, following up to Matthias email, in the underlying AFNetworking library default behaviour when calling cancel is to traverse all running operations, cancelling each one of them. Further, default behaviour is not too call the "failure" callbacks ( the reasons why is described here[1]). It can be adjusted though by doing an override, as described (without modifying AFNetworking library).

If we agree on this, that is calling the failure callbacks in case of "cancel", I can go ahead and implement this.

My only worries is that the "usual" failure callbacks, display some kind of an alert informing the user, and I am not sure if popping up multiple alerts (for simultaneous requests) is a good thing..

Another suggestion is to allow the user to register on the Pipe Config a cancel callback(optional) that will be called only once (when issue "cancel" on the pipe). This will: a) Will let the user decide how to handle cancel. Either dispatch an alert on the main UI queue, or do some other work, or if not configured, silently ignore. b) No checks on the failure callbacks to see if the failed was called by a cancel or by an error c) Enforces the statement that "cancel", cancels all the pending requests on the Pipe and a single callback is called when performing it.

What do you think? Thanks, Christos [1] https://github.com/AFNetworking/AFNetworking/issues/479 On Feb 15, 2013, at 10:14 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > On Thu, Feb 14, 2013 at 6:08 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >> On 02/14/2013 02:31 AM, Matthias Wessendorf wrote: >>> On Mon, Feb 11, 2013 at 4:12 PM, Summers Pittman <supittma(a)redhat.com&gt; wrote: >>>> We have three JIRA's[1] to add a cancel method to Pipe. >>>> >>>> In Android (and presumably iOS and to a lesser extent JS) Pipes are shared >>>> among multiple threads and each request exists in its own scope. (IE >>>> multiple threads can have multiple requests running at one time). >>>> >>>> When a "cancel" is called, which request is cancelled? >>> When calling cancel on a pipe, I'd assume that all enqueued/running >>> requests, for that particular pipe, are canceled. >> -.15 >> >> I don't like it but 99% of the time there will only be one call in the >> Pipe. > > that's what (because of underlying AFNetworking) the iOS side of > things will be doing > >> What happens on the callbacks? I would assume either onError would be >> called with an appropriate object/message(+1) > > +1 > >> or we add an onCancel >> method(-1). >> >> Summers >>> >>> -Matthias >>> >>> >>>> I've attempted to address this (and some larger issues) here: >>>> https://github.com/aerogear/aerogear.org/blob/pipe_spec/docs/specs/aeroge... >>>> >>>> >>>> Summers >>>> >>>> 1: (898,901,895) >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev