[aerogear-dev] Sync Day 4 Sync or Swim

[Corinne Krych]

On 03 Feb 2014, at 16:52, Lucas Holmquist <lholmqui at redhat.com> wrote:

> 
> On Feb 3, 2014, at 10:50 AM, Matthias Wessendorf <matzew at apache.org> wrote:
> 
>> 
>> 
>> 
>> On Mon, Feb 3, 2014 at 4:34 PM, Summers Pittman <supittma at redhat.com> wrote:
>> On 02/03/2014 10:28 AM, Matthias Wessendorf wrote:
>>> 
>>> 
>>> 
>>> On Mon, Feb 3, 2014 at 3:27 PM, Summers Pittman <supittma at redhat.com> wrote:
>>> So This should be all of the JIRAs (epics plus sub tasks)
>>> 
>>>   *
>>> https://issues.jboss.org/browse/AEROGEAR-1428?jql=project%20%3D%20AEROGEAR%20AND%20component%20%3D%20data-sync%20AND%20created%20%3E%3D%20-1w%20ORDER%20BY%20created%20DESC
>>> 
>>> 
>>> If we figure out something else, or change our mind, we can always move/create some JIRAs.
>>> 
>>> Overall these items you created here are looking good. However I think the server needs a bit more definition, e.g. what type of adapters (e.g. Couch-Adapter, Hibernate-Adapter), assuming we agreed on this architecture, instead of embedding w/in an application (e.g. on-top of JPA/Hibernate)
>> I mentioned that in response to DanBev
>> 
>> TL;DR;  I didn't think of the server beyond "the data has to come from somewhere".  I heavily prefer having a protocol and a reference implementation that having a "you have to use this server to use this client" setup.  But that is still up for discussion.
>> 
>> yeah not sure on just providing an RI
>>  
>> 
>> I feel like push struck a good balance.  We have Unified push as our default implementation, but it is easy to plug in your own.
>> 
>> hrm, sync based on UnifiedPush ? I was hope for this being a bit more flexible, or optional. hrm not sure
> 
> i read that as the UPS being a good RI for our push server protocol, not a sync thing

Same here, 
but moving forward server part will help define Ri imo

> 
> 
>> 
>>  
>> 
>>> 
>>>  
>>> Now we need to figure out things like versions, release dates, project
>>> specific JIRAs, etc.
>>> 
>>> Me PERSONALLY I think that
>>>   * https://issues.jboss.org/browse/AEROGEAR-1405 and
>>>   * https://issues.jboss.org/browse/AEROGEAR-1409
>>> 
>>> sounds like a good starting point
>>>  
>>> 
>>> 
>>> leave us in a great place for a 0.1.0 release.  It will have enough
>>> stuff done that we can say "yes this a product" but isn't so feature
>>> rich that we get bogged down in minutia.
>>> 
>>> WDYT?
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> 
>> 
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev