Hi, I do see your point about the stop parameter being a common paradigm in iOS, however, personally I would prefer that we remove it, especially if the request approach works. We then have one consistent way to cancel operations across the whole library (the parameter approach is only applicable to methods with progress).
Great to hear you're also interested in the browser binding. I did my initial work a while ago so I need to sync it with the recent changes but I'll commit it in a branch as soon as I can. I too think it would be a great idea to resurrect the status meeting, even if it's just once a month. I will schedule something once I've committed something. Can you remind me, are you guys able to use Google Hangouts or would webex be a better choice? Regards, Gavin > On 19 Mar 2014, at 13:00, "Gross, Lukas" <[email protected]> wrote: > > Hi, > > we added the stop flag because it looked to us as the right place to do this. > I didn't think about canceling the request via the object. I tested it and it > also seems to work. We could remove the stop flag again or leave it (as this > is a common paradigm also in other iOS methods) - what is your opinion on > that? > > We added the secondary object type support because we needed it in our > application. However there are still things to do to support the 1.1 atom > binding. For the complete list of missing features you should look into the > Open CMIS library. > > Good to hear that you are also looking into browser binding! We also have a > heavy demand for that to make the app faster and we plan to implement browser > binding during the next months. It would be great if you create a branch and > share your current status with us. We could then decide how to proceed. Maybe > we can split the workload :) We should also think of restarting the sync > meeting session or use another channel to coordinate browser binding > implementation if we do this together. > > Regards, > Lukas > > Sent from my iPad > >> On Mar 17, 2014, at 9:58 PM, "Gavin Cornwell" <[email protected]> >> wrote: >> >> Hi, >> >> I did have one question regarding the new *stop parameter, I’m just curious >> why the stop parameter was required when we already have a mechanism (via >> the CMISRequest object) to cancel running operations? >> >> Thanks very much for adding secondary type support too, we were planning on >> doing that as well some point soon. I presume this was to support the 1.1 >> binding? Do you know what else we need to do in order to support a 1.1 atom >> binding? >> >> Finally, as I background project I have started looking at the browser >> binding, I have some *very* early support for the browser binding on my >> machine. I was thinking of creating a branch for this once the initial >> commit is ready as it is going to require some minor moving and renaming of >> files. Does any have any objection to the creation of a branch? >> >> Regards, >> >> Gavin >> >> >> >>> On 17 Mar 2014, at 15:36, Gross, Lukas <[email protected]> wrote: >>> >>> Hi, >>> >>> I fixed the project file (missing files) and added some fixes so that all >>> tests are green again. >>> BTW: Please ignore my comment (below) about the incompatible changes (I've >>> made them some time ago) we currently still support the old interfaces, >>> however we can discuss if we want to get rid of them for 0.3 or if we want >>> to keep them for simple use cases. >>> >>> Best Regards, >>> Lukas >>> >>> >>> From: <Gross>, Lukas Gross <[email protected]<mailto:[email protected]>> >>> Date: Monday, March 17, 2014 3:02 PM >>> To: "[email protected]<mailto:[email protected]>" >>> <[email protected]<mailto:[email protected]>> >>> Subject: Commits to ObjectiveCMIS >>> >>> Hi, >>> >>> As announced earlier today we merged our changes (faster than I thought) >>> and committed them. >>> Please have a close look to the changes as they also include an >>> incompatible API change: We added a *stop parameter to the progress block >>> of all transmission methods, so that it is possible to abort the >>> transmission. We decided against creating new interfaces with the *stop >>> flag and just modified the exiting ones as creating additional interfaces >>> would basically double all transmission interfaces. >>> Please let us know if anyone has a different opinion on this topic. >>> >>> Best Regards, >>> Lukas >>
