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 Fri, 21 Mar 2014 11:29:34 GMT
Hi,

I think yes, we should target the 0.3 release without the browser binding.

We will probably need a 0.3 release sooner than 3-4 months (most likely in the next month)
and I will only be able to work on the browser binding as a background task in my spare time.

My preference therefore would be to finish your ACL write features and release that as 0.3
and then have a 0.4 release for the browser binding support.

What do you think?

Regards,

Gavin



On 20 Mar 2014, at 13:01, Gross, Lukas <lukas.gross@sap.com> wrote:

> Hi,
> 
> The main question is: Do we target a 0.3 release without browser binding
> or do we plan to get browser binding done first. From our side this
> depends on the timeframe in which we can get this done. If we could get
> this done within lets say the next 2 to 3 months I would prefer to bundle
> everything together and release 0.3. If you think we need longer than we
> should consider moving browser binding to 0.4. However we have a strong
> demand for browser binding and therefore plan to have at least one person
> working full-time on this topic.
> The only other thing currently in our pipeline is write support for ACLs.
> We recently committed the parser for read support however write is still
> missing. We plan to do this also during the next weeks.
> 
> Regards,
> Lukas
> 
> On 3/20/14 10:27 AM, "Gavin Cornwell" <gavin.cornwell@alfresco.com> wrote:
> 
>> Hi,
>> 
>> Excellent, a 0.3 release would also be really useful for us too.
>> 
>> I would suggest doing a release sooner rather than later, what other
>> implementation tasks are there from your side that would need to be done
>> before 0.3?
>> 
>> Cheers,
>> 
>> Gav
>> 
>> 
>> 
>> On 20 Mar 2014, at 07:58, Gross, Lukas <lukas.gross@sap.com> wrote:
>> 
>>> Hi,
>>> 
>>> I agree that it would be more consistent to have only the request object
>>> to cancel a request. I will change our code to use the request objects
>>> cancel method and then remove the stop parameter from the library.
>>> 
>>> We had problems using Google hangout in the past, however we could give
>>> it
>>> another try. Just let me know when you have setup the branch and we can
>>> schedule a session.
>>> 
>>> We should also discuss the timeframe for the upcoming implementation
>>> tasks
>>> so that we can plan the Objective CMIS 0.3 release. We need this new
>>> release as early as possible so that we can get an approval for it :)
>>> 
>>> Regards,
>>> Lukas
>>> 
>>> On 3/19/14 10:21 PM, "Gavin Cornwell" <gavin.cornwell@alfresco.com>
>>> wrote:
>>> 
>>>> 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
>>> 
>> 
> 


Mime
View raw message