chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gross, Lukas" <lukas.gr...@sap.com>
Subject Re: Commits to ObjectiveCMIS
Date Wed, 19 Mar 2014 13:00:13 GMT
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