Hi, Excellent thats also our opinion. However ACL write support is not on our list for the next weeks, so I would rather do a release now and then concentrate on Browser Binding. Do you want me to do the release? Please let me know how you want to proceed.
Regards, Lukas On 3/21/14 12:29 PM, "Gavin Cornwell" <[email protected]> wrote: >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 <[email protected]> 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" <[email protected]> >>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 <[email protected]> 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" <[email protected]> >>>> 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 >>>> >>> >> >
