Thanks guys!
I've got my answers.
I agree with you, I'll keep Pipe under the hood but I will define a new
protocol as you said 'save' method has 3 callbacks: success, failure
conflict using Pipe protocol feels awkward somehow.
I'll update ios-sync repo with a new proposal and i'll share it with you
shortly so we can discuss further.
Once we agree on API we can define spec.
++
Corinne
On 4 February 2014 18:14, Matthias Wessendorf <matzew(a)apache.org> wrote:
On Tue, Feb 4, 2014 at 6:10 PM, Summers Pittman <supittma(a)redhat.com>wrote:
> On 02/04/2014 11:52 AM, Matthias Wessendorf wrote:
>
>
>
>
> On Tue, Feb 4, 2014 at 5:42 PM, Summers Pittman <supittma(a)redhat.com>wrote:
>
>> On 02/04/2014 03:04 AM, Corinne Krych wrote:
>> > Hello all,
>> >
>> > I started doing demo app Buddies and Hobbies [1] (same idea than
>> luke's one [2]). But instead of usin gcomplete separate chanel I wrapped
>> Pipe within SyncPipe [3]. Questions:
>> > 1. looking at Luke's work I didn't see the usage of pipe at all.
>> > 2. do we want to reuse Pipe protocol/interface for sync Pipe or use a
>> different one?
>> > I rather use the pipe underneath as we don't want to reimplement
>> Paging, upload etc...
>> > wdyt guys?
>> I don't think extending Pipe is the best idea. However, I feel that any
>> synchronizer should use pipes under the hood.
>>
>
> +1
>
>>
>> Think composition over inheritance. Also overloading the read and save
>> methods will get rather rough when we also have to check for conflicts
>> and handle responses from the server.
>>
>
> +1
>
>
>>
>> A SyncPipe could be the implementation the sync system works in iOS,
>
>
> not sure I get this
>
> Sorry was a merge error on my part when I was writing the email.
>
> I meant that there isn't anything wrong with making a sync pipe for
> making implementing sync on iOS easier. I just don't think it should be
> part of the platform.
>
Ah! ok :-)
At least it sounds like a good idea to leverage the pipes internally,
instead of making a AGSyncPipe
>
>
>
>
>> but
>> I don't think it should be part of the spec/protocol.
>>
>>
>> >
>> > With our actual server [4], we need adjust to serve REST endpoint.
>> Ugly harcoded it (for now) to serve my purpose.
>> >
>> > ++
>> > Corinne
>> > [1]
>>
https://github.com/corinnekrych/aerogear-ios-cookbook/tree/sync.demo.reci...
>> > [2]
https://github.com/lholmquist/ag-js-ds-poc
>> > [3]
https://github.com/corinnekrych/aerogear-sync-ios
>> > [4]
>>
https://github.com/corinnekrych/aerogear-sync-server/blob/master/server/s...
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev(a)lists.jboss.org
>> >
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog:
http://matthiaswessendorf.wordpress.com/
> sessions:
http://www.slideshare.net/mwessendorf
> twitter:
http://twitter.com/mwessendorf
>
>
> _______________________________________________
> aerogear-dev mailing
listaerogear-dev@lists.jboss.orghttps://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
--
Matthias Wessendorf
blog:
http://matthiaswessendorf.wordpress.com/
sessions:
http://www.slideshare.net/mwessendorf
twitter:
http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev