On Mon, Feb 3, 2014 at 4:55 PM, Summers Pittman <supittma@redhat.com> wrote:
On 02/03/2014 10:52 AM, Lucas Holmquist wrote:

On Feb 3, 2014, at 10:50 AM, Matthias Wessendorf <matzew@apache.org> wrote:




On Mon, Feb 3, 2014 at 4:34 PM, Summers Pittman <supittma@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@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
I was more talking about the interaction among APIs, implementations, protocols and servers.

It is easy to add your own messaging system into the Push APIs (on Android anyway). 

yep - but not on iOS/SimplePush clients

And than I really 'fear' that our different client API might really be Android versus iOS/SimplePush at the end of the day;
Not sure, but I feel at the end they are all really different.
 
We provide an implementation for connecting to the Unified push server however.




 


 
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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev



_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@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