chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gavin Cornwell <gavin.cornw...@alfresco.com>
Subject Re: Commits to ObjectiveCMIS
Date Wed, 19 Mar 2014 21:21:28 GMT
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" <lukas.gross@sap.com> 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" <gavin.cornwell@alfresco.com>
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 <lukas.gross@sap.com> 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 <lukas.gross@sap.com<mailto:lukas.gross@sap.com>>
>>> Date: Monday, March 17, 2014 3:02 PM
>>> To: "dev@chemistry.apache.org<mailto:dev@chemistry.apache.org>" <dev@chemistry.apache.org<mailto:dev@chemistry.apache.org>>
>>> 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
>> 

Mime
View raw message