From daniel.bevenius at gmail.com Mon Sep 1 01:09:34 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 1 Sep 2014 07:09:34 +0200 Subject: [aerogear-dev] Team meeting Message-ID: Agenda: http://oksoclap.com/p/aerogear-team-mgt-20140901 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140901/69ffa4ed/attachment.html From daniel.bevenius at gmail.com Mon Sep 1 03:35:25 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 1 Sep 2014 09:35:25 +0200 Subject: [aerogear-dev] Suggestion for DataSync roadmap In-Reply-To: References: Message-ID: We updated the DataSync roadmap branch [1]. Again if you don't want to build it you might be able to see it on this OpenShift instance[2] (ping me if it's down). We have merged the two of initial version of "conflict resolution" as they did not really contain very much in and by themselves in reality, and we might have most of the functionality for the first version already (perhaps hidden in the current Pipes concepts). The roadmap currently contains a "conflict resolution" part, and a "data sync" part. This is inline with what we discussed at the f2f to start simple and evolve in a step by step manner. At that time we were thinking in terms of a message format that must be able to be evolve over time. At the moment, in the "conflict resolution" suggestion we are not forcing any data format and instead the developer will use whatever message/data format they already have, with the only requirement that the server side can detect conflicts. When conflict is detected the server will reply with a 409 and the body must contain the latest version of the object/document that the server has. This would be the only change that is required on the server side and it would not have to be updated to return any specific message format that we define. This also brings up what others have previously pointed out that this is not "data sync", and perhaps we should keep these completely different. Should we keep these separate each with it's own roadmap, spec, jira, and releases? Do we think that there are users that would be interested in using only the "conflict resolution" version, and some that are only interested in the "data sync" version is really what we are asking I guess. Regarding offline support, for the "conflict resolution" version our current thinking is that we would not support it in the client libraries. A client application could support offline work itself with this version though, for example allowing information to be updated and when a network connection is available it would send the updates to the server which in case of a conflict would take the actions as described above. But for the "data sync" version it would be supported and updates (really diffs or operations on the document/object) would be queued up and later sent to the server to be applied. Please let us know if you have questions or different views/ideas on anything here! [1] https://github.com/danbev/beta.aerogear.org/tree/data-sync-rebirth-roadmap [2] http://diy-dbevenius.rhcloud.com/docs/planning/roadmaps/AeroGearDataSync/ On 25 August 2014 14:47, Daniel Bevenius wrote: > >The main architectural point I'm missing here is whether AeroGear sync > server should be primarily at the end: > >1) standalone storage mechanism with data sync capability (such as > CouchDB) > >CLIENT <--> DATA SYNC SERVER > >2) mediator for synchronization with storage mechanism > >CLIENT <--> DATA SYNC SERVER <--> STORE (pluggable) > >And here pluggable storage mechanism could be JAX-RS server with > interceptors, LiveOak server, MongoDB or CouchDB... > I'l like to see this done using option 2 in your list above. > > > >Just one more question, how are these documents up to date? > >http://aerogear.org/docs/specs/aerogear-sync-client-api/ > >http://aerogear.org/docs/specs/aerogear-sync-server-api/ > No sorry, these are have not been updated only the roadmap and minor > spelling corrections have been done to the DataSync spec page at this > stage. > > > On 25 August 2014 14:40, Luk?? Fry? wrote: > >> >> >> >> On Mon, Aug 25, 2014 at 12:39 PM, Daniel Bevenius < >> daniel.bevenius at gmail.com> wrote: >> >>> >I expect in the mean time we should also play with prototypes and >>> figure out what approaches fit best the needs, >>> > and evaluate that functionally and performance-wise on sample apps. >>> Yeah, we should definitely do that and especially with the later version >>> as we still don't know the exact direction there. >>> >>> >Something what I'm missing is more comprehensive elaboration / insight >>> in what are the target use cases and requirements on final architecture: >>> Yeah, we should probably have some links from the road map to a page >>> that elaborates more on these. I thought having too much in the road map >>> would not be very nice but rather keep it pretty simple. We already have >>> some information in the Specifications section [1] and perhaps that is the >>> correct place to add such details and then link to them from the roadmap. >>> What do you (all) think? >>> >>> >> +1 for linking them (I didn't notice that page, my bad, and good summary >> btw) >> >> >>> >* integrate /w any general REST interface (compliant with given >>> limitations) >>> For the first stage we're thinking that the only requirement would be >>> that the server can detect a conflict and return a 409 accompanied with the >>> latest version of that the server has. This is what was discussed at the >>> f2f and which Erik has a Forge plugin to generate. >>> But the "real" data sync version will have much more impact on the >>> backend and it would have to follow an application protocol that we define. >>> >>> >HATEOAS-compliant backend? >>> Does this differ from the REST interface describe above now that some >>> background information was provided? >>> If it does that it would be great to either gather them here or that we >>> add to aerogear.org. I'll push the branch to master so we can all work >>> off it. >>> >>> > generic JAX-RS? >>> Not sure about this, but would Erik's Forge plugin take care the generic >>> JAX-RS backend case. Users would not need to use Forge if they choose not >>> to, and we should document the requirements upon the backend like described >>> in the first version. Again, if there are things we've missed then please >>> add them. >>> >> >> The main architectural point I'm missing here is whether AeroGear sync >> server should be primarily at the end: >> >> >> 1) standalone storage mechanism with data sync capability (such as >> CouchDB) >> >> CLIENT <--> DATA SYNC SERVER >> >> >> >> 2) mediator for synchronization with storage mechanism >> >> CLIENT <--> DATA SYNC SERVER <--> STORE (pluggable) >> >> And here pluggable storage mechanism could be JAX-RS server with >> interceptors, LiveOak server, MongoDB or CouchDB... >> >> >> >> The proposals that I've seen (and I apologize if I've missed something) >> talk about synchronization protocol (DS, OT), conflict resolution and means >> of communication (request/response, realtime), >> but doesn't talk about restrictions on backend architecture. And this I >> guess applies to 0.2, 0.3 and 0.4 versions as on the Roadmap. >> >> >> >> Just one more question, how are these documents up to date? >> >> http://aerogear.org/docs/specs/aerogear-sync-client-api/ >> http://aerogear.org/docs/specs/aerogear-sync-server-api/ >> >> Is it something that fully reflects current implementation state / plans? >> >> >>> >>> >*Use cases / end-user stories:* >>> These could be added to the existing use cases I think. See the last >>> section of [1]. >>> >>> Thanks for comments and the link to that document, I'll read through it. >>> >>> >>> [1] http://diy-dbevenius.rhcloud.com/docs/specs/aerogear-data-sync/ >>> >>> >>> On 25 August 2014 11:20, Luk?? Fry? wrote: >>> >>>> Hey Dan, >>>> >>>> this sounds good. >>>> >>>> I expect in the mean time we should also play with prototypes and >>>> figure out what approaches fit best the needs, >>>> and evaluate that functionally and performance-wise on sample apps. >>>> >>>> >>>> >>>> Something what I'm missing is more comprehensive elaboration / insight >>>> in what are the target use cases and requirements on final architecture: >>>> >>>> *Requirements:* >>>> >>>> * integrate /w any general REST interface (compliant with given >>>> limitations) >>>> ** HATEOAS-compliant backend? >>>> ** generic JAX-RS? >>>> * integrate seamlessly with LiveOak >>>> >>>> *Use cases / end-user stories:* >>>> >>>> * mobile sales client >>>> * mobile warehouse manager >>>> * delivery agent >>>> >>>> Inspiration: >>>> https://docs.google.com/document/d/1DMacL7iwjSMPP0ytZfugpU4v0PWUK0BT6lhyaVEmlBQ/edit >>>> >>>> >>>> I expect we target different use cases in different phases. >>>> So we could indicate what use cases are valid in what phase. >>>> >>>> Should we brainstorm this on wiki or so? >>>> >>>> >>>> Cheers! >>>> >>>> ~ Lukas >>>> >>>> >>>> >>>> On Mon, Aug 25, 2014 at 9:58 AM, Daniel Bevenius < >>>> daniel.bevenius at gmail.com> wrote: >>>> >>>>> >is Nov, 2014, right? >>>>> Yep, sorry that should be 2015. I'll correct that. Thx >>>>> >>>>> >>>>> On 25 August 2014 09:57, Matthias Wessendorf >>>>> wrote: >>>>> >>>>>> 0.2.0 (Nov, 2015) Conflict resolvers >>>>>> is Nov, 2014, right? >>>>>> >>>>>> >>>>>> On Mon, Aug 25, 2014 at 9:30 AM, Daniel Bevenius < >>>>>> daniel.bevenius at gmail.com> wrote: >>>>>> >>>>>>> We have been working on a roadmap for DataSync to help our planning >>>>>>> of the features and time frames. >>>>>>> >>>>>>> A suggestion for the roadmap can be found in this branch: >>>>>>> >>>>>>> https://github.com/danbev/beta.aerogear.org/tree/data-sync-rebirth-roadmap >>>>>>> >>>>>>> If you don't feel like building it yourself you can try this >>>>>>> OpenShift instance: >>>>>>> >>>>>>> http://diy-dbevenius.rhcloud.com/docs/planning/roadmaps/AeroGearDataSync/ >>>>>>> >>>>>>> Please note that the dates are just made up and something that we >>>>>>> need help from each client library project to provide feedback on what is >>>>>>> reasonable. >>>>>>> >>>>>>> Let us know what you think and from the feedback given, either here >>>>>>> or as PRs, we will try to break this down further and start creating JIRAs >>>>>>> to link to the roadmap. >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140901/c41b9507/attachment-0001.html From edewit at redhat.com Mon Sep 1 07:33:37 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 1 Sep 2014 13:33:37 +0200 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: <1409234343233.eec9f5f8@Nodemailer> <20140828142629.GA61471@abstractj.org> Message-ID: <2F83CCAA-7DF1-433A-BB72-207C3CE9009A@redhat.com> > > Another option that might work out of the box would be to use the jax-rs @Consumes annotation e.g @Consumes({"application/vnd.aerogear.v101+json"}) on the service endpoints. > So by making an abstract PushNotificationSenderEndpoint and and several PushNotificationSenderEndpointV101, PushNotificationSenderEndpointV102 with the right @Consumes annotation should work. I haven't tried it though Tried out this option as well, seems to work, but to use it one must set the Content-Type to ?application/vnd.aerogear.v101+json? instead of the Accept header. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140901/87886f09/attachment.html From tolisemm at gmail.com Mon Sep 1 07:50:40 2014 From: tolisemm at gmail.com (tolis emmanouilidis) Date: Mon, 1 Sep 2014 14:50:40 +0300 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: <2F83CCAA-7DF1-433A-BB72-207C3CE9009A@redhat.com> References: <1409234343233.eec9f5f8@Nodemailer> <20140828142629.GA61471@abstractj.org> <2F83CCAA-7DF1-433A-BB72-207C3CE9009A@redhat.com> Message-ID: Could you try the @produces annotation? I believe it will work with the Accept header since it indicates the acceptable media-types from the client 2014-09-01 14:33 GMT+03:00 Erik Jan de Wit : > > Another option that might work out of the box would be to use the jax-rs > @Consumes annotation e.g @Consumes({"application/vnd.aerogear.v101+json"}) > on the service endpoints. > So by making an abstract PushNotificationSenderEndpoint and and several > PushNotificationSenderEndpointV101, PushNotificationSenderEndpointV102 with > the right @Consumes annotation should work. I haven't tried it though > > > > Tried out this option as well, seems to work, but to use it one must set > the Content-Type to ?application/vnd.aerogear.v101+json? instead of the > Accept header. > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140901/1c787908/attachment.html From daniel.bevenius at gmail.com Mon Sep 1 09:01:19 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 1 Sep 2014 15:01:19 +0200 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: I won't be able to make todays meeting by the looks of things. m?ndag 1 september 2014 skrev Daniel Bevenius : > Agenda: > http://oksoclap.com/p/aerogear-team-mgt-20140901 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140901/655f9ffa/attachment.html From scm.blanc at gmail.com Mon Sep 1 09:09:56 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 1 Sep 2014 15:09:56 +0200 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: And since US is off today let's move that to tomorrow ? wdyt ? Sebi On Mon, Sep 1, 2014 at 3:01 PM, Daniel Bevenius wrote: > I won't be able to make todays meeting by the looks of things. > > m?ndag 1 september 2014 skrev Daniel Bevenius : > >> Agenda: >> http://oksoclap.com/p/aerogear-team-mgt-20140901 >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140901/75e3ab58/attachment.html From corinnekrych at gmail.com Mon Sep 1 09:11:48 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 1 Sep 2014 15:11:48 +0200 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: <99C2881A-D439-4E43-AF01-BC5B25024EE5@gmail.com> +1 Corinne On 01 Sep 2014, at 15:09, Sebastien Blanc wrote: > And since US is off today let's move that to tomorrow ? wdyt ? > Sebi > > > > On Mon, Sep 1, 2014 at 3:01 PM, Daniel Bevenius wrote: > I won't be able to make todays meeting by the looks of things. > > m?ndag 1 september 2014 skrev Daniel Bevenius : > Agenda: > http://oksoclap.com/p/aerogear-team-mgt-20140901 > > _______________________________________________ > 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 From daniel.bevenius at gmail.com Mon Sep 1 09:13:32 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 1 Sep 2014 15:13:32 +0200 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: +1 m?ndag 1 september 2014 skrev Sebastien Blanc : > And since US is off today let's move that to tomorrow ? wdyt ? > Sebi > > > > On Mon, Sep 1, 2014 at 3:01 PM, Daniel Bevenius > wrote: > >> I won't be able to make todays meeting by the looks of things. >> >> m?ndag 1 september 2014 skrev Daniel Bevenius > >: >> >>> Agenda: >>> http://oksoclap.com/p/aerogear-team-mgt-20140901 >>> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140901/ca4e819c/attachment.html From lukas.fryc at gmail.com Mon Sep 1 09:33:46 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Mon, 1 Sep 2014 15:33:46 +0200 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: +1 On Mon, Sep 1, 2014 at 3:13 PM, Daniel Bevenius wrote: > +1 > > m?ndag 1 september 2014 skrev Sebastien Blanc : > > And since US is off today let's move that to tomorrow ? wdyt ? >> Sebi >> >> >> >> On Mon, Sep 1, 2014 at 3:01 PM, Daniel Bevenius < >> daniel.bevenius at gmail.com> wrote: >> >>> I won't be able to make todays meeting by the looks of things. >>> >>> m?ndag 1 september 2014 skrev Daniel Bevenius >> >: >>> >>>> Agenda: >>>> http://oksoclap.com/p/aerogear-team-mgt-20140901 >>>> >>> >>> _______________________________________________ >>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140901/7dce1021/attachment-0001.html From daniel at passos.me Mon Sep 1 10:01:05 2014 From: daniel at passos.me (Daniel Passos) Date: Mon, 1 Sep 2014 11:01:05 -0300 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: +1 On Mon, Sep 1, 2014 at 10:33 AM, Luk?? Fry? wrote: > +1 > > > On Mon, Sep 1, 2014 at 3:13 PM, Daniel Bevenius > wrote: > >> +1 >> >> m?ndag 1 september 2014 skrev Sebastien Blanc : >> >> And since US is off today let's move that to tomorrow ? wdyt ? >>> Sebi >>> >>> >>> >>> On Mon, Sep 1, 2014 at 3:01 PM, Daniel Bevenius < >>> daniel.bevenius at gmail.com> wrote: >>> >>>> I won't be able to make todays meeting by the looks of things. >>>> >>>> m?ndag 1 september 2014 skrev Daniel Bevenius < >>>> daniel.bevenius at gmail.com>: >>>> >>>>> Agenda: >>>>> http://oksoclap.com/p/aerogear-team-mgt-20140901 >>>>> >>>> >>>> _______________________________________________ >>>> 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 >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140901/a40c4953/attachment.html From bruno at abstractj.org Mon Sep 1 10:20:57 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 1 Sep 2014 11:20:57 -0300 Subject: [aerogear-dev] Team meeting In-Reply-To: <99C2881A-D439-4E43-AF01-BC5B25024EE5@gmail.com> References: <99C2881A-D439-4E43-AF01-BC5B25024EE5@gmail.com> Message-ID: <20140901142056.GA7367@abstractj.org> The meeting was postoned for tomorrow at the same time. On 2014-09-01, Corinne Krych wrote: > +1 > Corinne > On 01 Sep 2014, at 15:09, Sebastien Blanc wrote: > > > And since US is off today let's move that to tomorrow ? wdyt ? > > Sebi > > > > > > > > On Mon, Sep 1, 2014 at 3:01 PM, Daniel Bevenius wrote: > > I won't be able to make todays meeting by the looks of things. > > > > m?ndag 1 september 2014 skrev Daniel Bevenius : > > Agenda: > > http://oksoclap.com/p/aerogear-team-mgt-20140901 > > > > _______________________________________________ > > 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 > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From edewit at redhat.com Tue Sep 2 02:24:12 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 2 Sep 2014 08:24:12 +0200 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: <1409234343233.eec9f5f8@Nodemailer> <20140828142629.GA61471@abstractj.org> <2F83CCAA-7DF1-433A-BB72-207C3CE9009A@redhat.com> Message-ID: <2BF96CA9-E14C-4182-BD43-193F6D1AA69F@redhat.com> > Could you try the @produces annotation? Same effect > > I believe it will work with the Accept header since it indicates the acceptable media-types from the client > > > 2014-09-01 14:33 GMT+03:00 Erik Jan de Wit : >> >> Another option that might work out of the box would be to use the jax-rs @Consumes annotation e.g @Consumes({"application/vnd.aerogear.v101+json"}) on the service endpoints. >> So by making an abstract PushNotificationSenderEndpoint and and several PushNotificationSenderEndpointV101, PushNotificationSenderEndpointV102 with the right @Consumes annotation should work. I haven't tried it though > > > Tried out this option as well, seems to work, but to use it one must set the Content-Type to ?application/vnd.aerogear.v101+json? instead of the Accept header. > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140902/671b9f23/attachment.html From tolisemm at gmail.com Tue Sep 2 03:27:38 2014 From: tolisemm at gmail.com (tolis emmanouilidis) Date: Tue, 2 Sep 2014 10:27:38 +0300 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: <2BF96CA9-E14C-4182-BD43-193F6D1AA69F@redhat.com> References: <1409234343233.eec9f5f8@Nodemailer> <20140828142629.GA61471@abstractj.org> <2F83CCAA-7DF1-433A-BB72-207C3CE9009A@redhat.com> <2BF96CA9-E14C-4182-BD43-193F6D1AA69F@redhat.com> Message-ID: Hi Eric, I have tried the jax-rs @Produces annotation both at method and class levels as shown here ( http://docs.oracle.com/cd/E19798-01/821-1841/gipzh/index.html) and it works for me. I don't have to specify the Content-Type header in the request.The resource method or endpoint is chosen according the Accept header. method level @GET @Produces({"application/vnd.aerogear.v101+json"}) public List listAllMembers() { return repository.findAllOrderedByName(); } @GET @Produces({"application/vnd.aerogear.v102+json"}) public List listAllMembersNew() { return null; } class level @Path("/members") @RequestScoped @Produces({"application/vnd.aerogear.v102+json"}) public class MemberResourceRESTServiceV102 { @Path("/members") @RequestScoped @Produces({"application/vnd.aerogear.v101+json"}) public class MemberResourceRESTService { 2014-09-02 9:24 GMT+03:00 Erik Jan de Wit : > > Could you try the @produces annotation? > > > Same effect > > > I believe it will work with the Accept header since it indicates the > acceptable media-types from the client > > > 2014-09-01 14:33 GMT+03:00 Erik Jan de Wit : > >> >> Another option that might work out of the box would be to use the jax-rs >> @Consumes annotation e.g @Consumes({"application/vnd.aerogear.v101+json"}) >> on the service endpoints. >> So by making an abstract PushNotificationSenderEndpoint and and several >> PushNotificationSenderEndpointV101, PushNotificationSenderEndpointV102 with >> the right @Consumes annotation should work. I haven't tried it though >> >> >> >> Tried out this option as well, seems to work, but to use it one must set >> the Content-Type to ?application/vnd.aerogear.v101+json? instead of the >> Accept header. >> >> >> _______________________________________________ >> 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 > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140902/f889a74b/attachment.html From daniel at passos.me Tue Sep 2 10:17:02 2014 From: daniel at passos.me (Daniel Passos) Date: Tue, 2 Sep 2014 11:17:02 -0300 Subject: [aerogear-dev] Team meeting In-Reply-To: <20140901142056.GA7367@abstractj.org> References: <99C2881A-D439-4E43-AF01-BC5B25024EE5@gmail.com> <20140901142056.GA7367@abstractj.org> Message-ID: Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-09-02-14.00.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-09-02-14.00.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-09-02-14.00.log.html On Mon, Sep 1, 2014 at 11:20 AM, Bruno Oliveira wrote: > The meeting was postoned for tomorrow at the same time. > > On 2014-09-01, Corinne Krych wrote: > > +1 > > Corinne > > On 01 Sep 2014, at 15:09, Sebastien Blanc wrote: > > > > > And since US is off today let's move that to tomorrow ? wdyt ? > > > Sebi > > > > > > > > > > > > On Mon, Sep 1, 2014 at 3:01 PM, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > > > I won't be able to make todays meeting by the looks of things. > > > > > > m?ndag 1 september 2014 skrev Daniel Bevenius < > daniel.bevenius at gmail.com>: > > > Agenda: > > > http://oksoclap.com/p/aerogear-team-mgt-20140901 > > > > > > _______________________________________________ > > > 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 > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140902/33ad4809/attachment-0001.html From lholmqui at redhat.com Wed Sep 3 13:48:44 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 3 Sep 2014 13:48:44 -0400 Subject: [aerogear-dev] Chrome Push Messages In-Reply-To: References: Message-ID: <60194944-06DE-44BF-AEF4-B729DF9B5E69@redhat.com> So to follow up on this, Chrome Packaged Applications, no recommend to use the same GCM network for Android when sending push notifications. Currently in the UnifiedPush Server, a user can use the Android variant to use this new API now. I think we should rename the AndroidVariant.class and related stuff to GCMVariant . I created this Task to track the changes, https://issues.jboss.org/browse/AGPUSH-928 since we need to deprecate the current Chrome implementation and update the UI?s for the new way. i?m wondering for the ?Create Variant? dialog, for Android, we would need to change the name to GCM, but for the icon?s i wonder how it would look to put both Android and Chrome icons, side by side On Aug 27, 2014, at 2:19 PM, Lucas Holmquist wrote: > > On Aug 27, 2014, at 2:15 PM, Luk?? Fry? wrote: > >> Hey Luke, >> >> ad) Variants >> >> it would be ideal if we could just use the same variant! > > yea, it?s looking like it will be the same thing, we might just have to make a note of it on the UI >> >> >> ad) Compatibility >> >> I would say we should preserve the compatibility with 1.x as long as it does not make much efforts to keep both supported. >> >> If it would be too much hassle, let's remove it in 1.1. >> Chrome is updated pro-actively anyway, so no one will hear about the old API in few months. > > exactly, so maybe a warning or something >> >> >> Cheers, >> >> ~ Lukas >> >> >> On Wed, Aug 27, 2014 at 3:28 PM, Lucas Holmquist wrote: >> Hello, >> >> now that the 1.0.0-final is pretty much out for the UnifiedPush Server, i?m starting to look at the new API that Chrome apps use for sending push notifications. >> >> the TL;DR of it is, it?s basically the same as Android now.( no more refresh tokens and access tokens and such ) >> >> So the question is, do we need to have a deprecation period on what is currently there? >> >> The v1 of the chrome pushMessaging api has become legacy and it is recommended to use the new stuff. https://developer.chrome.com/apps/cloudMessagingV1 >> >> While i have looked to deeply, it?s possible we can use the same ?Variant? structure for Chrome Apps, Since they will be using the same Network >> >> wdyt? >> >> -Luke >> >> _______________________________________________ >> 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140903/0ae6fd7c/attachment.html From corinnekrych at gmail.com Wed Sep 3 15:12:46 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 3 Sep 2014 21:12:46 +0200 Subject: [aerogear-dev] Xcode6 beta7 is out... Message-ID: <9E732C9D-A6B9-4F49-9607-40D6A4F3BD16@gmail.com> Hello Guys Xcode6 beta7 was out yesterday. iOS8 is still beta5. Beta7 seems less of a change than others betas. Most changes are around optionals. you can read apple release notes [1] or blog post [2] PRs on their ways. If you have beta7 installed, review build and run test (for now Travis is not on Xcode6) when reviewing them. ++ Corinne [1] http://adcdownload.apple.com//Developer_Tools/xcode_6_beta_7_apzr94/xcode_6__beta_7_release_notes.pdf [2] http://fortheloveoftech.com/2014/09/02/xcode-6-beta-7-is-available-with-a-swift-release-around-the-corner/ From lukas.fryc at gmail.com Wed Sep 3 15:32:43 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Wed, 3 Sep 2014 21:32:43 +0200 Subject: [aerogear-dev] Chrome Push Messages In-Reply-To: <60194944-06DE-44BF-AEF4-B729DF9B5E69@redhat.com> References: <60194944-06DE-44BF-AEF4-B729DF9B5E69@redhat.com> Message-ID: >From the UI perspective, Android/Chrome merge has few options: 1. merged half-Android / half-Chrome logo (+ "Android / Chrome" as a description) 2. use one radio button, but two rows with two logos (Android, Chrome) 3. use Google logo ("G"? [1]) (and "Google Cloud Messaging" description) Anyway, in any case it won't be as nice and polished as it is now. :-) [1] https://www.google.com/search?q=g+google&source=lnms&tbm=isch&sa=X&ei=kWsHVILKJsn8yQSO9IDoCQ&ved=0CAoQ_AUoAw&biw=1283&bih=861 On Wed, Sep 3, 2014 at 7:48 PM, Lucas Holmquist wrote: > So to follow up on this, > > > Chrome Packaged Applications, no recommend to use the same GCM network for > Android when sending push notifications. > > Currently in the UnifiedPush Server, a user can use the Android variant to > use this new API now. > > I think we should rename the AndroidVariant.class and related stuff to > GCMVariant . > > I created this Task to track the changes, > https://issues.jboss.org/browse/AGPUSH-928 since we need to deprecate > the current Chrome implementation and update the UI?s for the new way. > > i?m wondering for the ?Create Variant? dialog, for Android, we would > need to change the name to GCM, but for the icon?s i wonder how it would > look to put both Android and Chrome icons, side by side > > > On Aug 27, 2014, at 2:19 PM, Lucas Holmquist wrote: > > > On Aug 27, 2014, at 2:15 PM, Luk?? Fry? wrote: > > Hey Luke, > > ad) Variants > > it would be ideal if we could just use the same variant! > > > yea, it?s looking like it will be the same thing, we might just have to > make a note of it on the UI > > > > ad) Compatibility > > I would say we should preserve the compatibility with 1.x as long as it > does not make much efforts to keep both supported. > > > If it would be too much hassle, let's remove it in 1.1. > Chrome is updated pro-actively anyway, so no one will hear about the old > API in few months. > > > exactly, so maybe a warning or something > > > > Cheers, > > ~ Lukas > > > On Wed, Aug 27, 2014 at 3:28 PM, Lucas Holmquist > wrote: > >> Hello, >> >> now that the 1.0.0-final is pretty much out for the UnifiedPush Server, >> i?m starting to look at the new API that Chrome apps use for sending push >> notifications. >> >> the TL;DR of it is, it?s basically the same as Android now.( no more >> refresh tokens and access tokens and such ) >> >> So the question is, do we need to have a deprecation period on what is >> currently there? >> >> The v1 of the chrome pushMessaging api has become legacy and it is >> recommended to use the new stuff. >> https://developer.chrome.com/apps/cloudMessagingV1 >> >> While i have looked to deeply, it?s possible we can use the same >> ?Variant? structure for Chrome Apps, Since they will be using the same >> Network >> >> wdyt? >> >> -Luke >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140903/8704882b/attachment-0001.html From scm.blanc at gmail.com Wed Sep 3 16:27:41 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Wed, 3 Sep 2014 22:27:41 +0200 Subject: [aerogear-dev] Chrome Push Messages In-Reply-To: References: <60194944-06DE-44BF-AEF4-B729DF9B5E69@redhat.com> Message-ID: Looks like there is a gcm logo but it is not really nice and I can not find it with a decent resolution Envoy? de mon iPhone > Le 3 sept. 2014 ? 21:32, Luk?? Fry? a ?crit : > > From the UI perspective, Android/Chrome merge has few options: > > 1. merged half-Android / half-Chrome logo (+ "Android / Chrome" as a description) > > 2. use one radio button, but two rows with two logos (Android, Chrome) > > 3. use Google logo ("G"? [1]) (and "Google Cloud Messaging" description) > > > Anyway, in any case it won't be as nice and polished as it is now. :-) > > > [1] https://www.google.com/search?q=g+google&source=lnms&tbm=isch&sa=X&ei=kWsHVILKJsn8yQSO9IDoCQ&ved=0CAoQ_AUoAw&biw=1283&bih=861 > > >> On Wed, Sep 3, 2014 at 7:48 PM, Lucas Holmquist wrote: >> So to follow up on this, >> >> >> Chrome Packaged Applications, no recommend to use the same GCM network for Android when sending push notifications. >> >> Currently in the UnifiedPush Server, a user can use the Android variant to use this new API now. >> >> I think we should rename the AndroidVariant.class and related stuff to GCMVariant . >> >> I created this Task to track the changes, https://issues.jboss.org/browse/AGPUSH-928 since we need to deprecate the current Chrome implementation and update the UI?s for the new way. >> >> i?m wondering for the ?Create Variant? dialog, for Android, we would need to change the name to GCM, but for the icon?s i wonder how it would look to put both Android and Chrome icons, side by side >> >> >>> On Aug 27, 2014, at 2:19 PM, Lucas Holmquist wrote: >>> >>> >>>> On Aug 27, 2014, at 2:15 PM, Luk?? Fry? wrote: >>>> >>>> Hey Luke, >>>> >>>> ad) Variants >>>> >>>> it would be ideal if we could just use the same variant! >>> >>> yea, it?s looking like it will be the same thing, we might just have to make a note of it on the UI >>>> >>>> >>>> ad) Compatibility >>>> >>>> I would say we should preserve the compatibility with 1.x as long as it does not make much efforts to keep both supported. >>>> >>>> If it would be too much hassle, let's remove it in 1.1. >>>> Chrome is updated pro-actively anyway, so no one will hear about the old API in few months. >>> >>> exactly, so maybe a warning or something >>>> >>>> >>>> Cheers, >>>> >>>> ~ Lukas >>>> >>>> >>>>> On Wed, Aug 27, 2014 at 3:28 PM, Lucas Holmquist wrote: >>>>> Hello, >>>>> >>>>> now that the 1.0.0-final is pretty much out for the UnifiedPush Server, i?m starting to look at the new API that Chrome apps use for sending push notifications. >>>>> >>>>> the TL;DR of it is, it?s basically the same as Android now.( no more refresh tokens and access tokens and such ) >>>>> >>>>> So the question is, do we need to have a deprecation period on what is currently there? >>>>> >>>>> The v1 of the chrome pushMessaging api has become legacy and it is recommended to use the new stuff. https://developer.chrome.com/apps/cloudMessagingV1 >>>>> >>>>> While i have looked to deeply, it?s possible we can use the same ?Variant? structure for Chrome Apps, Since they will be using the same Network >>>>> >>>>> wdyt? >>>>> >>>>> -Luke >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140903/595d2262/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 3926 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140903/595d2262/attachment.png From daniel.bevenius at gmail.com Thu Sep 4 02:05:12 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 4 Sep 2014 08:05:12 +0200 Subject: [aerogear-dev] Xcode6 beta7 is out... In-Reply-To: <9E732C9D-A6B9-4F49-9607-40D6A4F3BD16@gmail.com> References: <9E732C9D-A6B9-4F49-9607-40D6A4F3BD16@gmail.com> Message-ID: Cool, thanks for the heads up. On 3 September 2014 21:12, Corinne Krych wrote: > Hello Guys > > Xcode6 beta7 was out yesterday. > iOS8 is still beta5. > > Beta7 seems less of a change than others betas. Most changes are around > optionals. you can read apple release notes [1] or blog post [2] > > PRs on their ways. If you have beta7 installed, review build and run test > (for now Travis is not on Xcode6) when reviewing them. > > ++ > Corinne > [1] > http://adcdownload.apple.com//Developer_Tools/xcode_6_beta_7_apzr94/xcode_6__beta_7_release_notes.pdf > [2] > http://fortheloveoftech.com/2014/09/02/xcode-6-beta-7-is-available-with-a-swift-release-around-the-corner/ > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140904/2dc56782/attachment.html From daniel.bevenius at gmail.com Thu Sep 4 02:31:51 2014 From: daniel.bevenius at gmail.com (danielbevenius) Date: Wed, 3 Sep 2014 23:31:51 -0700 (PDT) Subject: [aerogear-dev] Suggestion for DataSync roadmap In-Reply-To: References: Message-ID: <1409812311337-9114.post@n5.nabble.com> Lukas and I talked yesterday and he brought up an issue that it is not as smooth as it could be to contribute to the roadmap. He instead suggested to have a shared docs which I'll later clean up and include in a pull request. The current version can be found here and is in raw asciidoc format: http://oksoclap.com/p/datasync_roadmap Let me know if this works out better. -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Suggestion-for-DataSync-roadmap-tp9006p9114.html Sent from the aerogear-dev mailing list archive at Nabble.com. From lukas.fryc at gmail.com Thu Sep 4 04:53:40 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Thu, 4 Sep 2014 10:53:40 +0200 Subject: [aerogear-dev] Suggestion for DataSync roadmap In-Reply-To: <1409812311337-9114.post@n5.nabble.com> References: <1409812311337-9114.post@n5.nabble.com> Message-ID: Yea, I rather meant if we are in brainstorming phase e.g. with Sync spec, I see a fit for rather collaborative solution, but I was mistaken with suggesting oksoclap, because it does not offer that level of interactivity as well. :-) What I meant is sharing a document such as Data Sync Spec on collaborative editor where: * you can suggest additions / modifications * you can comment * comments can be resolved once resolved * that document is owned and maintained by group of people such as Google Docs: https://docs.google.com/document/d/1hOsAN5og6dz07-k66ooaGbJ5KrnWJWRyHRelwyjf6bk/edit?usp=sharing But I don't see a point into bringing other technology if it should not help us be more productive, so tell me if I'm mistaken! Cheers, ~ Lukas On Thu, Sep 4, 2014 at 8:31 AM, danielbevenius wrote: > Lukas and I talked yesterday and he brought up an issue that it is not as > smooth as it could be to contribute to the roadmap. He instead suggested to > have a shared docs which I'll later clean up and include in a pull request. > > The current version can be found here and is in raw asciidoc format: > http://oksoclap.com/p/datasync_roadmap > > Let me know if this works out better. > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Suggestion-for-DataSync-roadmap-tp9006p9114.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140904/6eb603a8/attachment-0001.html From daniel.bevenius at gmail.com Thu Sep 4 05:00:05 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 4 Sep 2014 11:00:05 +0200 Subject: [aerogear-dev] Suggestion for DataSync roadmap In-Reply-To: References: <1409812311337-9114.post@n5.nabble.com> Message-ID: I fine with Google docs or anything else. On 4 September 2014 10:53, Luk?? Fry? wrote: > Yea, I rather meant if we are in brainstorming phase e.g. with Sync spec, > I see a fit for rather collaborative solution, > > but I was mistaken with suggesting oksoclap, because it does not offer > that level of interactivity as well. :-) > > > What I meant is sharing a document such as Data Sync Spec on collaborative > editor where: > > * you can suggest additions / modifications > * you can comment > * comments can be resolved once resolved > * that document is owned and maintained by group of people > > such as Google Docs: > https://docs.google.com/document/d/1hOsAN5og6dz07-k66ooaGbJ5KrnWJWRyHRelwyjf6bk/edit?usp=sharing > > > But I don't see a point into bringing other technology if it should not > help us be more productive, so tell me if I'm mistaken! > > > Cheers, > > ~ Lukas > > > > > On Thu, Sep 4, 2014 at 8:31 AM, danielbevenius > wrote: > >> Lukas and I talked yesterday and he brought up an issue that it is not as >> smooth as it could be to contribute to the roadmap. He instead suggested >> to >> have a shared docs which I'll later clean up and include in a pull >> request. >> >> The current version can be found here and is in raw asciidoc format: >> http://oksoclap.com/p/datasync_roadmap >> >> Let me know if this works out better. >> >> >> >> -- >> View this message in context: >> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Suggestion-for-DataSync-roadmap-tp9006p9114.html >> Sent from the aerogear-dev mailing list archive at Nabble.com. >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140904/d6490516/attachment.html From bruno at abstractj.org Thu Sep 4 09:28:47 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 4 Sep 2014 10:28:47 -0300 Subject: [aerogear-dev] UPS Release 1.0.1 - planning Message-ID: <20140904132847.GA67024@abstractj.org> Good morning, Today we have the remaining Jiras for 1.0.1 (https://issues.jboss.org/issues/?jql=fixVersion%20%3D%201.0.1%20AND%20project%20%3D%20AGPUSH%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC). After a hangout with Luk?? and Sebastien we agreed that it's doable to do the code freezing by Wednesday (Set, 10) and immediately stage the release for testing. I will be on PTO on 15th September. So please, be nice and help Sebastien with testing and fixing bugs if necessary. Thoughts or tomatoes? -- abstractj PGP: 0x84DC9914 From daniel.bevenius at gmail.com Thu Sep 4 09:34:04 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 4 Sep 2014 15:34:04 +0200 Subject: [aerogear-dev] UPS Release 1.0.1 - planning In-Reply-To: <20140904132847.GA67024@abstractj.org> References: <20140904132847.GA67024@abstractj.org> Message-ID: Sounds good to me! On 4 September 2014 15:28, Bruno Oliveira wrote: > Good morning, > > Today we have the remaining Jiras for 1.0.1 > ( > https://issues.jboss.org/issues/?jql=fixVersion%20%3D%201.0.1%20AND%20project%20%3D%20AGPUSH%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC > ). > After a hangout with Luk?? and Sebastien we agreed that it's doable to > do the code freezing by Wednesday (Set, 10) and immediately stage the > release for testing. > > I will be on PTO on 15th September. So please, be nice and help > Sebastien with testing and fixing bugs if necessary. > > Thoughts or tomatoes? > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140904/b8e1615e/attachment.html From matzew at apache.org Thu Sep 4 09:47:37 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 4 Sep 2014 15:47:37 +0200 Subject: [aerogear-dev] UPS Release 1.0.1 - planning In-Reply-To: References: <20140904132847.GA67024@abstractj.org> Message-ID: Sounds good ?? On Thursday, September 4, 2014, Daniel Bevenius wrote: > Sounds good to me! > > > > On 4 September 2014 15:28, Bruno Oliveira > wrote: > >> Good morning, >> >> Today we have the remaining Jiras for 1.0.1 >> ( >> https://issues.jboss.org/issues/?jql=fixVersion%20%3D%201.0.1%20AND%20project%20%3D%20AGPUSH%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC >> ). >> After a hangout with Luk?? and Sebastien we agreed that it's doable to >> do the code freezing by Wednesday (Set, 10) and immediately stage the >> release for testing. >> >> I will be on PTO on 15th September. So please, be nice and help >> Sebastien with testing and fixing bugs if necessary. >> >> Thoughts or tomatoes? >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140904/cb2dc5ec/attachment.html From hagai.sela at gmail.com Thu Sep 4 06:24:21 2014 From: hagai.sela at gmail.com (hagai.sela) Date: Thu, 4 Sep 2014 03:24:21 -0700 (PDT) Subject: [aerogear-dev] errors in cordova / android app Message-ID: <1409826261155-9117.post@n5.nabble.com> Hi, I am trying to use aerogear to send push notifications to cordova application which runs on my android device. I followed this tutorial: http://aerogear.org/docs/guides/aerogear-push-cordova-android/cordova-android-app/ When my app loads in the device I am getting this error: Could not find method com.google.android.gms.gcm.GoogleCloudMessaging.getInstance, referenced from method org.jboss.aerogear.android.impl.unifiedpush.AeroGearGCMPushRegistrar$2.get Help, please. This is the complete log file: 09-04 12:45:09.724: I/dalvikvm(14690): Debugger is active 09-04 12:45:09.884: I/System.out(14690): Debugger has connected 09-04 12:45:09.884: I/System.out(14690): waiting for debugger to settle... 09-04 12:45:10.084: I/System.out(14690): waiting for debugger to settle... 09-04 12:45:10.284: I/System.out(14690): waiting for debugger to settle... 09-04 12:45:10.484: I/System.out(14690): waiting for debugger to settle... 09-04 12:45:10.684: I/System.out(14690): waiting for debugger to settle... 09-04 12:45:10.884: I/System.out(14690): waiting for debugger to settle... 09-04 12:45:11.084: I/System.out(14690): waiting for debugger to settle... 09-04 12:45:11.284: I/System.out(14690): waiting for debugger to settle... 09-04 12:45:11.484: I/System.out(14690): waiting for debugger to settle... 09-04 12:45:11.684: I/System.out(14690): waiting for debugger to settle... 09-04 12:45:11.884: I/System.out(14690): debugger has settled (1310) 09-04 12:45:11.914: I/CordovaLog(14690): Changing log level to DEBUG(3) 09-04 12:45:11.914: I/CordovaLog(14690): Found start page location: index.html 09-04 12:45:11.914: D/Whitelist(14690): Unlimited access to network resources 09-04 12:45:11.914: D/CordovaActivity(14690): CordovaActivity.onCreate() 09-04 12:45:11.924: V/WebViewChromium(14690): Binding Chromium to the background looper Looper (main, tid 1) {42832650} 09-04 12:45:11.934: I/chromium(14690): [INFO:library_loader_hooks.cc(112)] Chromium logging enabled: level = 0, default verbosity = 0 09-04 12:45:11.934: I/BrowserProcessMain(14690): Initializing chromium process, renderers=0 09-04 12:45:11.944: W/chromium(14690): [WARNING:proxy_service.cc(888)] PAC support disabled because there is no system implementation 09-04 12:45:11.954: I/Adreno-EGL(14690): : EGL 1.4 QUALCOMM build: () 09-04 12:45:11.954: I/Adreno-EGL(14690): OpenGL ES Shader Compiler Version: E031.24.00.02 09-04 12:45:11.954: I/Adreno-EGL(14690): Build Date: 01/20/14 Mon 09-04 12:45:11.954: I/Adreno-EGL(14690): Local Branch: PMH2-KK_3.5-RB1-AU61-554722-586267-set2 09-04 12:45:11.954: I/Adreno-EGL(14690): Remote Branch: 09-04 12:45:11.954: I/Adreno-EGL(14690): Local Patches: 09-04 12:45:11.954: I/Adreno-EGL(14690): Reconstruct Branch: 09-04 12:45:12.024: D/CordovaWebView(14690): CordovaWebView is running on device made by: LGE 09-04 12:45:12.034: D/JsMessageQueue(14690): Set native->JS mode to 2 09-04 12:45:12.034: D/CordovaActivity(14690): CordovaActivity.init() 09-04 12:45:12.054: D/CordovaWebView(14690): >>> loadUrl(file:///android_asset/www/index.html) 09-04 12:45:12.054: D/PluginManager(14690): init() 09-04 12:45:12.064: D/CordovaWebView(14690): >>> loadUrlNow() 09-04 12:45:12.064: D/dalvikvm(14690): Note: class Lcom/lge/mdm/manager/ILGMDMDevicePolicyManager$Stub; has 319 unimplemented (abstract) methods 09-04 12:45:12.094: I/CordovaLog(14690): Changing log level to DEBUG(3) 09-04 12:45:12.104: I/CordovaLog(14690): Found start page location: index.html 09-04 12:45:12.104: D/Whitelist(14690): Unlimited access to network resources 09-04 12:45:12.104: D/CordovaActivity(14690): Resuming the App 09-04 12:45:12.104: D/CordovaActivity(14690): CB-3064: The errorUrl is null 09-04 12:45:12.104: W/BaseRuntimeLoader(14690): don't searchcom.lge.telephony.msim.QcomMSimTelephonyManagerAdaptor class 09-04 12:45:12.124: W/BaseRuntimeLoader(14690): don't searchcom.lge.telephony.msim.MtkMSimTelephonyManagerAdaptor class 09-04 12:45:12.124: W/BaseRuntimeLoader(14690): don't searchcom.lge.telephony.msim.QcomMSimTelephonyManagerAdaptor class 09-04 12:45:12.124: W/BaseRuntimeLoader(14690): don't searchcom.lge.telephony.msim.MtkMSimTelephonyManagerAdaptor class 09-04 12:45:12.134: D/CordovaActivity(14690): Paused the application! 09-04 12:45:12.134: D/CordovaWebView(14690): Handle the pause 09-04 12:45:12.194: D/OpenGLRenderer(14690): Enabling debug mode 0 09-04 12:45:12.214: D/OpenGLRenderer(14690): GL error from OpenGLRenderer: 0x502 09-04 12:45:12.214: E/OpenGLRenderer(14690): GL_INVALID_OPERATION 09-04 12:45:12.234: I/ActivityManager(14690): Timeline: Activity_idle id: android.os.BinderProxy at 42834218 time:6453809 09-04 12:45:12.244: D/CordovaWebViewClient(14690): onPageStarted(file:///android_asset/www/index.html) 09-04 12:45:12.244: D/CordovaActivity(14690): onMessage(onPageStarted,file:///android_asset/www/index.html) 09-04 12:45:12.294: D/CordovaLog(14690): : Line 1 : exception firing pause event from native 09-04 12:45:12.294: I/chromium(14690): [INFO:CONSOLE(1)] "exception firing pause event from native", source: (1) 09-04 12:45:12.314: D/CordovaLog(14690): file:///android_asset/www/index.html: Line 25 : Viewport target-densitydpi is not supported. 09-04 12:45:12.314: I/chromium(14690): [INFO:CONSOLE(25)] "Viewport target-densitydpi is not supported.", source: file:///android_asset/www/index.html (25) 09-04 12:45:12.424: D/CordovaWebViewClient(14690): onPageFinished(file:///android_asset/www/index.html) 09-04 12:45:12.424: D/CordovaActivity(14690): onMessage(onPageFinished,file:///android_asset/www/index.html) 09-04 12:45:12.464: D/CordovaActivity(14690): onMessage(spinner,stop) 09-04 12:45:12.484: D/CordovaLog(14690): file:///android_asset/www/js/index.js: Line 71 : Received Event: deviceready 09-04 12:45:12.484: I/chromium(14690): [INFO:CONSOLE(71)] "Received Event: deviceready", source: file:///android_asset/www/js/index.js (71) 09-04 12:45:12.484: V/PushPlugin(14690): execute: action=register 09-04 12:45:12.494: V/PushPlugin(14690): execute: data=[{"android":{"variantSecret":"e69404ed-e23b-4cff-9476-63f3ce242e35","senderID":"406666539484","variantID":"6d3153b7-f64f-47ad-b7fb-d0310532d57f"},"pushServerURL":"http:\/\/192.168.10.27:8080\/ag-push\/"}] 09-04 12:45:12.534: I/dalvikvm(14690): Could not find method com.google.android.gms.gcm.GoogleCloudMessaging.getInstance, referenced from method org.jboss.aerogear.android.impl.unifiedpush.AeroGearGCMPushRegistrar$2.get 09-04 12:45:12.534: W/dalvikvm(14690): VFY: unable to resolve static method 5245: Lcom/google/android/gms/gcm/GoogleCloudMessaging;.getInstance (Landroid/content/Context;)Lcom/google/android/gms/gcm/GoogleCloudMessaging; 09-04 12:45:12.534: D/dalvikvm(14690): VFY: replacing opcode 0x71 at 0x0005 09-04 12:45:12.534: W/dalvikvm(14690): VFY: unable to find class referenced in signature (Lcom/google/android/gms/gcm/GoogleCloudMessaging;) 09-04 12:45:12.544: W/dalvikvm(14690): VFY: unable to find class referenced in signature (Lcom/google/android/gms/gcm/GoogleCloudMessaging;) 09-04 12:45:12.544: E/dalvikvm(14690): Could not find class 'com.google.android.gms.gcm.GoogleCloudMessaging', referenced from method org.jboss.aerogear.android.impl.unifiedpush.AeroGearGCMPushRegistrar$3.doInBackground 09-04 12:45:12.544: W/dalvikvm(14690): VFY: unable to resolve check-cast 766 (Lcom/google/android/gms/gcm/GoogleCloudMessaging;) in Lorg/jboss/aerogear/android/impl/unifiedpush/AeroGearGCMPushRegistrar$3; 09-04 12:45:12.544: D/dalvikvm(14690): VFY: replacing opcode 0x1f at 0x001c 09-04 12:45:12.554: W/dalvikvm(14690): VFY: unable to find class referenced in signature (Lcom/google/android/gms/gcm/GoogleCloudMessaging;) 09-04 12:45:12.554: I/dalvikvm(14690): Could not find method com.google.android.gms.gcm.GoogleCloudMessaging.register, referenced from method org.jboss.aerogear.android.impl.unifiedpush.AeroGearGCMPushRegistrar$3.doInBackground 09-04 12:45:12.554: W/dalvikvm(14690): VFY: unable to resolve virtual method 5247: Lcom/google/android/gms/gcm/GoogleCloudMessaging;.register ([Ljava/lang/String;)Ljava/lang/String; 09-04 12:45:12.554: D/dalvikvm(14690): VFY: replacing opcode 0x6e at 0x0046 09-04 12:45:14.424: D/CordovaActivity(14690): onMessage(spinner,stop) 09-04 12:45:29.854: W/dalvikvm(14690): threadid=23: thread exiting with uncaught exception (group=0x417f0e48) 09-04 12:45:29.884: E/AndroidRuntime(14690): FATAL EXCEPTION: AsyncTask #1 09-04 12:45:29.884: E/AndroidRuntime(14690): Process: com.speakez.userapp, PID: 14690 09-04 12:45:29.884: E/AndroidRuntime(14690): java.lang.RuntimeException: An error occured while executing doInBackground() 09-04 12:45:29.884: E/AndroidRuntime(14690): at android.os.AsyncTask$3.done(AsyncTask.java:300) 09-04 12:45:29.884: E/AndroidRuntime(14690): at java.util.concurrent.FutureTask.finishCompletion(FutureTask.java:355) 09-04 12:45:29.884: E/AndroidRuntime(14690): at java.util.concurrent.FutureTask.setException(FutureTask.java:222) 09-04 12:45:29.884: E/AndroidRuntime(14690): at java.util.concurrent.FutureTask.run(FutureTask.java:242) 09-04 12:45:29.884: E/AndroidRuntime(14690): at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:231) 09-04 12:45:29.884: E/AndroidRuntime(14690): at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112) 09-04 12:45:29.884: E/AndroidRuntime(14690): at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587) 09-04 12:45:29.884: E/AndroidRuntime(14690): at java.lang.Thread.run(Thread.java:841) 09-04 12:45:29.884: E/AndroidRuntime(14690): Caused by: java.lang.NoClassDefFoundError: com.google.android.gms.gcm.GoogleCloudMessaging 09-04 12:45:29.884: E/AndroidRuntime(14690): at org.jboss.aerogear.android.impl.unifiedpush.AeroGearGCMPushRegistrar$2.get(AeroGearGCMPushRegistrar.java:76) 09-04 12:45:29.884: E/AndroidRuntime(14690): at org.jboss.aerogear.android.impl.unifiedpush.AeroGearGCMPushRegistrar$2.get(AeroGearGCMPushRegistrar.java:72) 09-04 12:45:29.884: E/AndroidRuntime(14690): at org.jboss.aerogear.android.impl.unifiedpush.AeroGearGCMPushRegistrar$3.doInBackground(AeroGearGCMPushRegistrar.java:95) 09-04 12:45:29.884: E/AndroidRuntime(14690): at org.jboss.aerogear.android.impl.unifiedpush.AeroGearGCMPushRegistrar$3.doInBackground(AeroGearGCMPushRegistrar.java:87) 09-04 12:45:29.884: E/AndroidRuntime(14690): at android.os.AsyncTask$2.call(AsyncTask.java:288) 09-04 12:45:29.884: E/AndroidRuntime(14690): at java.util.concurrent.FutureTask.run(FutureTask.java:237) 09-04 12:45:29.884: E/AndroidRuntime(14690): ... 4 more 09-04 12:45:29.924: I/Process(14690): Sending signal. PID: 14690 SIG: 9 -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/errors-in-cordova-android-app-tp9117.html Sent from the aerogear-dev mailing list archive at Nabble.com. From lukas.fryc at gmail.com Thu Sep 4 10:02:02 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Thu, 4 Sep 2014 16:02:02 +0200 Subject: [aerogear-dev] UPS Release 1.0.1 - planning In-Reply-To: References: <20140904132847.GA67024@abstractj.org> Message-ID: Yep, Wednesday it fine. On Thu, Sep 4, 2014 at 3:47 PM, Matthias Wessendorf wrote: > Sounds good ?? > > > On Thursday, September 4, 2014, Daniel Bevenius > wrote: > >> Sounds good to me! >> >> >> >> On 4 September 2014 15:28, Bruno Oliveira wrote: >> >>> Good morning, >>> >>> Today we have the remaining Jiras for 1.0.1 >>> ( >>> https://issues.jboss.org/issues/?jql=fixVersion%20%3D%201.0.1%20AND%20project%20%3D%20AGPUSH%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC >>> ). >>> After a hangout with Luk?? and Sebastien we agreed that it's doable to >>> do the code freezing by Wednesday (Set, 10) and immediately stage the >>> release for testing. >>> >>> I will be on PTO on 15th September. So please, be nice and help >>> Sebastien with testing and fixing bugs if necessary. >>> >>> Thoughts or tomatoes? >>> >>> -- >>> >>> abstractj >>> PGP: 0x84DC9914 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> > > -- > Sent from Gmail Mobile > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140904/0e9bfafb/attachment.html From gorkem.ercan at gmail.com Thu Sep 4 11:05:13 2014 From: gorkem.ercan at gmail.com (Gorkem Ercan) Date: Thu, 4 Sep 2014 11:05:13 -0400 Subject: [aerogear-dev] Should Cordova push plugin dependencies be shrinkwrapped? Message-ID: Hi All, I have been working cordova push quickstarts and noticed that on Android installation through JBoss tools started to fail. After a bit of investigation I figured that the failure occurs because push plugin defines cordova plugin "com.google.playservices" as a dependency through a git URL[1] that points to the master of the plugin's repo. Unfortunately this repo received a change [2] which started to use a new feature that was not implemented for JBoss tools. In this particular case, I am already implementing the missing feature so it should be all good soon. However I have doubts that referencing a dependency through master is a good idea. I think it may not only make it really difficult for us to reproduce cases but also unexpected behaviour may just appear. [1] https://github.com/MobileChromeApps/google-play-services [2] https://github.com/MobileChromeApps/google-play-services/commit/41c19152c21981c9a2f6497cc2100c317f5c660d -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140904/8eebb56b/attachment.html From lukas.fryc at gmail.com Thu Sep 4 11:38:03 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Thu, 4 Sep 2014 17:38:03 +0200 Subject: [aerogear-dev] Differential Synchronization: Shadow/Backup Revision Control and its Garbage Collection Message-ID: Hey guys, TL;DR: there are ways how to make the memory footprint of Differential Synchronization (DS) very low; if we assume that JSON patches are reversible and we create cumulative patches from series of individual patches, we can use (smart, garbage-collactable) revision control for storage of documents that server need to maintain. ---- I had an idea in my head that for couple of days as I was becoming familiar with how Differential Synchronization (DS) works and studying Dan's and Luke's impl. I share the concern that Randall expressed in earlier thread - the DS in its pure version doesn't scale for huge amount of users when connected to one server. Sure, the algorithm can be scaled trivially by adding new nodes that uses very same algorithm as is used for client<->server. But that doesn't mean it is something that we should do regularly to get more memory available. Instead, I was thinking about limiting a memory that server needs to maintain in any point in time. In pure DS, server have to maintain all copies of documents that clients ever requested. Even worse, it has to maintain two copies - "shadow" and "backup", So, in worst case, 2 x N copies of document will be maintained by the server for N clients. ----- The DS algorithm doesn't tell us how the "shadow" and "backup" documents should be stored. We can transparently plug in a storage that will be clever about how to use "backups" and "shadow". ----- CONCEPTS: 1) REVISION CONTROL In order to limit a number of documents we need to maintain in server's memory, we can come with a system where just last known state is remembered in full version. Together with last known version, we remember also history of the document for each revision as it was patched by clients. But server doesn't have to maintain full history of the document, it maintains just revisions that are known to its clients (that revision is known by DS for each client out of the box). 2) GARBAGE COLLECTION Server trivially knows what versions are mantained by client, so it can get rid of those revisions that are no longer needed. First, it can cut all the history that is older than the oldest version of document throughout all its clients. Secondly, it can accumulate the serious of patches between states so that it doesn't have to maintain full history, but just revisions that is known to any of those clients. ---- DIAGRAM: I've attached a picture for illustration of the revision control / garbage collection, it does not illustrate algorithm itself (Dan did awesome job describing DS here [3]). In the attached diagram, you can see four clients with different revisions: Client 1: revision X Client 2: revision X+3 Client 3: revision X+3 Client 4: revision X+4 If any of the clients reaches server, server can reconstruct the document (shadow and backup) for given client revision and the DS algorithm then can operate as normally (that's why it is transparent from algorithmic point of view). If server comes to garbage collection, it can scan through available client revisions. As it identifies, that the oldest known revision is X, it can remove patch for X-1 and less as they are no longer needed. Later, it can even more optimize, and accumulate patches so that the only information he knows is how to get to the revision for each participating client. In the picture, he can compute cumulative patch for getting from state X to state X+3, as X+1 and X+2 themselves are not needed. (Patch accumulation is actually something that Google Wave does in its Operational Transformation implementation, just there it is called cumulative Operations). ---- Then it comes to caching strategies, you can maintain caches of things like last recently used revisions (they don't need to be computed each time). You can store some documents and their revision history to the disk (fully or partially), etc. ---- THE USE CASE: 1000 employees maintain one document - Contact List - on their smartphones 400 of those employees has mobile data plan, so they want to synchronize almost immediately as they are notified about changes. The rest of the devices is connected rather sparely. If one employee changes data, 600 devices are notified about the change immediately (some on data plan, some through Wifi, etc.) Those clients all have version say X+3, because they are synchronized proactively. These clients reach the server in say <10 seconds after that employee did the change. First client reaches server and ask for version X+3 (it probably is still in the memory, but if it isn't, it is deconstructed and placed into MRU cache). All of the others reaches the server and re-synchronize themselves against the one copy of backup/shadow that is in the memory already. The other clients will reach the server later, as they are connecting to Wifi, say in 5 minutes to 24 hours. They will have even older versions, such as X. Those clients will require more computation, but at the end the server can resolve them and through their revisions out of the window. At the end, there are clients that didn't connected for days, maybe months - I suggest we don't actually use DS here and fallback to e.g. slow synchronization (show me what you have, I will show you mine), because maintaining full history for longer period of days may be too resource demanding (configurable?). Obviously, 1000 is not much, but this can scale to pretty decent numbers if we use hybrid approach (fallback to other sync strategies if revision is already forgotten by a server). ---- WORST CASE: we still have to maintain all the document revisions, but practically it won't happen :-) ---- ASSUMPTIONS: 1. patches are reversible (we are able to compute reverse patch for each patch sent by client) 2. patches are cumulative (we are able to compute aggregated patch from series of patches) For 1, it seems many of JSON-patch libraries actually implement it (Java, JavaScript) [1, 2] For 2, it again seems some libraries implement it and if not, we can implement it or even use brute-force - compute a patch between two documents ---- It's not the only way how to make it scale, but it does solve the problem pretty independently of the DS algorithm and still leaves the algorithm clean and simple. Cheers, ~ Lukas [1] https://github.com/fge/json-patch [2] https://github.com/benjamine/jsondiffpatch -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140904/d118ee2c/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: DS-revision-control.png Type: image/png Size: 75399 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140904/d118ee2c/attachment-0001.png From lukas.fryc at gmail.com Thu Sep 4 12:33:39 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Thu, 4 Sep 2014 18:33:39 +0200 Subject: [aerogear-dev] Should Cordova push plugin dependencies be shrinkwrapped? In-Reply-To: References: Message-ID: +1 it should definitely point to the specific version On Thu, Sep 4, 2014 at 5:05 PM, Gorkem Ercan wrote: > Hi All, > I have been working cordova push quickstarts and noticed that on Android > installation through JBoss tools started to fail. > > After a bit of investigation I figured that the failure occurs because > push plugin defines cordova plugin "com.google.playservices" as a > dependency through a git URL[1] that points to the master of the plugin's > repo. Unfortunately this repo received a change [2] which started to use a > new feature that was not implemented for JBoss tools. In this particular > case, I am already implementing the missing feature so it should be all > good soon. However I have doubts that referencing a dependency through > master is a good idea. I think it may not only make it really difficult for > us to reproduce cases but also unexpected behaviour may just appear. > > > [1] https://github.com/MobileChromeApps/google-play-services > [2] > https://github.com/MobileChromeApps/google-play-services/commit/41c19152c21981c9a2f6497cc2100c317f5c660d > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140904/6b4c4777/attachment.html From john.manko at gmail.com Thu Sep 4 19:00:16 2014 From: john.manko at gmail.com (John Manko) Date: Thu, 4 Sep 2014 19:00:16 -0400 Subject: [aerogear-dev] Maven repo config in pom.xml Message-ID: I added the repo and plugin config to my pom, but I still can't find the aerogear artifacts. For org.jboss.aerogear:aerogear-android-push, only v0.2 and v0.1 are found, not v1.0. Also, getting Failed to execute goal on project blah: Could not resolve dependencies for project .... Failed to collect dependencies for [org.jboss.aerogear:aerogear-android:jar:1.4.0 (compile), org.jboss.aerogear:aerogear-security:jar:1.3.1 (compile), org.jboss.aerogear:aerogear-security-picketlink:jar:1.3.1 (compile), com.google.android:support-v4:jar:r7 (compile), javax:javaee-web-api:jar:6.0 (provided)]: No versions available for android.support:compatibility-v4:jar:[18,) within specified range -> [Help 1] I'm running in Netbeans 8, btw. Is Eclipse a requirement due to IDE plugin support? jboss-public-repository-group JBoss Public Maven Repository Group https://repository.jboss.org/nexus/content/groups/public-jboss/ default true never true never jboss-public-repository-group JBoss Public Maven Repository Group https://repository.jboss.org/nexus/content/groups/public-jboss/ default true never true never -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140904/84614419/attachment.html From john.manko at gmail.com Thu Sep 4 20:38:31 2014 From: john.manko at gmail.com (John Manko) Date: Thu, 4 Sep 2014 20:38:31 -0400 Subject: [aerogear-dev] Maven repo config in pom.xml In-Reply-To: References: Message-ID: You know, I really appreciate the work you guys are doing, but the documentation is horrible for new adopters. Something needs to be done. On Thu, Sep 4, 2014 at 7:00 PM, John Manko wrote: > I added the repo and plugin config to my pom, but I still can't find the > aerogear artifacts. > > For org.jboss.aerogear:aerogear-android-push, only v0.2 and v0.1 are > found, not v1.0. > > Also, getting Failed to execute goal on project blah: Could not resolve > dependencies for project .... Failed to collect dependencies for > [org.jboss.aerogear:aerogear-android:jar:1.4.0 (compile), > org.jboss.aerogear:aerogear-security:jar:1.3.1 (compile), > org.jboss.aerogear:aerogear-security-picketlink:jar:1.3.1 (compile), > com.google.android:support-v4:jar:r7 (compile), > javax:javaee-web-api:jar:6.0 (provided)]: No versions available for > android.support:compatibility-v4:jar:[18,) within specified range -> [Help > 1] > > I'm running in Netbeans 8, btw. Is Eclipse a requirement due to IDE > plugin support? > > > > jboss-public-repository-group > JBoss Public Maven Repository Group > > https://repository.jboss.org/nexus/content/groups/public-jboss/ > default > > true > never > > > true > never > > > > > > jboss-public-repository-group > JBoss Public Maven Repository Group > > https://repository.jboss.org/nexus/content/groups/public-jboss/ > default > > true > never > > > true > never > > > > > > -- ?If the American people ever allow private banks to control the issue of their currency, first by inflation, then by deflation, the banks...will deprive the people of all property until their children wake-up homeless on the continent their fathers conquered... The issuing power should be taken from the banks and restored to the people, to whom it properly belongs." -- Thomas Jefferson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140904/df1816f7/attachment.html From scm.blanc at gmail.com Fri Sep 5 02:07:53 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 5 Sep 2014 08:07:53 +0200 Subject: [aerogear-dev] Maven repo config in pom.xml In-Reply-To: References: Message-ID: On Fri, Sep 5, 2014 at 1:00 AM, John Manko wrote: > I added the repo and plugin config to my pom, but I still can't find the > aerogear artifacts. > > For org.jboss.aerogear:aerogear-android-push, only v0.2 and v0.1 are > found, not v1.0. > I can see 1.0 on Maven Central http://search.maven.org/#artifactdetails%7Corg.jboss.aerogear%7Caerogear-android-push%7C1.0.0%7Capklib So you don't even need the jboss repos. Please check you have the right dep in your POM : org.jboss.aerogear aerogear-android-push 1.0.0 > Also, getting Failed to execute goal on project blah: Could not resolve > dependencies for project .... Failed to collect dependencies for > [org.jboss.aerogear:aerogear-android:jar:1.4.0 (compile), > org.jboss.aerogear:aerogear-security:jar:1.3.1 (compile), > org.jboss.aerogear:aerogear-security-picketlink:jar:1.3.1 (compile), > com.google.android:support-v4:jar:r7 (compile), > javax:javaee-web-api:jar:6.0 (provided)]: No versions available for > android.support:compatibility-v4:jar:[18,) within specified range -> [Help > 1] > This should be gone if you are on 1.0 , BTW have you followed this guide ? http://aerogear.org/docs/guides/aerogear-android/how-to-build-aerogear-android/ > > I'm running in Netbeans 8, btw. Is Eclipse a requirement due to IDE > plugin support? > No, aerogear-android is IDE agnostic. > > > > jboss-public-repository-group > JBoss Public Maven Repository Group > > https://repository.jboss.org/nexus/content/groups/public-jboss/ > default > > true > never > > > true > never > > > > > > jboss-public-repository-group > JBoss Public Maven Repository Group > > https://repository.jboss.org/nexus/content/groups/public-jboss/ > default > > true > never > > > true > never > > > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140905/8c77be6e/attachment-0001.html From edewit at redhat.com Fri Sep 5 03:00:53 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Fri, 5 Sep 2014 09:00:53 +0200 Subject: [aerogear-dev] Should Cordova push plugin dependencies be shrinkwrapped? In-Reply-To: References: Message-ID: Fully agree, problem is these repos don?t have any tag or releases. Maybe we should not use them. On 4 Sep,2014, at 17:05 , Gorkem Ercan wrote: > Hi All, > I have been working cordova push quickstarts and noticed that on Android installation through JBoss tools started to fail. > > After a bit of investigation I figured that the failure occurs because push plugin defines cordova plugin "com.google.playservices" as a dependency through a git URL[1] that points to the master of the plugin's repo. Unfortunately this repo received a change [2] which started to use a new feature that was not implemented for JBoss tools. In this particular case, I am already implementing the missing feature so it should be all good soon. However I have doubts that referencing a dependency through master is a good idea. I think it may not only make it really difficult for us to reproduce cases but also unexpected behaviour may just appear. > > > [1] https://github.com/MobileChromeApps/google-play-services > [2] https://github.com/MobileChromeApps/google-play-services/commit/41c19152c21981c9a2f6497cc2100c317f5c660d > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140905/7ca95501/attachment.html From edewit at redhat.com Fri Sep 5 03:25:55 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Fri, 5 Sep 2014 09:25:55 +0200 Subject: [aerogear-dev] errors in cordova / android app In-Reply-To: <1409826261155-9117.post@n5.nabble.com> References: <1409826261155-9117.post@n5.nabble.com> Message-ID: <02A6F6A8-AB6E-4138-9778-80EABF84B9A5@redhat.com> Hi, Seems like a problem with the google play libs, what device are you installing it on? Do you have a google account setup on it? Cheers, Erik Jan On 4 Sep,2014, at 12:24 , hagai.sela wrote: > Hi, > I am trying to use aerogear to send push notifications to cordova > application which runs on my android device. > I followed this tutorial: > http://aerogear.org/docs/guides/aerogear-push-cordova-android/cordova-android-app/ > When my app loads in the device I am getting this error: > > Could not find method > com.google.android.gms.gcm.GoogleCloudMessaging.getInstance, referenced from > method > org.jboss.aerogear.android.impl.unifiedpush.AeroGearGCMPushRegistrar$2.get > > Help, please. This is the complete log file: > > 09-04 12:45:09.724: I/dalvikvm(14690): Debugger is active > 09-04 12:45:09.884: I/System.out(14690): Debugger has connected > 09-04 12:45:09.884: I/System.out(14690): waiting for debugger to settle... > 09-04 12:45:10.084: I/System.out(14690): waiting for debugger to settle... > 09-04 12:45:10.284: I/System.out(14690): waiting for debugger to settle... > 09-04 12:45:10.484: I/System.out(14690): waiting for debugger to settle... > 09-04 12:45:10.684: I/System.out(14690): waiting for debugger to settle... > 09-04 12:45:10.884: I/System.out(14690): waiting for debugger to settle... > 09-04 12:45:11.084: I/System.out(14690): waiting for debugger to settle... > 09-04 12:45:11.284: I/System.out(14690): waiting for debugger to settle... > 09-04 12:45:11.484: I/System.out(14690): waiting for debugger to settle... > 09-04 12:45:11.684: I/System.out(14690): waiting for debugger to settle... > 09-04 12:45:11.884: I/System.out(14690): debugger has settled (1310) > 09-04 12:45:11.914: I/CordovaLog(14690): Changing log level to DEBUG(3) > 09-04 12:45:11.914: I/CordovaLog(14690): Found start page location: > index.html > 09-04 12:45:11.914: D/Whitelist(14690): Unlimited access to network > resources > 09-04 12:45:11.914: D/CordovaActivity(14690): CordovaActivity.onCreate() > 09-04 12:45:11.924: V/WebViewChromium(14690): Binding Chromium to the > background looper Looper (main, tid 1) {42832650} > 09-04 12:45:11.934: I/chromium(14690): [INFO:library_loader_hooks.cc(112)] > Chromium logging enabled: level = 0, default verbosity = 0 > 09-04 12:45:11.934: I/BrowserProcessMain(14690): Initializing chromium > process, renderers=0 > 09-04 12:45:11.944: W/chromium(14690): [WARNING:proxy_service.cc(888)] PAC > support disabled because there is no system implementation > 09-04 12:45:11.954: I/Adreno-EGL(14690): : EGL > 1.4 QUALCOMM build: () > 09-04 12:45:11.954: I/Adreno-EGL(14690): OpenGL ES Shader Compiler Version: > E031.24.00.02 > 09-04 12:45:11.954: I/Adreno-EGL(14690): Build Date: 01/20/14 Mon > 09-04 12:45:11.954: I/Adreno-EGL(14690): Local Branch: > PMH2-KK_3.5-RB1-AU61-554722-586267-set2 > 09-04 12:45:11.954: I/Adreno-EGL(14690): Remote Branch: > 09-04 12:45:11.954: I/Adreno-EGL(14690): Local Patches: > 09-04 12:45:11.954: I/Adreno-EGL(14690): Reconstruct Branch: > 09-04 12:45:12.024: D/CordovaWebView(14690): CordovaWebView is running on > device made by: LGE > 09-04 12:45:12.034: D/JsMessageQueue(14690): Set native->JS mode to 2 > 09-04 12:45:12.034: D/CordovaActivity(14690): CordovaActivity.init() > 09-04 12:45:12.054: D/CordovaWebView(14690): >>> > loadUrl(file:///android_asset/www/index.html) > 09-04 12:45:12.054: D/PluginManager(14690): init() > 09-04 12:45:12.064: D/CordovaWebView(14690): >>> loadUrlNow() > 09-04 12:45:12.064: D/dalvikvm(14690): Note: class > Lcom/lge/mdm/manager/ILGMDMDevicePolicyManager$Stub; has 319 unimplemented > (abstract) methods > 09-04 12:45:12.094: I/CordovaLog(14690): Changing log level to DEBUG(3) > 09-04 12:45:12.104: I/CordovaLog(14690): Found start page location: > index.html > 09-04 12:45:12.104: D/Whitelist(14690): Unlimited access to network > resources > 09-04 12:45:12.104: D/CordovaActivity(14690): Resuming the App > 09-04 12:45:12.104: D/CordovaActivity(14690): CB-3064: The errorUrl is null > 09-04 12:45:12.104: W/BaseRuntimeLoader(14690): don't > searchcom.lge.telephony.msim.QcomMSimTelephonyManagerAdaptor class > 09-04 12:45:12.124: W/BaseRuntimeLoader(14690): don't > searchcom.lge.telephony.msim.MtkMSimTelephonyManagerAdaptor class > 09-04 12:45:12.124: W/BaseRuntimeLoader(14690): don't > searchcom.lge.telephony.msim.QcomMSimTelephonyManagerAdaptor class > 09-04 12:45:12.124: W/BaseRuntimeLoader(14690): don't > searchcom.lge.telephony.msim.MtkMSimTelephonyManagerAdaptor class > 09-04 12:45:12.134: D/CordovaActivity(14690): Paused the application! > 09-04 12:45:12.134: D/CordovaWebView(14690): Handle the pause > 09-04 12:45:12.194: D/OpenGLRenderer(14690): Enabling debug mode 0 > 09-04 12:45:12.214: D/OpenGLRenderer(14690): GL error from OpenGLRenderer: > 0x502 > 09-04 12:45:12.214: E/OpenGLRenderer(14690): GL_INVALID_OPERATION > 09-04 12:45:12.234: I/ActivityManager(14690): Timeline: Activity_idle id: > android.os.BinderProxy at 42834218 time:6453809 > 09-04 12:45:12.244: D/CordovaWebViewClient(14690): > onPageStarted(file:///android_asset/www/index.html) > 09-04 12:45:12.244: D/CordovaActivity(14690): > onMessage(onPageStarted,file:///android_asset/www/index.html) > 09-04 12:45:12.294: D/CordovaLog(14690): : Line 1 : exception firing pause > event from native > 09-04 12:45:12.294: I/chromium(14690): [INFO:CONSOLE(1)] "exception firing > pause event from native", source: (1) > 09-04 12:45:12.314: D/CordovaLog(14690): > file:///android_asset/www/index.html: Line 25 : Viewport target-densitydpi > is not supported. > 09-04 12:45:12.314: I/chromium(14690): [INFO:CONSOLE(25)] "Viewport > target-densitydpi is not supported.", source: > file:///android_asset/www/index.html (25) > 09-04 12:45:12.424: D/CordovaWebViewClient(14690): > onPageFinished(file:///android_asset/www/index.html) > 09-04 12:45:12.424: D/CordovaActivity(14690): > onMessage(onPageFinished,file:///android_asset/www/index.html) > 09-04 12:45:12.464: D/CordovaActivity(14690): onMessage(spinner,stop) > 09-04 12:45:12.484: D/CordovaLog(14690): > file:///android_asset/www/js/index.js: Line 71 : Received Event: deviceready > 09-04 12:45:12.484: I/chromium(14690): [INFO:CONSOLE(71)] "Received Event: > deviceready", source: file:///android_asset/www/js/index.js (71) > 09-04 12:45:12.484: V/PushPlugin(14690): execute: action=register > 09-04 12:45:12.494: V/PushPlugin(14690): execute: > data=[{"android":{"variantSecret":"e69404ed-e23b-4cff-9476-63f3ce242e35","senderID":"406666539484","variantID":"6d3153b7-f64f-47ad-b7fb-d0310532d57f"},"pushServerURL":"http:\/\/192.168.10.27:8080\/ag-push\/"}] > 09-04 12:45:12.534: I/dalvikvm(14690): Could not find method > com.google.android.gms.gcm.GoogleCloudMessaging.getInstance, referenced from > method > org.jboss.aerogear.android.impl.unifiedpush.AeroGearGCMPushRegistrar$2.get > 09-04 12:45:12.534: W/dalvikvm(14690): VFY: unable to resolve static method > 5245: Lcom/google/android/gms/gcm/GoogleCloudMessaging;.getInstance > (Landroid/content/Context;)Lcom/google/android/gms/gcm/GoogleCloudMessaging; > 09-04 12:45:12.534: D/dalvikvm(14690): VFY: replacing opcode 0x71 at 0x0005 > 09-04 12:45:12.534: W/dalvikvm(14690): VFY: unable to find class referenced > in signature (Lcom/google/android/gms/gcm/GoogleCloudMessaging;) > 09-04 12:45:12.544: W/dalvikvm(14690): VFY: unable to find class referenced > in signature (Lcom/google/android/gms/gcm/GoogleCloudMessaging;) > 09-04 12:45:12.544: E/dalvikvm(14690): Could not find class > 'com.google.android.gms.gcm.GoogleCloudMessaging', referenced from method > org.jboss.aerogear.android.impl.unifiedpush.AeroGearGCMPushRegistrar$3.doInBackground > 09-04 12:45:12.544: W/dalvikvm(14690): VFY: unable to resolve check-cast 766 > (Lcom/google/android/gms/gcm/GoogleCloudMessaging;) in > Lorg/jboss/aerogear/android/impl/unifiedpush/AeroGearGCMPushRegistrar$3; > 09-04 12:45:12.544: D/dalvikvm(14690): VFY: replacing opcode 0x1f at 0x001c > 09-04 12:45:12.554: W/dalvikvm(14690): VFY: unable to find class referenced > in signature (Lcom/google/android/gms/gcm/GoogleCloudMessaging;) > 09-04 12:45:12.554: I/dalvikvm(14690): Could not find method > com.google.android.gms.gcm.GoogleCloudMessaging.register, referenced from > method > org.jboss.aerogear.android.impl.unifiedpush.AeroGearGCMPushRegistrar$3.doInBackground > 09-04 12:45:12.554: W/dalvikvm(14690): VFY: unable to resolve virtual method > 5247: Lcom/google/android/gms/gcm/GoogleCloudMessaging;.register > ([Ljava/lang/String;)Ljava/lang/String; > 09-04 12:45:12.554: D/dalvikvm(14690): VFY: replacing opcode 0x6e at 0x0046 > 09-04 12:45:14.424: D/CordovaActivity(14690): onMessage(spinner,stop) > 09-04 12:45:29.854: W/dalvikvm(14690): threadid=23: thread exiting with > uncaught exception (group=0x417f0e48) > 09-04 12:45:29.884: E/AndroidRuntime(14690): FATAL EXCEPTION: AsyncTask #1 > 09-04 12:45:29.884: E/AndroidRuntime(14690): Process: com.speakez.userapp, > PID: 14690 > 09-04 12:45:29.884: E/AndroidRuntime(14690): java.lang.RuntimeException: An > error occured while executing doInBackground() > 09-04 12:45:29.884: E/AndroidRuntime(14690): at > android.os.AsyncTask$3.done(AsyncTask.java:300) > 09-04 12:45:29.884: E/AndroidRuntime(14690): at > java.util.concurrent.FutureTask.finishCompletion(FutureTask.java:355) > 09-04 12:45:29.884: E/AndroidRuntime(14690): at > java.util.concurrent.FutureTask.setException(FutureTask.java:222) > 09-04 12:45:29.884: E/AndroidRuntime(14690): at > java.util.concurrent.FutureTask.run(FutureTask.java:242) > 09-04 12:45:29.884: E/AndroidRuntime(14690): at > android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:231) > 09-04 12:45:29.884: E/AndroidRuntime(14690): at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112) > 09-04 12:45:29.884: E/AndroidRuntime(14690): at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587) > 09-04 12:45:29.884: E/AndroidRuntime(14690): at > java.lang.Thread.run(Thread.java:841) > 09-04 12:45:29.884: E/AndroidRuntime(14690): Caused by: > java.lang.NoClassDefFoundError: > com.google.android.gms.gcm.GoogleCloudMessaging > 09-04 12:45:29.884: E/AndroidRuntime(14690): at > org.jboss.aerogear.android.impl.unifiedpush.AeroGearGCMPushRegistrar$2.get(AeroGearGCMPushRegistrar.java:76) > 09-04 12:45:29.884: E/AndroidRuntime(14690): at > org.jboss.aerogear.android.impl.unifiedpush.AeroGearGCMPushRegistrar$2.get(AeroGearGCMPushRegistrar.java:72) > 09-04 12:45:29.884: E/AndroidRuntime(14690): at > org.jboss.aerogear.android.impl.unifiedpush.AeroGearGCMPushRegistrar$3.doInBackground(AeroGearGCMPushRegistrar.java:95) > 09-04 12:45:29.884: E/AndroidRuntime(14690): at > org.jboss.aerogear.android.impl.unifiedpush.AeroGearGCMPushRegistrar$3.doInBackground(AeroGearGCMPushRegistrar.java:87) > 09-04 12:45:29.884: E/AndroidRuntime(14690): at > android.os.AsyncTask$2.call(AsyncTask.java:288) > 09-04 12:45:29.884: E/AndroidRuntime(14690): at > java.util.concurrent.FutureTask.run(FutureTask.java:237) > 09-04 12:45:29.884: E/AndroidRuntime(14690): ... 4 more > 09-04 12:45:29.924: I/Process(14690): Sending signal. PID: 14690 SIG: 9 > > > > -- > View this message in context: http://aerogear-dev.1069024.n5.nabble.com/errors-in-cordova-android-app-tp9117.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From hagai.sela at gmail.com Fri Sep 5 04:38:03 2014 From: hagai.sela at gmail.com (hagai.sela) Date: Fri, 5 Sep 2014 01:38:03 -0700 (PDT) Subject: [aerogear-dev] errors in cordova / android app In-Reply-To: <02A6F6A8-AB6E-4138-9778-80EABF84B9A5@redhat.com> References: <1409826261155-9117.post@n5.nabble.com> <02A6F6A8-AB6E-4138-9778-80EABF84B9A5@redhat.com> Message-ID: <1409906283320-9130.post@n5.nabble.com> Hi, I am installing it on an LG G2. I have a google account set up. Hagai. -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/errors-in-cordova-android-app-tp9117p9130.html Sent from the aerogear-dev mailing list archive at Nabble.com. From daniel.bevenius at gmail.com Fri Sep 5 04:47:46 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 5 Sep 2014 10:47:46 +0200 Subject: [aerogear-dev] Differential Synchronization: Shadow/Backup Revision Control and its Garbage Collection In-Reply-To: References: Message-ID: I like the idea and anything that we can do to reduce the memory footprint is great. I think this is worth investigating further and trying it out in practice. Thanks for the detailed description Lukas! On 4 September 2014 17:38, Luk?? Fry? wrote: > Hey guys, > > > TL;DR: there are ways how to make the memory footprint of Differential > Synchronization (DS) very low; if we assume that JSON patches are > reversible and we create cumulative patches from series of individual > patches, we can use (smart, garbage-collactable) revision control for > storage of documents that server need to maintain. > > ---- > > I had an idea in my head that for couple of days as I was becoming > familiar with how Differential Synchronization (DS) works and studying > Dan's and Luke's impl. > > I share the concern that Randall expressed in earlier thread - the DS in > its pure version doesn't scale for huge amount of users when connected to > one server. > > Sure, the algorithm can be scaled trivially by adding new nodes that uses > very same algorithm as is used for client<->server. But that doesn't mean > it is something that we should do regularly to get more memory available. > > > Instead, I was thinking about limiting a memory that server needs to > maintain in any point in time. > > > In pure DS, server have to maintain all copies of documents that clients > ever requested. Even worse, it has to maintain two copies - "shadow" and > "backup", > > So, in worst case, 2 x N copies of document will be maintained by the > server for N clients. > > ----- > > The DS algorithm doesn't tell us how the "shadow" and "backup" documents > should be stored. > > We can transparently plug in a storage that will be clever about how to > use "backups" and "shadow". > > ----- > > CONCEPTS: > > 1) REVISION CONTROL > > In order to limit a number of documents we need to maintain in server's > memory, we can come with a system where just last known state is remembered > in full version. Together with last known version, we remember also history > of the document for each revision as it was patched by clients. > > But server doesn't have to maintain full history of the document, it > maintains just revisions that are known to its clients (that revision is > known by DS for each client out of the box). > > 2) GARBAGE COLLECTION > > Server trivially knows what versions are mantained by client, so it can > get rid of those revisions that are no longer needed. > > First, it can cut all the history that is older than the oldest version of > document throughout all its clients. > > Secondly, it can accumulate the serious of patches between states so that > it doesn't have to maintain full history, but just revisions that is known > to any of those clients. > > ---- > > DIAGRAM: > > I've attached a picture for illustration of the revision control / garbage > collection, it does not illustrate algorithm itself (Dan did awesome job > describing DS here [3]). > > In the attached diagram, you can see four clients with different revisions: > > Client 1: revision X > Client 2: revision X+3 > Client 3: revision X+3 > Client 4: revision X+4 > > If any of the clients reaches server, server can reconstruct the document > (shadow and backup) for given client revision and the DS algorithm then can > operate as normally (that's why it is transparent from algorithmic point of > view). > > If server comes to garbage collection, it can scan through available > client revisions. As it identifies, that the oldest known revision is X, it > can remove patch for X-1 and less as they are no longer needed. > > Later, it can even more optimize, and accumulate patches so that the only > information he knows is how to get to the revision for each participating > client. In the picture, he can compute cumulative patch for getting from > state X to state X+3, as X+1 and X+2 themselves are not needed. > > (Patch accumulation is actually something that Google Wave does in its > Operational Transformation implementation, just there it is called > cumulative Operations). > > ---- > > Then it comes to caching strategies, you can maintain caches of things > like last recently used revisions (they don't need to be computed each > time). You can store some documents and their revision history to the disk > (fully or partially), etc. > > ---- > > THE USE CASE: > > > 1000 employees maintain one document - Contact List - on their smartphones > > 400 of those employees has mobile data plan, so they want to synchronize > almost immediately as they are notified about changes. The rest of the > devices is connected rather sparely. > > If one employee changes data, 600 devices are notified about the change > immediately (some on data plan, some through Wifi, etc.) Those clients all > have version say X+3, because they are synchronized proactively. > > These clients reach the server in say <10 seconds after that employee did > the change. > > First client reaches server and ask for version X+3 (it probably is still > in the memory, but if it isn't, it is deconstructed and placed into MRU > cache). All of the others reaches the server and re-synchronize themselves > against the one copy of backup/shadow that is in the memory already. > > The other clients will reach the server later, as they are connecting to > Wifi, say in 5 minutes to 24 hours. They will have even older versions, > such as X. Those clients will require more computation, but at the end the > server can resolve them and through their revisions out of the window. > > At the end, there are clients that didn't connected for days, maybe months > - I suggest we don't actually use DS here and fallback to e.g. slow > synchronization (show me what you have, I will show you mine), because > maintaining full history for longer period of days may be too resource > demanding (configurable?). > > Obviously, 1000 is not much, but this can scale to pretty decent numbers > if we use hybrid approach (fallback to other sync strategies if revision is > already forgotten by a server). > > ---- > > WORST CASE: > > we still have to maintain all the document revisions, but practically it > won't happen :-) > > ---- > > ASSUMPTIONS: > > 1. patches are reversible (we are able to compute reverse patch for each > patch sent by client) > 2. patches are cumulative (we are able to compute aggregated patch from > series of patches) > > For 1, it seems many of JSON-patch libraries actually implement it (Java, > JavaScript) [1, 2] > > For 2, it again seems some libraries implement it and if not, we can > implement it or even use brute-force - compute a patch between two documents > > > ---- > > It's not the only way how to make it scale, but it does solve the problem > pretty independently of the DS algorithm and still leaves the algorithm > clean and simple. > > > > Cheers, > > ~ Lukas > > > [1] https://github.com/fge/json-patch > [2] https://github.com/benjamine/jsondiffpatch > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140905/2ffeee74/attachment-0001.html From daniel at passos.me Fri Sep 5 06:38:04 2014 From: daniel at passos.me (Daniel Passos) Date: Fri, 5 Sep 2014 07:38:04 -0300 Subject: [aerogear-dev] Chrome Push Messages In-Reply-To: References: <60194944-06DE-44BF-AEF4-B729DF9B5E69@redhat.com> Message-ID: +1 to GCM logo On Sep 3, 2014 5:28 PM, "S?bastien Blanc" wrote: > Looks like there is a gcm logo but it is not really nice and I can not > find it with a decent resolution > [image: logo.png] > > Envoy? de mon iPhone > > Le 3 sept. 2014 ? 21:32, Luk?? Fry? a ?crit : > > From the UI perspective, Android/Chrome merge has few options: > > 1. merged half-Android / half-Chrome logo (+ "Android / Chrome" as a > description) > > 2. use one radio button, but two rows with two logos (Android, Chrome) > > 3. use Google logo ("G"? [1]) (and "Google Cloud Messaging" description) > > > Anyway, in any case it won't be as nice and polished as it is now. :-) > > > [1] > https://www.google.com/search?q=g+google&source=lnms&tbm=isch&sa=X&ei=kWsHVILKJsn8yQSO9IDoCQ&ved=0CAoQ_AUoAw&biw=1283&bih=861 > > > On Wed, Sep 3, 2014 at 7:48 PM, Lucas Holmquist > wrote: > >> So to follow up on this, >> >> >> Chrome Packaged Applications, no recommend to use the same GCM network >> for Android when sending push notifications. >> >> Currently in the UnifiedPush Server, a user can use the Android variant >> to use this new API now. >> >> I think we should rename the AndroidVariant.class and related stuff to >> GCMVariant . >> >> I created this Task to track the changes, >> https://issues.jboss.org/browse/AGPUSH-928 since we need to deprecate >> the current Chrome implementation and update the UI?s for the new way. >> >> i?m wondering for the ?Create Variant? dialog, for Android, we would >> need to change the name to GCM, but for the icon?s i wonder how it would >> look to put both Android and Chrome icons, side by side >> >> >> On Aug 27, 2014, at 2:19 PM, Lucas Holmquist wrote: >> >> >> On Aug 27, 2014, at 2:15 PM, Luk?? Fry? wrote: >> >> Hey Luke, >> >> ad) Variants >> >> it would be ideal if we could just use the same variant! >> >> >> yea, it?s looking like it will be the same thing, we might just have to >> make a note of it on the UI >> >> >> >> ad) Compatibility >> >> I would say we should preserve the compatibility with 1.x as long as it >> does not make much efforts to keep both supported. >> >> >> If it would be too much hassle, let's remove it in 1.1. >> Chrome is updated pro-actively anyway, so no one will hear about the old >> API in few months. >> >> >> exactly, so maybe a warning or something >> >> >> >> Cheers, >> >> ~ Lukas >> >> >> On Wed, Aug 27, 2014 at 3:28 PM, Lucas Holmquist >> wrote: >> >>> Hello, >>> >>> now that the 1.0.0-final is pretty much out for the UnifiedPush Server, >>> i?m starting to look at the new API that Chrome apps use for sending push >>> notifications. >>> >>> the TL;DR of it is, it?s basically the same as Android now.( no more >>> refresh tokens and access tokens and such ) >>> >>> So the question is, do we need to have a deprecation period on what is >>> currently there? >>> >>> The v1 of the chrome pushMessaging api has become legacy and it is >>> recommended to use the new stuff. >>> https://developer.chrome.com/apps/cloudMessagingV1 >>> >>> While i have looked to deeply, it?s possible we can use the same >>> ?Variant? structure for Chrome Apps, Since they will be using the same >>> Network >>> >>> wdyt? >>> >>> -Luke >>> >>> _______________________________________________ >>> 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 >> >> >> _______________________________________________ >> 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 >> > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140905/ad917b4a/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: logo.png Type: image/png Size: 3926 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140905/ad917b4a/attachment.png From daniel at passos.me Fri Sep 5 07:20:56 2014 From: daniel at passos.me (Daniel Passos) Date: Fri, 5 Sep 2014 08:20:56 -0300 Subject: [aerogear-dev] Maven repo config in pom.xml In-Reply-To: References: Message-ID: On Thu, Sep 4, 2014 at 8:00 PM, John Manko wrote: > I added the repo and plugin config to my pom, but I still can't find the > aerogear artifacts. > What repo and plugin you mean? For org.jboss.aerogear:aerogear-android-push, only v0.2 and v0.1 are found, > not v1.0. > All our Android library are in Maven central: http://search.maven.org/#search%7Cga%7C1%7Caerogear-android-push > Also, getting Failed to execute goal on project blah: Could not resolve > dependencies for project .... Failed to collect dependencies for > [org.jboss.aerogear:aerogear-android:jar:1.4.0 (compile), > org.jboss.aerogear:aerogear-security:jar:1.3.1 (compile), > org.jboss.aerogear:aerogear-security-picketlink:jar:1.3.1 (compile), > com.google.android:support-v4:jar:r7 (compile), > javax:javaee-web-api:jar:6.0 (provided)]: No versions available for > android.support:compatibility-v4:jar:[18,) within specified range -> [Help > 1] > Unfortunately Google don't ship the support library to Maven central. You need build/deploy it locally: http://aerogear.org/docs/guides/aerogear-android/how-to-build-aerogear-android/ > I'm running in Netbeans 8, btw. Is Eclipse a requirement due to IDE > plugin support? > No. Netbeans works well. > > > > jboss-public-repository-group > JBoss Public Maven Repository Group > > https://repository.jboss.org/nexus/content/groups/public-jboss/ > default > > true > never > > > true > never > > > > > > jboss-public-repository-group > JBoss Public Maven Repository Group > > https://repository.jboss.org/nexus/content/groups/public-jboss/ > default > > true > never > > > true > never > > > > > > It's not necessary In related news. Take a look of our docs[1], README[2], and example app[3] [1] http://aerogear.org/docs/guides/aerogear-android/ [2] https://github.com/aerogear/aerogear-android-push/blob/master/README.md [3] https://github.com/aerogear/aerogear-push-helloworld/tree/master/android -- Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140905/1af13bdb/attachment-0001.html From daniel at passos.me Fri Sep 5 07:58:20 2014 From: daniel at passos.me (Daniel Passos) Date: Fri, 5 Sep 2014 08:58:20 -0300 Subject: [aerogear-dev] UPS Release 1.0.1 - planning In-Reply-To: References: <20140904132847.GA67024@abstractj.org> Message-ID: +1 On Thu, Sep 4, 2014 at 11:02 AM, Luk?? Fry? wrote: > Yep, Wednesday it fine. > > > On Thu, Sep 4, 2014 at 3:47 PM, Matthias Wessendorf > wrote: > >> Sounds good ?? >> >> >> On Thursday, September 4, 2014, Daniel Bevenius < >> daniel.bevenius at gmail.com> wrote: >> >>> Sounds good to me! >>> >>> >>> >>> On 4 September 2014 15:28, Bruno Oliveira wrote: >>> >>>> Good morning, >>>> >>>> Today we have the remaining Jiras for 1.0.1 >>>> ( >>>> https://issues.jboss.org/issues/?jql=fixVersion%20%3D%201.0.1%20AND%20project%20%3D%20AGPUSH%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC >>>> ). >>>> After a hangout with Luk?? and Sebastien we agreed that it's doable to >>>> do the code freezing by Wednesday (Set, 10) and immediately stage the >>>> release for testing. >>>> >>>> I will be on PTO on 15th September. So please, be nice and help >>>> Sebastien with testing and fixing bugs if necessary. >>>> >>>> Thoughts or tomatoes? >>>> >>>> -- >>>> >>>> abstractj >>>> PGP: 0x84DC9914 >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >> >> -- >> Sent from Gmail Mobile >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140905/915abe98/attachment.html From supittma at redhat.com Fri Sep 5 10:39:42 2014 From: supittma at redhat.com (Summers Pittman) Date: Fri, 05 Sep 2014 10:39:42 -0400 Subject: [aerogear-dev] Maven repo config in pom.xml In-Reply-To: References: Message-ID: <5409CB2E.5000109@redhat.com> On 9/4/2014 8:38 PM, John Manko wrote: > You know, I really appreciate the work you guys are doing, but the > documentation is horrible for new adopters. Something needs to be done. We are always willing to take suggestions from the community. If you don't mind, could you write down where your bugs/glitches/hiccups/gripes and share them with us. If you are feeling particularly inspired feel free to fork the project, update the docs, and send in a PR. > > > On Thu, Sep 4, 2014 at 7:00 PM, John Manko > wrote: > > I added the repo and plugin config to my pom, but I still can't > find the aerogear artifacts. > > For org.jboss.aerogear:aerogear-android-push, only v0.2 and v0.1 > are found, not v1.0. > > Also, getting Failed to execute goal on project blah: Could not > resolve dependencies for project .... Failed to collect > dependencies for [org.jboss.aerogear:aerogear-android:jar:1.4.0 > (compile), org.jboss.aerogear:aerogear-security:jar:1.3.1 > (compile), > org.jboss.aerogear:aerogear-security-picketlink:jar:1.3.1 > (compile), com.google.android:support-v4:jar:r7 (compile), > javax:javaee-web-api:jar:6.0 (provided)]: No versions available > for android.support:compatibility-v4:jar:[18,) within specified > range -> [Help 1] > > I'm running in Netbeans 8, btw. Is Eclipse a requirement due to > IDE plugin support? > > > > jboss-public-repository-group > JBoss Public Maven Repository Group > > https://repository.jboss.org/nexus/content/groups/public-jboss/ > > default > > true > never > > > true > never > > > > > > jboss-public-repository-group > JBoss Public Maven Repository Group > > https://repository.jboss.org/nexus/content/groups/public-jboss/ > > default > > true > never > > > true > never > > > > > > > > > -- > "If the American people ever allow private banks to control the issue > of their currency, first by inflation, then by deflation, the > banks...will deprive the people of all property until their children > wake-up homeless on the continent their fathers conquered... The > issuing power should be taken from the banks and restored to the > people, to whom it properly belongs." -- Thomas Jefferson > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140905/529755b3/attachment.html From gorkem.ercan at gmail.com Fri Sep 5 12:55:36 2014 From: gorkem.ercan at gmail.com (Gorkem Ercan) Date: Fri, 5 Sep 2014 12:55:36 -0400 Subject: [aerogear-dev] Should Cordova push plugin dependencies be shrinkwrapped? In-Reply-To: References: Message-ID: Actually, it looks like push plugin is already broken because of the dependency, see AGCORDOVA-31. I have also created a PR [1] that freezes the dependencies to a commit. [1] https://github.com/aerogear/aerogear-pushplugin-cordova/pull/51 -- Gorkem On Fri, Sep 5, 2014 at 3:00 AM, Erik Jan de Wit wrote: > Fully agree, problem is these repos don?t have any tag or releases. Maybe > we should not use them. > > On 4 Sep,2014, at 17:05 , Gorkem Ercan wrote: > > Hi All, > I have been working cordova push quickstarts and noticed that on Android > installation through JBoss tools started to fail. > > After a bit of investigation I figured that the failure occurs because > push plugin defines cordova plugin "com.google.playservices" as a > dependency through a git URL[1] that points to the master of the plugin's > repo. Unfortunately this repo received a change [2] which started to use a > new feature that was not implemented for JBoss tools. In this particular > case, I am already implementing the missing feature so it should be all > good soon. However I have doubts that referencing a dependency through > master is a good idea. I think it may not only make it really difficult for > us to reproduce cases but also unexpected behaviour may just appear. > > > [1] https://github.com/MobileChromeApps/google-play-services > [2] > https://github.com/MobileChromeApps/google-play-services/commit/41c19152c21981c9a2f6497cc2100c317f5c660d > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140905/ecde19c2/attachment-0001.html From rhauch at redhat.com Fri Sep 5 14:32:18 2014 From: rhauch at redhat.com (Randall Hauch) Date: Fri, 5 Sep 2014 13:32:18 -0500 Subject: [aerogear-dev] Differential Synchronization: Shadow/Backup Revision Control and its Garbage Collection In-Reply-To: References: Message-ID: This does sounds quite interesting, Luk??. If AeroGear uses Differential Synchronization, this approach might make it more efficient for the server to implement the behavior. But I?m still bothered by the thought that AeroGear?s Data Sync feature uses any algorithm that requires the server to maintain client-specific state. First of all, servers that maintain no client state across requests will *always* scale much better than servers that maintain client-specific state across requests. Maintaining client-specific state requires extra work, consumes more memory, and complicates clustering, failover, and fault tolerance. Secondly, if a server is maintaining client-specific state, how long does that client state have to be maintained before assuming the client is no longer there? What happens when a client on a mobile device loses its connection for a short period of time and then reconnects? What if load balancing cause the client to reconnect to a different process in the cluster? Bottom line is that it adds quite a bit of complexity. Finally, I completely understand the benefits of using Differential Synchronization where many clients are collaborating on a single document. That?s the ?collaborative editor? scenario, and surely there are apps that need this functionality. I?m just not convinced that this is the most common use case. In fact, I think it?s relatively uncommon, and I don?t think LiveOak will support it in the near term. (BTW, please tell me if the whole purpose of AeroGear's Data Sync feature is to satisfy this and only this scenario. If so, then I apologize for being a distraction.) My understanding of the Data Sync feature, though, is that it is should be applicable to other scenarios. IMO, the far more common scenario is: The server manages (many) millions of small entities, each of which is a domain-specific aggregate JSON document. Examples of different kinds of entities include: customers, books, insurance claims, catalog items, restaurants, purchases, tasks, etc. A single customer entity would aggregate most/all the information about the customer, including the name, phone numbers, addresses, profile information, domain-specific privileges (e.g., authorized to log issues or call support), etc. Note that these aggregate entities do not correspond to the entities in a traditional RDBMS/JPA/Hibernate app, where you?d have much finer-grained records (separate tables for customer, customer addresses, customer phone numbers, customer privileges, etc.). At any point in time there may be 1Ks or 10Ks of clients reading dozens of documents/entities and sending changes to some of them (likely in batch operations). IOW, any one document might be concurrently modified by a relatively small number of clients. I think it?s possible to support Data Sync in this scenario while maintaining no client-specific state on the server (other than while processing a single request). The Data Sync functionality of the SDK used in the clients would work with local persistence and enable the app to function online or offline. This includes making it possible to edit entities and create new entities while offline, though it does not matter to Data Sync which subset of entities is persisted locally. If the client goes offline and then back online, the Data Sync functionality in the SDK would figure out which of the local entities the client has changed, and request from the server the latest revisions for each of them. Data Sync then merges the local changes onto the latest revisions (perhaps asking the user to manually resolve anything that cannot be automatically resolved), computes the new effective changes, and then sends a single batch request to the server to apply them. Some, all or none changes are accepted, and likely the application then has to decide whether to continue the process again, revert to the server?s versions, etc. (The SDK would also make use of subscriptions/notifications so that it can be told immediately when entities are changed.) What the batch operations entail is dependent upon the needs of the client app and capabilities of the server. If a server supports batch operations that contain the entire entity, then the server will almost certainly need to put revision identifiers in each entity sent to the client, so that when the client sends back a modified representation entity, the server can tell whether that document has since been modified by another client. If so, the server might rely upon client preferences (see below) to know whether to merge the changes (using a simple algorithm or more useful application-specific logic), overwrite, or fail to update the entity. On the other hand, the server might support batch operations with partial updates, where the client only sends for each entity only the set of fields that are to be changed or removed. Conflicts and merging with this approach are easier and less-likely to be application specific, though client preferences (see below) might still dictate whether or not to merge based upon revision numbers. It also might make it easier for Data Sync, since the SDK simply has to record for each modified entity only those modified fields (no matter how long the client was offline). To keep the SDK simple, a best practice might be to ensure clients always modify together those fields that must be consistent. For example, in a contacts application, if a user modifies the first name of a contact, the app might tell the SDK to modify the first name and last name fields, even though the user didn?t modify the last name. When synchronized, both the first name and last name fields would be sent to the server as a single update. This helps ensure that even when multiple clients are concurrently updating the same set of fields to different values, the result of applying all of those changes will exactly match the state as set by one of the clients. It?s also likely that for batch operations to work well for many different kinds of applications, the server may support multiple policies that specify for a given batch operation the atomicity, consistency, and isolation guarantees. One policy might ensure that the entire batch either completely succeeds only when there are no revision conflicts, otherwise it completely fails. Another policy might be eventually-consistent in the sense that the changes in every batch operations will eventually be applied, though this may require the server to have application-specific conflict resolution logic. And there are policies that are somewhere in-between. For example, imagine a server that supports ?public? collections whose entities can be read/updated by any user, and ?private? collections that expose only the entities that are readable and editable by that user. The likelihood of a concurrent update conflict on a private entity is quite small, since it?s possible only when different changes made on different devices are submitted at exactly the same time. On the other hand, the likelihood of a concurrent update conflict on a public entity is much higher. The server may allow updates to both public and private entities within a single batch operation, and a save policy that might update all private entities atomically (they all succeed or they all fail) while updates to *each* public entity is atomic (some might succeed while others might fail). Any given server will likely support only a few of these policies. But either way, the server has to report back to the client the outcome of the batch request: which entities were updated, which were not, and the reason why each of the rejected updates failed (because other entity changes were rejected, because of a conflict, etc.). The SDK?s Data Sync functionality would use those results to know how to update the local persisted representations, and to start trying to resolve any failures. The kinds of requests needed to support data sync in this scenario are fairly basic, so the server doesn?t have to be that complicated. Best of all, the server is not required to maintain any client-specific state. Thoughts? Am I way off-base? Best regards, Randall On Sep 4, 2014, at 10:38 AM, Luk?? Fry? wrote: > Hey guys, > > > TL;DR: there are ways how to make the memory footprint of Differential Synchronization (DS) very low; if we assume that JSON patches are reversible and we create cumulative patches from series of individual patches, we can use (smart, garbage-collactable) revision control for storage of documents that server need to maintain. > > ---- > > I had an idea in my head that for couple of days as I was becoming familiar with how Differential Synchronization (DS) works and studying Dan's and Luke's impl. > > I share the concern that Randall expressed in earlier thread - the DS in its pure version doesn't scale for huge amount of users when connected to one server. > > Sure, the algorithm can be scaled trivially by adding new nodes that uses very same algorithm as is used for client<->server. But that doesn't mean it is something that we should do regularly to get more memory available. > > > Instead, I was thinking about limiting a memory that server needs to maintain in any point in time. > > > In pure DS, server have to maintain all copies of documents that clients ever requested. Even worse, it has to maintain two copies - "shadow" and "backup", > > So, in worst case, 2 x N copies of document will be maintained by the server for N clients. > > ----- > > The DS algorithm doesn't tell us how the "shadow" and "backup" documents should be stored. > > We can transparently plug in a storage that will be clever about how to use "backups" and "shadow". > > ----- > > CONCEPTS: > > 1) REVISION CONTROL > > In order to limit a number of documents we need to maintain in server's memory, we can come with a system where just last known state is remembered in full version. Together with last known version, we remember also history of the document for each revision as it was patched by clients. > > But server doesn't have to maintain full history of the document, it maintains just revisions that are known to its clients (that revision is known by DS for each client out of the box). > > 2) GARBAGE COLLECTION > > Server trivially knows what versions are mantained by client, so it can get rid of those revisions that are no longer needed. > > First, it can cut all the history that is older than the oldest version of document throughout all its clients. > > Secondly, it can accumulate the serious of patches between states so that it doesn't have to maintain full history, but just revisions that is known to any of those clients. > > ---- > > DIAGRAM: > > I've attached a picture for illustration of the revision control / garbage collection, it does not illustrate algorithm itself (Dan did awesome job describing DS here [3]). > > In the attached diagram, you can see four clients with different revisions: > > Client 1: revision X > Client 2: revision X+3 > Client 3: revision X+3 > Client 4: revision X+4 > > If any of the clients reaches server, server can reconstruct the document (shadow and backup) for given client revision and the DS algorithm then can operate as normally (that's why it is transparent from algorithmic point of view). > > If server comes to garbage collection, it can scan through available client revisions. As it identifies, that the oldest known revision is X, it can remove patch for X-1 and less as they are no longer needed. > > Later, it can even more optimize, and accumulate patches so that the only information he knows is how to get to the revision for each participating client. In the picture, he can compute cumulative patch for getting from state X to state X+3, as X+1 and X+2 themselves are not needed. > > (Patch accumulation is actually something that Google Wave does in its Operational Transformation implementation, just there it is called cumulative Operations). > > ---- > > Then it comes to caching strategies, you can maintain caches of things like last recently used revisions (they don't need to be computed each time). You can store some documents and their revision history to the disk (fully or partially), etc. > > ---- > > THE USE CASE: > > > 1000 employees maintain one document - Contact List - on their smartphones > > 400 of those employees has mobile data plan, so they want to synchronize almost immediately as they are notified about changes. The rest of the devices is connected rather sparely. > > If one employee changes data, 600 devices are notified about the change immediately (some on data plan, some through Wifi, etc.) Those clients all have version say X+3, because they are synchronized proactively. > > These clients reach the server in say <10 seconds after that employee did the change. > > First client reaches server and ask for version X+3 (it probably is still in the memory, but if it isn't, it is deconstructed and placed into MRU cache). All of the others reaches the server and re-synchronize themselves against the one copy of backup/shadow that is in the memory already. > > The other clients will reach the server later, as they are connecting to Wifi, say in 5 minutes to 24 hours. They will have even older versions, such as X. Those clients will require more computation, but at the end the server can resolve them and through their revisions out of the window. > > At the end, there are clients that didn't connected for days, maybe months - I suggest we don't actually use DS here and fallback to e.g. slow synchronization (show me what you have, I will show you mine), because maintaining full history for longer period of days may be too resource demanding (configurable?). > > Obviously, 1000 is not much, but this can scale to pretty decent numbers if we use hybrid approach (fallback to other sync strategies if revision is already forgotten by a server). > > ---- > > WORST CASE: > > we still have to maintain all the document revisions, but practically it won't happen :-) > > ---- > > ASSUMPTIONS: > > 1. patches are reversible (we are able to compute reverse patch for each patch sent by client) > 2. patches are cumulative (we are able to compute aggregated patch from series of patches) > > For 1, it seems many of JSON-patch libraries actually implement it (Java, JavaScript) [1, 2] > > For 2, it again seems some libraries implement it and if not, we can implement it or even use brute-force - compute a patch between two documents > > > ---- > > It's not the only way how to make it scale, but it does solve the problem pretty independently of the DS algorithm and still leaves the algorithm clean and simple. > > > > Cheers, > > ~ Lukas > > > [1] https://github.com/fge/json-patch > [2] https://github.com/benjamine/jsondiffpatch > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140905/7c54205c/attachment-0001.html From john.manko at gmail.com Sat Sep 6 02:51:10 2014 From: john.manko at gmail.com (John Manko) Date: Sat, 6 Sep 2014 02:51:10 -0400 Subject: [aerogear-dev] Maven repo config in pom.xml In-Reply-To: <5409CB2E.5000109@redhat.com> References: <5409CB2E.5000109@redhat.com> Message-ID: First, I'd like to apologize. Long days of fruitless development leads to shortened patients! I'm going to work on this over the weekend and I'll try to be as concise as possible with an problems I'm having! Again, I appreciate everything you're doing! Thank you. :) On Fri, Sep 5, 2014 at 10:39 AM, Summers Pittman wrote: > On 9/4/2014 8:38 PM, John Manko wrote: > > You know, I really appreciate the work you guys are doing, but the > documentation is horrible for new adopters. Something needs to be done. > > We are always willing to take suggestions from the community. If you > don't mind, could you write down where your bugs/glitches/hiccups/gripes > and share them with us. If you are feeling particularly inspired feel free > to fork the project, update the docs, and send in a PR. > > > > On Thu, Sep 4, 2014 at 7:00 PM, John Manko wrote: > >> I added the repo and plugin config to my pom, but I still can't find >> the aerogear artifacts. >> >> For org.jboss.aerogear:aerogear-android-push, only v0.2 and v0.1 are >> found, not v1.0. >> >> Also, getting Failed to execute goal on project blah: Could not resolve >> dependencies for project .... Failed to collect dependencies for >> [org.jboss.aerogear:aerogear-android:jar:1.4.0 (compile), >> org.jboss.aerogear:aerogear-security:jar:1.3.1 (compile), >> org.jboss.aerogear:aerogear-security-picketlink:jar:1.3.1 (compile), >> com.google.android:support-v4:jar:r7 (compile), >> javax:javaee-web-api:jar:6.0 (provided)]: No versions available for >> android.support:compatibility-v4:jar:[18,) within specified range -> [Help >> 1] >> >> I'm running in Netbeans 8, btw. Is Eclipse a requirement due to IDE >> plugin support? >> >> >> >> jboss-public-repository-group >> JBoss Public Maven Repository Group >> >> https://repository.jboss.org/nexus/content/groups/public-jboss/ >> default >> >> true >> never >> >> >> true >> never >> >> >> >> >> >> jboss-public-repository-group >> JBoss Public Maven Repository Group >> >> https://repository.jboss.org/nexus/content/groups/public-jboss/ >> default >> >> true >> never >> >> >> true >> never >> >> >> >> >> >> > > > -- > ?If the American people ever allow private banks to control the issue of > their currency, first by inflation, then by deflation, the banks...will > deprive the people of all property until their children wake-up homeless on > the continent their fathers conquered... The issuing power should be taken > from the banks and restored to the people, to whom it properly belongs." > -- Thomas Jefferson > > > _______________________________________________ > aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://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 > -- ?If the American people ever allow private banks to control the issue of their currency, first by inflation, then by deflation, the banks...will deprive the people of all property until their children wake-up homeless on the continent their fathers conquered... The issuing power should be taken from the banks and restored to the people, to whom it properly belongs." -- Thomas Jefferson -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140906/35433ac1/attachment.html From ronald.van.aken at gmail.com Sat Sep 6 12:07:53 2014 From: ronald.van.aken at gmail.com (Ronald van Aken) Date: Sat, 6 Sep 2014 18:07:53 +0200 Subject: [aerogear-dev] JMS example Message-ID: Hi all, Apologies if this is not the appropriate area for posting this question. But I see in the HornetQ an example integrating with the UnifiedPush server. However when i install the server i do not see any registration for JMS consumers. Should I install a different package? Thanks in advance. Kind regards, Ronald -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140906/de725051/attachment.html From matzew at apache.org Sat Sep 6 12:54:47 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sat, 6 Sep 2014 18:54:47 +0200 Subject: [aerogear-dev] JMS example In-Reply-To: References: Message-ID: Hi Ronald, I think their aerogear-integration module ([1]) is mainly for sending a message to the UnifiedPush Server, from w/in the JMS broker (see their AeroGearConnectorService.java file). Once the message hit the UnifiedPush Server, it than delivers the push message to the different push networks, like APNs or GCM. Which then eventually triggers your device. Greetings, Matthias [1] https://github.com/hornetq/hornetq/tree/master/integration/hornetq-aerogear-integration On Sat, Sep 6, 2014 at 6:07 PM, Ronald van Aken wrote: > Hi all, > > Apologies if this is not the appropriate area for posting this question. > But I see in the HornetQ an example integrating with the UnifiedPush > server. However when i install the server i do not see any registration for > JMS consumers. Should I install a different package? > > Thanks in advance. > > Kind regards, > Ronald > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140906/63ee8d25/attachment.html From hagai.sela at gmail.com Sun Sep 7 05:12:07 2014 From: hagai.sela at gmail.com (hagai.sela) Date: Sun, 7 Sep 2014 02:12:07 -0700 (PDT) Subject: [aerogear-dev] errors in cordova / android app In-Reply-To: <02A6F6A8-AB6E-4138-9778-80EABF84B9A5@redhat.com> References: <1409826261155-9117.post@n5.nabble.com> <02A6F6A8-AB6E-4138-9778-80EABF84B9A5@redhat.com> Message-ID: <1410081127150-9142.post@n5.nabble.com> just to be clear, is there anything else I need to run except from the cordova setup page? http://aerogear.org/docs/guides/aerogear-push-cordova-android/cordova-android-app/ Specifically, do I need to import the google play services library? Thanks, Hagai. -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/errors-in-cordova-android-app-tp9117p9142.html Sent from the aerogear-dev mailing list archive at Nabble.com. From edewit at redhat.com Mon Sep 8 02:20:57 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 8 Sep 2014 08:20:57 +0200 Subject: [aerogear-dev] errors in cordova / android app In-Reply-To: <1410081127150-9142.post@n5.nabble.com> References: <1409826261155-9117.post@n5.nabble.com> <02A6F6A8-AB6E-4138-9778-80EABF84B9A5@redhat.com> <1410081127150-9142.post@n5.nabble.com> Message-ID: <4156D51F-4265-4123-B3EA-39134E0B340B@redhat.com> Hi Hagai, After some more investigation we found the error, it?s been fixed on the master branch could you try it out with our latest master? You can use the master with the following commands: cordova plugin rm org.jboss.aerogear.cordova.push cordova plugin add https://github.com/aerogear/aerogear-pushplugin-cordova Hope that helps, Erik Jan On 7 Sep,2014, at 11:12 , hagai.sela wrote: > just to be clear, is there anything else I need to run except from the > cordova setup page? > > http://aerogear.org/docs/guides/aerogear-push-cordova-android/cordova-android-app/ > > Specifically, do I need to import the google play services library? > > Thanks, > Hagai. > > > > -- > View this message in context: http://aerogear-dev.1069024.n5.nabble.com/errors-in-cordova-android-app-tp9117p9142.html > Sent from the aerogear-dev mailing list archive at Nabble.com. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140908/955a3566/attachment-0001.html From daniel.bevenius at gmail.com Mon Sep 8 02:55:32 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 8 Sep 2014 08:55:32 +0200 Subject: [aerogear-dev] Team meeting Message-ID: Agenda: http://oksoclap.com/p/aerogear-team-mgt-20140908 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140908/b24a5594/attachment.html From daniel.bevenius at gmail.com Mon Sep 8 05:04:59 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 8 Sep 2014 11:04:59 +0200 Subject: [aerogear-dev] Differential Synchronization: Shadow/Backup Revision Control and its Garbage Collection In-Reply-To: References: Message-ID: >What happens when a client on a mobile device loses its connection for a short period of time and then reconnects? The edits/patches/operations on the client would be stacked up and later when an connection is available that stack of edits/patches/operations would be sent to the server. >What if load balancing cause the client to reconnect to a different process in the cluster? If we allow for different types of what we currently call a DataStore to be pluggable, then it would be possible for that client to reconnect to a different instance with the assumption here that the underlying datastore is distributed. >BTW, please tell me if the whole purpose of AeroGear's Data Sync feature is to satisfy this and only this scenario. If so, then I apologize for being a distraction.) No, it is not the only scenario. We want to satisfy as many scenarios as possible, but we also have to start somewhere and preferable start small and build out from there. In the roadmap, we outlined as the first steps what is called conflict resolution. This is what our initial focus will be on and it will require minimal server side changes to existing server application (no server side state for clients). Our hope is that doing this might gain us some early adopters. This does not rule out that this could not be evolve into something like you've described in you email above, more about this later. > If the client goes offline and then back online, the Data Sync functionality in the SDK would figure out which of the local entities the client has changed, and request from the server the latest revisions for each of them. Data Sync then merges the local changes onto the latest revisions (perhaps asking the user to manually resolve anything that cannot be automatically resolved), computes the new effective changes, and then sends a single batch request to the server to apply them. Some, all or none changes are accepted, and likely the application then has to decide whether to continue the process again, revert to the server?s versions, etc. This sounds simliar to what we have discussed as conflict resolution in the Data Sync roadmap. It differs somewhat, like we don't specify anything with regard to batches as the goal it to limit the changes need for existing server implementations, in that the server only detects a conflict and does not try to apply any effective changes/operations/patches but instead works with complete objects/documents. >The SDK would also make use of subscriptions/notifications so that it can be told immediately when entities are changed. This is considered as a later part of conflict resolution where we notifications are planned to be used. >The kinds of requests needed to support data sync in this scenario are fairly basic, so the server doesn?t have to be that complicated. Best of all, the server is not required to maintain any client-specific state. This does sound like what we are trying to do with the conflict resolution approach. I know that it is even more basic than what you have described here but we could extend the roadmap to include such features. I think there will be use cases for both the conflict resolution and the data sync approaches and users that might be quite happy with conflict resolution. I think it would make sense to split the two roadmaps/specs into separate ones. At the moment it looks, and was the original idea, that this would involve into the "real-time" datasync solution. But have these separate would hopefully make this clear that these are independent and can evolve independently. Does this sound alright with everyone? Thanks, /Dan On 5 September 2014 20:32, Randall Hauch wrote: > This does sounds quite interesting, Luk??. If AeroGear uses Differential > Synchronization, this approach might make it more efficient for the server > to implement the behavior. > > But I?m still bothered by the thought that AeroGear?s Data Sync feature > uses any algorithm that requires the server to maintain client-specific > state. > > First of all, servers that maintain no client state across requests will > *always* scale much better than servers that maintain client-specific state > across requests. Maintaining client-specific state requires extra work, > consumes more memory, and complicates clustering, failover, and fault > tolerance. > > Secondly, if a server is maintaining client-specific state, how long does > that client state have to be maintained before assuming the client is no > longer there? What happens when a client on a mobile device loses its > connection for a short period of time and then reconnects? What if load > balancing cause the client to reconnect to a different process in the > cluster? Bottom line is that it adds quite a bit of complexity. > > Finally, I completely understand the benefits of using Differential > Synchronization where many clients are collaborating on a single document. > That?s the ?collaborative editor? scenario, and surely there are apps that > need this functionality. I?m just not convinced that this is the most > common use case. In fact, I think it?s relatively uncommon, and I don?t > think LiveOak will support it in the near term. (BTW, please tell me if the > whole purpose of AeroGear's Data Sync feature is to satisfy this and only > this scenario. If so, then I apologize for being a distraction.) > > My understanding of the Data Sync feature, though, is that it is should be > applicable to other scenarios. IMO, the far more common scenario is: > > > - The server manages (many) millions of small entities, each of which > is a domain-specific aggregate JSON document. Examples of different kinds > of entities include: customers, books, insurance claims, catalog items, > restaurants, purchases, tasks, etc. A single customer entity would > aggregate most/all the information about the customer, including the name, > phone numbers, addresses, profile information, domain-specific privileges > (e.g., authorized to log issues or call support), etc. Note that these > aggregate entities do not correspond to the entities in a traditional > RDBMS/JPA/Hibernate app, where you?d have much finer-grained records > (separate tables for customer, customer addresses, customer phone numbers, > customer privileges, etc.). > - At any point in time there may be 1Ks or 10Ks of clients reading > dozens of documents/entities and sending changes to some of them (likely in > batch operations). IOW, any one document might be concurrently modified by > a relatively small number of clients. > > > I think it?s possible to support Data Sync in this scenario while > maintaining no client-specific state on the server (other than while > processing a single request). > > The Data Sync functionality of the SDK used in the clients would work with > local persistence and enable the app to function online or offline. This > includes making it possible to edit entities and create new entities while > offline, though it does not matter to Data Sync which subset of entities is > persisted locally. If the client goes offline and then back online, the > Data Sync functionality in the SDK would figure out which of the local > entities the client has changed, and request from the server the latest > revisions for each of them. Data Sync then merges the local changes onto > the latest revisions (perhaps asking the user to manually resolve anything > that cannot be automatically resolved), computes the new effective changes, > and then sends a single batch request to the server to apply them. Some, > all or none changes are accepted, and likely the application then has to > decide whether to continue the process again, revert to the server?s > versions, etc. (The SDK would also make use of subscriptions/notifications > so that it can be told immediately when entities are changed.) > > What the batch operations entail is dependent upon the needs of the client > app and capabilities of the server. If a server supports batch operations > that contain the entire entity, then the server will almost certainly need > to put revision identifiers in each entity sent to the client, so that when > the client sends back a modified representation entity, the server can tell > whether that document has since been modified by another client. If so, the > server might rely upon client preferences (see below) to know whether to > merge the changes (using a simple algorithm or more useful > application-specific logic), overwrite, or fail to update the entity. > > On the other hand, the server might support batch operations with partial > updates, where the client only sends for each entity only the set of fields > that are to be changed or removed. Conflicts and merging with this approach > are easier and less-likely to be application specific, though client > preferences (see below) might still dictate whether or not to merge based > upon revision numbers. It also might make it easier for Data Sync, since > the SDK simply has to record for each modified entity only those modified > fields (no matter how long the client was offline). To keep the SDK simple, > a best practice might be to ensure clients always modify together those > fields that must be consistent. For example, in a contacts application, if > a user modifies the first name of a contact, the app might tell the SDK to > modify the first name and last name fields, even though the user didn?t > modify the last name. When synchronized, both the first name and last name > fields would be sent to the server as a single update. This helps ensure > that even when multiple clients are concurrently updating the same set of > fields to different values, the result of applying all of those changes > will exactly match the state as set by one of the clients. > > It?s also likely that for batch operations to work well for many different > kinds of applications, the server may support multiple policies that > specify for a given batch operation the atomicity, consistency, and > isolation guarantees. One policy might ensure that the entire batch either > completely succeeds only when there are no revision conflicts, otherwise it > completely fails. Another policy might be eventually-consistent in the > sense that the changes in every batch operations will eventually be > applied, though this may require the server to have application-specific > conflict resolution logic. And there are policies that are somewhere > in-between. For example, imagine a server that supports ?public? > collections whose entities can be read/updated by any user, and ?private? > collections that expose only the entities that are readable and editable by > that user. The likelihood of a concurrent update conflict on a private > entity is quite small, since it?s possible only when different changes made > on different devices are submitted at exactly the same time. On the other > hand, the likelihood of a concurrent update conflict on a public entity is > much higher. The server may allow updates to both public and private > entities within a single batch operation, and a save policy that might > update all private entities atomically (they all succeed or they all fail) > while updates to *each* public entity is atomic (some might succeed while > others might fail). > > Any given server will likely support only a few of these policies. But > either way, the server has to report back to the client the outcome of the > batch request: which entities were updated, which were not, and the reason > why each of the rejected updates failed (because other entity changes were > rejected, because of a conflict, etc.). The SDK?s Data Sync functionality > would use those results to know how to update the local persisted > representations, and to start trying to resolve any failures. > > The kinds of requests needed to support data sync in this scenario are > fairly basic, so the server doesn?t have to be that complicated. Best of > all, the server is not required to maintain any client-specific state. > > Thoughts? Am I way off-base? > > Best regards, > > Randall > > > > > On Sep 4, 2014, at 10:38 AM, Luk?? Fry? wrote: > > Hey guys, > > > TL;DR: there are ways how to make the memory footprint of Differential > Synchronization (DS) very low; if we assume that JSON patches are > reversible and we create cumulative patches from series of individual > patches, we can use (smart, garbage-collactable) revision control for > storage of documents that server need to maintain. > > ---- > > I had an idea in my head that for couple of days as I was becoming > familiar with how Differential Synchronization (DS) works and studying > Dan's and Luke's impl. > > I share the concern that Randall expressed in earlier thread - the DS in > its pure version doesn't scale for huge amount of users when connected to > one server. > > Sure, the algorithm can be scaled trivially by adding new nodes that uses > very same algorithm as is used for client<->server. But that doesn't mean > it is something that we should do regularly to get more memory available. > > > Instead, I was thinking about limiting a memory that server needs to > maintain in any point in time. > > > In pure DS, server have to maintain all copies of documents that clients > ever requested. Even worse, it has to maintain two copies - "shadow" and > "backup", > > So, in worst case, 2 x N copies of document will be maintained by the > server for N clients. > > ----- > > The DS algorithm doesn't tell us how the "shadow" and "backup" documents > should be stored. > > We can transparently plug in a storage that will be clever about how to > use "backups" and "shadow". > > ----- > > CONCEPTS: > > 1) REVISION CONTROL > > In order to limit a number of documents we need to maintain in server's > memory, we can come with a system where just last known state is remembered > in full version. Together with last known version, we remember also history > of the document for each revision as it was patched by clients. > > But server doesn't have to maintain full history of the document, it > maintains just revisions that are known to its clients (that revision is > known by DS for each client out of the box). > > 2) GARBAGE COLLECTION > > Server trivially knows what versions are mantained by client, so it can > get rid of those revisions that are no longer needed. > > First, it can cut all the history that is older than the oldest version of > document throughout all its clients. > > Secondly, it can accumulate the serious of patches between states so that > it doesn't have to maintain full history, but just revisions that is known > to any of those clients. > > ---- > > DIAGRAM: > > I've attached a picture for illustration of the revision control / garbage > collection, it does not illustrate algorithm itself (Dan did awesome job > describing DS here [3]). > > In the attached diagram, you can see four clients with different revisions: > > Client 1: revision X > Client 2: revision X+3 > Client 3: revision X+3 > Client 4: revision X+4 > > If any of the clients reaches server, server can reconstruct the document > (shadow and backup) for given client revision and the DS algorithm then can > operate as normally (that's why it is transparent from algorithmic point of > view). > > If server comes to garbage collection, it can scan through available > client revisions. As it identifies, that the oldest known revision is X, it > can remove patch for X-1 and less as they are no longer needed. > > Later, it can even more optimize, and accumulate patches so that the only > information he knows is how to get to the revision for each participating > client. In the picture, he can compute cumulative patch for getting from > state X to state X+3, as X+1 and X+2 themselves are not needed. > > (Patch accumulation is actually something that Google Wave does in its > Operational Transformation implementation, just there it is called > cumulative Operations). > > ---- > > Then it comes to caching strategies, you can maintain caches of things > like last recently used revisions (they don't need to be computed each > time). You can store some documents and their revision history to the disk > (fully or partially), etc. > > ---- > > THE USE CASE: > > > 1000 employees maintain one document - Contact List - on their smartphones > > 400 of those employees has mobile data plan, so they want to synchronize > almost immediately as they are notified about changes. The rest of the > devices is connected rather sparely. > > If one employee changes data, 600 devices are notified about the change > immediately (some on data plan, some through Wifi, etc.) Those clients all > have version say X+3, because they are synchronized proactively. > > These clients reach the server in say <10 seconds after that employee did > the change. > > First client reaches server and ask for version X+3 (it probably is still > in the memory, but if it isn't, it is deconstructed and placed into MRU > cache). All of the others reaches the server and re-synchronize themselves > against the one copy of backup/shadow that is in the memory already. > > The other clients will reach the server later, as they are connecting to > Wifi, say in 5 minutes to 24 hours. They will have even older versions, > such as X. Those clients will require more computation, but at the end the > server can resolve them and through their revisions out of the window. > > At the end, there are clients that didn't connected for days, maybe months > - I suggest we don't actually use DS here and fallback to e.g. slow > synchronization (show me what you have, I will show you mine), because > maintaining full history for longer period of days may be too resource > demanding (configurable?). > > Obviously, 1000 is not much, but this can scale to pretty decent numbers > if we use hybrid approach (fallback to other sync strategies if revision is > already forgotten by a server). > > ---- > > WORST CASE: > > we still have to maintain all the document revisions, but practically it > won't happen :-) > > ---- > > ASSUMPTIONS: > > 1. patches are reversible (we are able to compute reverse patch for each > patch sent by client) > 2. patches are cumulative (we are able to compute aggregated patch from > series of patches) > > For 1, it seems many of JSON-patch libraries actually implement it (Java, > JavaScript) [1, 2] > > For 2, it again seems some libraries implement it and if not, we can > implement it or even use brute-force - compute a patch between two documents > > > ---- > > It's not the only way how to make it scale, but it does solve the problem > pretty independently of the DS algorithm and still leaves the algorithm > clean and simple. > > > > Cheers, > > ~ Lukas > > > [1] https://github.com/fge/json-patch > [2] https://github.com/benjamine/jsondiffpatch > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140908/c181f5aa/attachment-0001.html From hagai.sela at gmail.com Mon Sep 8 05:39:18 2014 From: hagai.sela at gmail.com (hagai.sela) Date: Mon, 8 Sep 2014 02:39:18 -0700 (PDT) Subject: [aerogear-dev] errors in cordova / android app In-Reply-To: <4156D51F-4265-4123-B3EA-39134E0B340B@redhat.com> References: <1409826261155-9117.post@n5.nabble.com> <02A6F6A8-AB6E-4138-9778-80EABF84B9A5@redhat.com> <1410081127150-9142.post@n5.nabble.com> <4156D51F-4265-4123-B3EA-39134E0B340B@redhat.com> Message-ID: <1410169158381-9146.post@n5.nabble.com> This problem seems to be solved, but I got others. I'll open another thread. -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/errors-in-cordova-android-app-tp9117p9146.html Sent from the aerogear-dev mailing list archive at Nabble.com. From lukas.fryc at gmail.com Mon Sep 8 06:23:43 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Mon, 8 Sep 2014 12:23:43 +0200 Subject: [aerogear-dev] Differential Synchronization: Shadow/Backup Revision Control and its Garbage Collection In-Reply-To: References: Message-ID: Thanks for great feedback, Randall! *ad) Scalability* Sure, I'm also worried about DiffSync being an algorithm that implies statefulness. But we must consider that only way how to make synchronization process efficient always involves holding some state on server (be it e.g. revision control). *ad) AeroGear Data Sync == Differential Synchronization?* DiffSync is not only solution we are working on, it is just the most advanced one. We have started its prototype early to give it a chance to settle down (which may also mean figuring out it is totally inappropriate for any use case we can about and abandoning the idea). We are considering several approaches as outlined in the Data Sync module roadmap from Dan [1]: 1. offline storage (we alreave have that) + conflict detection + conflict resolution 2. realtime updates 3. realtime synchronization It seems that most of the concerns you've mentioned are covered by (1) and that you highlight the importance to get the APIs we are working on in (1) right. That's right and that's exactly the feedback we need at this stage! Solution (2) is extension to (1) that makes sure that clients are updated periodically and so that conflicts happen less often. Solution (3) is extension to (1) and (2) that allows framework to implement efficient synchronization and realtime collaboration. While DiffSync makes conflicts less often, there will always be cases when API for (1) will matter a lot. The API for conflict resolution will be a crucial part, especially considering UI feedback when conflict need to be resolved by an app user himself. *ad) Relevance for various use cases* I completely agree that Differential Synchronization seems a most valid in a case of collaboration on bigger documents. (Note: that's exactly how, lets say Firebase works - you have a huge unstructured document that all of the connected parties can freely modify, while rest of the clients are notified about changes in realtime) DiffSync gives us perfect case for studying a JSON patching strategy that may be base for similar, but better scalable solutions. We have to balance between several concerns Data Sync is connected with (not necessarily complete list): 1. efficiency of synchronization 2. statefulness / scalability 3. first sync after longer period of disconnection (aka batches) 4. prioritization of sync after reconnect (aka slow network connection) 5. simplicity of adoption DiffSync ensures (1) and (3). Slow sync (simple conflict detection + resolution) ensures (2) out of the box. The huge variable part here is (5). I'm very interested in (5). To satisfy all these needs we may build several different, handshake / data-exchange protocols that will make sure all the use cases are covered, and it may be a hybrid approach that will make AeroGear Data Sync relevant in all cases. One protocol can be fallback to another. Such a hybrid solution depends on the application developer what approach he will choose to take (it can be even multiple approaches in one app). We will leave a space for customization by configuration (and plugins). E.g. let's configure how long the document synced with DiffSync (say JSON array of company employees) will be held on the server before it will expire and you fallback to Slow Sync (solution (1) on the roadmap). Thanks for the feedback! Cheers, ~ Lukas [1] https://github.com/danbev/beta.aerogear.org/blob/data-sync-rebirth-roadmap/docs/planning/roadmaps/AeroGearDataSync.asciidoc On Fri, Sep 5, 2014 at 8:32 PM, Randall Hauch wrote: > This does sounds quite interesting, Luk??. If AeroGear uses Differential > Synchronization, this approach might make it more efficient for the server > to implement the behavior. > > But I?m still bothered by the thought that AeroGear?s Data Sync feature > uses any algorithm that requires the server to maintain client-specific > state. > > First of all, servers that maintain no client state across requests will > *always* scale much better than servers that maintain client-specific state > across requests. Maintaining client-specific state requires extra work, > consumes more memory, and complicates clustering, failover, and fault > tolerance. > > Secondly, if a server is maintaining client-specific state, how long does > that client state have to be maintained before assuming the client is no > longer there? What happens when a client on a mobile device loses its > connection for a short period of time and then reconnects? What if load > balancing cause the client to reconnect to a different process in the > cluster? Bottom line is that it adds quite a bit of complexity. > > Finally, I completely understand the benefits of using Differential > Synchronization where many clients are collaborating on a single document. > That?s the ?collaborative editor? scenario, and surely there are apps that > need this functionality. I?m just not convinced that this is the most > common use case. In fact, I think it?s relatively uncommon, and I don?t > think LiveOak will support it in the near term. (BTW, please tell me if the > whole purpose of AeroGear's Data Sync feature is to satisfy this and only > this scenario. If so, then I apologize for being a distraction.) > > My understanding of the Data Sync feature, though, is that it is should be > applicable to other scenarios. IMO, the far more common scenario is: > > > - The server manages (many) millions of small entities, each of which > is a domain-specific aggregate JSON document. Examples of different kinds > of entities include: customers, books, insurance claims, catalog items, > restaurants, purchases, tasks, etc. A single customer entity would > aggregate most/all the information about the customer, including the name, > phone numbers, addresses, profile information, domain-specific privileges > (e.g., authorized to log issues or call support), etc. Note that these > aggregate entities do not correspond to the entities in a traditional > RDBMS/JPA/Hibernate app, where you?d have much finer-grained records > (separate tables for customer, customer addresses, customer phone numbers, > customer privileges, etc.). > - At any point in time there may be 1Ks or 10Ks of clients reading > dozens of documents/entities and sending changes to some of them (likely in > batch operations). IOW, any one document might be concurrently modified by > a relatively small number of clients. > > > I think it?s possible to support Data Sync in this scenario while > maintaining no client-specific state on the server (other than while > processing a single request). > > The Data Sync functionality of the SDK used in the clients would work with > local persistence and enable the app to function online or offline. This > includes making it possible to edit entities and create new entities while > offline, though it does not matter to Data Sync which subset of entities is > persisted locally. If the client goes offline and then back online, the > Data Sync functionality in the SDK would figure out which of the local > entities the client has changed, and request from the server the latest > revisions for each of them. Data Sync then merges the local changes onto > the latest revisions (perhaps asking the user to manually resolve anything > that cannot be automatically resolved), computes the new effective changes, > and then sends a single batch request to the server to apply them. Some, > all or none changes are accepted, and likely the application then has to > decide whether to continue the process again, revert to the server?s > versions, etc. (The SDK would also make use of subscriptions/notifications > so that it can be told immediately when entities are changed.) > > What the batch operations entail is dependent upon the needs of the client > app and capabilities of the server. If a server supports batch operations > that contain the entire entity, then the server will almost certainly need > to put revision identifiers in each entity sent to the client, so that when > the client sends back a modified representation entity, the server can tell > whether that document has since been modified by another client. If so, the > server might rely upon client preferences (see below) to know whether to > merge the changes (using a simple algorithm or more useful > application-specific logic), overwrite, or fail to update the entity. > > On the other hand, the server might support batch operations with partial > updates, where the client only sends for each entity only the set of fields > that are to be changed or removed. Conflicts and merging with this approach > are easier and less-likely to be application specific, though client > preferences (see below) might still dictate whether or not to merge based > upon revision numbers. It also might make it easier for Data Sync, since > the SDK simply has to record for each modified entity only those modified > fields (no matter how long the client was offline). To keep the SDK simple, > a best practice might be to ensure clients always modify together those > fields that must be consistent. For example, in a contacts application, if > a user modifies the first name of a contact, the app might tell the SDK to > modify the first name and last name fields, even though the user didn?t > modify the last name. When synchronized, both the first name and last name > fields would be sent to the server as a single update. This helps ensure > that even when multiple clients are concurrently updating the same set of > fields to different values, the result of applying all of those changes > will exactly match the state as set by one of the clients. > > It?s also likely that for batch operations to work well for many different > kinds of applications, the server may support multiple policies that > specify for a given batch operation the atomicity, consistency, and > isolation guarantees. One policy might ensure that the entire batch either > completely succeeds only when there are no revision conflicts, otherwise it > completely fails. Another policy might be eventually-consistent in the > sense that the changes in every batch operations will eventually be > applied, though this may require the server to have application-specific > conflict resolution logic. And there are policies that are somewhere > in-between. For example, imagine a server that supports ?public? > collections whose entities can be read/updated by any user, and ?private? > collections that expose only the entities that are readable and editable by > that user. The likelihood of a concurrent update conflict on a private > entity is quite small, since it?s possible only when different changes made > on different devices are submitted at exactly the same time. On the other > hand, the likelihood of a concurrent update conflict on a public entity is > much higher. The server may allow updates to both public and private > entities within a single batch operation, and a save policy that might > update all private entities atomically (they all succeed or they all fail) > while updates to *each* public entity is atomic (some might succeed while > others might fail). > > Any given server will likely support only a few of these policies. But > either way, the server has to report back to the client the outcome of the > batch request: which entities were updated, which were not, and the reason > why each of the rejected updates failed (because other entity changes were > rejected, because of a conflict, etc.). The SDK?s Data Sync functionality > would use those results to know how to update the local persisted > representations, and to start trying to resolve any failures. > > The kinds of requests needed to support data sync in this scenario are > fairly basic, so the server doesn?t have to be that complicated. Best of > all, the server is not required to maintain any client-specific state. > > Thoughts? Am I way off-base? > > Best regards, > > Randall > > > > > On Sep 4, 2014, at 10:38 AM, Luk?? Fry? wrote: > > Hey guys, > > > TL;DR: there are ways how to make the memory footprint of Differential > Synchronization (DS) very low; if we assume that JSON patches are > reversible and we create cumulative patches from series of individual > patches, we can use (smart, garbage-collactable) revision control for > storage of documents that server need to maintain. > > ---- > > I had an idea in my head that for couple of days as I was becoming > familiar with how Differential Synchronization (DS) works and studying > Dan's and Luke's impl. > > I share the concern that Randall expressed in earlier thread - the DS in > its pure version doesn't scale for huge amount of users when connected to > one server. > > Sure, the algorithm can be scaled trivially by adding new nodes that uses > very same algorithm as is used for client<->server. But that doesn't mean > it is something that we should do regularly to get more memory available. > > > Instead, I was thinking about limiting a memory that server needs to > maintain in any point in time. > > > In pure DS, server have to maintain all copies of documents that clients > ever requested. Even worse, it has to maintain two copies - "shadow" and > "backup", > > So, in worst case, 2 x N copies of document will be maintained by the > server for N clients. > > ----- > > The DS algorithm doesn't tell us how the "shadow" and "backup" documents > should be stored. > > We can transparently plug in a storage that will be clever about how to > use "backups" and "shadow". > > ----- > > CONCEPTS: > > 1) REVISION CONTROL > > In order to limit a number of documents we need to maintain in server's > memory, we can come with a system where just last known state is remembered > in full version. Together with last known version, we remember also history > of the document for each revision as it was patched by clients. > > But server doesn't have to maintain full history of the document, it > maintains just revisions that are known to its clients (that revision is > known by DS for each client out of the box). > > 2) GARBAGE COLLECTION > > Server trivially knows what versions are mantained by client, so it can > get rid of those revisions that are no longer needed. > > First, it can cut all the history that is older than the oldest version of > document throughout all its clients. > > Secondly, it can accumulate the serious of patches between states so that > it doesn't have to maintain full history, but just revisions that is known > to any of those clients. > > ---- > > DIAGRAM: > > I've attached a picture for illustration of the revision control / garbage > collection, it does not illustrate algorithm itself (Dan did awesome job > describing DS here [3]). > > In the attached diagram, you can see four clients with different revisions: > > Client 1: revision X > Client 2: revision X+3 > Client 3: revision X+3 > Client 4: revision X+4 > > If any of the clients reaches server, server can reconstruct the document > (shadow and backup) for given client revision and the DS algorithm then can > operate as normally (that's why it is transparent from algorithmic point of > view). > > If server comes to garbage collection, it can scan through available > client revisions. As it identifies, that the oldest known revision is X, it > can remove patch for X-1 and less as they are no longer needed. > > Later, it can even more optimize, and accumulate patches so that the only > information he knows is how to get to the revision for each participating > client. In the picture, he can compute cumulative patch for getting from > state X to state X+3, as X+1 and X+2 themselves are not needed. > > (Patch accumulation is actually something that Google Wave does in its > Operational Transformation implementation, just there it is called > cumulative Operations). > > ---- > > Then it comes to caching strategies, you can maintain caches of things > like last recently used revisions (they don't need to be computed each > time). You can store some documents and their revision history to the disk > (fully or partially), etc. > > ---- > > THE USE CASE: > > > 1000 employees maintain one document - Contact List - on their smartphones > > 400 of those employees has mobile data plan, so they want to synchronize > almost immediately as they are notified about changes. The rest of the > devices is connected rather sparely. > > If one employee changes data, 600 devices are notified about the change > immediately (some on data plan, some through Wifi, etc.) Those clients all > have version say X+3, because they are synchronized proactively. > > These clients reach the server in say <10 seconds after that employee did > the change. > > First client reaches server and ask for version X+3 (it probably is still > in the memory, but if it isn't, it is deconstructed and placed into MRU > cache). All of the others reaches the server and re-synchronize themselves > against the one copy of backup/shadow that is in the memory already. > > The other clients will reach the server later, as they are connecting to > Wifi, say in 5 minutes to 24 hours. They will have even older versions, > such as X. Those clients will require more computation, but at the end the > server can resolve them and through their revisions out of the window. > > At the end, there are clients that didn't connected for days, maybe months > - I suggest we don't actually use DS here and fallback to e.g. slow > synchronization (show me what you have, I will show you mine), because > maintaining full history for longer period of days may be too resource > demanding (configurable?). > > Obviously, 1000 is not much, but this can scale to pretty decent numbers > if we use hybrid approach (fallback to other sync strategies if revision is > already forgotten by a server). > > ---- > > WORST CASE: > > we still have to maintain all the document revisions, but practically it > won't happen :-) > > ---- > > ASSUMPTIONS: > > 1. patches are reversible (we are able to compute reverse patch for each > patch sent by client) > 2. patches are cumulative (we are able to compute aggregated patch from > series of patches) > > For 1, it seems many of JSON-patch libraries actually implement it (Java, > JavaScript) [1, 2] > > For 2, it again seems some libraries implement it and if not, we can > implement it or even use brute-force - compute a patch between two documents > > > ---- > > It's not the only way how to make it scale, but it does solve the problem > pretty independently of the DS algorithm and still leaves the algorithm > clean and simple. > > > > Cheers, > > ~ Lukas > > > [1] https://github.com/fge/json-patch > [2] https://github.com/benjamine/jsondiffpatch > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140908/101a5b63/attachment-0001.html From lukas.fryc at gmail.com Mon Sep 8 06:33:26 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Mon, 8 Sep 2014 12:33:26 +0200 Subject: [aerogear-dev] Differential Synchronization: Shadow/Backup Revision Control and its Garbage Collection In-Reply-To: References: Message-ID: On Fri, Sep 5, 2014 at 8:32 PM, Randall Hauch wrote: > > > It?s also likely that for batch operations to work well for many different > kinds of applications, the server may support multiple policies that > specify for a given batch operation the atomicity, consistency, and > isolation guarantees. One policy might ensure that the entire batch either > completely succeeds only when there are no revision conflicts, otherwise it > completely fails. Another policy might be eventually-consistent in the > sense that the changes in every batch operations will eventually be > applied, though this may require the server to have application-specific > conflict resolution logic. And there are policies that are somewhere > in-between. For example, imagine a server that supports ?public? > collections whose entities can be read/updated by any user, and ?private? > collections that expose only the entities that are readable and editable by > that user. The likelihood of a concurrent update conflict on a private > entity is quite small, since it?s possible only when different changes made > on different devices are submitted at exactly the same time. On the other > hand, the likelihood of a concurrent update conflict on a public entity is > much higher. The server may allow updates to both public and private > entities within a single batch operation, and a save policy that might > update all private entities atomically (they all succeed or they all fail) > while updates to *each* public entity is atomic (some might succeed while > others might fail). > I don't believe LiveOak ensure ACID guarantees (at least not on batch update level; correct me if I'm wrong), and I don't think we should start with that. Any given REST call that leads to updating more than one endpoint is not atomic anymore. I would rather say that whole Data Sync is eventually consistent solution (at least in its first versions). Sure, app/user will know that there is a conflict on one of the updated entities (and we may provide an API to make the resolution easier), but it will be up to him to resolve it. Or am I wrong? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140908/eb0f6c9c/attachment.html From lukas.fryc at gmail.com Mon Sep 8 06:35:30 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Mon, 8 Sep 2014 12:35:30 +0200 Subject: [aerogear-dev] Differential Synchronization: Shadow/Backup Revision Control and its Garbage Collection In-Reply-To: References: Message-ID: Oh, sorry for two answers, I noticed Dan already answered to some concerns already. :-) On Mon, Sep 8, 2014 at 12:33 PM, Luk?? Fry? wrote: > > > On Fri, Sep 5, 2014 at 8:32 PM, Randall Hauch wrote: >> >> >> It?s also likely that for batch operations to work well for many >> different kinds of applications, the server may support multiple policies >> that specify for a given batch operation the atomicity, consistency, and >> isolation guarantees. One policy might ensure that the entire batch either >> completely succeeds only when there are no revision conflicts, otherwise it >> completely fails. Another policy might be eventually-consistent in the >> sense that the changes in every batch operations will eventually be >> applied, though this may require the server to have application-specific >> conflict resolution logic. And there are policies that are somewhere >> in-between. For example, imagine a server that supports ?public? >> collections whose entities can be read/updated by any user, and ?private? >> collections that expose only the entities that are readable and editable by >> that user. The likelihood of a concurrent update conflict on a private >> entity is quite small, since it?s possible only when different changes made >> on different devices are submitted at exactly the same time. On the other >> hand, the likelihood of a concurrent update conflict on a public entity is >> much higher. The server may allow updates to both public and private >> entities within a single batch operation, and a save policy that might >> update all private entities atomically (they all succeed or they all fail) >> while updates to *each* public entity is atomic (some might succeed while >> others might fail). >> > > > I don't believe LiveOak ensure ACID guarantees (at least not on batch > update level; correct me if I'm wrong), and I don't think we should start > with that. > Any given REST call that leads to updating more than one endpoint is not > atomic anymore. > > I would rather say that whole Data Sync is eventually consistent solution > (at least in its first versions). > > Sure, app/user will know that there is a conflict on one of the updated > entities (and we may provide an API to make the resolution easier), but it > will be up to him to resolve it. > > Or am I wrong? > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140908/71f963ab/attachment.html From lukas.fryc at gmail.com Mon Sep 8 07:37:05 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Mon, 8 Sep 2014 13:37:05 +0200 Subject: [aerogear-dev] Differential Synchronization: Shadow/Backup Revision Control and its Garbage Collection In-Reply-To: References: Message-ID: On Mon, Sep 8, 2014 at 11:04 AM, Daniel Bevenius wrote: > >What if load balancing cause the client to reconnect to a different process in the cluster? > If we allow for different types of what we currently call a DataStore to be pluggable, then it would be possible for that client to reconnect to a different instance with the assumption here that the underlying datastore is distributed. > > Yeah, the problem here will still be that Shadows/Backups themselves aren't distributed - if failover or load balancing causes the client go to another node in distributed DiffSync scenario, then we would lose a state. What we can do? * Sticky sessions? * Having revision control distributed (Infinispan?) At the end, a less effective-strategy (say SlowSync) can always be used as a fallback! > > > > If the client goes offline and then back online, the Data Sync functionality in the SDK would figure out which of the local entities the client has changed, and request from the server the latest revisions for each of them. Data Sync then merges the local changes onto the latest revisions (perhaps asking the user to manually resolve anything that cannot be automatically resolved), computes the new effective changes, and then sends a single batch request to the server to apply them. Some, all or none changes are accepted, and likely the application then has to decide whether to continue the process again, revert to the server?s versions, etc. > This sounds simliar to what we have discussed as conflict resolution in the Data Sync roadmap. It differs somewhat, like we don't specify anything with regard to batches as the goal it to limit the changes need for existing server implementations, in that the server only detects a conflict and does not try to apply any effective changes/operations/patches but instead works with complete objects/documents. > > Right, we need to add batches to the roadmap (batches as a case for reconnects after longer period of time). What about second milestone? > > I think there will be use cases for both the conflict resolution and the data sync approaches and users that might be quite happy with conflict resolution. I think it would make sense to split the two roadmaps/specs into separate ones. At the moment it looks, and was the original idea, that this would involve into the "real-time" datasync solution. But have these separate would hopefully make this clear that these are independent and can evolve independently. > > Yes, I agree that Data Sync can be conceptually split into two pieces: 1) Simple Data Sync (persistence (we already have it), conflict detection, resolution, partial updates, batch updates, notifications) 2) Realtime Data Sync (+ with all the above) The client APIs for those should be same. It's likely that part of (1) can be reused in (2) and vice versa. > Does this sound alright with everyone? > > Thanks, > > /Dan > > > > On 5 September 2014 20:32, Randall Hauch wrote: > >> This does sounds quite interesting, Luk??. If AeroGear uses Differential >> Synchronization, this approach might make it more efficient for the server >> to implement the behavior. >> >> But I?m still bothered by the thought that AeroGear?s Data Sync feature >> uses any algorithm that requires the server to maintain client-specific >> state. >> >> First of all, servers that maintain no client state across requests will >> *always* scale much better than servers that maintain client-specific state >> across requests. Maintaining client-specific state requires extra work, >> consumes more memory, and complicates clustering, failover, and fault >> tolerance. >> >> Secondly, if a server is maintaining client-specific state, how long does >> that client state have to be maintained before assuming the client is no >> longer there? What happens when a client on a mobile device loses its >> connection for a short period of time and then reconnects? What if load >> balancing cause the client to reconnect to a different process in the >> cluster? Bottom line is that it adds quite a bit of complexity. >> >> Finally, I completely understand the benefits of using Differential >> Synchronization where many clients are collaborating on a single document. >> That?s the ?collaborative editor? scenario, and surely there are apps that >> need this functionality. I?m just not convinced that this is the most >> common use case. In fact, I think it?s relatively uncommon, and I don?t >> think LiveOak will support it in the near term. (BTW, please tell me if the >> whole purpose of AeroGear's Data Sync feature is to satisfy this and only >> this scenario. If so, then I apologize for being a distraction.) >> >> My understanding of the Data Sync feature, though, is that it is should >> be applicable to other scenarios. IMO, the far more common scenario is: >> >> >> - The server manages (many) millions of small entities, each of which >> is a domain-specific aggregate JSON document. Examples of different kinds >> of entities include: customers, books, insurance claims, catalog items, >> restaurants, purchases, tasks, etc. A single customer entity would >> aggregate most/all the information about the customer, including the name, >> phone numbers, addresses, profile information, domain-specific privileges >> (e.g., authorized to log issues or call support), etc. Note that these >> aggregate entities do not correspond to the entities in a traditional >> RDBMS/JPA/Hibernate app, where you?d have much finer-grained records >> (separate tables for customer, customer addresses, customer phone numbers, >> customer privileges, etc.). >> - At any point in time there may be 1Ks or 10Ks of clients reading >> dozens of documents/entities and sending changes to some of them (likely in >> batch operations). IOW, any one document might be concurrently modified by >> a relatively small number of clients. >> >> >> I think it?s possible to support Data Sync in this scenario while >> maintaining no client-specific state on the server (other than while >> processing a single request). >> >> The Data Sync functionality of the SDK used in the clients would work >> with local persistence and enable the app to function online or offline. >> This includes making it possible to edit entities and create new entities >> while offline, though it does not matter to Data Sync which subset of >> entities is persisted locally. If the client goes offline and then back >> online, the Data Sync functionality in the SDK would figure out which of >> the local entities the client has changed, and request from the server the >> latest revisions for each of them. Data Sync then merges the local changes >> onto the latest revisions (perhaps asking the user to manually resolve >> anything that cannot be automatically resolved), computes the new effective >> changes, and then sends a single batch request to the server to apply them. >> Some, all or none changes are accepted, and likely the application then has >> to decide whether to continue the process again, revert to the server?s >> versions, etc. (The SDK would also make use of subscriptions/notifications >> so that it can be told immediately when entities are changed.) >> >> What the batch operations entail is dependent upon the needs of the >> client app and capabilities of the server. If a server supports batch >> operations that contain the entire entity, then the server will almost >> certainly need to put revision identifiers in each entity sent to the >> client, so that when the client sends back a modified representation >> entity, the server can tell whether that document has since been modified >> by another client. If so, the server might rely upon client preferences >> (see below) to know whether to merge the changes (using a simple algorithm >> or more useful application-specific logic), overwrite, or fail to update >> the entity. >> >> On the other hand, the server might support batch operations with partial >> updates, where the client only sends for each entity only the set of fields >> that are to be changed or removed. Conflicts and merging with this approach >> are easier and less-likely to be application specific, though client >> preferences (see below) might still dictate whether or not to merge based >> upon revision numbers. It also might make it easier for Data Sync, since >> the SDK simply has to record for each modified entity only those modified >> fields (no matter how long the client was offline). To keep the SDK simple, >> a best practice might be to ensure clients always modify together those >> fields that must be consistent. For example, in a contacts application, if >> a user modifies the first name of a contact, the app might tell the SDK to >> modify the first name and last name fields, even though the user didn?t >> modify the last name. When synchronized, both the first name and last name >> fields would be sent to the server as a single update. This helps ensure >> that even when multiple clients are concurrently updating the same set of >> fields to different values, the result of applying all of those changes >> will exactly match the state as set by one of the clients. >> >> It?s also likely that for batch operations to work well for many >> different kinds of applications, the server may support multiple policies >> that specify for a given batch operation the atomicity, consistency, and >> isolation guarantees. One policy might ensure that the entire batch either >> completely succeeds only when there are no revision conflicts, otherwise it >> completely fails. Another policy might be eventually-consistent in the >> sense that the changes in every batch operations will eventually be >> applied, though this may require the server to have application-specific >> conflict resolution logic. And there are policies that are somewhere >> in-between. For example, imagine a server that supports ?public? >> collections whose entities can be read/updated by any user, and ?private? >> collections that expose only the entities that are readable and editable by >> that user. The likelihood of a concurrent update conflict on a private >> entity is quite small, since it?s possible only when different changes made >> on different devices are submitted at exactly the same time. On the other >> hand, the likelihood of a concurrent update conflict on a public entity is >> much higher. The server may allow updates to both public and private >> entities within a single batch operation, and a save policy that might >> update all private entities atomically (they all succeed or they all fail) >> while updates to *each* public entity is atomic (some might succeed while >> others might fail). >> >> Any given server will likely support only a few of these policies. But >> either way, the server has to report back to the client the outcome of the >> batch request: which entities were updated, which were not, and the reason >> why each of the rejected updates failed (because other entity changes were >> rejected, because of a conflict, etc.). The SDK?s Data Sync functionality >> would use those results to know how to update the local persisted >> representations, and to start trying to resolve any failures. >> >> The kinds of requests needed to support data sync in this scenario are >> fairly basic, so the server doesn?t have to be that complicated. Best of >> all, the server is not required to maintain any client-specific state. >> >> Thoughts? Am I way off-base? >> >> Best regards, >> >> Randall >> >> >> >> >> On Sep 4, 2014, at 10:38 AM, Luk?? Fry? wrote: >> >> Hey guys, >> >> >> TL;DR: there are ways how to make the memory footprint of Differential >> Synchronization (DS) very low; if we assume that JSON patches are >> reversible and we create cumulative patches from series of individual >> patches, we can use (smart, garbage-collactable) revision control for >> storage of documents that server need to maintain. >> >> ---- >> >> I had an idea in my head that for couple of days as I was becoming >> familiar with how Differential Synchronization (DS) works and studying >> Dan's and Luke's impl. >> >> I share the concern that Randall expressed in earlier thread - the DS in >> its pure version doesn't scale for huge amount of users when connected to >> one server. >> >> Sure, the algorithm can be scaled trivially by adding new nodes that uses >> very same algorithm as is used for client<->server. But that doesn't mean >> it is something that we should do regularly to get more memory available. >> >> >> Instead, I was thinking about limiting a memory that server needs to >> maintain in any point in time. >> >> >> In pure DS, server have to maintain all copies of documents that clients >> ever requested. Even worse, it has to maintain two copies - "shadow" and >> "backup", >> >> So, in worst case, 2 x N copies of document will be maintained by the >> server for N clients. >> >> ----- >> >> The DS algorithm doesn't tell us how the "shadow" and "backup" documents >> should be stored. >> >> We can transparently plug in a storage that will be clever about how to >> use "backups" and "shadow". >> >> ----- >> >> CONCEPTS: >> >> 1) REVISION CONTROL >> >> In order to limit a number of documents we need to maintain in server's >> memory, we can come with a system where just last known state is remembered >> in full version. Together with last known version, we remember also history >> of the document for each revision as it was patched by clients. >> >> But server doesn't have to maintain full history of the document, it >> maintains just revisions that are known to its clients (that revision is >> known by DS for each client out of the box). >> >> 2) GARBAGE COLLECTION >> >> Server trivially knows what versions are mantained by client, so it can >> get rid of those revisions that are no longer needed. >> >> First, it can cut all the history that is older than the oldest version >> of document throughout all its clients. >> >> Secondly, it can accumulate the serious of patches between states so that >> it doesn't have to maintain full history, but just revisions that is known >> to any of those clients. >> >> ---- >> >> DIAGRAM: >> >> I've attached a picture for illustration of the revision control / >> garbage collection, it does not illustrate algorithm itself (Dan did >> awesome job describing DS here [3]). >> >> In the attached diagram, you can see four clients with different >> revisions: >> >> Client 1: revision X >> Client 2: revision X+3 >> Client 3: revision X+3 >> Client 4: revision X+4 >> >> If any of the clients reaches server, server can reconstruct the document >> (shadow and backup) for given client revision and the DS algorithm then can >> operate as normally (that's why it is transparent from algorithmic point of >> view). >> >> If server comes to garbage collection, it can scan through available >> client revisions. As it identifies, that the oldest known revision is X, it >> can remove patch for X-1 and less as they are no longer needed. >> >> Later, it can even more optimize, and accumulate patches so that the only >> information he knows is how to get to the revision for each participating >> client. In the picture, he can compute cumulative patch for getting from >> state X to state X+3, as X+1 and X+2 themselves are not needed. >> >> (Patch accumulation is actually something that Google Wave does in its >> Operational Transformation implementation, just there it is called >> cumulative Operations). >> >> ---- >> >> Then it comes to caching strategies, you can maintain caches of things >> like last recently used revisions (they don't need to be computed each >> time). You can store some documents and their revision history to the disk >> (fully or partially), etc. >> >> ---- >> >> THE USE CASE: >> >> >> 1000 employees maintain one document - Contact List - on their smartphones >> >> 400 of those employees has mobile data plan, so they want to synchronize >> almost immediately as they are notified about changes. The rest of the >> devices is connected rather sparely. >> >> If one employee changes data, 600 devices are notified about the change >> immediately (some on data plan, some through Wifi, etc.) Those clients all >> have version say X+3, because they are synchronized proactively. >> >> These clients reach the server in say <10 seconds after that employee did >> the change. >> >> First client reaches server and ask for version X+3 (it probably is still >> in the memory, but if it isn't, it is deconstructed and placed into MRU >> cache). All of the others reaches the server and re-synchronize themselves >> against the one copy of backup/shadow that is in the memory already. >> >> The other clients will reach the server later, as they are connecting to >> Wifi, say in 5 minutes to 24 hours. They will have even older versions, >> such as X. Those clients will require more computation, but at the end the >> server can resolve them and through their revisions out of the window. >> >> At the end, there are clients that didn't connected for days, maybe >> months - I suggest we don't actually use DS here and fallback to e.g. slow >> synchronization (show me what you have, I will show you mine), because >> maintaining full history for longer period of days may be too resource >> demanding (configurable?). >> >> Obviously, 1000 is not much, but this can scale to pretty decent numbers >> if we use hybrid approach (fallback to other sync strategies if revision is >> already forgotten by a server). >> >> ---- >> >> WORST CASE: >> >> we still have to maintain all the document revisions, but practically it >> won't happen :-) >> >> ---- >> >> ASSUMPTIONS: >> >> 1. patches are reversible (we are able to compute reverse patch for each >> patch sent by client) >> 2. patches are cumulative (we are able to compute aggregated patch from >> series of patches) >> >> For 1, it seems many of JSON-patch libraries actually implement it (Java, >> JavaScript) [1, 2] >> >> For 2, it again seems some libraries implement it and if not, we can >> implement it or even use brute-force - compute a patch between two documents >> >> >> ---- >> >> It's not the only way how to make it scale, but it does solve the problem >> pretty independently of the DS algorithm and still leaves the algorithm >> clean and simple. >> >> >> >> Cheers, >> >> ~ Lukas >> >> >> [1] https://github.com/fge/json-patch >> [2] https://github.com/benjamine/jsondiffpatch >> _______________________________________________ >> 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 >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140908/5e74ddfa/attachment-0001.html From daniel.bevenius at gmail.com Mon Sep 8 07:49:08 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 8 Sep 2014 13:49:08 +0200 Subject: [aerogear-dev] Differential Synchronization: Shadow/Backup Revision Control and its Garbage Collection In-Reply-To: References: Message-ID: >Yeah, the problem here will still be that Shadows/Backups themselves aren't distributed - if failover or load balancing causes the client go to another node in distributed DiffSync scenario, then we would lose a state. If the scenario of the document being stored in a distributed datastore then so would the Shadow/Backups. >What about second milestone? We can certainly add a second and more milestones for additional features. On 8 September 2014 13:37, Luk?? Fry? wrote: > > > On Mon, Sep 8, 2014 at 11:04 AM, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > >> >What if load balancing cause the client to reconnect to a different process in the cluster? >> If we allow for different types of what we currently call a DataStore to be pluggable, then it would be possible for that client to reconnect to a different instance with the assumption here that the underlying datastore is distributed. >> >> > Yeah, the problem here will still be that Shadows/Backups themselves > aren't distributed - if failover or load balancing causes the client go to > another node in distributed DiffSync scenario, then we would lose a state. > What we can do? > > * Sticky sessions? > * Having revision control distributed (Infinispan?) > > At the end, a less effective-strategy (say SlowSync) can always be used as > a fallback! > > > > >> >> >> > If the client goes offline and then back online, the Data Sync functionality in the SDK would figure out which of the local entities the client has changed, and request from the server the latest revisions for each of them. Data Sync then merges the local changes onto the latest revisions (perhaps asking the user to manually resolve anything that cannot be automatically resolved), computes the new effective changes, and then sends a single batch request to the server to apply them. Some, all or none changes are accepted, and likely the application then has to decide whether to continue the process again, revert to the server?s versions, etc. >> This sounds simliar to what we have discussed as conflict resolution in the Data Sync roadmap. It differs somewhat, like we don't specify anything with regard to batches as the goal it to limit the changes need for existing server implementations, in that the server only detects a conflict and does not try to apply any effective changes/operations/patches but instead works with complete objects/documents. >> >> > > Right, we need to add batches to the roadmap (batches as a case for > reconnects after longer period of time). > What about second milestone? > > >> >> I think there will be use cases for both the conflict resolution and the data sync approaches and users that might be quite happy with conflict resolution. I think it would make sense to split the two roadmaps/specs into separate ones. At the moment it looks, and was the original idea, that this would involve into the "real-time" datasync solution. But have these separate would hopefully make this clear that these are independent and can evolve independently. >> >> > Yes, I agree that Data Sync can be conceptually split into two pieces: > > 1) Simple Data Sync (persistence (we already have it), conflict detection, > resolution, partial updates, batch updates, notifications) > 2) Realtime Data Sync (+ with all the above) > > The client APIs for those should be same. > > It's likely that part of (1) can be reused in (2) and vice versa. > > > >> Does this sound alright with everyone? >> >> Thanks, >> >> /Dan >> >> >> >> On 5 September 2014 20:32, Randall Hauch wrote: >> >>> This does sounds quite interesting, Luk??. If AeroGear uses Differential >>> Synchronization, this approach might make it more efficient for the server >>> to implement the behavior. >>> >>> But I?m still bothered by the thought that AeroGear?s Data Sync feature >>> uses any algorithm that requires the server to maintain client-specific >>> state. >>> >>> First of all, servers that maintain no client state across requests will >>> *always* scale much better than servers that maintain client-specific state >>> across requests. Maintaining client-specific state requires extra work, >>> consumes more memory, and complicates clustering, failover, and fault >>> tolerance. >>> >>> Secondly, if a server is maintaining client-specific state, how long >>> does that client state have to be maintained before assuming the client is >>> no longer there? What happens when a client on a mobile device loses its >>> connection for a short period of time and then reconnects? What if load >>> balancing cause the client to reconnect to a different process in the >>> cluster? Bottom line is that it adds quite a bit of complexity. >>> >>> Finally, I completely understand the benefits of using Differential >>> Synchronization where many clients are collaborating on a single document. >>> That?s the ?collaborative editor? scenario, and surely there are apps that >>> need this functionality. I?m just not convinced that this is the most >>> common use case. In fact, I think it?s relatively uncommon, and I don?t >>> think LiveOak will support it in the near term. (BTW, please tell me if the >>> whole purpose of AeroGear's Data Sync feature is to satisfy this and only >>> this scenario. If so, then I apologize for being a distraction.) >>> >>> My understanding of the Data Sync feature, though, is that it is should >>> be applicable to other scenarios. IMO, the far more common scenario is: >>> >>> >>> - The server manages (many) millions of small entities, each of >>> which is a domain-specific aggregate JSON document. Examples of different >>> kinds of entities include: customers, books, insurance claims, catalog >>> items, restaurants, purchases, tasks, etc. A single customer entity would >>> aggregate most/all the information about the customer, including the name, >>> phone numbers, addresses, profile information, domain-specific privileges >>> (e.g., authorized to log issues or call support), etc. Note that these >>> aggregate entities do not correspond to the entities in a traditional >>> RDBMS/JPA/Hibernate app, where you?d have much finer-grained records >>> (separate tables for customer, customer addresses, customer phone numbers, >>> customer privileges, etc.). >>> - At any point in time there may be 1Ks or 10Ks of clients reading >>> dozens of documents/entities and sending changes to some of them (likely in >>> batch operations). IOW, any one document might be concurrently modified by >>> a relatively small number of clients. >>> >>> >>> I think it?s possible to support Data Sync in this scenario while >>> maintaining no client-specific state on the server (other than while >>> processing a single request). >>> >>> The Data Sync functionality of the SDK used in the clients would work >>> with local persistence and enable the app to function online or offline. >>> This includes making it possible to edit entities and create new entities >>> while offline, though it does not matter to Data Sync which subset of >>> entities is persisted locally. If the client goes offline and then back >>> online, the Data Sync functionality in the SDK would figure out which of >>> the local entities the client has changed, and request from the server the >>> latest revisions for each of them. Data Sync then merges the local changes >>> onto the latest revisions (perhaps asking the user to manually resolve >>> anything that cannot be automatically resolved), computes the new effective >>> changes, and then sends a single batch request to the server to apply them. >>> Some, all or none changes are accepted, and likely the application then has >>> to decide whether to continue the process again, revert to the server?s >>> versions, etc. (The SDK would also make use of subscriptions/notifications >>> so that it can be told immediately when entities are changed.) >>> >>> What the batch operations entail is dependent upon the needs of the >>> client app and capabilities of the server. If a server supports batch >>> operations that contain the entire entity, then the server will almost >>> certainly need to put revision identifiers in each entity sent to the >>> client, so that when the client sends back a modified representation >>> entity, the server can tell whether that document has since been modified >>> by another client. If so, the server might rely upon client preferences >>> (see below) to know whether to merge the changes (using a simple algorithm >>> or more useful application-specific logic), overwrite, or fail to update >>> the entity. >>> >>> On the other hand, the server might support batch operations with >>> partial updates, where the client only sends for each entity only the set >>> of fields that are to be changed or removed. Conflicts and merging with >>> this approach are easier and less-likely to be application specific, though >>> client preferences (see below) might still dictate whether or not to merge >>> based upon revision numbers. It also might make it easier for Data Sync, >>> since the SDK simply has to record for each modified entity only those >>> modified fields (no matter how long the client was offline). To keep the >>> SDK simple, a best practice might be to ensure clients always modify >>> together those fields that must be consistent. For example, in a contacts >>> application, if a user modifies the first name of a contact, the app might >>> tell the SDK to modify the first name and last name fields, even though the >>> user didn?t modify the last name. When synchronized, both the first name >>> and last name fields would be sent to the server as a single update. This >>> helps ensure that even when multiple clients are concurrently updating the >>> same set of fields to different values, the result of applying all of those >>> changes will exactly match the state as set by one of the clients. >>> >>> It?s also likely that for batch operations to work well for many >>> different kinds of applications, the server may support multiple policies >>> that specify for a given batch operation the atomicity, consistency, and >>> isolation guarantees. One policy might ensure that the entire batch either >>> completely succeeds only when there are no revision conflicts, otherwise it >>> completely fails. Another policy might be eventually-consistent in the >>> sense that the changes in every batch operations will eventually be >>> applied, though this may require the server to have application-specific >>> conflict resolution logic. And there are policies that are somewhere >>> in-between. For example, imagine a server that supports ?public? >>> collections whose entities can be read/updated by any user, and ?private? >>> collections that expose only the entities that are readable and editable by >>> that user. The likelihood of a concurrent update conflict on a private >>> entity is quite small, since it?s possible only when different changes made >>> on different devices are submitted at exactly the same time. On the other >>> hand, the likelihood of a concurrent update conflict on a public entity is >>> much higher. The server may allow updates to both public and private >>> entities within a single batch operation, and a save policy that might >>> update all private entities atomically (they all succeed or they all fail) >>> while updates to *each* public entity is atomic (some might succeed while >>> others might fail). >>> >>> Any given server will likely support only a few of these policies. But >>> either way, the server has to report back to the client the outcome of the >>> batch request: which entities were updated, which were not, and the reason >>> why each of the rejected updates failed (because other entity changes were >>> rejected, because of a conflict, etc.). The SDK?s Data Sync functionality >>> would use those results to know how to update the local persisted >>> representations, and to start trying to resolve any failures. >>> >>> The kinds of requests needed to support data sync in this scenario are >>> fairly basic, so the server doesn?t have to be that complicated. Best of >>> all, the server is not required to maintain any client-specific state. >>> >>> Thoughts? Am I way off-base? >>> >>> Best regards, >>> >>> Randall >>> >>> >>> >>> >>> On Sep 4, 2014, at 10:38 AM, Luk?? Fry? wrote: >>> >>> Hey guys, >>> >>> >>> TL;DR: there are ways how to make the memory footprint of Differential >>> Synchronization (DS) very low; if we assume that JSON patches are >>> reversible and we create cumulative patches from series of individual >>> patches, we can use (smart, garbage-collactable) revision control for >>> storage of documents that server need to maintain. >>> >>> ---- >>> >>> I had an idea in my head that for couple of days as I was becoming >>> familiar with how Differential Synchronization (DS) works and studying >>> Dan's and Luke's impl. >>> >>> I share the concern that Randall expressed in earlier thread - the DS in >>> its pure version doesn't scale for huge amount of users when connected to >>> one server. >>> >>> Sure, the algorithm can be scaled trivially by adding new nodes that >>> uses very same algorithm as is used for client<->server. But that doesn't >>> mean it is something that we should do regularly to get more memory >>> available. >>> >>> >>> Instead, I was thinking about limiting a memory that server needs to >>> maintain in any point in time. >>> >>> >>> In pure DS, server have to maintain all copies of documents that clients >>> ever requested. Even worse, it has to maintain two copies - "shadow" and >>> "backup", >>> >>> So, in worst case, 2 x N copies of document will be maintained by the >>> server for N clients. >>> >>> ----- >>> >>> The DS algorithm doesn't tell us how the "shadow" and "backup" documents >>> should be stored. >>> >>> We can transparently plug in a storage that will be clever about how to >>> use "backups" and "shadow". >>> >>> ----- >>> >>> CONCEPTS: >>> >>> 1) REVISION CONTROL >>> >>> In order to limit a number of documents we need to maintain in server's >>> memory, we can come with a system where just last known state is remembered >>> in full version. Together with last known version, we remember also history >>> of the document for each revision as it was patched by clients. >>> >>> But server doesn't have to maintain full history of the document, it >>> maintains just revisions that are known to its clients (that revision is >>> known by DS for each client out of the box). >>> >>> 2) GARBAGE COLLECTION >>> >>> Server trivially knows what versions are mantained by client, so it can >>> get rid of those revisions that are no longer needed. >>> >>> First, it can cut all the history that is older than the oldest version >>> of document throughout all its clients. >>> >>> Secondly, it can accumulate the serious of patches between states so >>> that it doesn't have to maintain full history, but just revisions that is >>> known to any of those clients. >>> >>> ---- >>> >>> DIAGRAM: >>> >>> I've attached a picture for illustration of the revision control / >>> garbage collection, it does not illustrate algorithm itself (Dan did >>> awesome job describing DS here [3]). >>> >>> In the attached diagram, you can see four clients with different >>> revisions: >>> >>> Client 1: revision X >>> Client 2: revision X+3 >>> Client 3: revision X+3 >>> Client 4: revision X+4 >>> >>> If any of the clients reaches server, server can reconstruct the >>> document (shadow and backup) for given client revision and the DS algorithm >>> then can operate as normally (that's why it is transparent from algorithmic >>> point of view). >>> >>> If server comes to garbage collection, it can scan through available >>> client revisions. As it identifies, that the oldest known revision is X, it >>> can remove patch for X-1 and less as they are no longer needed. >>> >>> Later, it can even more optimize, and accumulate patches so that the >>> only information he knows is how to get to the revision for each >>> participating client. In the picture, he can compute cumulative patch for >>> getting from state X to state X+3, as X+1 and X+2 themselves are not needed. >>> >>> (Patch accumulation is actually something that Google Wave does in its >>> Operational Transformation implementation, just there it is called >>> cumulative Operations). >>> >>> ---- >>> >>> Then it comes to caching strategies, you can maintain caches of things >>> like last recently used revisions (they don't need to be computed each >>> time). You can store some documents and their revision history to the disk >>> (fully or partially), etc. >>> >>> ---- >>> >>> THE USE CASE: >>> >>> >>> 1000 employees maintain one document - Contact List - on their >>> smartphones >>> >>> 400 of those employees has mobile data plan, so they want to synchronize >>> almost immediately as they are notified about changes. The rest of the >>> devices is connected rather sparely. >>> >>> If one employee changes data, 600 devices are notified about the change >>> immediately (some on data plan, some through Wifi, etc.) Those clients all >>> have version say X+3, because they are synchronized proactively. >>> >>> These clients reach the server in say <10 seconds after that employee >>> did the change. >>> >>> First client reaches server and ask for version X+3 (it probably is >>> still in the memory, but if it isn't, it is deconstructed and placed into >>> MRU cache). All of the others reaches the server and re-synchronize >>> themselves against the one copy of backup/shadow that is in the memory >>> already. >>> >>> The other clients will reach the server later, as they are connecting to >>> Wifi, say in 5 minutes to 24 hours. They will have even older versions, >>> such as X. Those clients will require more computation, but at the end the >>> server can resolve them and through their revisions out of the window. >>> >>> At the end, there are clients that didn't connected for days, maybe >>> months - I suggest we don't actually use DS here and fallback to e.g. slow >>> synchronization (show me what you have, I will show you mine), because >>> maintaining full history for longer period of days may be too resource >>> demanding (configurable?). >>> >>> Obviously, 1000 is not much, but this can scale to pretty decent numbers >>> if we use hybrid approach (fallback to other sync strategies if revision is >>> already forgotten by a server). >>> >>> ---- >>> >>> WORST CASE: >>> >>> we still have to maintain all the document revisions, but practically it >>> won't happen :-) >>> >>> ---- >>> >>> ASSUMPTIONS: >>> >>> 1. patches are reversible (we are able to compute reverse patch for each >>> patch sent by client) >>> 2. patches are cumulative (we are able to compute aggregated patch from >>> series of patches) >>> >>> For 1, it seems many of JSON-patch libraries actually implement it >>> (Java, JavaScript) [1, 2] >>> >>> For 2, it again seems some libraries implement it and if not, we can >>> implement it or even use brute-force - compute a patch between two documents >>> >>> >>> ---- >>> >>> It's not the only way how to make it scale, but it does solve the >>> problem pretty independently of the DS algorithm and still leaves the >>> algorithm clean and simple. >>> >>> >>> >>> Cheers, >>> >>> ~ Lukas >>> >>> >>> [1] https://github.com/fge/json-patch >>> [2] https://github.com/benjamine/jsondiffpatch >>> _______________________________________________ >>> 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 >>> >> >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140908/b5a2c506/attachment-0001.html From lukas.fryc at gmail.com Mon Sep 8 08:04:24 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Mon, 8 Sep 2014 14:04:24 +0200 Subject: [aerogear-dev] Data Sync: use of IETFs formats Message-ID: Hey guys, I've recently encountered two standard formats that standardizes the HTTP PATCH, that could be important for formats we use for Data Sync features: *json-patch* http://tools.ietf.org/html/rfc6902 Defines set of operations that you can do with JSON object such as: add, remove, replace, move, copy, replace, test. [ { "op": "test", "path": "/a/b/c", "value": "foo" }, { "op": "remove", "path": "/a/b/c" }, { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] }, { "op": "replace", "path": "/a/b/c", "value": 42 }, { "op": "move", "from": "/a/b/c", "path": "/a/b/d" }, { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" } ] The structure of the patch is list of operations, not the document itself. We could actually rewrite DiffSync Server to use it (since it is very close to that format). *json-merge-patch* (draft) http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-0 Defines a format where you send updated parts of the JSON Object itself in same structure as original object: e.g.: object: { "a": "b", "c": { "d": "e", "f": "g" } } patch: { "a":"z", "c": { "f": null } } Cheers, ~ Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140908/e5de9a1f/attachment.html From kpiwko at redhat.com Mon Sep 8 08:17:05 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Mon, 08 Sep 2014 14:17:05 +0200 Subject: [aerogear-dev] Should Cordova push plugin dependencies be shrinkwrapped? In-Reply-To: References: Message-ID: <1410178625.4260.26.camel@kpiwko-x220> +1, we were hardcoding versions in UPS and this change in Cordova plugin has slipped of QE eyes. On Thu, 2014-09-04 at 18:33 +0200, Luk?? Fry? wrote: > +1 it should definitely point to the specific version > > > On Thu, Sep 4, 2014 at 5:05 PM, Gorkem Ercan wrote: > > > Hi All, > > I have been working cordova push quickstarts and noticed that on Android > > installation through JBoss tools started to fail. > > > > After a bit of investigation I figured that the failure occurs because > > push plugin defines cordova plugin "com.google.playservices" as a > > dependency through a git URL[1] that points to the master of the plugin's > > repo. Unfortunately this repo received a change [2] which started to use a > > new feature that was not implemented for JBoss tools. In this particular > > case, I am already implementing the missing feature so it should be all > > good soon. However I have doubts that referencing a dependency through > > master is a good idea. I think it may not only make it really difficult for > > us to reproduce cases but also unexpected behaviour may just appear. > > > > > > [1] https://github.com/MobileChromeApps/google-play-services > > [2] > > https://github.com/MobileChromeApps/google-play-services/commit/41c19152c21981c9a2f6497cc2100c317f5c660d > > > > _______________________________________________ > > 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 From corinnekrych at gmail.com Mon Sep 8 08:20:58 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 8 Sep 2014 14:20:58 +0200 Subject: [aerogear-dev] Data Sync: use of IETFs formats In-Reply-To: References: Message-ID: <23CE72FF-DB66-4CFF-A849-95E1941EE38D@gmail.com> On 08 Sep 2014, at 14:04, Luk?? Fry? wrote: > Hey guys, > > I've recently encountered two standard formats that standardizes the HTTP PATCH, that could be important for formats we use for Data Sync features: > > json-patch > http://tools.ietf.org/html/rfc6902 +1 Yeap I mentioned it too in theis thread http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Comparing-sync-in-Android-vs-other-platforms-td6617.html#a6637 some time ago > > Defines set of operations that you can do with JSON object such as: add, remove, replace, move, copy, replace, test. > > [ > { "op": "test", "path": "/a/b/c", "value": "foo" }, > { "op": "remove", "path": "/a/b/c" }, > { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] }, > { "op": "replace", "path": "/a/b/c", "value": 42 }, > { "op": "move", "from": "/a/b/c", "path": "/a/b/d" }, > { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" } > ] > > The structure of the patch is list of operations, not the document itself. > > We could actually rewrite DiffSync Server to use it (since it is very close to that format). > > > > json-merge-patch (draft) > http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-0 > > Defines a format where you send updated parts of the JSON Object itself in same structure as original object: > > e.g.: object: > > { > "a": "b", > "c": { > "d": "e", > "f": "g" > } > } > > patch: > > { > "a":"z", > "c": { > "f": null > } > } > > > > Cheers, > > ~ Lukas > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From lukas.fryc at gmail.com Mon Sep 8 08:43:01 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Mon, 8 Sep 2014 14:43:01 +0200 Subject: [aerogear-dev] Data Sync: use of IETFs formats In-Reply-To: <23CE72FF-DB66-4CFF-A849-95E1941EE38D@gmail.com> References: <23CE72FF-DB66-4CFF-A849-95E1941EE38D@gmail.com> Message-ID: Ah, thanks Corinne! I wasn't sure and didn't remember it! On Mon, Sep 8, 2014 at 2:20 PM, Corinne Krych wrote: > > On 08 Sep 2014, at 14:04, Luk?? Fry? wrote: > > > Hey guys, > > > > I've recently encountered two standard formats that standardizes the > HTTP PATCH, that could be important for formats we use for Data Sync > features: > > > > json-patch > > http://tools.ietf.org/html/rfc6902 > > +1 > > Yeap I mentioned it too in theis thread > > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Comparing-sync-in-Android-vs-other-platforms-td6617.html#a6637 > some time ago > > > > > > Defines set of operations that you can do with JSON object such as: add, > remove, replace, move, copy, replace, test. > > > > [ > > { "op": "test", "path": "/a/b/c", "value": "foo" }, > > { "op": "remove", "path": "/a/b/c" }, > > { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] }, > > { "op": "replace", "path": "/a/b/c", "value": 42 }, > > { "op": "move", "from": "/a/b/c", "path": "/a/b/d" }, > > { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" } > > ] > > > > The structure of the patch is list of operations, not the document > itself. > > > > We could actually rewrite DiffSync Server to use it (since it is very > close to that format). > > > > > > > > json-merge-patch (draft) > > http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-0 > > > > Defines a format where you send updated parts of the JSON Object itself > in same structure as original object: > > > > e.g.: object: > > > > { > > "a": "b", > > "c": { > > "d": "e", > > "f": "g" > > } > > } > > > > patch: > > > > { > > "a":"z", > > "c": { > > "f": null > > } > > } > > > > > > > > Cheers, > > > > ~ Lukas > > _______________________________________________ > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140908/e46cb22a/attachment.html From avibelli at redhat.com Mon Sep 8 08:49:57 2014 From: avibelli at redhat.com (Andrea Vibelli) Date: Mon, 8 Sep 2014 05:49:57 -0700 (PDT) Subject: [aerogear-dev] Should Cordova push plugin dependencies be shrinkwrapped? In-Reply-To: References: Message-ID: <1410180597125-9156.post@n5.nabble.com> Absolutely yes :-), +1 Thanks Andrea gercan wrote > Hi All, > I have been working cordova push quickstarts and noticed that on Android > installation through JBoss tools started to fail. > > After a bit of investigation I figured that the failure occurs because > push plugin defines cordova plugin "com.google.playservices" as a > dependency through a git URL[1] that points to the master of the plugin's > repo. Unfortunately this repo received a change [2] which started to use a > new feature that was not implemented for JBoss tools. In this particular > case, I am already implementing the missing feature so it should be all > good soon. However I have doubts that referencing a dependency through > master is a good idea. I think it may not only make it really difficult > for > us to reproduce cases but also unexpected behaviour may just appear. > > > [1] https://github.com/MobileChromeApps/google-play-services > [2] > https://github.com/MobileChromeApps/google-play-services/commit/41c19152c21981c9a2f6497cc2100c317f5c660d > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at .jboss > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Should-Cordova-push-plugin-dependencies-be-shrinkwrapped-tp9122p9156.html Sent from the aerogear-dev mailing list archive at Nabble.com. From corinnekrych at gmail.com Mon Sep 8 08:50:17 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 8 Sep 2014 14:50:17 +0200 Subject: [aerogear-dev] Data Sync: use of IETFs formats In-Reply-To: References: <23CE72FF-DB66-4CFF-A849-95E1941EE38D@gmail.com> Message-ID: np another thing you might be interested in is the spring implementation (JSON Patch + diff) https://github.com/cujojs/jiff ++ Corinne On 08 Sep 2014, at 14:43, Luk?? Fry? wrote: > Ah, thanks Corinne! > > I wasn't sure and didn't remember it! > > On Mon, Sep 8, 2014 at 2:20 PM, Corinne Krych wrote: > > On 08 Sep 2014, at 14:04, Luk?? Fry? wrote: > > > Hey guys, > > > > I've recently encountered two standard formats that standardizes the HTTP PATCH, that could be important for formats we use for Data Sync features: > > > > json-patch > > http://tools.ietf.org/html/rfc6902 > > +1 > > Yeap I mentioned it too in theis thread > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Comparing-sync-in-Android-vs-other-platforms-td6617.html#a6637 > some time ago > > > > > > Defines set of operations that you can do with JSON object such as: add, remove, replace, move, copy, replace, test. > > > > [ > > { "op": "test", "path": "/a/b/c", "value": "foo" }, > > { "op": "remove", "path": "/a/b/c" }, > > { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] }, > > { "op": "replace", "path": "/a/b/c", "value": 42 }, > > { "op": "move", "from": "/a/b/c", "path": "/a/b/d" }, > > { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" } > > ] > > > > The structure of the patch is list of operations, not the document itself. > > > > We could actually rewrite DiffSync Server to use it (since it is very close to that format). > > > > > > > > json-merge-patch (draft) > > http://tools.ietf.org/html/draft-ietf-appsawg-json-merge-patch-0 > > > > Defines a format where you send updated parts of the JSON Object itself in same structure as original object: > > > > e.g.: object: > > > > { > > "a": "b", > > "c": { > > "d": "e", > > "f": "g" > > } > > } > > > > patch: > > > > { > > "a":"z", > > "c": { > > "f": null > > } > > } > > > > > > > > Cheers, > > > > ~ Lukas > > _______________________________________________ > > 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From rhauch at redhat.com Mon Sep 8 10:14:16 2014 From: rhauch at redhat.com (Randall Hauch) Date: Mon, 8 Sep 2014 09:14:16 -0500 Subject: [aerogear-dev] Differential Synchronization: Shadow/Backup Revision Control and its Garbage Collection In-Reply-To: References: Message-ID: <155C3DA5-94D7-4A0C-8D69-034081C3D961@redhat.com> On Sep 8, 2014, at 4:04 AM, Daniel Bevenius wrote: > >What happens when a client on a mobile device loses its connection for a short period of time and then reconnects? > The edits/patches/operations on the client would be stacked up and later when an connection is available that stack of edits/patches/operations would be sent to the server. I more concerned about what happens in the server when a client on a mobile device loses its connection. Server-side session management adds complexity and reduces scalability. > >What if load balancing cause the client to reconnect to a different process in the cluster? > If we allow for different types of what we currently call a DataStore to be pluggable, then it would be possible for that client to reconnect to a different instance with the assumption here that the underlying datastore is distributed. Sure, except doesn?t that presume that the server?s client states are distributed (or distributable) or persisted? Again, this is more complexity creep. > >BTW, please tell me if the whole purpose of AeroGear's Data Sync feature is to satisfy this and only this scenario. If so, then I apologize for being a distraction.) > No, it is not the only scenario. We want to satisfy as many scenarios as possible, but we also have to start somewhere and preferable start small and build out from there. In the roadmap, we outlined as the first steps what is called conflict resolution. This is what our initial focus will be on and it will require minimal server side changes to existing server application (no server side state for clients). Our hope is that doing this might gain us some early adopters. This does not rule out that this could not be evolve into something like you've described in you email above, more about this later. Yup, the conflict resolution first step is a great approach. It?s lightweight, and I think Data Sync can do an awful lot with it. My hunch is that if a server supported it, then the client-side SDK can add a lot of the features I was talking about earlier. > > > If the client goes offline and then back online, the Data Sync functionality in the SDK would figure out which of the local entities the client has changed, and request from the server the latest revisions for each of them. Data Sync then merges the local changes onto the latest revisions (perhaps asking the user to manually resolve anything that cannot be automatically resolved), computes the new effective changes, and then sends a single batch request to the server to apply them. Some, all or none changes are accepted, and likely the application then has to decide whether to continue the process again, revert to the server?s versions, etc. > This sounds simliar to what we have discussed as conflict resolution in the Data Sync roadmap. It differs somewhat, like we don't specify anything with regard to batches as the goal it to limit the changes need for existing server implementations, in that the server only detects a conflict and does not try to apply any effective changes/operations/patches but instead works with complete objects/documents. Batches does complicate things, and they?re not needed right from the start. Using a batch instead of multiple separate requests reduces network costs, and this is always important in mobile. But it also allows the client to do control consistency and atomicity of their updates. Without batches, some apps will just be harder to write and will have to have logic that compensates for when one update request succeeded and a second did not. > > >The SDK would also make use of subscriptions/notifications so that it can be told immediately when entities are changed. > This is considered as a later part of conflict resolution where we notifications are planned to be used. Right. I was just trying to point out how it fits in to my scenario. > > >The kinds of requests needed to support data sync in this scenario are fairly basic, so the server doesn?t have to be that complicated. Best of all, the server is not required to maintain any client-specific state. > This does sound like what we are trying to do with the conflict resolution approach. I know that it is even more basic than what you have described here but we could extend the roadmap to include such features. +1. > I think there will be use cases for both the conflict resolution and the data sync approaches and users that might be quite happy with conflict resolution. I think it would make sense to split the two roadmaps/specs into separate ones. At the moment it looks, and was the original idea, that this would involve into the "real-time" datasync solution. But have these separate would hopefully make this clear that these are independent and can evolve independently. > Does this sound alright with everyone? That sounds good to me. I think they do target slightly different scenarios. Thanks for the discussion! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140908/ecfa3f34/attachment.html From cvasilak at gmail.com Mon Sep 8 10:14:50 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 8 Sep 2014 17:14:50 +0300 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: <3A71205A-85D2-4371-BE67-296C8A6CAC5A@gmail.com> fyi, meeting minutes: Meeting ended Mon Sep 8 14:13:27 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-09-08-14.00.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-09-08-14.00.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-09-08-14.00.log.html On Sep 8, 2014, at 9:55 AM, Daniel Bevenius wrote: > Agenda: > http://oksoclap.com/p/aerogear-team-mgt-20140908 > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140908/ddeabb89/attachment.html From rhauch at redhat.com Mon Sep 8 10:21:34 2014 From: rhauch at redhat.com (Randall Hauch) Date: Mon, 8 Sep 2014 09:21:34 -0500 Subject: [aerogear-dev] Differential Synchronization: Shadow/Backup Revision Control and its Garbage Collection In-Reply-To: References: Message-ID: <714DD5F1-0509-4FB5-A34F-B521189C0393@redhat.com> On Sep 8, 2014, at 5:33 AM, Luk?? Fry? wrote: > I don't believe LiveOak ensure ACID guarantees (at least not on batch update level; correct me if I'm wrong), and I don't think we should start with that. > Any given REST call that leads to updating more than one endpoint is not atomic anymore. IIUC, LiveOak?s batches are essentially just a set of operations each performed atomically. I am going to start looking at several longer-lead things in LiveOak, including batch operations with predefined policies that dictate whether the operations in the batch are consistent, atomic, and isolated. > > I would rather say that whole Data Sync is eventually consistent solution (at least in its first versions). > > Sure, app/user will know that there is a conflict on one of the updated entities (and we may provide an API to make the resolution easier), but it will be up to him to resolve it. > > Or am I wrong? It sounds like this may be the case early on, with the conflict resolution approach. Hopefully, support for batches can eventually be added, and if so then apps can rely less (hopefully far less) on the user for deconflicting data. From bam at tretau.net Mon Sep 8 11:11:18 2014 From: bam at tretau.net (Torben) Date: Mon, 08 Sep 2014 17:11:18 +0200 Subject: [aerogear-dev] AeroGear openshift cartridge Message-ID: <20140908171118.Horde.kn4dBM3xKlU9PZVdJ6q4Gg4@webmail.df.eu> Hi all, I started some days ago a Unified Push Server 0.10.4 using the openshift aerogear quickstart cartridge. After hearing that the cartridge has to be updated due to security reasons on openshift I wondered: Is it possible to update the cartridge via taking snapshots or something? Can I update this cartridge to the security fixed cartridge version (0.10.4)? Or has it to be updated to the latest release? Kind regards, Torben From matzew at apache.org Mon Sep 8 12:15:01 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 8 Sep 2014 18:15:01 +0200 Subject: [aerogear-dev] AeroGear openshift cartridge In-Reply-To: <20140908171118.Horde.kn4dBM3xKlU9PZVdJ6q4Gg4@webmail.df.eu> References: <20140908171118.Horde.kn4dBM3xKlU9PZVdJ6q4Gg4@webmail.df.eu> Message-ID: Hi Torben, The cartridge now is based on our 1.0.0.Final. However there is no automatic update of existing instance at the moment. That said, we have a JIRA for 1.0.x on this to help w/ the database migration HTH, Matthias On Monday, September 8, 2014, Torben wrote: > > Hi all, > > I started some days ago a Unified Push Server 0.10.4 using the > openshift aerogear quickstart cartridge. > After hearing that the cartridge has to be updated due to security > reasons on openshift I wondered: > > Is it possible to update the cartridge via taking snapshots or something? > Can I update this cartridge to the security fixed cartridge version > (0.10.4)? > Or has it to be updated to the latest release? > > Kind regards, > > Torben > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140908/c6967f69/attachment-0001.html From matzew at apache.org Mon Sep 8 13:07:49 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 8 Sep 2014 19:07:49 +0200 Subject: [aerogear-dev] Apache Mesos and UnifiedPush Server Message-ID: Hello, over the weekend, I played a bit with the Apache Mesos cluster manager and got WildFly / UnifiedPush Server running on it. In case some are interested, here is a little blog post on it: http://matthiaswessendorf.wordpress.com/2014/09/08/apache-mesos-and-marathon-for-unifiedpush-server-and-wildfly/ Greetings, Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140908/af7fa3bc/attachment.html From corinnekrych at gmail.com Tue Sep 9 04:51:38 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 9 Sep 2014 10:51:38 +0200 Subject: [aerogear-dev] iOS meeting Message-ID: <731050CF-DEDB-4A4A-B835-1EC606CD35B1@gmail.com> Hello Swifter and iOS lovers, Here is the proposed agenda of our next meeting which will take place Tuesday 16 September at 2pm (CEST - UTC + 2hours) soclap.com/p/aerogear_ios_meeting_11sept2014 Feel free to add topics to it and join us if you want to discuss with us next 2.0 iOS release. ++ Corinne From bam at tretau.net Tue Sep 9 07:19:57 2014 From: bam at tretau.net (Torben) Date: Tue, 09 Sep 2014 13:19:57 +0200 Subject: [aerogear-dev] AeroGear openshift cartridge In-Reply-To: References: <20140908171118.Horde.kn4dBM3xKlU9PZVdJ6q4Gg4@webmail.df.eu> Message-ID: <20140909131957.Horde.92XOidp-tDTfhUd8HbPYXA1@webmail.df.eu> Hi Matthias, You mean https://issues.jboss.org/browse/AGPUSH-564 for the needed database migration? This is something I have to look for if I move from 0.10.4. Right now, as this cartridge is already used, I think my only option is to fix the scripts by hand via ssh, to make this work after openshift is updated on 15th September. I saw a PR you merged from jwhonce, is this the change that has to be made for the openshift update? Kind regards, Torben Quoting Matthias Wessendorf : > Hi Torben, > > The cartridge now is based on our 1.0.0.Final. However there is no > automatic update of existing instance at the moment. > > That said, we have a JIRA for 1.0.x on this to help w/ the database > migration > > HTH, > Matthias > > On Monday, September 8, 2014, Torben wrote: > >> >> Hi all, >> >> I started some days ago a Unified Push Server 0.10.4 using the >> openshift aerogear quickstart cartridge. >> After hearing that the cartridge has to be updated due to security >> reasons on openshift I wondered: >> >> Is it possible to update the cartridge via taking snapshots or something? >> Can I update this cartridge to the security fixed cartridge version >> (0.10.4)? >> Or has it to be updated to the latest release? >> >> Kind regards, >> >> Torben >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > -- > Sent from Gmail Mobile From edewit at redhat.com Tue Sep 9 12:40:19 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 9 Sep 2014 12:40:19 -0400 (EDT) Subject: [aerogear-dev] Windows Phone support 8.0 In-Reply-To: <1366214555.53913471.1410280486331.JavaMail.zimbra@redhat.com> Message-ID: <1855101801.53916663.1410280819013.JavaMail.zimbra@redhat.com> Hi all, I'm building the cordova support, but there is a bit of an issue, right now we support windows WNS message, these 'only' work for windows phone 8.1. Seems though that cordova projects are for multiple versions 8.0 also being one of them. This means that WNS will not work on cordova, but the older MPNS will. The client library already supports both, but UPS not yet. The problem now is how do we support both of these on UPS. The most simple solution is to have 2 variant types WindowsWNSVariant and WindowsMPNSVariant, that we can have 2 sender implementations for both protocols. We could still group these together somehow on the UI. What do you think? Cheers, Erik Jan From scm.blanc at gmail.com Tue Sep 9 13:17:34 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 9 Sep 2014 19:17:34 +0200 Subject: [aerogear-dev] Windows Phone support 8.0 In-Reply-To: <1855101801.53916663.1410280819013.JavaMail.zimbra@redhat.com> References: <1366214555.53913471.1410280486331.JavaMail.zimbra@redhat.com> <1855101801.53916663.1410280819013.JavaMail.zimbra@redhat.com> Message-ID: I don't know the details so sorry if what I say make no sense : Could we not hide these 2 protocols/senders behind the same variant and use the metadata of the "installation" like "platform" or "os" to make the right switch ? On Tue, Sep 9, 2014 at 6:40 PM, Erik Jan de Wit wrote: > Hi all, > > I'm building the cordova support, but there is a bit of an issue, right > now we support windows WNS message, these 'only' work for windows phone > 8.1. Seems though that cordova projects are for multiple versions 8.0 also > being one of them. This means that WNS will not work on cordova, but the > older MPNS will. The client library already supports both, but UPS not yet. > The problem now is how do we support both of these on UPS. The most simple > solution is to have 2 variant types WindowsWNSVariant and > WindowsMPNSVariant, that we can have 2 sender implementations for both > protocols. We could still group these together somehow on the UI. What do > you think? > > Cheers, > Erik Jan > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140909/4a8c094a/attachment.html From bruno at abstractj.org Wed Sep 10 05:53:35 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 10 Sep 2014 06:53:35 -0300 Subject: [aerogear-dev] AeroGear Jiras housekeeping Message-ID: <20140910095335.GE35456@abstractj.org> Good morning, while revisiting the jiras assinged to me on AeroGear I noticed that we have a ton of issues out of date. I would like your help to do some clean up on it: https://issues.jboss.org/issues/?jql=project%20%3D%20AEROGEAR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC You can help just checking the issues reported or assigned to you. -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Wed Sep 10 06:36:50 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 10 Sep 2014 07:36:50 -0300 Subject: [aerogear-dev] Keycloak - call for arms Message-ID: <20140910103650.GA39224@abstractj.org> Good morning my friends, we've been working together with Keycloak since the beginning and the KC team did a hard work to meet our requirements on UPS. For this reason, I would like your help on testing mostly Keycloak. It's a huge step to everyone. How? - git clone git at github.com:keycloak/keycloak.git && cd keycloak && mvn clean install -DskipTests=true - git clone git at github.com:aerogear/aerogear-unifiedpush-server.git && cd aerogear-unifiedpush-server && git checkout keycloak_final && mvn clean install -DskipTests=true - Deploy on WildFly or JBoss I also deployed it on OpenShift https://golum-abstractj.rhcloud.com/ag-push. User: admin pass: 123. Please make sure to test on multiple browsers. Please make sure to reply on this thread http://lists.jboss.org/pipermail/keycloak-dev/2014-September/002543.html with issues found. If you don't want to test anything, sooner or later the problem will hit you ;) -- abstractj PGP: 0x84DC9914 From lukas.fryc at gmail.com Wed Sep 10 07:31:54 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Wed, 10 Sep 2014 13:31:54 +0200 Subject: [aerogear-dev] AeroGear Jiras housekeeping In-Reply-To: <20140910095335.GE35456@abstractj.org> References: <20140910095335.GE35456@abstractj.org> Message-ID: Just to help a little bit with housekeeping... here is a modified filter for "reporter/assignee = currentUser()": https://issues.jboss.org/issues/?filter=12322270&jql=project%20%3D%20AEROGEAR%20AND%20resolution%20%3D%20Unresolved%20AND%20(assignee%3DcurrentUser()%20OR%20reporter%3DcurrentUser())%20ORDER%20BY%20priority%20DESC%2C%20updated%20ASC On Wed, Sep 10, 2014 at 11:53 AM, Bruno Oliveira wrote: > Good morning, while revisiting the jiras assinged to me on AeroGear I > noticed that we have a ton of issues out of date. > > I would like your help to do some clean up on it: > > https://issues.jboss.org/issues/?jql=project%20%3D%20AEROGEAR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC > > > You can help just checking the issues reported or assigned to you. > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140910/5642824c/attachment.html From daniel.bevenius at gmail.com Wed Sep 10 07:56:22 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Wed, 10 Sep 2014 13:56:22 +0200 Subject: [aerogear-dev] Keycloak - call for arms In-Reply-To: <20140910103650.GA39224@abstractj.org> References: <20140910103650.GA39224@abstractj.org> Message-ID: I've tested using running the server on EAP 6.3 and with FireFox everything works fine. With Safari and get the error in the attached screenshot. On 10 September 2014 12:36, Bruno Oliveira wrote: > Good morning my friends, we've been working together with Keycloak since > the beginning and the KC team did a hard work to meet our requirements > on UPS. > > For this reason, I would like your help on testing mostly Keycloak. It's > a huge step to everyone. > > How? > > - git clone git at github.com:keycloak/keycloak.git && cd keycloak && mvn > clean install -DskipTests=true > - git clone git at github.com:aerogear/aerogear-unifiedpush-server.git && > cd aerogear-unifiedpush-server && git checkout keycloak_final && mvn > clean install -DskipTests=true > - Deploy on WildFly or JBoss > > I also deployed it on OpenShift > https://golum-abstractj.rhcloud.com/ag-push. User: admin pass: 123. > Please make sure to test on multiple browsers. > > Please make sure to reply on this thread > http://lists.jboss.org/pipermail/keycloak-dev/2014-September/002543.html > with issues found. > > If you don't want to test anything, sooner or later the problem will hit > you ;) > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140910/1e48d7d7/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: safari-keycloak-issue.png Type: image/png Size: 167800 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140910/1e48d7d7/attachment-0001.png From stian at redhat.com Wed Sep 10 08:27:23 2014 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 10 Sep 2014 08:27:23 -0400 (EDT) Subject: [aerogear-dev] Keycloak - call for arms In-Reply-To: References: <20140910103650.GA39224@abstractj.org> Message-ID: <529686875.46853644.1410352043876.JavaMail.zimbra@redhat.com> Daniel: I assume login doesn't work at all on Safari then? ----- Original Message ----- > From: "Daniel Bevenius" > To: "AeroGear Developer Mailing List" > Sent: Wednesday, 10 September, 2014 1:56:22 PM > Subject: Re: [aerogear-dev] Keycloak - call for arms > > I've tested using running the server on EAP 6.3 and with FireFox everything > works fine. With Safari and get the error in the attached screenshot. > > > On 10 September 2014 12:36, Bruno Oliveira < bruno at abstractj.org > wrote: > > > Good morning my friends, we've been working together with Keycloak since > the beginning and the KC team did a hard work to meet our requirements > on UPS. > > For this reason, I would like your help on testing mostly Keycloak. It's > a huge step to everyone. > > How? > > - git clone git at github.com:keycloak/keycloak.git && cd keycloak && mvn > clean install -DskipTests=true > - git clone git at github.com:aerogear/aerogear-unifiedpush-server.git && > cd aerogear-unifiedpush-server && git checkout keycloak_final && mvn > clean install -DskipTests=true > - Deploy on WildFly or JBoss > > I also deployed it on OpenShift > https://golum-abstractj.rhcloud.com/ag-push . User: admin pass: 123. Please > make sure to test on multiple browsers. > > Please make sure to reply on this thread > http://lists.jboss.org/pipermail/keycloak-dev/2014-September/002543.html > with issues found. > > If you don't want to test anything, sooner or later the problem will hit you > ;) > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > 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 From daniel.bevenius at gmail.com Wed Sep 10 08:32:01 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Wed, 10 Sep 2014 14:32:01 +0200 Subject: [aerogear-dev] Keycloak - call for arms In-Reply-To: <529686875.46853644.1410352043876.JavaMail.zimbra@redhat.com> References: <20140910103650.GA39224@abstractj.org> <529686875.46853644.1410352043876.JavaMail.zimbra@redhat.com> Message-ID: Sorry about not giving more details. This occurs as soon as I request: http://localhost:8080/ag-push/ On 10 September 2014 14:27, Stian Thorgersen wrote: > Daniel: I assume login doesn't work at all on Safari then? > > ----- Original Message ----- > > From: "Daniel Bevenius" > > To: "AeroGear Developer Mailing List" > > Sent: Wednesday, 10 September, 2014 1:56:22 PM > > Subject: Re: [aerogear-dev] Keycloak - call for arms > > > > I've tested using running the server on EAP 6.3 and with FireFox > everything > > works fine. With Safari and get the error in the attached screenshot. > > > > > > On 10 September 2014 12:36, Bruno Oliveira < bruno at abstractj.org > > wrote: > > > > > > Good morning my friends, we've been working together with Keycloak since > > the beginning and the KC team did a hard work to meet our requirements > > on UPS. > > > > For this reason, I would like your help on testing mostly Keycloak. It's > > a huge step to everyone. > > > > How? > > > > - git clone git at github.com:keycloak/keycloak.git && cd keycloak && mvn > > clean install -DskipTests=true > > - git clone git at github.com:aerogear/aerogear-unifiedpush-server.git && > > cd aerogear-unifiedpush-server && git checkout keycloak_final && mvn > > clean install -DskipTests=true > > - Deploy on WildFly or JBoss > > > > I also deployed it on OpenShift > > https://golum-abstractj.rhcloud.com/ag-push . User: admin pass: 123. > Please > > make sure to test on multiple browsers. > > > > Please make sure to reply on this thread > > http://lists.jboss.org/pipermail/keycloak-dev/2014-September/002543.html > > with issues found. > > > > If you don't want to test anything, sooner or later the problem will hit > you > > ;) > > > > -- > > > > abstractj > > PGP: 0x84DC9914 > > _______________________________________________ > > 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140910/deafd568/attachment.html From daniel.bevenius at gmail.com Wed Sep 10 08:32:50 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Wed, 10 Sep 2014 14:32:50 +0200 Subject: [aerogear-dev] Keycloak - call for arms In-Reply-To: References: <20140910103650.GA39224@abstractj.org> <529686875.46853644.1410352043876.JavaMail.zimbra@redhat.com> Message-ID: So I never get a chance to enter any login credentials or anything like that is what I meant. On 10 September 2014 14:32, Daniel Bevenius wrote: > Sorry about not giving more details. This occurs as soon as I request: > http://localhost:8080/ag-push/ > > > On 10 September 2014 14:27, Stian Thorgersen wrote: > >> Daniel: I assume login doesn't work at all on Safari then? >> >> ----- Original Message ----- >> > From: "Daniel Bevenius" >> > To: "AeroGear Developer Mailing List" >> > Sent: Wednesday, 10 September, 2014 1:56:22 PM >> > Subject: Re: [aerogear-dev] Keycloak - call for arms >> > >> > I've tested using running the server on EAP 6.3 and with FireFox >> everything >> > works fine. With Safari and get the error in the attached screenshot. >> > >> > >> > On 10 September 2014 12:36, Bruno Oliveira < bruno at abstractj.org > >> wrote: >> > >> > >> > Good morning my friends, we've been working together with Keycloak since >> > the beginning and the KC team did a hard work to meet our requirements >> > on UPS. >> > >> > For this reason, I would like your help on testing mostly Keycloak. It's >> > a huge step to everyone. >> > >> > How? >> > >> > - git clone git at github.com:keycloak/keycloak.git && cd keycloak && mvn >> > clean install -DskipTests=true >> > - git clone git at github.com:aerogear/aerogear-unifiedpush-server.git && >> > cd aerogear-unifiedpush-server && git checkout keycloak_final && mvn >> > clean install -DskipTests=true >> > - Deploy on WildFly or JBoss >> > >> > I also deployed it on OpenShift >> > https://golum-abstractj.rhcloud.com/ag-push . User: admin pass: 123. >> Please >> > make sure to test on multiple browsers. >> > >> > Please make sure to reply on this thread >> > >> http://lists.jboss.org/pipermail/keycloak-dev/2014-September/002543.html >> > with issues found. >> > >> > If you don't want to test anything, sooner or later the problem will >> hit you >> > ;) >> > >> > -- >> > >> > abstractj >> > PGP: 0x84DC9914 >> > _______________________________________________ >> > 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 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140910/a00ed432/attachment.html From daniel.bevenius at gmail.com Wed Sep 10 09:18:14 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Wed, 10 Sep 2014 15:18:14 +0200 Subject: [aerogear-dev] Keycloak - call for arms In-Reply-To: References: <20140910103650.GA39224@abstractj.org> <529686875.46853644.1410352043876.JavaMail.zimbra@redhat.com> Message-ID: Sorry guys, this was my fault. I'd configured Safari to block cookies which was the cause of this issue. The default setting in Safari is: [1] "From third parties and advertisers" is the default Safari setting. With this set I have no issue login in. Sorry for the noise. /Dan [1] http://support.apple.com/kb/TS4207 On 10 September 2014 14:32, Daniel Bevenius wrote: > So I never get a chance to enter any login credentials or anything like > that is what I meant. > > On 10 September 2014 14:32, Daniel Bevenius > wrote: > >> Sorry about not giving more details. This occurs as soon as I request: >> http://localhost:8080/ag-push/ >> >> >> On 10 September 2014 14:27, Stian Thorgersen wrote: >> >>> Daniel: I assume login doesn't work at all on Safari then? >>> >>> ----- Original Message ----- >>> > From: "Daniel Bevenius" >>> > To: "AeroGear Developer Mailing List" >>> > Sent: Wednesday, 10 September, 2014 1:56:22 PM >>> > Subject: Re: [aerogear-dev] Keycloak - call for arms >>> > >>> > I've tested using running the server on EAP 6.3 and with FireFox >>> everything >>> > works fine. With Safari and get the error in the attached screenshot. >>> > >>> > >>> > On 10 September 2014 12:36, Bruno Oliveira < bruno at abstractj.org > >>> wrote: >>> > >>> > >>> > Good morning my friends, we've been working together with Keycloak >>> since >>> > the beginning and the KC team did a hard work to meet our requirements >>> > on UPS. >>> > >>> > For this reason, I would like your help on testing mostly Keycloak. >>> It's >>> > a huge step to everyone. >>> > >>> > How? >>> > >>> > - git clone git at github.com:keycloak/keycloak.git && cd keycloak && mvn >>> > clean install -DskipTests=true >>> > - git clone git at github.com:aerogear/aerogear-unifiedpush-server.git && >>> > cd aerogear-unifiedpush-server && git checkout keycloak_final && mvn >>> > clean install -DskipTests=true >>> > - Deploy on WildFly or JBoss >>> > >>> > I also deployed it on OpenShift >>> > https://golum-abstractj.rhcloud.com/ag-push . User: admin pass: 123. >>> Please >>> > make sure to test on multiple browsers. >>> > >>> > Please make sure to reply on this thread >>> > >>> http://lists.jboss.org/pipermail/keycloak-dev/2014-September/002543.html >>> > with issues found. >>> > >>> > If you don't want to test anything, sooner or later the problem will >>> hit you >>> > ;) >>> > >>> > -- >>> > >>> > abstractj >>> > PGP: 0x84DC9914 >>> > _______________________________________________ >>> > 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 >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140910/05144f7a/attachment-0001.html From lukas.fryc at gmail.com Wed Sep 10 09:18:12 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Wed, 10 Sep 2014 15:18:12 +0200 Subject: [aerogear-dev] Suggestion for DataSync roadmap In-Reply-To: References: <1409812311337-9114.post@n5.nabble.com> Message-ID: Hey team, I've proposed following change to the Conflict Resolution part of the Data Sync roadmap after recent discussions about Data Sync. I'm very interested in feedback from all the specific SDK teams, in terms of whether the whole idea matches the visions you have for Data Sync and whether we are able to leverage (and/or extend) platform specific tools. Changes contains following additions: - Dec 2014 - Partial Updates - SPDY - Jan 2015 - Batch API You can read the doc directly here (starting with 0.2.0): https://github.com/lfryc/aerogear.org/blob/partial-updates-spdy-batches/docs/planning/roadmaps/AeroGearConflictResolution.asciidoc#020-dec-2015-partial-updates-spdy Please leave any comment right in PR: https://github.com/aerogear/aerogear.org/pull/386 Thanks! ~ Lukas On Thu, Sep 4, 2014 at 11:00 AM, Daniel Bevenius wrote: > I fine with Google docs or anything else. > > > On 4 September 2014 10:53, Luk?? Fry? wrote: > >> Yea, I rather meant if we are in brainstorming phase e.g. with Sync spec, >> I see a fit for rather collaborative solution, >> >> but I was mistaken with suggesting oksoclap, because it does not offer >> that level of interactivity as well. :-) >> >> >> What I meant is sharing a document such as Data Sync Spec on >> collaborative editor where: >> >> * you can suggest additions / modifications >> * you can comment >> * comments can be resolved once resolved >> * that document is owned and maintained by group of people >> >> such as Google Docs: >> https://docs.google.com/document/d/1hOsAN5og6dz07-k66ooaGbJ5KrnWJWRyHRelwyjf6bk/edit?usp=sharing >> >> >> But I don't see a point into bringing other technology if it should not >> help us be more productive, so tell me if I'm mistaken! >> >> >> Cheers, >> >> ~ Lukas >> >> >> >> >> On Thu, Sep 4, 2014 at 8:31 AM, danielbevenius > > wrote: >> >>> Lukas and I talked yesterday and he brought up an issue that it is not as >>> smooth as it could be to contribute to the roadmap. He instead suggested >>> to >>> have a shared docs which I'll later clean up and include in a pull >>> request. >>> >>> The current version can be found here and is in raw asciidoc format: >>> http://oksoclap.com/p/datasync_roadmap >>> >>> Let me know if this works out better. >>> >>> >>> >>> -- >>> View this message in context: >>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Suggestion-for-DataSync-roadmap-tp9006p9114.html >>> Sent from the aerogear-dev mailing list archive at Nabble.com. >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140910/c47b4927/attachment.html From lholmqui at redhat.com Wed Sep 10 09:52:01 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 10 Sep 2014 09:52:01 -0400 Subject: [aerogear-dev] AeroGear Jiras housekeeping In-Reply-To: <20140910095335.GE35456@abstractj.org> References: <20140910095335.GE35456@abstractj.org> Message-ID: <4BE026A9-4B90-427C-B693-1BC4E059615F@redhat.com> yea, i was looking at some of the real early ones, wondering if they are still valid. and yes, i know i should probably provide a link to them, but... On Sep 10, 2014, at 5:53 AM, Bruno Oliveira wrote: > Good morning, while revisiting the jiras assinged to me on AeroGear I > noticed that we have a ton of issues out of date. > > I would like your help to do some clean up on it: > https://issues.jboss.org/issues/?jql=project%20%3D%20AEROGEAR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC > > > You can help just checking the issues reported or assigned to you. > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From supittma at redhat.com Wed Sep 10 11:16:22 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 10 Sep 2014 11:16:22 -0400 Subject: [aerogear-dev] AeroGear Jiras housekeeping In-Reply-To: <20140910095335.GE35456@abstractj.org> References: <20140910095335.GE35456@abstractj.org> Message-ID: <54106B46.7020306@redhat.com> On 9/10/2014 5:53 AM, Bruno Oliveira wrote: > Good morning, while revisiting the jiras assinged to me on AeroGear I > noticed that we have a ton of issues out of date. > > I would like your help to do some clean up on it: > https://issues.jboss.org/issues/?jql=project%20%3D%20AEROGEAR%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC > > > You can help just checking the issues reported or assigned to you. Nice kick in the pants for me an passos to clean up in AGDROID as well :) > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From edewit at redhat.com Thu Sep 11 02:40:31 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 11 Sep 2014 02:40:31 -0400 (EDT) Subject: [aerogear-dev] cordova push plugin release 1.0.1 In-Reply-To: <678724489.262187.1410417355980.JavaMail.zimbra@redhat.com> Message-ID: <615718775.263549.1410417631553.JavaMail.zimbra@redhat.com> Hi all, We found a issue in the 1.0.0 release of the push plugin, one of it's dependencies change in a way that it's no longer working for android. We'll fix this in the 1.0.1 release, I've created a branch 1.0.1-release for testing. If all is well the release will be synced with the UPS 1.0.1 release. Cheers, Erik Jan [1] the fix https://github.com/gorkem/aerogear-pushplugin-cordova/commit/c960d852e8f8d841e8d8dd8c16a9b96a67b6014f From lukas.fryc at gmail.com Thu Sep 11 06:27:48 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Thu, 11 Sep 2014 12:27:48 +0200 Subject: [aerogear-dev] Suggestion for DataSync roadmap In-Reply-To: References: <1409812311337-9114.post@n5.nabble.com> Message-ID: The roadmap was further tweaked by the comments: - stick with dates proposed by Dan - added Offline/Persistence Rendered version: https://github.com/lfryc/aerogear.org/blob/partial-updates-spdy-batches/docs/planning/roadmaps/AeroGearConflictResolution.asciidoc PR: https://github.com/aerogear/aerogear.org/pull/386 ~ Lukas On Wed, Sep 10, 2014 at 3:18 PM, Luk?? Fry? wrote: > Hey team, > > I've proposed following change to the Conflict Resolution part of the Data > Sync roadmap after recent discussions about Data Sync. > > I'm very interested in feedback from all the specific SDK teams, in terms > of whether the whole idea matches the visions you have for Data Sync and > whether we are able to leverage (and/or extend) platform specific tools. > > > Changes contains following additions: > > > - Dec 2014 > - Partial Updates > - SPDY > - Jan 2015 > - Batch API > > > You can read the doc directly here (starting with 0.2.0): > > > https://github.com/lfryc/aerogear.org/blob/partial-updates-spdy-batches/docs/planning/roadmaps/AeroGearConflictResolution.asciidoc#020-dec-2015-partial-updates-spdy > > > Please leave any comment right in PR: > > https://github.com/aerogear/aerogear.org/pull/386 > > > Thanks! > > ~ Lukas > > On Thu, Sep 4, 2014 at 11:00 AM, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > >> I fine with Google docs or anything else. >> >> >> On 4 September 2014 10:53, Luk?? Fry? wrote: >> >>> Yea, I rather meant if we are in brainstorming phase e.g. with Sync spec, >>> I see a fit for rather collaborative solution, >>> >>> but I was mistaken with suggesting oksoclap, because it does not offer >>> that level of interactivity as well. :-) >>> >>> >>> What I meant is sharing a document such as Data Sync Spec on >>> collaborative editor where: >>> >>> * you can suggest additions / modifications >>> * you can comment >>> * comments can be resolved once resolved >>> * that document is owned and maintained by group of people >>> >>> such as Google Docs: >>> https://docs.google.com/document/d/1hOsAN5og6dz07-k66ooaGbJ5KrnWJWRyHRelwyjf6bk/edit?usp=sharing >>> >>> >>> But I don't see a point into bringing other technology if it should not >>> help us be more productive, so tell me if I'm mistaken! >>> >>> >>> Cheers, >>> >>> ~ Lukas >>> >>> >>> >>> >>> On Thu, Sep 4, 2014 at 8:31 AM, danielbevenius < >>> daniel.bevenius at gmail.com> wrote: >>> >>>> Lukas and I talked yesterday and he brought up an issue that it is not >>>> as >>>> smooth as it could be to contribute to the roadmap. He instead >>>> suggested to >>>> have a shared docs which I'll later clean up and include in a pull >>>> request. >>>> >>>> The current version can be found here and is in raw asciidoc format: >>>> http://oksoclap.com/p/datasync_roadmap >>>> >>>> Let me know if this works out better. >>>> >>>> >>>> >>>> -- >>>> View this message in context: >>>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Suggestion-for-DataSync-roadmap-tp9006p9114.html >>>> Sent from the aerogear-dev mailing list archive at Nabble.com. >>>> _______________________________________________ >>>> 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 >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140911/a86a8dfa/attachment-0001.html From scm.blanc at gmail.com Thu Sep 11 10:59:41 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 11 Sep 2014 16:59:41 +0200 Subject: [aerogear-dev] [VOTE] UnifiedPush 1.0.1 Release Message-ID: Hi all, We are pleased to announce that the UnifiedPush Server 1.0.1 has been staged. Thx to the fixers/reviewers/mergers. This release contains mainly UI fixes, Keycloak update and device registration is now async. The full list can be found here : http://red.ht/WNT4Iv The staging repo is here : https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3841/org/jboss/aerogear/unifiedpush/unifiedpush-dist/1.0.1/ Please test and vote ! Sebi -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140911/ca9e60bc/attachment.html From edewit at redhat.com Fri Sep 12 04:58:25 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Fri, 12 Sep 2014 10:58:25 +0200 Subject: [aerogear-dev] REST-based API Versioning In-Reply-To: References: <1409234343233.eec9f5f8@Nodemailer> <20140828142629.GA61471@abstractj.org> <2F83CCAA-7DF1-433A-BB72-207C3CE9009A@redhat.com> <2BF96CA9-E14C-4182-BD43-193F6D1AA69F@redhat.com> Message-ID: <4158F523-DF69-48CE-A828-D3F29F6FD45D@redhat.com> On 2 Sep,2014, at 9:27 , tolis emmanouilidis wrote: > Hi Eric, > > I have tried the jax-rs @Produces annotation both at method and class levels as shown here (http://docs.oracle.com/cd/E19798-01/821-1841/gipzh/index.html) and it works for me. I don't have to specify the Content-Type header in the request.The resource method or endpoint is chosen according the Accept header. > You are right, I must have done something wrong. > > class level > > @Path("/members") > @RequestScoped > @Produces({"application/vnd.aerogear.v102+json"}) > public class MemberResourceRESTServiceV102 { > > @Path("/members") > @RequestScoped > @Produces({"application/vnd.aerogear.v101+json"}) > public class MemberResourceRESTService { > So this is also an option of doing it, what option do you like the best? Cheers, Erik Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140912/e0fa7088/attachment.html From bruno at abstractj.org Fri Sep 12 08:57:42 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 12 Sep 2014 09:57:42 -0300 Subject: [aerogear-dev] Community page - revamp Message-ID: <20140912125742.GA11754@abstractj.org> Good morning, The heart of any open source project is the community. Today we have the following page dedicate to our community http://aerogear.org/community/. I think it's quite unclear for newcomers on AeroGear. IMO, community should have references to GitHub, mailing list (not only dev, but users too), IRC channel, Twitter... Something close to what the contributing page does http://aerogear.org/docs/guides/Contributing/. Thoughts? -- abstractj PGP: 0x84DC9914 From daniel.bevenius at gmail.com Fri Sep 12 09:01:14 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 12 Sep 2014 15:01:14 +0200 Subject: [aerogear-dev] Community page - revamp In-Reply-To: <20140912125742.GA11754@abstractj.org> References: <20140912125742.GA11754@abstractj.org> Message-ID: +1 We could create a better page and like you said link to the mailing list archive instead of that being the main content of that page. On 12 September 2014 14:57, Bruno Oliveira wrote: > Good morning, > > The heart of any open source project is the community. Today we have the > following page dedicate to our community http://aerogear.org/community/. > > I think it's quite unclear for newcomers on AeroGear. IMO, community > should have references to GitHub, mailing list (not only dev, but users > too), IRC channel, Twitter... > > Something close to what the contributing page does > http://aerogear.org/docs/guides/Contributing/. > > Thoughts? > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140912/fdc819c8/attachment.html From daniel at passos.me Fri Sep 12 09:34:57 2014 From: daniel at passos.me (Daniel Passos) Date: Fri, 12 Sep 2014 10:34:57 -0300 Subject: [aerogear-dev] cordova push plugin release 1.0.1 In-Reply-To: <615718775.263549.1410417631553.JavaMail.zimbra@redhat.com> References: <678724489.262187.1410417355980.JavaMail.zimbra@redhat.com> <615718775.263549.1410417631553.JavaMail.zimbra@redhat.com> Message-ID: I'm testing it! -- Passos On Thu, Sep 11, 2014 at 3:40 AM, Erik Jan de Wit wrote: > Hi all, > > We found a issue in the 1.0.0 release of the push plugin, one of it's > dependencies change in a way that it's no longer working for android. We'll > fix this in the 1.0.1 release, I've created a branch 1.0.1-release for > testing. If all is well the release will be synced with the UPS 1.0.1 > release. > > Cheers, > Erik Jan > > [1] the fix > https://github.com/gorkem/aerogear-pushplugin-cordova/commit/c960d852e8f8d841e8d8dd8c16a9b96a67b6014f > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140912/bf28f209/attachment.html From daniel at passos.me Fri Sep 12 12:01:33 2014 From: daniel at passos.me (Daniel Passos) Date: Fri, 12 Sep 2014 13:01:33 -0300 Subject: [aerogear-dev] cordova push plugin release 1.0.1 In-Reply-To: References: <678724489.262187.1410417355980.JavaMail.zimbra@redhat.com> <615718775.263549.1410417631553.JavaMail.zimbra@redhat.com> Message-ID: Tested creating a new app and follow the cordova push docs[1]. I can: * Register a device on UPS * Receive message when application is in foreground * Receive message when application is in background [1] http://aerogear.org/docs/guides/aerogear-cordova/AerogearCordovaPush/ -- Passos On Fri, Sep 12, 2014 at 10:34 AM, Daniel Passos wrote: > I'm testing it! > > -- Passos > > > On Thu, Sep 11, 2014 at 3:40 AM, Erik Jan de Wit > wrote: > >> Hi all, >> >> We found a issue in the 1.0.0 release of the push plugin, one of it's >> dependencies change in a way that it's no longer working for android. We'll >> fix this in the 1.0.1 release, I've created a branch 1.0.1-release for >> testing. If all is well the release will be synced with the UPS 1.0.1 >> release. >> >> Cheers, >> Erik Jan >> >> [1] the fix >> https://github.com/gorkem/aerogear-pushplugin-cordova/commit/c960d852e8f8d841e8d8dd8c16a9b96a67b6014f >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140912/8442648b/attachment.html From bruno at abstractj.org Sat Sep 13 11:07:59 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Sat, 13 Sep 2014 12:07:59 -0300 Subject: [aerogear-dev] [off-topic] Change your IRC passwords Message-ID: <20140913150759.GA27150@abstractj.org> Aloha, freenode was compromised. Change your IRC passwords, please. "Earlier today the freenode infra team noticed an anomaly on a single IRC server. We have since identified that this was indicative of the server being compromised by an unknown third party. We immediately started an investigation to map the extent of the problem and located similar issues with several other machines and have taken those offline. For now, we recommend that everyone change their NickServ password as a precaution. We?ll issue more updates as WALLOPS and via social media!" Source: http://blog.freenode.net/2014/09/server-issues-2/ -- abstractj PGP: 0x84DC9914 From qmx at qmx.me Mon Sep 15 00:26:06 2014 From: qmx at qmx.me (Douglas Campos) Date: Mon, 15 Sep 2014 01:26:06 -0300 Subject: [aerogear-dev] aerogear.org hosting cleanup Message-ID: <20140915042606.GF25102@darkstar.local> Hello all! As we've discussed a few weeks ago, aerogear.org had a lot of old files lying around the server, and I've volunteered to take a weekend and do the site cleanup (delete everything and re-upload the new stuff). So I've just did it! Please let me know if you find any issues with aerogear.org! kthxbai -- qmx From daniel.bevenius at gmail.com Mon Sep 15 02:46:21 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 15 Sep 2014 08:46:21 +0200 Subject: [aerogear-dev] Team meeting Message-ID: Agenda: http://oksoclap.com/p/aerogear-team-mgt-20140915 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140915/38786775/attachment.html From daniel.bevenius at gmail.com Mon Sep 15 04:21:18 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 15 Sep 2014 10:21:18 +0200 Subject: [aerogear-dev] [VOTE] UnifiedPush 1.0.1 Release In-Reply-To: References: Message-ID: +1 Tested the staged server bits and used aerogear-push-helloworld/ios to receive push notifications. On 11 September 2014 16:59, Sebastien Blanc wrote: > Hi all, > We are pleased to announce that the UnifiedPush Server 1.0.1 has been > staged. > Thx to the fixers/reviewers/mergers. > > This release contains mainly UI fixes, Keycloak update and device > registration is now async. The full list can be found here : > http://red.ht/WNT4Iv > > The staging repo is here : > > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3841/org/jboss/aerogear/unifiedpush/unifiedpush-dist/1.0.1/ > > Please test and vote ! > > Sebi > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140915/0224bcd9/attachment.html From lholmqui at redhat.com Mon Sep 15 09:03:58 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 15 Sep 2014 09:03:58 -0400 Subject: [aerogear-dev] Community page - revamp In-Reply-To: <20140912125742.GA11754@abstractj.org> References: <20140912125742.GA11754@abstractj.org> Message-ID: <9F5D09AC-88C7-4EF6-AF10-17A8678D8C2B@redhat.com> +1 On Sep 12, 2014, at 8:57 AM, Bruno Oliveira wrote: > Good morning, > > The heart of any open source project is the community. Today we have the > following page dedicate to our community http://aerogear.org/community/. > > I think it's quite unclear for newcomers on AeroGear. IMO, community > should have references to GitHub, mailing list (not only dev, but users > too), IRC channel, Twitter... > > Something close to what the contributing page does > http://aerogear.org/docs/guides/Contributing/. > > Thoughts? > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From cvasilak at gmail.com Mon Sep 15 10:18:37 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 15 Sep 2014 17:18:37 +0300 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: fyi, meeting minutes: Meeting ended Mon Sep 15 14:13:22 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-09-15-14.01.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-09-15-14.01.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-09-15-14.01.log.html On Sep 15, 2014, at 9:46 AM, Daniel Bevenius wrote: Agenda: http://oksoclap.com/p/aerogear-team-mgt-20140915 _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140915/25e43c3f/attachment.html -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 506 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140915/25e43c3f/attachment.bin From supittma at redhat.com Mon Sep 15 10:36:31 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 15 Sep 2014 10:36:31 -0400 Subject: [aerogear-dev] [Android] KeyCloak Authenticator Message-ID: <5416F96F.8030605@redhat.com> DEVELOPERS WILL NEVER HAVE TO WRITE ANOTHER LINE OF AUTH LOGIC AGAIN! Over the weekend I tried my hand at writing a Android Account Authenticator for KeyCloak. This lets Android manage the KeyCloak account, fetch tokens, provide tokens to other apps etc. KeyCloak Authenticator let's you drop your keycloak.json file into an apk and access your KeyCloak Account with one line of code from any application on your Android device. Right now this is very much in the "I have an itch needing scratching" phase. It doesn't do any robust error handling, hasn't been testing off the golden scenario, has no integration with any of the AeroGear stuff, etc. Take a moment to watch the Demo and look at the demo project. Video Demo : https://plus.google.com/103442292643366117394/posts/WSFbdodMsej The Demo video uses Android's native account menu to request from the authenticator a KeyCloak account. This launches the authenticator's activity which will retrieve the credentials for Android and store them. When I am back in the settings page and showing off the stored account, this is all native Android UI and not part of the KeyCloak authenticator. When I launch the Demo application this is a separate application from the authenticator apk. The Demo project fetches the KeyCloak account from Android and gets its auth token. Then it makes a request to KeyCloak's account service to fetch the user's account data. In the demo app there are three lines of code related to auth. final Account account = am.getAccountsByType("org.keycloak.Account")[0]; String token = am.getAuthToken(account, "org.keycloak.Account.token", null, null, null, null).getResult().getString(AccountManager.KEY_AUTHTOKEN); and provider.setDefaultHeader("Authorization", "bearer " + token); The first two lines fetch the account and token from Android. The second line attaches the account's auth token to the web request to the server. So now what? I'll probably use this for my projects/demos because it makes my work easier. Right now it doesn't have any connection to any of the "official" projects (Again, I wrote this over the weekend to see if I could) however it may be quite useful to someone. In the project's README I've included a (incomplete) list of things that don't work. wdyt? Links : Project : https://github.com/secondsun/keycloak-android-authenticator Video Demo : https://plus.google.com/103442292643366117394/posts/WSFbdodMsej Demo Source : https://github.com/secondsun/keycloak-account-authenticator-demo/ -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. From bruno at abstractj.org Mon Sep 15 11:28:10 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 15 Sep 2014 08:28:10 -0700 (PDT) Subject: [aerogear-dev] [Android] KeyCloak Authenticator In-Reply-To: <5416F96F.8030605@redhat.com> References: <5416F96F.8030605@redhat.com> Message-ID: <1410794889840.059d9964@Nodemailer> Amazing Summers! Please turn this list of thing into Jiras if possible.? abstractj PGP: 0x84DC9914 On Mon, Sep 15, 2014 at 11:36 AM, Summers Pittman wrote: > DEVELOPERS WILL NEVER HAVE TO WRITE ANOTHER LINE OF AUTH LOGIC > AGAIN! > Over the weekend I tried my hand at writing a Android Account > Authenticator for KeyCloak. This lets Android manage the KeyCloak > account, fetch tokens, provide tokens to other apps etc. KeyCloak > Authenticator let's you drop your keycloak.json file into an apk and > access your KeyCloak Account with one line of code from any application > on your Android device. > Right now this is very much in the "I have an itch needing scratching" > phase. It doesn't do any robust error handling, hasn't been testing off > the golden scenario, has no integration with any of the AeroGear stuff, > etc. Take a moment to watch the Demo and look at the demo project. > Video Demo : > https://plus.google.com/103442292643366117394/posts/WSFbdodMsej > The Demo video uses Android's native account menu to request from the > authenticator a KeyCloak account. This launches the authenticator's > activity which will retrieve the credentials for Android and store > them. When I am back in the settings page and showing off the stored > account, this is all native Android UI and not part of the KeyCloak > authenticator. > When I launch the Demo application this is a separate application from > the authenticator apk. The Demo project fetches the KeyCloak account > from Android and gets its auth token. Then it makes a request to > KeyCloak's account service to fetch the user's account data. > In the demo app there are three lines of code related to auth. > final Account account = am.getAccountsByType("org.keycloak.Account")[0]; > String token = am.getAuthToken(account, "org.keycloak.Account.token", > null, null, null, null).getResult().getString(AccountManager.KEY_AUTHTOKEN); > and > provider.setDefaultHeader("Authorization", "bearer " + token); > The first two lines fetch the account and token from Android. The > second line attaches the account's auth token to the web request to the > server. > So now what? I'll probably use this for my projects/demos because it > makes my work easier. Right now it doesn't have any connection to any > of the "official" projects (Again, I wrote this over the weekend to see > if I could) however it may be quite useful to someone. In the project's > README I've included a (incomplete) list of things that don't work. > wdyt? > Links : > Project : https://github.com/secondsun/keycloak-android-authenticator > Video Demo : > https://plus.google.com/103442292643366117394/posts/WSFbdodMsej > Demo Source : > https://github.com/secondsun/keycloak-account-authenticator-demo/ > -- > Summers Pittman >>>Phone:404 941 4698 >>>Java is my crack. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140915/2f99ff83/attachment-0001.html From supittma at redhat.com Mon Sep 15 12:10:57 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 15 Sep 2014 12:10:57 -0400 Subject: [aerogear-dev] [Android] KeyCloak Authenticator In-Reply-To: <1410794889840.059d9964@Nodemailer> References: <5416F96F.8030605@redhat.com> <1410794889840.059d9964@Nodemailer> Message-ID: <54170F91.9080209@redhat.com> On 09/15/2014 11:28 AM, Bruno Oliveira wrote: > Amazing Summers! Please turn this list of thing into Jiras if possible. Probably will. I need to figure out what this even belongs to (AeroGear, KeyCloak etc) and then get it hosted there. I suppose a cage match between bburke and matzew is in order ;) > --- > abstractj > PGP: 0x84DC9914 > > > On Mon, Sep 15, 2014 at 11:36 AM, Summers Pittman > wrote: > > DEVELOPERS WILL NEVER HAVE TO WRITE ANOTHER LINE OF AUTH LOGIC > AGAIN! > > Over the weekend I tried my hand at writing a Android Account > Authenticator for KeyCloak. This lets Android manage the KeyCloak > account, fetch tokens, provide tokens to other apps etc. KeyCloak > Authenticator let's you drop your keycloak.json file into an apk and > access your KeyCloak Account with one line of code from any > application > on your Android device. > > Right now this is very much in the "I have an itch needing > scratching" > phase. It doesn't do any robust error handling, hasn't been > testing off > the golden scenario, has no integration with any of the AeroGear > stuff, > etc. Take a moment to watch the Demo and look at the demo project. > > Video Demo : > https://plus.google.com/103442292643366117394/posts/WSFbdodMsej > > The Demo video uses Android's native account menu to request from the > authenticator a KeyCloak account. This launches the authenticator's > activity which will retrieve the credentials for Android and store > them. When I am back in the settings page and showing off the stored > account, this is all native Android UI and not part of the KeyCloak > authenticator. > > When I launch the Demo application this is a separate application > from > the authenticator apk. The Demo project fetches the KeyCloak account > from Android and gets its auth token. Then it makes a request to > KeyCloak's account service to fetch the user's account data. > > In the demo app there are three lines of code related to auth. > > final Account account = > am.getAccountsByType("org.keycloak.Account")[0]; > String token = am.getAuthToken(account, "org.keycloak.Account.token", > null, null, null, > null).getResult().getString(AccountManager.KEY_AUTHTOKEN); > > and > > provider.setDefaultHeader("Authorization", "bearer " + token); > > The first two lines fetch the account and token from Android. The > second line attaches the account's auth token to the web request > to the > server. > > So now what? I'll probably use this for my projects/demos because it > makes my work easier. Right now it doesn't have any connection to any > of the "official" projects (Again, I wrote this over the weekend > to see > if I could) however it may be quite useful to someone. In the > project's > README I've included a (incomplete) list of things that don't work. > > wdyt? > > Links : > Project : https://github.com/secondsun/keycloak-android-authenticator > Video Demo : > https://plus.google.com/103442292643366117394/posts/WSFbdodMsej > Demo Source : > https://github.com/secondsun/keycloak-account-authenticator-demo/ > > > -- > Summers Pittman > >>Phone:404 941 4698 > >>Java is my crack. > > _______________________________________________ > 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 -- Summers Pittman >>Phone:404 941 4698 >>Java is my crack. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140915/153fe673/attachment.html From cvasilak at gmail.com Mon Sep 15 13:02:02 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 15 Sep 2014 20:02:02 +0300 Subject: [aerogear-dev] [VOTE] UnifiedPush 1.0.1 Release In-Reply-To: References: Message-ID: Hi tested against ?*wildfly-8.1.0.Final*? and '*jboss-eap-6.3*? using the contacts-quick-start as the driving app. Registered both iOS and Android variants and tested the respective apps (iOS, Android and Cordova variants(Angular / JQM). All worked correctly and successfully send/receive notifications. +1 for the release. (Noticed that the Jira link for the changes is wrong, I think the correct is this one http://tinyurl.com/l59343d) - Christos On Sep 11, 2014, at 5:59 PM, Sebastien Blanc wrote: Hi all, We are pleased to announce that the UnifiedPush Server 1.0.1 has been staged. Thx to the fixers/reviewers/mergers. This release contains mainly UI fixes, Keycloak update and device registration is now async. The full list can be found here : http://red.ht/WNT4Iv The staging repo is here : https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3841/org/jboss/aerogear/unifiedpush/unifiedpush-dist/1.0.1/ Please test and vote ! Sebi _______________________________________________ aerogear-dev mailing list aerogear-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140915/e87bce11/attachment.html From gorkem.ercan at gmail.com Mon Sep 15 15:16:24 2014 From: gorkem.ercan at gmail.com (Gorkem Ercan) Date: Mon, 15 Sep 2014 15:16:24 -0400 Subject: [aerogear-dev] Push server and JBDS Screencast Message-ID: Uploaded a screencats that shows how to develop a push enabled Cordova Application using Push Server with JBoss developer studio 8. You may find it useful. Get it from: https://www.youtube.com/watch?v=DbuCVgZEaDw -- Gorkem -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140915/2dce5ec5/attachment.html From stian at redhat.com Tue Sep 16 02:42:56 2014 From: stian at redhat.com (Stian Thorgersen) Date: Tue, 16 Sep 2014 02:42:56 -0400 (EDT) Subject: [aerogear-dev] [Android] KeyCloak Authenticator In-Reply-To: <5416F96F.8030605@redhat.com> References: <5416F96F.8030605@redhat.com> Message-ID: <1494403184.50136856.1410849776276.JavaMail.zimbra@redhat.com> Really, really nice :) IMO this is absolutely something that should be pursued. We need to figure out where mobile adapters for Keycloak should live. I'm inclined to think that Keycloak itself shouldn't have mobile adapters, but instead we'll have references on our webpages and documentation to point folks towards AeroGear. ----- Original Message ----- > From: "Summers Pittman" > To: "AeroGear Developer Mailing List" > Sent: Monday, 15 September, 2014 4:36:31 PM > Subject: [aerogear-dev] [Android] KeyCloak Authenticator > > DEVELOPERS WILL NEVER HAVE TO WRITE ANOTHER LINE OF AUTH LOGIC > AGAIN! > > Over the weekend I tried my hand at writing a Android Account > Authenticator for KeyCloak. This lets Android manage the KeyCloak > account, fetch tokens, provide tokens to other apps etc. KeyCloak > Authenticator let's you drop your keycloak.json file into an apk and > access your KeyCloak Account with one line of code from any application > on your Android device. > > Right now this is very much in the "I have an itch needing scratching" > phase. It doesn't do any robust error handling, hasn't been testing off > the golden scenario, has no integration with any of the AeroGear stuff, > etc. Take a moment to watch the Demo and look at the demo project. > > Video Demo : > https://plus.google.com/103442292643366117394/posts/WSFbdodMsej > > The Demo video uses Android's native account menu to request from the > authenticator a KeyCloak account. This launches the authenticator's > activity which will retrieve the credentials for Android and store > them. When I am back in the settings page and showing off the stored > account, this is all native Android UI and not part of the KeyCloak > authenticator. > > When I launch the Demo application this is a separate application from > the authenticator apk. The Demo project fetches the KeyCloak account > from Android and gets its auth token. Then it makes a request to > KeyCloak's account service to fetch the user's account data. > > In the demo app there are three lines of code related to auth. > > final Account account = am.getAccountsByType("org.keycloak.Account")[0]; > String token = am.getAuthToken(account, "org.keycloak.Account.token", > null, null, null, null).getResult().getString(AccountManager.KEY_AUTHTOKEN); > > and > > provider.setDefaultHeader("Authorization", "bearer " + token); > > The first two lines fetch the account and token from Android. The > second line attaches the account's auth token to the web request to the > server. > > So now what? I'll probably use this for my projects/demos because it > makes my work easier. Right now it doesn't have any connection to any > of the "official" projects (Again, I wrote this over the weekend to see > if I could) however it may be quite useful to someone. In the project's > README I've included a (incomplete) list of things that don't work. > > wdyt? > > Links : > Project : https://github.com/secondsun/keycloak-android-authenticator > Video Demo : > https://plus.google.com/103442292643366117394/posts/WSFbdodMsej > Demo Source : > https://github.com/secondsun/keycloak-account-authenticator-demo/ > > > -- > Summers Pittman > >>Phone:404 941 4698 > >>Java is my crack. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > From corinnekrych at gmail.com Tue Sep 16 03:45:00 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 16 Sep 2014 09:45:00 +0200 Subject: [aerogear-dev] [Android] KeyCloak Authenticator In-Reply-To: <1494403184.50136856.1410849776276.JavaMail.zimbra@redhat.com> References: <5416F96F.8030605@redhat.com> <1494403184.50136856.1410849776276.JavaMail.zimbra@redhat.com> Message-ID: <263BAE83-701F-485B-A536-B1EFB250C1BE@gmail.com> Hello I think indeed this is an interesting feature to have. We don?t have the same extensible AccountManager in iOS. You can configure social access but the list of available providers is not extensible (not yet at least). However, in aerogear-ios-oauth2 we have an AccountManager capable of easily creating fb, google oauth2 module and we should also have a keycloack one. See https://github.com/corinnekrych/aerogear-ios-oauth2-1/blob/AGIOS-193/AeroGearOAuth2/AccountManager.swift#L20 @summers Similarly as you demo it, for Keycloak it would be nice to create the config file from json Thinking further I think this easy configuration or config integration with os should go on a separate module, it should not be part of oauth2 module. I would suggest a social module. wdyt? ++ Corinne On 16 Sep 2014, at 08:42, Stian Thorgersen wrote: > Really, really nice :) IMO this is absolutely something that should be pursued. > > We need to figure out where mobile adapters for Keycloak should live. I'm inclined to think that Keycloak itself shouldn't have mobile adapters, but instead we'll have references on our webpages and documentation to point folks towards AeroGear. > > ----- Original Message ----- >> From: "Summers Pittman" >> To: "AeroGear Developer Mailing List" >> Sent: Monday, 15 September, 2014 4:36:31 PM >> Subject: [aerogear-dev] [Android] KeyCloak Authenticator >> >> DEVELOPERS WILL NEVER HAVE TO WRITE ANOTHER LINE OF AUTH LOGIC >> AGAIN! >> >> Over the weekend I tried my hand at writing a Android Account >> Authenticator for KeyCloak. This lets Android manage the KeyCloak >> account, fetch tokens, provide tokens to other apps etc. KeyCloak >> Authenticator let's you drop your keycloak.json file into an apk and >> access your KeyCloak Account with one line of code from any application >> on your Android device. >> >> Right now this is very much in the "I have an itch needing scratching" >> phase. It doesn't do any robust error handling, hasn't been testing off >> the golden scenario, has no integration with any of the AeroGear stuff, >> etc. Take a moment to watch the Demo and look at the demo project. >> >> Video Demo : >> https://plus.google.com/103442292643366117394/posts/WSFbdodMsej >> >> The Demo video uses Android's native account menu to request from the >> authenticator a KeyCloak account. This launches the authenticator's >> activity which will retrieve the credentials for Android and store >> them. When I am back in the settings page and showing off the stored >> account, this is all native Android UI and not part of the KeyCloak >> authenticator. >> >> When I launch the Demo application this is a separate application from >> the authenticator apk. The Demo project fetches the KeyCloak account >> from Android and gets its auth token. Then it makes a request to >> KeyCloak's account service to fetch the user's account data. >> >> In the demo app there are three lines of code related to auth. >> >> final Account account = am.getAccountsByType("org.keycloak.Account")[0]; >> String token = am.getAuthToken(account, "org.keycloak.Account.token", >> null, null, null, null).getResult().getString(AccountManager.KEY_AUTHTOKEN); >> >> and >> >> provider.setDefaultHeader("Authorization", "bearer " + token); >> >> The first two lines fetch the account and token from Android. The >> second line attaches the account's auth token to the web request to the >> server. >> >> So now what? I'll probably use this for my projects/demos because it >> makes my work easier. Right now it doesn't have any connection to any >> of the "official" projects (Again, I wrote this over the weekend to see >> if I could) however it may be quite useful to someone. In the project's >> README I've included a (incomplete) list of things that don't work. >> >> wdyt? >> >> Links : >> Project : https://github.com/secondsun/keycloak-android-authenticator >> Video Demo : >> https://plus.google.com/103442292643366117394/posts/WSFbdodMsej >> Demo Source : >> https://github.com/secondsun/keycloak-account-authenticator-demo/ >> >> >> -- >> Summers Pittman >>>> Phone:404 941 4698 >>>> Java is my crack. >> >> _______________________________________________ >> 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 From corinnekrych at gmail.com Tue Sep 16 03:49:26 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 16 Sep 2014 09:49:26 +0200 Subject: [aerogear-dev] [Android] KeyCloak Authenticator In-Reply-To: <263BAE83-701F-485B-A536-B1EFB250C1BE@gmail.com> References: <5416F96F.8030605@redhat.com> <1494403184.50136856.1410849776276.JavaMail.zimbra@redhat.com> <263BAE83-701F-485B-A536-B1EFB250C1BE@gmail.com> Message-ID: I?ve just created https://issues.jboss.org/browse/AGIOS-262 to track it! ++ Corinne On 16 Sep 2014, at 09:45, Corinne Krych wrote: > Hello > > I think indeed this is an interesting feature to have. > > We don?t have the same extensible AccountManager in iOS. You can configure social access but the list of available providers is not extensible (not yet at least). > However, in aerogear-ios-oauth2 we have an AccountManager capable of easily creating fb, google oauth2 module and we should also have a keycloack one. > See > https://github.com/corinnekrych/aerogear-ios-oauth2-1/blob/AGIOS-193/AeroGearOAuth2/AccountManager.swift#L20 > @summers Similarly as you demo it, for Keycloak it would be nice to create the config file from json > > Thinking further I think this easy configuration or config integration with os should go on a separate module, it should not be part of oauth2 module. I would suggest a social module. wdyt? > > ++ > Corinne > > On 16 Sep 2014, at 08:42, Stian Thorgersen wrote: > >> Really, really nice :) IMO this is absolutely something that should be pursued. >> >> We need to figure out where mobile adapters for Keycloak should live. I'm inclined to think that Keycloak itself shouldn't have mobile adapters, but instead we'll have references on our webpages and documentation to point folks towards AeroGear. >> >> ----- Original Message ----- >>> From: "Summers Pittman" >>> To: "AeroGear Developer Mailing List" >>> Sent: Monday, 15 September, 2014 4:36:31 PM >>> Subject: [aerogear-dev] [Android] KeyCloak Authenticator >>> >>> DEVELOPERS WILL NEVER HAVE TO WRITE ANOTHER LINE OF AUTH LOGIC >>> AGAIN! >>> >>> Over the weekend I tried my hand at writing a Android Account >>> Authenticator for KeyCloak. This lets Android manage the KeyCloak >>> account, fetch tokens, provide tokens to other apps etc. KeyCloak >>> Authenticator let's you drop your keycloak.json file into an apk and >>> access your KeyCloak Account with one line of code from any application >>> on your Android device. >>> >>> Right now this is very much in the "I have an itch needing scratching" >>> phase. It doesn't do any robust error handling, hasn't been testing off >>> the golden scenario, has no integration with any of the AeroGear stuff, >>> etc. Take a moment to watch the Demo and look at the demo project. >>> >>> Video Demo : >>> https://plus.google.com/103442292643366117394/posts/WSFbdodMsej >>> >>> The Demo video uses Android's native account menu to request from the >>> authenticator a KeyCloak account. This launches the authenticator's >>> activity which will retrieve the credentials for Android and store >>> them. When I am back in the settings page and showing off the stored >>> account, this is all native Android UI and not part of the KeyCloak >>> authenticator. >>> >>> When I launch the Demo application this is a separate application from >>> the authenticator apk. The Demo project fetches the KeyCloak account >>> from Android and gets its auth token. Then it makes a request to >>> KeyCloak's account service to fetch the user's account data. >>> >>> In the demo app there are three lines of code related to auth. >>> >>> final Account account = am.getAccountsByType("org.keycloak.Account")[0]; >>> String token = am.getAuthToken(account, "org.keycloak.Account.token", >>> null, null, null, null).getResult().getString(AccountManager.KEY_AUTHTOKEN); >>> >>> and >>> >>> provider.setDefaultHeader("Authorization", "bearer " + token); >>> >>> The first two lines fetch the account and token from Android. The >>> second line attaches the account's auth token to the web request to the >>> server. >>> >>> So now what? I'll probably use this for my projects/demos because it >>> makes my work easier. Right now it doesn't have any connection to any >>> of the "official" projects (Again, I wrote this over the weekend to see >>> if I could) however it may be quite useful to someone. In the project's >>> README I've included a (incomplete) list of things that don't work. >>> >>> wdyt? >>> >>> Links : >>> Project : https://github.com/secondsun/keycloak-android-authenticator >>> Video Demo : >>> https://plus.google.com/103442292643366117394/posts/WSFbdodMsej >>> Demo Source : >>> https://github.com/secondsun/keycloak-account-authenticator-demo/ >>> >>> >>> -- >>> Summers Pittman >>>>> Phone:404 941 4698 >>>>> Java is my crack. >>> >>> _______________________________________________ >>> 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 > From scm.blanc at gmail.com Tue Sep 16 08:11:03 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 16 Sep 2014 14:11:03 +0200 Subject: [aerogear-dev] Push server and JBDS Screencast In-Reply-To: References: Message-ID: Thx for sharing Gorkem. This is really a nice and complete screencast ! On Mon, Sep 15, 2014 at 9:16 PM, Gorkem Ercan wrote: > Uploaded a screencats that shows how to develop a push enabled Cordova > Application using Push Server with JBoss developer studio 8. You may find > it useful. > > Get it from: https://www.youtube.com/watch?v=DbuCVgZEaDw > > -- > Gorkem > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140916/8447bb66/attachment.html From cvasilak at gmail.com Tue Sep 16 08:18:51 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 16 Sep 2014 15:18:51 +0300 Subject: [aerogear-dev] iOS meeting In-Reply-To: <731050CF-DEDB-4A4A-B835-1EC606CD35B1@gmail.com> References: <731050CF-DEDB-4A4A-B835-1EC606CD35B1@gmail.com> Message-ID: fyi, meeting minutes: Meeting ended Tue Sep 16 12:04:44 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-09-16-12.00.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-09-16-12.00.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-09-16-12.00.log.html On Tue, Sep 9, 2014 at 11:51 AM, Corinne Krych wrote: > Hello Swifter and iOS lovers, > > > Here is the proposed agenda of our next meeting which will take place > Tuesday 16 September at 2pm (CEST - UTC + 2hours) > soclap.com/p/aerogear_ios_meeting_11sept2014 > > Feel free to add topics to it and join us if you want to discuss with us > next 2.0 iOS release. > > ++ > Corinne > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140916/bb45b43b/attachment.html From supittma at redhat.com Tue Sep 16 09:46:28 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 16 Sep 2014 09:46:28 -0400 Subject: [aerogear-dev] [Android] KeyCloak Authenticator In-Reply-To: <263BAE83-701F-485B-A536-B1EFB250C1BE@gmail.com> References: <5416F96F.8030605@redhat.com> <1494403184.50136856.1410849776276.JavaMail.zimbra@redhat.com> <263BAE83-701F-485B-A536-B1EFB250C1BE@gmail.com> Message-ID: <54183F34.9080000@redhat.com> On 9/16/2014 3:45 AM, Corinne Krych wrote: > Hello > > I think indeed this is an interesting feature to have. > > We don?t have the same extensible AccountManager in iOS. You can configure social access but the list of available providers is not extensible (not yet at least). > However, in aerogear-ios-oauth2 we have an AccountManager capable of easily creating fb, google oauth2 module and we should also have a keycloack one. > See > https://github.com/corinnekrych/aerogear-ios-oauth2-1/blob/AGIOS-193/AeroGearOAuth2/AccountManager.swift#L20 > @summers Similarly as you demo it, for Keycloak it would be nice to create the config file from json > > Thinking further I think this easy configuration or config integration with os should go on a separate module, it should not be part of oauth2 module. I would suggest a social module. wdyt? +.5 :) I would like, in Android, to use the OS level integration for authz (including OAuth2). I think this can be done done without changing the APIs too much/ diverging from iOS. However for the specific modules (keycloak, Google, Facebook) I wouldn't mind separate packages. This is especially so on Android where the Google and Facebook accounts may already be stored locally and not need an extra trip to web land. > > ++ > Corinne > > On 16 Sep 2014, at 08:42, Stian Thorgersen wrote: > >> Really, really nice :) IMO this is absolutely something that should be pursued. >> >> We need to figure out where mobile adapters for Keycloak should live. I'm inclined to think that Keycloak itself shouldn't have mobile adapters, but instead we'll have references on our webpages and documentation to point folks towards AeroGear. >> >> ----- Original Message ----- >>> From: "Summers Pittman" >>> To: "AeroGear Developer Mailing List" >>> Sent: Monday, 15 September, 2014 4:36:31 PM >>> Subject: [aerogear-dev] [Android] KeyCloak Authenticator >>> >>> DEVELOPERS WILL NEVER HAVE TO WRITE ANOTHER LINE OF AUTH LOGIC >>> AGAIN! >>> >>> Over the weekend I tried my hand at writing a Android Account >>> Authenticator for KeyCloak. This lets Android manage the KeyCloak >>> account, fetch tokens, provide tokens to other apps etc. KeyCloak >>> Authenticator let's you drop your keycloak.json file into an apk and >>> access your KeyCloak Account with one line of code from any application >>> on your Android device. >>> >>> Right now this is very much in the "I have an itch needing scratching" >>> phase. It doesn't do any robust error handling, hasn't been testing off >>> the golden scenario, has no integration with any of the AeroGear stuff, >>> etc. Take a moment to watch the Demo and look at the demo project. >>> >>> Video Demo : >>> https://plus.google.com/103442292643366117394/posts/WSFbdodMsej >>> >>> The Demo video uses Android's native account menu to request from the >>> authenticator a KeyCloak account. This launches the authenticator's >>> activity which will retrieve the credentials for Android and store >>> them. When I am back in the settings page and showing off the stored >>> account, this is all native Android UI and not part of the KeyCloak >>> authenticator. >>> >>> When I launch the Demo application this is a separate application from >>> the authenticator apk. The Demo project fetches the KeyCloak account >>> from Android and gets its auth token. Then it makes a request to >>> KeyCloak's account service to fetch the user's account data. >>> >>> In the demo app there are three lines of code related to auth. >>> >>> final Account account = am.getAccountsByType("org.keycloak.Account")[0]; >>> String token = am.getAuthToken(account, "org.keycloak.Account.token", >>> null, null, null, null).getResult().getString(AccountManager.KEY_AUTHTOKEN); >>> >>> and >>> >>> provider.setDefaultHeader("Authorization", "bearer " + token); >>> >>> The first two lines fetch the account and token from Android. The >>> second line attaches the account's auth token to the web request to the >>> server. >>> >>> So now what? I'll probably use this for my projects/demos because it >>> makes my work easier. Right now it doesn't have any connection to any >>> of the "official" projects (Again, I wrote this over the weekend to see >>> if I could) however it may be quite useful to someone. In the project's >>> README I've included a (incomplete) list of things that don't work. >>> >>> wdyt? >>> >>> Links : >>> Project : https://github.com/secondsun/keycloak-android-authenticator >>> Video Demo : >>> https://plus.google.com/103442292643366117394/posts/WSFbdodMsej >>> Demo Source : >>> https://github.com/secondsun/keycloak-account-authenticator-demo/ >>> >>> >>> -- >>> Summers Pittman >>>>> Phone:404 941 4698 >>>>> Java is my crack. >>> _______________________________________________ >>> 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From lukas.fryc at gmail.com Tue Sep 16 10:35:50 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Tue, 16 Sep 2014 16:35:50 +0200 Subject: [aerogear-dev] [VOTE] UnifiedPush 1.0.1 Release In-Reply-To: References: Message-ID: Tried UPS 1.0.1 with Push Quickstart Cordova/Angular on Android and iOS and works like a charm! +1 for pushing a button ~ Lukas On Mon, Sep 15, 2014 at 7:02 PM, Christos Vasilakis wrote: > Hi > > tested against ?*wildfly-8.1.0.Final*? and '*jboss-eap-6.3*? using the > contacts-quick-start as the driving app. Registered both iOS and Android > variants and tested the respective apps (iOS, Android and Cordova > variants(Angular / JQM). > > All worked correctly and successfully send/receive notifications. > > +1 for the release. > > (Noticed that the Jira link for the changes is wrong, I think the correct > is this one http://tinyurl.com/l59343d) > > > - > Christos > > > > On Sep 11, 2014, at 5:59 PM, Sebastien Blanc wrote: > > Hi all, > We are pleased to announce that the UnifiedPush Server 1.0.1 has been > staged. > Thx to the fixers/reviewers/mergers. > > This release contains mainly UI fixes, Keycloak update and device > registration is now async. The full list can be found here : > http://red.ht/WNT4Iv > > The staging repo is here : > > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3841/org/jboss/aerogear/unifiedpush/unifiedpush-dist/1.0.1/ > > Please test and vote ! > > Sebi > > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140916/c40082dc/attachment-0001.html From daniel at passos.me Tue Sep 16 10:45:41 2014 From: daniel at passos.me (Daniel Passos) Date: Tue, 16 Sep 2014 11:45:41 -0300 Subject: [aerogear-dev] Push server and JBDS Screencast In-Reply-To: References: Message-ID: Nice screencast! On Tue, Sep 16, 2014 at 9:11 AM, Sebastien Blanc wrote: > Thx for sharing Gorkem. This is really a nice and complete screencast ! > > On Mon, Sep 15, 2014 at 9:16 PM, Gorkem Ercan > wrote: > >> Uploaded a screencats that shows how to develop a push enabled Cordova >> Application using Push Server with JBoss developer studio 8. You may find >> it useful. >> >> Get it from: https://www.youtube.com/watch?v=DbuCVgZEaDw >> >> -- >> Gorkem >> >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140916/09c205c2/attachment.html From daniel at passos.me Tue Sep 16 10:47:06 2014 From: daniel at passos.me (Daniel Passos) Date: Tue, 16 Sep 2014 11:47:06 -0300 Subject: [aerogear-dev] [VOTE] UnifiedPush 1.0.1 Release In-Reply-To: References: Message-ID: Tested using wildfly-8.1.0.Final and push helloworld (only android) and all works -- Passos On Tue, Sep 16, 2014 at 11:35 AM, Luk?? Fry? wrote: > Tried UPS 1.0.1 with Push Quickstart Cordova/Angular on Android and iOS > and works like a charm! > > > +1 for pushing a button > > ~ Lukas > > On Mon, Sep 15, 2014 at 7:02 PM, Christos Vasilakis > wrote: > >> Hi >> >> tested against ?*wildfly-8.1.0.Final*? and '*jboss-eap-6.3*? using the >> contacts-quick-start as the driving app. Registered both iOS and Android >> variants and tested the respective apps (iOS, Android and Cordova >> variants(Angular / JQM). >> >> All worked correctly and successfully send/receive notifications. >> >> +1 for the release. >> >> (Noticed that the Jira link for the changes is wrong, I think the correct >> is this one http://tinyurl.com/l59343d) >> >> >> - >> Christos >> >> >> >> On Sep 11, 2014, at 5:59 PM, Sebastien Blanc wrote: >> >> Hi all, >> We are pleased to announce that the UnifiedPush Server 1.0.1 has been >> staged. >> Thx to the fixers/reviewers/mergers. >> >> This release contains mainly UI fixes, Keycloak update and device >> registration is now async. The full list can be found here : >> http://red.ht/WNT4Iv >> >> The staging repo is here : >> >> >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3841/org/jboss/aerogear/unifiedpush/unifiedpush-dist/1.0.1/ >> >> Please test and vote ! >> >> Sebi >> >> >> _______________________________________________ >> 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 >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140916/68cc47e5/attachment.html From corinnekrych at gmail.com Tue Sep 16 11:17:10 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 16 Sep 2014 17:17:10 +0200 Subject: [aerogear-dev] [Android] KeyCloak Authenticator In-Reply-To: <54183F34.9080000@redhat.com> References: <5416F96F.8030605@redhat.com> <1494403184.50136856.1410849776276.JavaMail.zimbra@redhat.com> <263BAE83-701F-485B-A536-B1EFB250C1BE@gmail.com> <54183F34.9080000@redhat.com> Message-ID: <1679F0D2-DD9B-4235-B1F0-FBA45DBC93C2@gmail.com> On 16 Sep 2014, at 15:46, Summers Pittman wrote: > On 9/16/2014 3:45 AM, Corinne Krych wrote: >> Hello >> >> I think indeed this is an interesting feature to have. >> >> We don?t have the same extensible AccountManager in iOS. You can configure social access but the list of available providers is not extensible (not yet at least). >> However, in aerogear-ios-oauth2 we have an AccountManager capable of easily creating fb, google oauth2 module and we should also have a keycloack one. >> See >> https://github.com/corinnekrych/aerogear-ios-oauth2-1/blob/AGIOS-193/AeroGearOAuth2/AccountManager.swift#L20 >> @summers Similarly as you demo it, for Keycloak it would be nice to create the config file from json >> >> Thinking further I think this easy configuration or config integration with os should go on a separate module, it should not be part of oauth2 module. I would suggest a social module. wdyt? > +.5 :) > > I would like, in Android, to use the OS level integration for authz > (including OAuth2). I think this can be done done without changing the > APIs too much/ diverging from iOS. Make sense, I don?t think we?ll have an equivalent in iOS > > However for the specific modules (keycloak, Google, Facebook) I wouldn't > mind separate packages. This is especially so on Android where the > Google and Facebook accounts may already be stored locally and not need > an extra trip to web land. Same in iOS land, Twitter, Facebook could come from setting configuration via Social.fwk from Apple. Eventually we?ll move them to aerogear-ios-social or even its own module (we?ll discuss that in more details when time comes). >> >> ++ >> Corinne >> >> On 16 Sep 2014, at 08:42, Stian Thorgersen wrote: >> >>> Really, really nice :) IMO this is absolutely something that should be pursued. >>> >>> We need to figure out where mobile adapters for Keycloak should live. I'm inclined to think that Keycloak itself shouldn't have mobile adapters, but instead we'll have references on our webpages and documentation to point folks towards AeroGear. >>> >>> ----- Original Message ----- >>>> From: "Summers Pittman" >>>> To: "AeroGear Developer Mailing List" >>>> Sent: Monday, 15 September, 2014 4:36:31 PM >>>> Subject: [aerogear-dev] [Android] KeyCloak Authenticator >>>> >>>> DEVELOPERS WILL NEVER HAVE TO WRITE ANOTHER LINE OF AUTH LOGIC >>>> AGAIN! >>>> >>>> Over the weekend I tried my hand at writing a Android Account >>>> Authenticator for KeyCloak. This lets Android manage the KeyCloak >>>> account, fetch tokens, provide tokens to other apps etc. KeyCloak >>>> Authenticator let's you drop your keycloak.json file into an apk and >>>> access your KeyCloak Account with one line of code from any application >>>> on your Android device. >>>> >>>> Right now this is very much in the "I have an itch needing scratching" >>>> phase. It doesn't do any robust error handling, hasn't been testing off >>>> the golden scenario, has no integration with any of the AeroGear stuff, >>>> etc. Take a moment to watch the Demo and look at the demo project. >>>> >>>> Video Demo : >>>> https://plus.google.com/103442292643366117394/posts/WSFbdodMsej >>>> >>>> The Demo video uses Android's native account menu to request from the >>>> authenticator a KeyCloak account. This launches the authenticator's >>>> activity which will retrieve the credentials for Android and store >>>> them. When I am back in the settings page and showing off the stored >>>> account, this is all native Android UI and not part of the KeyCloak >>>> authenticator. >>>> >>>> When I launch the Demo application this is a separate application from >>>> the authenticator apk. The Demo project fetches the KeyCloak account >>>> from Android and gets its auth token. Then it makes a request to >>>> KeyCloak's account service to fetch the user's account data. >>>> >>>> In the demo app there are three lines of code related to auth. >>>> >>>> final Account account = am.getAccountsByType("org.keycloak.Account")[0]; >>>> String token = am.getAuthToken(account, "org.keycloak.Account.token", >>>> null, null, null, null).getResult().getString(AccountManager.KEY_AUTHTOKEN); >>>> >>>> and >>>> >>>> provider.setDefaultHeader("Authorization", "bearer " + token); >>>> >>>> The first two lines fetch the account and token from Android. The >>>> second line attaches the account's auth token to the web request to the >>>> server. >>>> >>>> So now what? I'll probably use this for my projects/demos because it >>>> makes my work easier. Right now it doesn't have any connection to any >>>> of the "official" projects (Again, I wrote this over the weekend to see >>>> if I could) however it may be quite useful to someone. In the project's >>>> README I've included a (incomplete) list of things that don't work. >>>> >>>> wdyt? >>>> >>>> Links : >>>> Project : https://github.com/secondsun/keycloak-android-authenticator >>>> Video Demo : >>>> https://plus.google.com/103442292643366117394/posts/WSFbdodMsej >>>> Demo Source : >>>> https://github.com/secondsun/keycloak-account-authenticator-demo/ >>>> >>>> >>>> -- >>>> Summers Pittman >>>>>> Phone:404 941 4698 >>>>>> Java is my crack. >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 From supittma at redhat.com Tue Sep 16 11:44:57 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 16 Sep 2014 11:44:57 -0400 Subject: [aerogear-dev] [android] Removing AGAuthenticationModule Message-ID: <54185AF9.4080501@redhat.com> AGAuthenticationModule was originally made to login/logout/register with the AeroGear controller. Since controller is dead in a ditch somewhere, for AGDroid 2.0 I'm proposing we remove it from the platform. This will leave HttpBasicAuthenticationModule and HttpDigestAuthenticationModule. However I know this also exists for iOS and Javascript so I'm putting this post up for discussion. wdyt? From lholmqui at redhat.com Tue Sep 16 11:49:17 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 16 Sep 2014 11:49:17 -0400 Subject: [aerogear-dev] [android] Removing AGAuthenticationModule In-Reply-To: <54185AF9.4080501@redhat.com> References: <54185AF9.4080501@redhat.com> Message-ID: i would not be opposed to removing the authentication module for JS since it doesn?t really do anything other than give a short hand for the login/logout/enroll stuff since the browser handles the ?security part of it? On Sep 16, 2014, at 11:44 AM, Summers Pittman wrote: > AGAuthenticationModule was originally made to login/logout/register with > the AeroGear controller. Since controller is dead in a ditch somewhere, > for AGDroid 2.0 I'm proposing we remove it from the platform. This will > leave HttpBasicAuthenticationModule and HttpDigestAuthenticationModule. > However I know this also exists for iOS and Javascript so I'm putting > this post up for discussion. > > wdyt? > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From cvasilak at gmail.com Tue Sep 16 12:07:37 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 16 Sep 2014 19:07:37 +0300 Subject: [aerogear-dev] [android] Removing AGAuthenticationModule In-Reply-To: <54185AF9.4080501@redhat.com> References: <54185AF9.4080501@redhat.com> Message-ID: <8BABC9FE-7CB1-470F-9907-660EAD62FE11@gmail.com> +1 don?t think it makes sense to keep it, for iOS it was used only for the Controller case since basic/digest was already handled by the platform - Christos On Sep 16, 2014, at 6:44 PM, Summers Pittman wrote: > AGAuthenticationModule was originally made to login/logout/register with > the AeroGear controller. Since controller is dead in a ditch somewhere, > for AGDroid 2.0 I'm proposing we remove it from the platform. This will > leave HttpBasicAuthenticationModule and HttpDigestAuthenticationModule. > However I know this also exists for iOS and Javascript so I'm putting > this post up for discussion. > > wdyt? > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From tkriz at redhat.com Wed Sep 17 07:41:07 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Wed, 17 Sep 2014 13:41:07 +0200 Subject: [aerogear-dev] [VOTE] UnifiedPush 1.0.1 Release In-Reply-To: References: Message-ID: <5BDFE445-EEBC-4872-AD6C-306372EC2CC5@redhat.com> Hey, I?ve run integration tests, unit tests and some manual testing. All went well, tests are green. +1 on release. Great job everyone! ? Tadeas Kriz On 16 Sep 2014, at 04:47 pm, Daniel Passos wrote: > Tested using wildfly-8.1.0.Final and push helloworld (only android) and all works > > -- Passos > > On Tue, Sep 16, 2014 at 11:35 AM, Luk?? Fry? wrote: > Tried UPS 1.0.1 with Push Quickstart Cordova/Angular on Android and iOS and works like a charm! > > > +1 for pushing a button > > ~ Lukas > > On Mon, Sep 15, 2014 at 7:02 PM, Christos Vasilakis wrote: > Hi > > tested against ?wildfly-8.1.0.Final? and 'jboss-eap-6.3? using the contacts-quick-start as the driving app. Registered both iOS and Android variants and tested the respective apps (iOS, Android and Cordova variants(Angular / JQM). > > All worked correctly and successfully send/receive notifications. > > +1 for the release. > > (Noticed that the Jira link for the changes is wrong, I think the correct is this one http://tinyurl.com/l59343d) > > > - > Christos > > > > On Sep 11, 2014, at 5:59 PM, Sebastien Blanc wrote: > >> Hi all, >> We are pleased to announce that the UnifiedPush Server 1.0.1 has been staged. >> Thx to the fixers/reviewers/mergers. >> >> This release contains mainly UI fixes, Keycloak update and device registration is now async. The full list can be found here : http://red.ht/WNT4Iv >> >> The staging repo is here : >> >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3841/org/jboss/aerogear/unifiedpush/unifiedpush-dist/1.0.1/ >> >> Please test and vote ! >> >> Sebi >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140917/3afd6a88/attachment.html From lukas.fryc at gmail.com Thu Sep 18 10:03:33 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Thu, 18 Sep 2014 16:03:33 +0200 Subject: [aerogear-dev] Aerogear.js Gang Meeting [Notes] Message-ID: #aerogear: Aerogear.js Gang MeetingMeeting started by lfryc at 12:43:50 UTC (full logs ). Meeting summary 1. *Integration Tests* (lfryc , 12:44:17) 1. integration tests are unstable (see travis builds) (lfryc , 12:44:29) 2. they also use several different approaches for managing and executing external dependencies (lfryc , 12:44:29) 3. test code reusal (e.g. DataManager duplicates lot of code) (lfryc , 12:44:29) 4. https://issues.jboss.org/browse/AGJS-211 (lfryc , 12:44:48) 5. consider cross-browser testing (with Karma), Jasmine for BDD (lfryc , 12:44:59) 6. AGREED: lfryc: yea, what i was thinking (lholmquist , 12:47:32) 7. AGREED: (dbevenius , 12:47:41) 8. ACTION: lfryc write-up on ML about pros/cons of QUnit and Jasmine ( lfryc , 12:50:06) 9. AGREED: (lholmquist , 12:51:05) 10. AGREED: (dbevenius , 12:51:09) 2. *DataSync/Conflict Resolution* (lfryc , 12:51:58) 1. Dan works on creating JIRAs for Conflict Resolution (lfryc , 12:52:12) 2. https://github.com/aerogear/aerogear.org/pull/393 (lfryc , 12:52:16) 3. ACTION: lfryc lholmquist please review the PR (dbevenius , 12:52:57) 4. continued work on Real Time DataSync in parallel (lfryc , 12:53:18) 5. AGREED: dbevenius (lholmquist , 12:55:12) 6. ACTION: lholmquist create JIRAs for next steps for the realtime sync js-client (lfryc , 12:56:03) 7. ACTION: dbevenius create JIRAs for extracting and moving the DiffSync JS client/demo to aergear-js. (dbevenius , 12:56:04) 8. I think it would be nice if it was separate. (dbevenius , 12:57:26) 9. https://github.com/lholmquist/ag-js-ds-poc (lholmquist , 12:58:52) 10. AGREED: (lholmquist , 12:59:53) 11. AGREED: (dbevenius , 13:01:30) 12. AGREED: (lfryc , 13:01:33) 13. AGREED: (lholmquist , 13:01:38) 14. ACTION: lfryc review Luke's syncer (conflict resolution) https://github.com/lholmquist/ag-js-ds-poc/blob/master/app.js (lfryc , 13:02:04) 15. API: consider Data Binding solution - object that is watched for changes from outside and managed by API calls (save(), sync(), next()) - Object.observe, Proxy (lfryc , 13:02:45) 16. AGREED: (dbevenius , 13:04:50) 17. AGREED: (lholmquist , 13:04:53) 18. AGREED: (lfryc , 13:04:55) 3. *ES6 modules* (lfryc , 13:06:04) 1. i think this can be done for 1.X also. Transpiling can give us AMD, Common.JS and Global versions (or use UMD) (lfryc , 13:06:12) 2. http://esnext.github.io/es6-module-transpiler/ (lfryc , 13:06:22) 3. Ember uses this one and is pretty nice (lfryc , 13:06:26) 4. https://github.com/umdjs/umd (lfryc , 13:06:54) 5. AGREED: (lholmquist , 13:09:08) 6. ACTION: lholmquist check whether ES6 can be transpiled to AMD, CommonJS and offer global access at same time (lfryc , 13:11:43) 7. Lukas was considering using Traceur for ES6 transpilation (lfryc , 13:12:32) 8. https://github.com/google/traceur-compiler/wiki/LanguageFeatures#modules (lfryc , 13:12:41) 9. Luke pointed out: traceurs modules still need the traceur loader api, so not sure i like this one (lfryc , 13:12:50) 10. https://github.com/lfryc/traceur-playground (lfryc , 13:13:55) 11. should we be creating separate repo's like the other libraries, are the package managers mature enough for this. (lfryc , 13:14:41) 12. Lukas does not agree that more separate Git repositories are a way to go unless there is specific technical need (lfryc , 13:14:55) 13. AGREED: , this is not a good idea (lholmquist , 13:15:05) 14. AGREED: (dbevenius , 13:15:16) 15. AGREED: (lfryc , 13:15:37) 4. *ES6 features* (lfryc , 13:15:56) 1. Promises - probably pretty soon we can remove the polyfill from being packaged with lib and just link to it (lfryc , 13:16:02) 2. take a look at some of the other features that are available or easily shimmed (lfryc , 13:16:10) 3. https://github.com/paulmillr/es6-shim/ (lfryc , 13:16:15) 4. http://kangax.github.io/compat-table/es6/ (lfryc , 13:16:20) 5. AGREED: that sounds like a plan (lholmquist , 13:17:23) 6. AGREED: (dbevenius , 13:17:36) 7. ACTION: lfryc create a wiki page listing ES6 features we will aim in next development (lfryc , 13:17:44) 8. idea: we can explore and use ES6 for new features as needed, use transpilation to ES5 and revisit their use/shimmability/performance as we reach beta/candidates for 2.0 (lfryc , 13:18:00) 9. AGREED: (lholmquist , 13:18:41) 10. AGREED: (dbevenius , 13:18:46) 11. concern: can we keep transpiled code as accessible to final user on ES5 as it will be for ES6 user? (lfryc , 13:19:27) 5. *custom builder* (lfryc , 13:22:56) 1. gulp might be a better fit for this on the server side (lfryc , 13:23:07) 2. gulp might be a better fit for this on the server side (lholmquist , 13:23:35) 3. this depends on the modules topic, but probably should either have an option for what you want, AMD, commonjs , Global or just package all three together (lholmquist , 13:23:35) 6. *possibility of removing Authentication Module from lib* (lfryc , 13:26:25) 1. http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-android-Removing-AGAuthenticationModule-tp9209.html (lfryc , 13:26:32) 2. Auth doesn't do anyting "security wise", the browser handles all that anyway (lfryc , 13:26:39) 3. still may be beneficial for automatic data sync, server key management (lfryc , 13:26:44) 4. there is an idea to implement Keycloak and Mozilla's Personas adapters, do we want to keep this module around though? (lfryc , 13:26:53) 5. ACTION: lfryc start a ML discussion about removing or keeping Auth with removed REST + mention Keycloak and Mozilla Personas (lfryc , 13:29:41) 7. *deprecating Pipelines* (lfryc , 13:29:55) 1. to be removed in 2.0 (lfryc , 13:30:01) 2. need strategy how to fluently integrate with third-party libraries (jQuery.ajax, AngularJS $resource / Restangular, Ember Data?) (lfryc , 13:30:08) 3. AGREED: (dbevenius , 13:30:34) 4. AGREED: (lholmquist , 13:32:39) 5. AGREED: (dbevenius , 13:32:54) 6. AGREED: keep and support Pipelines in 1.x with no further development, deprecate in 2.0 (lfryc , 13:33:18) 8. *Bower for dependency management* (lfryc , 13:33:30) 1. https://github.com/aerogear/aerogear-js ? (lfryc , 13:35:03) 2. https://github.com/lholmquist/aerogear-js-dist (lholmquist , 13:35:31) 3. ACTION: lholmquist look to see what external deps for aerogear.js are now in bower (lholmquist , 13:37:31) 4. ACTION: lholmquist think about using bower in cookbook examples ( lholmquist , 13:39:59) 9. *Integration with third-party libraries* (lfryc , 13:40:25) 1. AngularJS, Ember (lfryc , 13:40:32) 2. Polymer?, jQuery Mobile? (lfryc , 13:40:32) 3. what about others? (lfryc , 13:40:32) 10. *Priorities for 2.0* (lfryc , 13:45:09) 1. ES6 support: modularity, promises, ... (lfryc , 13:45:19) 2. focus on integration with 3rd party frameworks (lfryc , 13:45:22) 3. refactor build and tests (lfryc , 13:45:22) 4. AGREED: (lholmquist , 13:46:37) 5. AGREED: (dbevenius , 13:46:38) 6. AGREED: ES6 support, data sync, refactor build and tests (lfryc , 13:47:01) 7. AGREED: es6 modules should be sooner than later (lfryc , 13:47:35) 11. *When to start 2.0* (lfryc , 13:47:42) 1. based on discussed usage of ES6 transpilation, I foresee a lot of breaking changes that will disallow simple merges from one branch to another (lfryc , 13:48:06) 2. at some point we have to start limit 1.x changes and focus on 2.0 ( lfryc , 13:48:06) 3. ACTION: lfryc start a ML discussion about when and where to include Data Sync module (lfryc , 13:49:44) 12. *use of Agile / Scrum Boards in JIRA* (lfryc , 13:50:28) 1. Agile boads are awesome way to manage development, load and track progress from version to version (lfryc , 13:50:34) 2. https://www.atlassian.com/software/jira/agile (lfryc , 13:50:39) 3. AGREED: we will try JIRA Agile / Scrum board (lfryc , 13:52:55) 13. *Documentation & Cookbooks* (lfryc , 13:53:48) 1. iOS team did very good job in bringing cookbooks to Aerogear.org site (lfryc , 13:54:08) 2. AGREED: (lholmquist , 13:54:35) 3. AGREED: (dbevenius , 13:54:40) Meeting ended at 13:56:25 UTC (full logs ). Action items 1. lfryc write-up on ML about pros/cons of QUnit and Jasmine 2. lfryc lholmquist please review the PR 3. lholmquist create JIRAs for next steps for the realtime sync js-client 4. dbevenius create JIRAs for extracting and moving the DiffSync JS client/demo to aergear-js. 5. lfryc review Luke's syncer (conflict resolution) https://github.com/lholmquist/ag-js-ds-poc/blob/master/app.js 6. lholmquist check whether ES6 can be transpiled to AMD, CommonJS and offer global access at same time 7. lfryc create a wiki page listing ES6 features we will aim in next development 8. lfryc start a ML discussion about removing or keeping Auth with removed REST + mention Keycloak and Mozilla Personas 9. lholmquist look to see what external deps for aerogear.js are now in bower 10. lholmquist think about using bower in cookbook examples 11. lfryc start a ML discussion about when and where to include Data Sync module Action items, by person 1. dbevenius 1. dbevenius create JIRAs for extracting and moving the DiffSync JS client/demo to aergear-js. 2. lfryc 1. lfryc write-up on ML about pros/cons of QUnit and Jasmine 2. lfryc lholmquist please review the PR 3. lfryc review Luke's syncer (conflict resolution) https://github.com/lholmquist/ag-js-ds-poc/blob/master/app.js 4. lfryc create a wiki page listing ES6 features we will aim in next development 5. lfryc start a ML discussion about removing or keeping Auth with removed REST + mention Keycloak and Mozilla Personas 6. lfryc start a ML discussion about when and where to include Data Sync module 3. lholmquist 1. lfryc lholmquist please review the PR 2. lholmquist create JIRAs for next steps for the realtime sync js-client 3. lfryc review Luke's syncer (conflict resolution) https://github.com/lholmquist/ag-js-ds-poc/blob/master/app.js 4. lholmquist check whether ES6 can be transpiled to AMD, CommonJS and offer global access at same time 5. lholmquist look to see what external deps for aerogear.js are now in bower 6. lholmquist think about using bower in cookbook examples People present (lines said) 1. lfryc (277) 2. lholmquist (103) 3. dbevenius (36) 4. jbossbot (8) 5. jbott (6) 6. aerobot (5) 7. corinnekrych (2) Generated by MeetBot 0.1.4. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140918/1d1a5281/attachment-0001.html From info at ahead-itec.com Thu Sep 18 11:11:30 2014 From: info at ahead-itec.com (Majster Ahead) Date: Thu, 18 Sep 2014 17:11:30 +0200 Subject: [aerogear-dev] aerogear - wp support Message-ID: Hello, We use aerogear to send push notification in android and iOS application, and we need to find same technology for our windows phone application. We are trying to use version 1.0.1. but this do not support windows phone. Also we tried to use source code from master branch because we saw ( https://github.com/aerogear/aerogear.org/pull/384/files) that you work on support for WP but we have problem with some maven plugins (javadoc ...) and after deploying it. After deployment in wildfly 8 and going to [address]/ag-push server responded with status Forbidden (403). When do you plan to release aerogear with WP support? Or can you help us with deployment problem? Thank you. -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140918/a5fa79e2/attachment.html From edewit at redhat.com Thu Sep 18 11:27:04 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 18 Sep 2014 17:27:04 +0200 Subject: [aerogear-dev] aerogear - wp support In-Reply-To: References: Message-ID: <8CD52CA3-DED7-4CFA-A3F3-83B139E885C5@redhat.com> Hi, Right on master (https://github.com/aerogear/aerogear-unifiedpush-server) there is already some windows support, you should already use it already. Could you provide us with some details (logs) so that we can diagnose the problem? Cheers, Erik Jan On 18 Sep,2014, at 17:11 , Majster Ahead wrote: > Hello, > We use aerogear to send push notification in android and iOS application, and we need to find same technology for our windows phone application. > We are trying to use version 1.0.1. but this do not support windows phone. Also we tried to use source code from master branch because we saw (https://github.com/aerogear/aerogear.org/pull/384/files) that you work on support for WP but we have problem with some maven plugins (javadoc ...) and after deploying it. After deployment in wildfly 8 and going to [address]/ag-push server responded with status Forbidden (403). > When do you plan to release aerogear with WP support? Or can you help us with deployment problem? > > Thank you. > > > -- > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140918/ad1a64dc/attachment.html From corinnekrych at gmail.com Thu Sep 18 11:30:19 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 18 Sep 2014 17:30:19 +0200 Subject: [aerogear-dev] some cookbook recipes need some backend Message-ID: Hello Guys To complete our cookbook repositories: iOS, web, android and cordova (still under eric private repo), I?d like to have a aerogear-backend-cookbook. We already have some demos which requires backend. I?ve put them together in: https://github.com/corinnekrych/aerogear-backend-cookbook Each app has a separate build and is independent. For new I?ve put together: AeroDoc PushQuickstart (as submodules) Buddies ProductInventory (oauth2 keycloak) kind of helloWorld app, very simple Next addition, I?m thinking to do a Shoot?nShare file upload Server using Keycloak. So we can have a more complete demo of AeroGear OAuth2 and Keycloak. Thoughts? ++ Corinne From info at ahead-itec.com Thu Sep 18 11:59:03 2014 From: info at ahead-itec.com (Majster Ahead) Date: Thu, 18 Sep 2014 17:59:03 +0200 Subject: [aerogear-dev] aerogear - wp support In-Reply-To: <8CD52CA3-DED7-4CFA-A3F3-83B139E885C5@redhat.com> References: <8CD52CA3-DED7-4CFA-A3F3-83B139E885C5@redhat.com> Message-ID: Hello, after importing maven project: - In adminui - pom.xml : " Plugin execution not covered by lifecycle configuration: com.github.eirslett:frontend-maven-plugin:0.0.16:install-node-and-npm (execution: install node and npm, phase: generate-resources) " after adding tag between and it is OK - When I tried build it: ok until .... [INFO] [INFO] --- maven-jar-plugin:2.4:jar (default-jar) @ unifiedpush-push --- [INFO] Building jar: C:\Users\Ivan\Documents\aerogear-unifiedpush-server-master\push\target\unifiedpush-push-1.1.0-SNAPSHOT.jar [INFO] [INFO] --- maven-source-plugin:2.2.1:jar-no-fork (attach-sources) @ unifiedpush-push --- [INFO] Building jar: C:\Users\Ivan\Documents\aerogear-unifiedpush-server-master\push\target\unifiedpush-push-1.1.0-SNAPSHOT-sources.jar [INFO] [INFO] --- maven-install-plugin:2.4:install (default-install) @ unifiedpush-push --- [INFO] Installing C:\Users\Ivan\Documents\aerogear-unifiedpush-server-master\push\target\unifiedpush-push-1.1.0-SNAPSHOT.jar to C:\Users\Ivan\.m2\repository\org\jboss\aerogear\unifiedpush\unifiedpush-push\1.1.0-SNAPSHOT\unifiedpush-push-1.1.0-SNAPSHOT.jar [INFO] Installing C:\Users\Ivan\Documents\aerogear-unifiedpush-server-master\push\pom.xml to C:\Users\Ivan\.m2\repository\org\jboss\aerogear\unifiedpush\unifiedpush-push\1.1.0-SNAPSHOT\unifiedpush-push-1.1.0-SNAPSHOT.pom [INFO] Installing C:\Users\Ivan\Documents\aerogear-unifiedpush-server-master\push\target\unifiedpush-push-1.1.0-SNAPSHOT-sources.jar to C:\Users\Ivan\.m2\repository\org\jboss\aerogear\unifiedpush\unifiedpush-push\1.1.0-SNAPSHOT\unifiedpush-push-1.1.0-SNAPSHOT-sources.jar [INFO] [INFO] ------------------------------------------------------------------------ [INFO] Building UnifiedPush RESTful Endpoint 1.1.0-SNAPSHOT [INFO] ------------------------------------------------------------------------ [INFO] [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-java-version) @ unifiedpush-jaxrs --- [INFO] [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-maven-version) @ unifiedpush-jaxrs --- [INFO] [INFO] --- buildnumber-maven-plugin:1.2:create-timestamp (get-build-timestamp) @ unifiedpush-jaxrs --- [INFO] [INFO] --- buildnumber-maven-plugin:1.2:create (get-scm-revision) @ unifiedpush-jaxrs --- [INFO] [INFO] >>> maven-javadoc-plugin:2.9:javadoc (jax-rs-docs) > generate-sources @ unifiedpush-jaxrs >>> [INFO] [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-java-version) @ unifiedpush-jaxrs --- [INFO] [INFO] --- maven-enforcer-plugin:1.3.1:enforce (enforce-maven-version) @ unifiedpush-jaxrs --- [INFO] [INFO] --- buildnumber-maven-plugin:1.2:create-timestamp (get-build-timestamp) @ unifiedpush-jaxrs --- [INFO] [INFO] --- buildnumber-maven-plugin:1.2:create (get-scm-revision) @ unifiedpush-jaxrs --- [INFO] [INFO] <<< maven-javadoc-plugin:2.9:javadoc (jax-rs-docs) < generate-sources @ unifiedpush-jaxrs <<< [INFO] [INFO] --- maven-javadoc-plugin:2.9:javadoc (jax-rs-docs) @ unifiedpush-jaxrs --- [ERROR] The given File link: C:\Users\Ivan\Documents\aerogear-unifiedpush-server-master\jaxrs\..\target\site\apidocs is not a dir. [ERROR] Error fetching link: C:\Users\Ivan\Documents\aerogear-unifiedpush-server-master\jaxrs/../target/site/apidocs/package-list. Ignored it. [INFO] Loading source files for package org.jboss.aerogear.unifiedpush.rest... Loading source files for package org.jboss.aerogear.unifiedpush.rest.annotations... Loading source files for package org.jboss.aerogear.unifiedpush.rest.registry.installations... Loading source files for package org.jboss.aerogear.unifiedpush.rest.sender... Constructing Javadoc information... 1 error [INFO] ------------------------------------------------------------------------ [INFO] Reactor Summary: [INFO] [INFO] AeroGear UnifiedPush Server ........................ SUCCESS [ 2.088 s] [INFO] UnifiedPush Model Layer ............................ SUCCESS [ 0.055 s] [INFO] UnifiedPush Server Model API ....................... SUCCESS [ 4.153 s] [INFO] UnifiedPush Server Model JPA implementation ........ SUCCESS [ 16.061 s] [INFO] UnifiedPush Service Layer .......................... SUCCESS [ 16.818 s] [INFO] UnifiedPush Push Notification Networks ............. SUCCESS [ 3.684 s] [INFO] UnifiedPush RESTful Endpoint ....................... FAILURE [ 2.492 s] [INFO] UnifiedPush Server (Admin UI) ...................... SKIPPED [INFO] UnifiedPush Dependencies Parent .................... SKIPPED [INFO] UnifiedPush Server Dependencies Server ............. SKIPPED [INFO] UnifiedPush Auth Server ............................ SKIPPED [INFO] UnifiedPush Server for JBossAS (WAR) ............... SKIPPED [INFO] UnifiedPush Server for Wildfly (WAR) ............... SKIPPED [INFO] UnifiedPush Servers Parent ......................... SKIPPED [INFO] ------------------------------------------------------------------------ [INFO] BUILD FAILURE [INFO] ------------------------------------------------------------------------ [INFO] Total time: 46.359 s [INFO] Finished at: 2014-09-18T17:47:20+02:00 [INFO] Final Memory: 78M/512M [INFO] ------------------------------------------------------------------------ [ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:2.9:javadoc (jax-rs-docs) on project unifiedpush-jaxrs: An error has occurred in JavaDocs report generation: [ERROR] Exit code: 1 - javadoc: error - In doclet class com.lunatech.doclets.jax.jaxrs.JAXRSDoclet, method start has thrown an exception java.lang.reflect.InvocationTargetException [ERROR] java.lang.NullPointerException [ERROR] at com.lunatech.doclets.jax.jaxrs.JAXRSDoclet.(JAXRSDoclet.java:84) [ERROR] at com.lunatech.doclets.jax.jaxrs.JAXRSDoclet.start(JAXRSDoclet.java:78) [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [ERROR] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) [ERROR] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [ERROR] at java.lang.reflect.Method.invoke(Method.java:483) [ERROR] at com.sun.tools.javadoc.DocletInvoker.invoke(DocletInvoker.java:310) [ERROR] at com.sun.tools.javadoc.DocletInvoker.start(DocletInvoker.java:189) [ERROR] at com.sun.tools.javadoc.Start.parseAndExecute(Start.java:366) [ERROR] at com.sun.tools.javadoc.Start.begin(Start.java:219) [ERROR] at com.sun.tools.javadoc.Start.begin(Start.java:205) [ERROR] at com.sun.tools.javadoc.Main.execute(Main.java:64) [ERROR] at com.sun.tools.javadoc.Main.main(Main.java:54) [ERROR] [ERROR] Command line was: "C:\Program Files\Java\jdk1.8.0_20\jre\..\bin\javadoc.exe" @options @packages [ERROR] [ERROR] Refer to the generated Javadoc files in 'C:\Users\Ivan\Documents\aerogear-unifiedpush-server-master\jaxrs\target\site\apidocs' dir. [ERROR] -> [Help 1] [ERROR] [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch. [ERROR] Re-run Maven using the -X switch to enable full debug logging. [ERROR] [ERROR] For more information about the errors and possible solutions, please read the following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException [ERROR] [ERROR] After correcting the problems, you can resume the build with the command [ERROR] mvn -rf :unifiedpush-jaxrs - when I removed from jaxrs from pom.xml block with javadoc ... build is succesfull but after deploying (2 wars and H2 database xml file) on wildfly 8 and going to [address]/ag-push server response status " Forbidden" (403) 2014-09-18 17:27 GMT+02:00 Erik Jan de Wit : > Hi, > > Right on master (https://github.com/aerogear/aerogear-unifiedpush-server) > there is already some windows support, you should already use it already. > Could you provide us with some details (logs) so that we can diagnose the > problem? > > Cheers, > Erik Jan > > On 18 Sep,2014, at 17:11 , Majster Ahead wrote: > > Hello, > We use aerogear to send push notification in android and iOS application, > and we need to find same technology for our windows phone application. > We are trying to use version 1.0.1. but this do not support windows phone. > Also we tried to use source code from master branch because we saw ( > https://github.com/aerogear/aerogear.org/pull/384/files) that you work on > support for WP but we have problem with some maven plugins (javadoc ...) > and after deploying it. After deployment in wildfly 8 and going to > [address]/ag-push server responded with status Forbidden (403). > When do you plan to release aerogear with WP support? Or can you help us > with deployment problem? > > Thank you. > > > -- > > > > _______________________________________________ > 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 > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140918/060a7b45/attachment-0001.html From edewit at redhat.com Thu Sep 18 12:14:45 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Thu, 18 Sep 2014 18:14:45 +0200 Subject: [aerogear-dev] aerogear - wp support In-Reply-To: References: <8CD52CA3-DED7-4CFA-A3F3-83B139E885C5@redhat.com> Message-ID: <665516DF-07A5-4D61-9D74-E35003070CE7@redhat.com> Hi, The problem is that you are building it with jdk8 it has some nice ?improvements? to javadoc that break our build. Easiest solution is to build with jdk7. Cheers, Erik Jan From info at ahead-itec.com Thu Sep 18 12:44:02 2014 From: info at ahead-itec.com (Majster Ahead) Date: Thu, 18 Sep 2014 18:44:02 +0200 Subject: [aerogear-dev] aerogear - wp support In-Reply-To: <665516DF-07A5-4D61-9D74-E35003070CE7@redhat.com> References: <8CD52CA3-DED7-4CFA-A3F3-83B139E885C5@redhat.com> <665516DF-07A5-4D61-9D74-E35003070CE7@redhat.com> Message-ID: Hello, building with jdk7 is better ... but response "Forbidden" after deploying is same 2014-09-18 18:14 GMT+02:00 Erik Jan de Wit : > Hi, > > The problem is that you are building it with jdk8 it has some nice > ?improvements? to javadoc that break our build. Easiest solution is to > build with jdk7. > > Cheers, > Erik Jan > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140918/b0315382/attachment.html From matzew at apache.org Thu Sep 18 12:57:43 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 18 Sep 2014 18:57:43 +0200 Subject: [aerogear-dev] aerogear - wp support In-Reply-To: References: <8CD52CA3-DED7-4CFA-A3F3-83B139E885C5@redhat.com> <665516DF-07A5-4D61-9D74-E35003070CE7@redhat.com> Message-ID: Did you deploy the auth-server as well? On Thursday, September 18, 2014, Majster Ahead wrote: > Hello, > building with jdk7 is better ... but response "Forbidden" after deploying > is same > > 2014-09-18 18:14 GMT+02:00 Erik Jan de Wit >: > >> Hi, >> >> The problem is that you are building it with jdk8 it has some nice >> ?improvements? to javadoc that break our build. Easiest solution is to >> build with jdk7. >> >> Cheers, >> Erik Jan >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > > > > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140918/8f1b949f/attachment.html From info at ahead-itec.com Thu Sep 18 13:00:50 2014 From: info at ahead-itec.com (Majster Ahead) Date: Thu, 18 Sep 2014 19:00:50 +0200 Subject: [aerogear-dev] aerogear - wp support In-Reply-To: References: <8CD52CA3-DED7-4CFA-A3F3-83B139E885C5@redhat.com> <665516DF-07A5-4D61-9D74-E35003070CE7@redhat.com> Message-ID: after remove tag everything is OK ... Thanks :D 2014-09-18 18:57 GMT+02:00 Matthias Wessendorf : > Did you deploy the auth-server as well? > > > On Thursday, September 18, 2014, Majster Ahead > wrote: > >> Hello, >> building with jdk7 is better ... but response "Forbidden" after deploying >> is same >> >> 2014-09-18 18:14 GMT+02:00 Erik Jan de Wit : >> >>> Hi, >>> >>> The problem is that you are building it with jdk8 it has some nice >>> ?improvements? to javadoc that break our build. Easiest solution is to >>> build with jdk7. >>> >>> Cheers, >>> Erik Jan >>> >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >> >> >> >> -- >> >> >> >> > > -- > Sent from Gmail Mobile > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140918/eb075c08/attachment.html From lukas.fryc at gmail.com Thu Sep 18 13:27:28 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Thu, 18 Sep 2014 19:27:28 +0200 Subject: [aerogear-dev] Data Sync / Conflict Resolution: Kick Off Message-ID: Hey guys, we have finished a ritual dance around Conflict Resolution Roadmap and this is the final draft: https://github.com/aerogear/aerogear.org/blob/data-sync-rebirth-roadmap/docs/planning/roadmaps/AeroGearConflictResolution.asciidoc Can I ask all the component leads to do a final review and +1 to acknowledge we can start works here? Off course every review & feedback will be more than welcomed! Cheers, ~ Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140918/cea07f50/attachment.html From lukas.fryc at gmail.com Thu Sep 18 14:14:03 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Thu, 18 Sep 2014 20:14:03 +0200 Subject: [aerogear-dev] Keycloak Ionic / Cordova theme Message-ID: Hey guys, I've started some work on a theme for Keycloak that would include Ionic Framework styling. This makes sure that Ionic/Cordova demos that includes Keycloak has smooth transition between application and login process / registration. See attached screenshots. It's still in early prototypal stage, so just just login, registration and social (only google) fully works so far, but others can be simply expanded. Feel free to use it in demos or so... ;-) Cheers, ~ Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140918/bcc5c27f/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: login.png Type: image/png Size: 10430 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140918/bcc5c27f/attachment-0002.png -------------- next part -------------- A non-text attachment was scrubbed... Name: register.png Type: image/png Size: 12041 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140918/bcc5c27f/attachment-0003.png From lukas.fryc at gmail.com Thu Sep 18 14:19:24 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Thu, 18 Sep 2014 20:19:24 +0200 Subject: [aerogear-dev] Keycloak Ionic / Cordova theme In-Reply-To: References: Message-ID: Yeah and off course, the source is here: https://github.com/lfryc/keycloak/tree/ionic-styling On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? wrote: > Hey guys, > > I've started some work on a theme for Keycloak that would include Ionic > Framework styling. > > This makes sure that Ionic/Cordova demos that includes Keycloak has smooth > transition between application and login process / registration. > > See attached screenshots. > > It's still in early prototypal stage, so just just login, registration and > social (only google) fully works so far, but others can be simply expanded. > > Feel free to use it in demos or so... ;-) > > > Cheers, > > ~ Lukas > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140918/7dca0f7b/attachment.html From scm.blanc at gmail.com Thu Sep 18 16:20:42 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 18 Sep 2014 22:20:42 +0200 Subject: [aerogear-dev] [RELEASE] UnifiedPush Server 1.0.1 has been released Message-ID: Dear community, We?re happy to announce the availability of AeroGear Mobile Push 1.0.1! UnifiedPush Server This release contains a lot of fixes and enhancements . A new feature has been introduced to enable bulk device registrations . Openshift Online The 1.0.1 release of the UnifiedPush Server is available on Openshift . Client SDKsCordova Plugin The Apache Cordova Push Plugin 1.0.1 contains an important fix for the Android Platform. The AeroGear team, http://aerogear.org/news/2014/09/17/aerogear-push-1.0.1-is-out/index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140918/1dc06784/attachment.html From edewit at redhat.com Fri Sep 19 02:08:02 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Fri, 19 Sep 2014 08:08:02 +0200 Subject: [aerogear-dev] Keycloak Ionic / Cordova theme In-Reply-To: References: Message-ID: <2A30DA9D-7924-4F17-BB94-19DC83A4B1C5@redhat.com> Looks very nice, will this integrate well with the work that Summers did? On 18 Sep,2014, at 20:19 , Luk?? Fry? wrote: > Yeah and off course, the source is here: > > https://github.com/lfryc/keycloak/tree/ionic-styling > > On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? wrote: > Hey guys, > > I've started some work on a theme for Keycloak that would include Ionic Framework styling. > > This makes sure that Ionic/Cordova demos that includes Keycloak has smooth transition between application and login process / registration. > > See attached screenshots. > > It's still in early prototypal stage, so just just login, registration and social (only google) fully works so far, but others can be simply expanded. > > Feel free to use it in demos or so... ;-) > > > Cheers, > > ~ Lukas > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140919/b82b3377/attachment.html From stian at redhat.com Fri Sep 19 03:43:02 2014 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 19 Sep 2014 03:43:02 -0400 (EDT) Subject: [aerogear-dev] Keycloak Ionic / Cordova theme In-Reply-To: <2A30DA9D-7924-4F17-BB94-19DC83A4B1C5@redhat.com> References: <2A30DA9D-7924-4F17-BB94-19DC83A4B1C5@redhat.com> Message-ID: <1295869352.52209134.1411112582602.JavaMail.zimbra@redhat.com> This raises the question. Should we allow overriding the theme on an per-application basis? It would allow a better integration with the app, but on the other side does it even make sense to login to a SSO realm that way? ----- Original Message ----- > From: "Erik Jan de Wit" > To: "AeroGear Developer Mailing List" > Cc: keycloak-dev at lists.jboss.org > Sent: Friday, 19 September, 2014 8:08:02 AM > Subject: Re: [aerogear-dev] Keycloak Ionic / Cordova theme > > Looks very nice, will this integrate well with the work that Summers did? > > On 18 Sep,2014, at 20:19 , Luk?? Fry? < lukas.fryc at gmail.com > wrote: > > > > > Yeah and off course, the source is here: > > https://github.com/lfryc/keycloak/tree/ionic-styling > > On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? < lukas.fryc at gmail.com > wrote: > > > > Hey guys, > > I've started some work on a theme for Keycloak that would include Ionic > Framework styling. > > This makes sure that Ionic/Cordova demos that includes Keycloak has smooth > transition between application and login process / registration. > > See attached screenshots. > > It's still in early prototypal stage, so just just login, registration and > social (only google) fully works so far, but others can be simply expanded. > > Feel free to use it in demos or so... ;-) > > > Cheers, > > ~ Lukas > > _______________________________________________ > 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 From matzew at apache.org Fri Sep 19 04:55:03 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 19 Sep 2014 10:55:03 +0200 Subject: [aerogear-dev] [Aerogear-users] [RELEASE] UnifiedPush Server 1.0.1 has been released In-Reply-To: References: Message-ID: Yay! Congrats folks! On Thursday, September 18, 2014, Sebastien Blanc wrote: > Dear community, > > We?re happy to announce the availability of AeroGear Mobile Push 1.0.1! > UnifiedPush Server > > This release contains a lot of fixes and enhancements > > . > > A new feature has been introduced to enable bulk device registrations > > . > Openshift Online > > The 1.0.1 release of the UnifiedPush Server is available on Openshift > > . > Client SDKsCordova Plugin > > The Apache Cordova Push Plugin 1.0.1 > contains > an important fix for the Android Platform. > > The AeroGear team, > > http://aerogear.org/news/2014/09/17/aerogear-push-1.0.1-is-out/index.html > > > > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140919/fa8944da/attachment.html From lukas.fryc at gmail.com Fri Sep 19 07:12:01 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Fri, 19 Sep 2014 13:12:01 +0200 Subject: [aerogear-dev] [android] Removing AGAuthenticationModule In-Reply-To: <8BABC9FE-7CB1-470F-9907-660EAD62FE11@gmail.com> References: <54185AF9.4080501@redhat.com> <8BABC9FE-7CB1-470F-9907-660EAD62FE11@gmail.com> Message-ID: Right now Auth module does not seem to serve any purpose anymore, but as we have discussed on JS meeting, there may possibility to integrate with third-party endpoints such as Keycloak, Auth0, Mozilla Personas, etc. As I can foresee it, Auth module may serve a purpose of single point holding authentication data such as tokens, that can be used for setting up authentication of either third-party frameworks we use (e.g. in demos, such as in AngularJS this can be used to register itself to HTTP request interceptor), or it may handle authentication for our modules, e.g. Data Sync. I'm not saying we shouldn't remove it at this point, but my question is rather what do we recommend instead? ~ Lukas On Tue, Sep 16, 2014 at 6:07 PM, Christos Vasilakis wrote: > +1 don?t think it makes sense to keep it, for iOS it was used only for > the Controller case since basic/digest was already handled by the platform > > - > Christos > > On Sep 16, 2014, at 6:44 PM, Summers Pittman wrote: > > > AGAuthenticationModule was originally made to login/logout/register with > > the AeroGear controller. Since controller is dead in a ditch somewhere, > > for AGDroid 2.0 I'm proposing we remove it from the platform. This will > > leave HttpBasicAuthenticationModule and HttpDigestAuthenticationModule. > > However I know this also exists for iOS and Javascript so I'm putting > > this post up for discussion. > > > > wdyt? > > _______________________________________________ > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140919/23d2ae0c/attachment-0001.html From lukas.fryc at gmail.com Fri Sep 19 07:25:26 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Fri, 19 Sep 2014 13:25:26 +0200 Subject: [aerogear-dev] In which version include Data Sync? 2.0 or 1.x? Message-ID: Hey guys, on yesterday's Aerogear.js meeting we have discussed in which version we should include Data Sync module. Since we are starting works on ES6 compatibility, which is one of the big features for 2.0, it make sense to continue with Data Sync there. What about Android and iOS SDKs? Do you plan to include new module in 2.0 or start that in 1.x and later backport to 2.0? Cheers! ~ Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140919/19233159/attachment.html From stian at redhat.com Fri Sep 19 07:26:54 2014 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 19 Sep 2014 07:26:54 -0400 (EDT) Subject: [aerogear-dev] [keycloak-dev] Keycloak Ionic / Cordova theme In-Reply-To: References: <2A30DA9D-7924-4F17-BB94-19DC83A4B1C5@redhat.com> <1295869352.52209134.1411112582602.JavaMail.zimbra@redhat.com> Message-ID: <351653437.52319304.1411126014067.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Luk?? Fry?" > To: "Stian Thorgersen" > Cc: "AeroGear Developer Mailing List" , keycloak-dev at lists.jboss.org > Sent: Friday, 19 September, 2014 1:18:19 PM > Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme > > IMHO the SSO endpoint could either detect an incoming client (that would be > rather complex) > > or simply allow user client preference. Can we allow more than one theme > per realm and let the client app choohse? Not sure what you mean, we always know which client is requesting the login (it's the client_id query param). The client should only be used for one variant of an application as well (so for an app that has a web, android and ios variants, there should be 3 clients configured in KC). So there's no problem providing an option to override the theme on a per-client basis. > > On Fri, Sep 19, 2014 at 9:43 AM, Stian Thorgersen wrote: > > > This raises the question. Should we allow overriding the theme on an > > per-application basis? > > > > It would allow a better integration with the app, but on the other side > > does it even make sense to login to a SSO realm that way? > > > > ----- Original Message ----- > > > From: "Erik Jan de Wit" > > > To: "AeroGear Developer Mailing List" > > > Cc: keycloak-dev at lists.jboss.org > > > Sent: Friday, 19 September, 2014 8:08:02 AM > > > Subject: Re: [aerogear-dev] Keycloak Ionic / Cordova theme > > > > > > Looks very nice, will this integrate well with the work that Summers did? > > > > > > On 18 Sep,2014, at 20:19 , Luk?? Fry? < lukas.fryc at gmail.com > wrote: > > > > > > > > > > > > > > > Yeah and off course, the source is here: > > > > > > https://github.com/lfryc/keycloak/tree/ionic-styling > > > > > > On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? < lukas.fryc at gmail.com > > > wrote: > > > > > > > > > > > > Hey guys, > > > > > > I've started some work on a theme for Keycloak that would include Ionic > > > Framework styling. > > > > > > This makes sure that Ionic/Cordova demos that includes Keycloak has > > smooth > > > transition between application and login process / registration. > > > > > > See attached screenshots. > > > > > > It's still in early prototypal stage, so just just login, registration > > and > > > social (only google) fully works so far, but others can be simply > > expanded. > > > > > > Feel free to use it in demos or so... ;-) > > > > > > > > > Cheers, > > > > > > ~ Lukas > > > > > > _______________________________________________ > > > 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 > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From lukas.fryc at gmail.com Fri Sep 19 07:30:21 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Fri, 19 Sep 2014 13:30:21 +0200 Subject: [aerogear-dev] [keycloak-dev] Keycloak Ionic / Cordova theme In-Reply-To: <351653437.52319304.1411126014067.JavaMail.zimbra@redhat.com> References: <2A30DA9D-7924-4F17-BB94-19DC83A4B1C5@redhat.com> <1295869352.52209134.1411112582602.JavaMail.zimbra@redhat.com> <351653437.52319304.1411126014067.JavaMail.zimbra@redhat.com> Message-ID: That would be awesome, do I read correctly that it is not possible at the moment? Should I create a feature request? On Fri, Sep 19, 2014 at 1:26 PM, Stian Thorgersen wrote: > ----- Original Message ----- > > From: "Luk?? Fry?" > > To: "Stian Thorgersen" > > Cc: "AeroGear Developer Mailing List" , > keycloak-dev at lists.jboss.org > > Sent: Friday, 19 September, 2014 1:18:19 PM > > Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme > > > > IMHO the SSO endpoint could either detect an incoming client (that would > be > > rather complex) > > > > or simply allow user client preference. Can we allow more than one theme > > per realm and let the client app choohse? > > Not sure what you mean, we always know which client is requesting the > login (it's the client_id query param). The client should only be used for > one variant of an application as well (so for an app that has a web, > android and ios variants, there should be 3 clients configured in KC). So > there's no problem providing an option to override the theme on a > per-client basis. > > > > > On Fri, Sep 19, 2014 at 9:43 AM, Stian Thorgersen > wrote: > > > > > This raises the question. Should we allow overriding the theme on an > > > per-application basis? > > > > > > It would allow a better integration with the app, but on the other side > > > does it even make sense to login to a SSO realm that way? > > > > > > ----- Original Message ----- > > > > From: "Erik Jan de Wit" > > > > To: "AeroGear Developer Mailing List" > > > > Cc: keycloak-dev at lists.jboss.org > > > > Sent: Friday, 19 September, 2014 8:08:02 AM > > > > Subject: Re: [aerogear-dev] Keycloak Ionic / Cordova theme > > > > > > > > Looks very nice, will this integrate well with the work that Summers > did? > > > > > > > > On 18 Sep,2014, at 20:19 , Luk?? Fry? < lukas.fryc at gmail.com > > wrote: > > > > > > > > > > > > > > > > > > > > Yeah and off course, the source is here: > > > > > > > > https://github.com/lfryc/keycloak/tree/ionic-styling > > > > > > > > On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? < lukas.fryc at gmail.com > > > > wrote: > > > > > > > > > > > > > > > > Hey guys, > > > > > > > > I've started some work on a theme for Keycloak that would include > Ionic > > > > Framework styling. > > > > > > > > This makes sure that Ionic/Cordova demos that includes Keycloak has > > > smooth > > > > transition between application and login process / registration. > > > > > > > > See attached screenshots. > > > > > > > > It's still in early prototypal stage, so just just login, > registration > > > and > > > > social (only google) fully works so far, but others can be simply > > > expanded. > > > > > > > > Feel free to use it in demos or so... ;-) > > > > > > > > > > > > Cheers, > > > > > > > > ~ Lukas > > > > > > > > _______________________________________________ > > > > 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 > > > > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140919/ca13adf7/attachment.html From stian at redhat.com Fri Sep 19 07:40:17 2014 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 19 Sep 2014 07:40:17 -0400 (EDT) Subject: [aerogear-dev] [keycloak-dev] Keycloak Ionic / Cordova theme In-Reply-To: References: <2A30DA9D-7924-4F17-BB94-19DC83A4B1C5@redhat.com> <1295869352.52209134.1411112582602.JavaMail.zimbra@redhat.com> <351653437.52319304.1411126014067.JavaMail.zimbra@redhat.com> Message-ID: <2147271865.52323484.1411126817564.JavaMail.zimbra@redhat.com> ----- Original Message ----- > From: "Luk?? Fry?" > To: "Stian Thorgersen" > Cc: "AeroGear Developer Mailing List" , keycloak-dev at lists.jboss.org > Sent: Friday, 19 September, 2014 1:30:21 PM > Subject: Re: [aerogear-dev] [keycloak-dev] Keycloak Ionic / Cordova theme > > That would be awesome, > > do I read correctly that it is not possible at the moment? Should I create a > feature request? Currently we can only configure the theme on a per-realm basis. With the exception of css media-types there's not currently any way to modify the l&f based on client (or client type). An alternative, which may make more sense, is to add multiple variants of a theme. So for example you could have a theme that has web, android, ios, etc variants. Then you have some way of specifying for the client what variant it is. The reason this may make more sense is so that the SSO login screen looks the same whichever application you come from. For example Acme Inc may have two applications (both with web, ios and android variants): * calendar * mail You want the login screen to be adapted to the variant of the apps. So the login screens can look different if you use a browser or if you use a mobile. What you don't want is the login screens to look different for the calendar and mail applications, as it's SSO you're not logging in to an app, you're looging in to a group of apps. Can we reliably detect what variant it is? Or does this have to be configured in the admin console on a per-client basis? > > On Fri, Sep 19, 2014 at 1:26 PM, Stian Thorgersen < stian at redhat.com > wrote: > > > ----- Original Message ----- > > From: "Luk?? Fry?" < lukas at fryc.eu > > > To: "Stian Thorgersen" < stian at redhat.com > > > Cc: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org >, > > keycloak-dev at lists.jboss.org > > Sent: Friday, 19 September, 2014 1:18:19 PM > > Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme > > > > IMHO the SSO endpoint could either detect an incoming client (that would be > > rather complex) > > > > or simply allow user client preference. Can we allow more than one theme > > per realm and let the client app choohse? > > Not sure what you mean, we always know which client is requesting the login > (it's the client_id query param). The client should only be used for one > variant of an application as well (so for an app that has a web, android and > ios variants, there should be 3 clients configured in KC). So there's no > problem providing an option to override the theme on a per-client basis. > > > > > On Fri, Sep 19, 2014 at 9:43 AM, Stian Thorgersen < stian at redhat.com > > > wrote: > > > > > This raises the question. Should we allow overriding the theme on an > > > per-application basis? > > > > > > It would allow a better integration with the app, but on the other side > > > does it even make sense to login to a SSO realm that way? > > > > > > ----- Original Message ----- > > > > From: "Erik Jan de Wit" < edewit at redhat.com > > > > > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > > > > > Cc: keycloak-dev at lists.jboss.org > > > > Sent: Friday, 19 September, 2014 8:08:02 AM > > > > Subject: Re: [aerogear-dev] Keycloak Ionic / Cordova theme > > > > > > > > Looks very nice, will this integrate well with the work that Summers > > > > did? > > > > > > > > On 18 Sep,2014, at 20:19 , Luk?? Fry? < lukas.fryc at gmail.com > wrote: > > > > > > > > > > > > > > > > > > > > Yeah and off course, the source is here: > > > > > > > > https://github.com/lfryc/keycloak/tree/ionic-styling > > > > > > > > On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? < lukas.fryc at gmail.com > > > > wrote: > > > > > > > > > > > > > > > > Hey guys, > > > > > > > > I've started some work on a theme for Keycloak that would include Ionic > > > > Framework styling. > > > > > > > > This makes sure that Ionic/Cordova demos that includes Keycloak has > > > smooth > > > > transition between application and login process / registration. > > > > > > > > See attached screenshots. > > > > > > > > It's still in early prototypal stage, so just just login, registration > > > and > > > > social (only google) fully works so far, but others can be simply > > > expanded. > > > > > > > > Feel free to use it in demos or so... ;-) > > > > > > > > > > > > Cheers, > > > > > > > > ~ Lukas > > > > > > > > _______________________________________________ > > > > 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 > > > > > > _______________________________________________ > > > keycloak-dev mailing list > > > keycloak-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From corinnekrych at gmail.com Fri Sep 19 08:18:36 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 19 Sep 2014 14:18:36 +0200 Subject: [aerogear-dev] In which version include Data Sync? 2.0 or 1.x? In-Reply-To: References: Message-ID: <7A9AD65E-8B5B-46C9-9004-4BBFB69B0C26@gmail.com> Hello Lukas For iOS, I initially planned as part of 2.2 (November), see roadmap: http://aerogear.org/docs/planning/roadmaps/AeroGeariOS/ but looking at finalize roadmap https://github.com/aerogear/aerogear.org/blob/data-sync-rebirth-roadmap/docs/planning/roadmaps/AeroGearConflictResolution.asciidoc I think i?m going to move AGIOS-266 and AGIOS-267 in 2.1 (October) so that it matches both roadmap. Specially we did some work already on Conflict reolution here: https://github.com/corinnekrych/aerogear-diff-patch-ios We?ll need to revisit it in Swift off course. Let me do a PR for iOS roadmap. ++ Corinne On 19 Sep 2014, at 13:25, Luk?? Fry? wrote: > Hey guys, > > on yesterday's Aerogear.js meeting we have discussed in which version we should include Data Sync module. Since we are starting works on ES6 compatibility, which is one of the big features for 2.0, it make sense to continue with Data Sync there. > > What about Android and iOS SDKs? Do you plan to include new module in 2.0 or start that in 1.x and later backport to 2.0? > > > Cheers! > > ~ Lukas > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From corinnekrych at gmail.com Fri Sep 19 08:45:50 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 19 Sep 2014 14:45:50 +0200 Subject: [aerogear-dev] Data Sync / Conflict Resolution: Kick Off In-Reply-To: References: Message-ID: +1 I?ve created https://github.com/aerogear/aerogear.org/pull/394 to adjust. It?s under review. ++ Corinne On 18 Sep 2014, at 19:27, Luk?? Fry? wrote: > Hey guys, > > we have finished a ritual dance around Conflict Resolution Roadmap and this is the final draft: > > https://github.com/aerogear/aerogear.org/blob/data-sync-rebirth-roadmap/docs/planning/roadmaps/AeroGearConflictResolution.asciidoc > > > Can I ask all the component leads to do a final review and +1 to acknowledge we can start works here? > > Off course every review & feedback will be more than welcomed! > > > Cheers, > > ~ Lukas > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From stian at redhat.com Fri Sep 19 08:53:12 2014 From: stian at redhat.com (Stian Thorgersen) Date: Fri, 19 Sep 2014 08:53:12 -0400 (EDT) Subject: [aerogear-dev] [keycloak-dev] Keycloak Ionic / Cordova theme In-Reply-To: References: <2A30DA9D-7924-4F17-BB94-19DC83A4B1C5@redhat.com> <1295869352.52209134.1411112582602.JavaMail.zimbra@redhat.com> <351653437.52319304.1411126014067.JavaMail.zimbra@redhat.com> <2147271865.52323484.1411126817564.JavaMail.zimbra@redhat.com> Message-ID: <1532259035.52366780.1411131192789.JavaMail.zimbra@redhat.com> Another thing we should consider is embedding of the login form. Instead of doing a full-page redirect we could allow embedding using a modal and/or iframe. In that situation you'd also want it to look slightly different than the full-page version. ----- Original Message ----- > From: "Luk?? Fry?" > To: "Stian Thorgersen" > Cc: "AeroGear Developer Mailing List" , keycloak-dev at lists.jboss.org > Sent: Friday, 19 September, 2014 2:49:43 PM > Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova theme > > I completely agree that the SSO should have same look for all applications > using one realm. > > > Yes, a customization can be partially achieved just with CSS tweaks, but it > doesn't have to meet all requirements and further per-platform tweaks may > be necessary. > > In the Ionic demo above I was to meet 70% cases by using built-in CSS > classes. The rest had to be hard-coded. We can either extend CSS classes > coverage or allow higher customization with e.g. theming per variants. > > This feature would make "theming per-platform" easier, I could achieve that > with pure CSS/HTML tweaks and media-queries anyway. > > On Fri, Sep 19, 2014 at 1:40 PM, Stian Thorgersen wrote: > > > > > > > ----- Original Message ----- > > > From: "Luk?? Fry?" > > > To: "Stian Thorgersen" > > > Cc: "AeroGear Developer Mailing List" , > > keycloak-dev at lists.jboss.org > > > Sent: Friday, 19 September, 2014 1:30:21 PM > > > Subject: Re: [aerogear-dev] [keycloak-dev] Keycloak Ionic / Cordova > > theme > > > > > > That would be awesome, > > > > > > do I read correctly that it is not possible at the moment? Should I > > create a > > > feature request? > > > > Currently we can only configure the theme on a per-realm basis. With the > > exception of css media-types there's not currently any way to modify the > > l&f based on client (or client type). > > > > An alternative, which may make more sense, is to add multiple variants of > > a theme. So for example you could have a theme that has web, android, ios, > > etc variants. Then you have some way of specifying for the client what > > variant it is. The reason this may make more sense is so that the SSO login > > screen looks the same whichever application you come from. > > > > For example Acme Inc may have two applications (both with web, ios and > > android variants): > > > > * calendar > > * mail > > > > You want the login screen to be adapted to the variant of the apps. So the > > login screens can look different if you use a browser or if you use a > > mobile. What you don't want is the login screens to look different for the > > calendar and mail applications, as it's SSO you're not logging in to an > > app, you're looging in to a group of apps. > > > > Can we reliably detect what variant it is? Or does this have to be > > configured in the admin console on a per-client basis? > > > > > > > > On Fri, Sep 19, 2014 at 1:26 PM, Stian Thorgersen < stian at redhat.com > > > wrote: > > > > > > > > > ----- Original Message ----- > > > > From: "Luk?? Fry?" < lukas at fryc.eu > > > > > To: "Stian Thorgersen" < stian at redhat.com > > > > > Cc: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > > >, > > > > keycloak-dev at lists.jboss.org > > > > Sent: Friday, 19 September, 2014 1:18:19 PM > > > > Subject: Re: [keycloak-dev] [aerogear-dev] Keycloak Ionic / Cordova > > theme > > > > > > > > IMHO the SSO endpoint could either detect an incoming client (that > > would be > > > > rather complex) > > > > > > > > or simply allow user client preference. Can we allow more than one > > theme > > > > per realm and let the client app choohse? > > > > > > Not sure what you mean, we always know which client is requesting the > > login > > > (it's the client_id query param). The client should only be used for one > > > variant of an application as well (so for an app that has a web, android > > and > > > ios variants, there should be 3 clients configured in KC). So there's no > > > problem providing an option to override the theme on a per-client basis. > > > > > > > > > > > On Fri, Sep 19, 2014 at 9:43 AM, Stian Thorgersen < stian at redhat.com > > > > > wrote: > > > > > > > > > This raises the question. Should we allow overriding the theme on an > > > > > per-application basis? > > > > > > > > > > It would allow a better integration with the app, but on the other > > side > > > > > does it even make sense to login to a SSO realm that way? > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Erik Jan de Wit" < edewit at redhat.com > > > > > > > To: "AeroGear Developer Mailing List" < > > aerogear-dev at lists.jboss.org > > > > > > > Cc: keycloak-dev at lists.jboss.org > > > > > > Sent: Friday, 19 September, 2014 8:08:02 AM > > > > > > Subject: Re: [aerogear-dev] Keycloak Ionic / Cordova theme > > > > > > > > > > > > Looks very nice, will this integrate well with the work that > > Summers > > > > > > did? > > > > > > > > > > > > On 18 Sep,2014, at 20:19 , Luk?? Fry? < lukas.fryc at gmail.com > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Yeah and off course, the source is here: > > > > > > > > > > > > https://github.com/lfryc/keycloak/tree/ionic-styling > > > > > > > > > > > > On Thu, Sep 18, 2014 at 8:14 PM, Luk?? Fry? < lukas.fryc at gmail.com > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hey guys, > > > > > > > > > > > > I've started some work on a theme for Keycloak that would include > > Ionic > > > > > > Framework styling. > > > > > > > > > > > > This makes sure that Ionic/Cordova demos that includes Keycloak has > > > > > smooth > > > > > > transition between application and login process / registration. > > > > > > > > > > > > See attached screenshots. > > > > > > > > > > > > It's still in early prototypal stage, so just just login, > > registration > > > > > and > > > > > > social (only google) fully works so far, but others can be simply > > > > > expanded. > > > > > > > > > > > > Feel free to use it in demos or so... ;-) > > > > > > > > > > > > > > > > > > Cheers, > > > > > > > > > > > > ~ Lukas > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > _______________________________________________ > > > > > keycloak-dev mailing list > > > > > keycloak-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > > > > > > > > > > > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > > keycloak-dev mailing list > > keycloak-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/keycloak-dev > > > From miguel21op at gmail.com Fri Sep 19 09:03:11 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Fri, 19 Sep 2014 14:03:11 +0100 Subject: [aerogear-dev] [Aerogear-users] [RELEASE] UnifiedPush Server 1.0.1 has been released In-Reply-To: References: Message-ID: Hi, hello! Congrats for your work and progresses. I've been out for a while but I'd like to retake the work (WIP...) with your push notifications service and see how it's doing now. Well, I don't know where I stored my credentials to access my account here: https://aerogear-metalpush.rhcloud.com/#/login I don't remember where I saved it. Since there's no password recovery tool, how can I solve this? Thanks Miguel On Fri, Sep 19, 2014 at 9:55 AM, Matthias Wessendorf wrote: > Yay! > > Congrats folks! > > > On Thursday, September 18, 2014, Sebastien Blanc > wrote: > >> Dear community, >> >> We?re happy to announce the availability of AeroGear Mobile Push 1.0.1! >> UnifiedPush Server >> >> This release contains a lot of fixes and enhancements >> >> . >> >> A new feature has been introduced to enable bulk device registrations >> >> . >> Openshift Online >> >> The 1.0.1 release of the UnifiedPush Server is available on Openshift >> >> . >> Client SDKsCordova Plugin >> >> The Apache Cordova Push Plugin 1.0.1 >> contains >> an important fix for the Android Platform. >> >> The AeroGear team, >> >> http://aerogear.org/news/2014/09/17/aerogear-push-1.0.1-is-out/index.html >> >> >> >> > > -- > Sent from Gmail Mobile > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140919/e945d513/attachment.html From supittma at redhat.com Fri Sep 19 09:20:21 2014 From: supittma at redhat.com (Summers Pittman) Date: Fri, 19 Sep 2014 09:20:21 -0400 Subject: [aerogear-dev] In which version include Data Sync? 2.0 or 1.x? In-Reply-To: References: Message-ID: <541C2D95.9050108@redhat.com> On 9/19/2014 7:25 AM, Luk?? Fry? wrote: > Hey guys, > > on yesterday's Aerogear.js meeting we have discussed in which version > we should include Data Sync module. Since we are starting works on ES6 > compatibility, which is one of the big features for 2.0, it make sense > to continue with Data Sync there. > > What about Android and iOS SDKs? Do you plan to include new module in > 2.0 or start that in 1.x and later backport to 2.0? It will be part of 2.0. We don't have any plans to back port this to the 1.x branches of things. Passos, feel free to correct me if I am wrong. > > > Cheers! > > ~ Lukas > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140919/e9289d6a/attachment.html From supittma at redhat.com Fri Sep 19 09:22:18 2014 From: supittma at redhat.com (Summers Pittman) Date: Fri, 19 Sep 2014 09:22:18 -0400 Subject: [aerogear-dev] [android] Removing AGAuthenticationModule In-Reply-To: References: <54185AF9.4080501@redhat.com> <8BABC9FE-7CB1-470F-9907-660EAD62FE11@gmail.com> Message-ID: <541C2E0A.1080802@redhat.com> On Friday, September 19, 2014 7:12:01 AM, Luk?? Fry? wrote: > Right now Auth module does not seem to serve any purpose anymore, > > but as we have discussed on JS meeting, > > there may possibility to integrate with third-party endpoints such as > Keycloak, Auth0, Mozilla Personas, etc. > > > As I can foresee it, Auth module may serve a purpose of single point > holding authentication data such as tokens, > that can be used for setting up authentication of either third-party > frameworks we use (e.g. in demos, such as in AngularJS this can be > used to register itself to HTTP request interceptor), > > or it may handle authentication for our modules, e.g. Data Sync. > > I'm not saying we shouldn't remove it at this point, but my question > is rather what do we recommend instead? I'm not saying we remove the auth module system. I'm just proposing we remove that one implementation because it doesn't do anything. > > ~ Lukas > > On Tue, Sep 16, 2014 at 6:07 PM, Christos Vasilakis > > wrote: > > +1 don?t think it makes sense to keep it, for iOS it was used > only for the Controller case since basic/digest was already > handled by the platform > > - > Christos > > On Sep 16, 2014, at 6:44 PM, Summers Pittman > wrote: > > > AGAuthenticationModule was originally made to > login/logout/register with > > the AeroGear controller. Since controller is dead in a ditch > somewhere, > > for AGDroid 2.0 I'm proposing we remove it from the platform. > This will > > leave HttpBasicAuthenticationModule and > HttpDigestAuthenticationModule. > > However I know this also exists for iOS and Javascript so I'm > putting > > this post up for discussion. > > > > wdyt? > > _______________________________________________ > > 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 > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From lholmqui at redhat.com Fri Sep 19 09:28:27 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 19 Sep 2014 09:28:27 -0400 Subject: [aerogear-dev] [android] Removing AGAuthenticationModule In-Reply-To: <541C2E0A.1080802@redhat.com> References: <54185AF9.4080501@redhat.com> <8BABC9FE-7CB1-470F-9907-660EAD62FE11@gmail.com> <541C2E0A.1080802@redhat.com> Message-ID: On Sep 19, 2014, at 9:22 AM, Summers Pittman wrote: > On Friday, September 19, 2014 7:12:01 AM, Luk?? Fry? wrote: >> Right now Auth module does not seem to serve any purpose anymore, >> >> but as we have discussed on JS meeting, >> >> there may possibility to integrate with third-party endpoints such as >> Keycloak, Auth0, Mozilla Personas, etc. >> >> >> As I can foresee it, Auth module may serve a purpose of single point >> holding authentication data such as tokens, >> that can be used for setting up authentication of either third-party >> frameworks we use (e.g. in demos, such as in AngularJS this can be >> used to register itself to HTTP request interceptor), >> >> or it may handle authentication for our modules, e.g. Data Sync. >> >> I'm not saying we shouldn't remove it at this point, but my question >> is rather what do we recommend instead? > I'm not saying we remove the auth module system. I'm just proposing we > remove that one implementation because it doesn't do anything. right, we, JS, only have 1 adapter, REST, so it might be that we just remove it totally > > > >> >> ~ Lukas >> >> On Tue, Sep 16, 2014 at 6:07 PM, Christos Vasilakis >> > wrote: >> >> +1 don?t think it makes sense to keep it, for iOS it was used >> only for the Controller case since basic/digest was already >> handled by the platform >> >> - >> Christos >> >> On Sep 16, 2014, at 6:44 PM, Summers Pittman > > wrote: >> >>> AGAuthenticationModule was originally made to >> login/logout/register with >>> the AeroGear controller. Since controller is dead in a ditch >> somewhere, >>> for AGDroid 2.0 I'm proposing we remove it from the platform. >> This will >>> leave HttpBasicAuthenticationModule and >> HttpDigestAuthenticationModule. >>> However I know this also exists for iOS and Javascript so I'm >> putting >>> this post up for discussion. >>> >>> wdyt? >>> _______________________________________________ >>> 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 >> >> >> >> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140919/480c778b/attachment.html From lholmqui at redhat.com Fri Sep 19 09:45:26 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 19 Sep 2014 09:45:26 -0400 Subject: [aerogear-dev] In which version include Data Sync? 2.0 or 1.x? In-Reply-To: <7A9AD65E-8B5B-46C9-9004-4BBFB69B0C26@gmail.com> References: <7A9AD65E-8B5B-46C9-9004-4BBFB69B0C26@gmail.com> Message-ID: <5D6FB4E2-9AEC-4F68-B05A-4742CD9AC1B3@redhat.com> On Sep 19, 2014, at 8:18 AM, Corinne Krych wrote: > Hello Lukas > > For iOS, I initially planned as part of 2.2 (November), see roadmap: > http://aerogear.org/docs/planning/roadmaps/AeroGeariOS/ have we discussed yet when 2.0 will start? > > but looking at finalize roadmap > https://github.com/aerogear/aerogear.org/blob/data-sync-rebirth-roadmap/docs/planning/roadmaps/AeroGearConflictResolution.asciidoc > > I think i?m going to move AGIOS-266 and AGIOS-267 in 2.1 (October) so that it matches both roadmap. Specially we did some work already on Conflict reolution here: > https://github.com/corinnekrych/aerogear-diff-patch-ios > > We?ll need to revisit it in Swift off course. Let me do a PR for iOS roadmap. > > ++ > Corinne > On 19 Sep 2014, at 13:25, Luk?? Fry? wrote: > >> Hey guys, >> >> on yesterday's Aerogear.js meeting we have discussed in which version we should include Data Sync module. Since we are starting works on ES6 compatibility, which is one of the big features for 2.0, it make sense to continue with Data Sync there. >> >> What about Android and iOS SDKs? Do you plan to include new module in 2.0 or start that in 1.x and later backport to 2.0? >> >> >> Cheers! >> >> ~ Lukas >> _______________________________________________ >> 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 From scm.blanc at gmail.com Fri Sep 19 09:47:23 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Fri, 19 Sep 2014 15:47:23 +0200 Subject: [aerogear-dev] [Aerogear-users] [RELEASE] UnifiedPush Server 1.0.1 has been released In-Reply-To: References: Message-ID: Hi Miguel ! Welcome back :) ! I see that your UPS instance is still an old one (0.9.0) and to be honest I'm not sure the password is recoverable. You shoudl try our latest version ;) We have a brand new console + user management ! Seb On Fri, Sep 19, 2014 at 3:03 PM, Miguel Lemos wrote: > Hi, hello! > > Congrats for your work and progresses. > > I've been out for a while but I'd like to retake the work (WIP...) with > your push notifications service and see how it's doing now. > > Well, I don't know where I stored my credentials to access my account here: > > https://aerogear-metalpush.rhcloud.com/#/login > > I don't remember where I saved it. Since there's no password recovery > tool, how can I solve this? > > Thanks > > Miguel > > > > On Fri, Sep 19, 2014 at 9:55 AM, Matthias Wessendorf > wrote: > >> Yay! >> >> Congrats folks! >> >> >> On Thursday, September 18, 2014, Sebastien Blanc >> wrote: >> >>> Dear community, >>> >>> We?re happy to announce the availability of AeroGear Mobile Push 1.0.1! >>> UnifiedPush Server >>> >>> This release contains a lot of fixes and enhancements >>> >>> . >>> >>> A new feature has been introduced to enable bulk device registrations >>> >>> . >>> Openshift Online >>> >>> The 1.0.1 release of the UnifiedPush Server is available on Openshift >>> >>> . >>> Client SDKsCordova Plugin >>> >>> The Apache Cordova Push Plugin 1.0.1 >>> contains >>> an important fix for the Android Platform. >>> >>> The AeroGear team, >>> >>> http://aerogear.org/news/2014/09/17/aerogear-push-1.0.1-is-out/index.html >>> >>> >>> >>> >> >> -- >> Sent from Gmail Mobile >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140919/9d58c3f5/attachment.html From miguel21op at gmail.com Fri Sep 19 09:58:01 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Fri, 19 Sep 2014 14:58:01 +0100 Subject: [aerogear-dev] [Aerogear-users] [RELEASE] UnifiedPush Server 1.0.1 has been released In-Reply-To: References: Message-ID: <8576811B-9391-487E-9515-3B79DDA99A1F@gmail.com> Indeed? I must register the devices again? My Openshift account is now useless? Where can I get more info on that? Thanks M Enviado do meu iPhone No dia 19/09/2014, ?s 14:47, Sebastien Blanc escreveu: > Hi Miguel ! Welcome back :) ! > > I see that your UPS instance is still an old one (0.9.0) and to be honest I'm not sure the password is recoverable. > You shoudl try our latest version ;) We have a brand new console + user management ! > > Seb > > >> On Fri, Sep 19, 2014 at 3:03 PM, Miguel Lemos wrote: >> Hi, hello! >> >> Congrats for your work and progresses. >> >> I've been out for a while but I'd like to retake the work (WIP...) with your push notifications service and see how it's doing now. >> >> Well, I don't know where I stored my credentials to access my account here: >> >> https://aerogear-metalpush.rhcloud.com/#/login >> >> I don't remember where I saved it. Since there's no password recovery tool, how can I solve this? >> >> Thanks >> >> Miguel >> >> >> >>> On Fri, Sep 19, 2014 at 9:55 AM, Matthias Wessendorf wrote: >>> Yay! >>> >>> Congrats folks! >>> >>> >>>> On Thursday, September 18, 2014, Sebastien Blanc wrote: >>>> Dear community, >>>> >>>> We?re happy to announce the availability of AeroGear Mobile Push 1.0.1! >>>> >>>> UnifiedPush Server >>>> >>>> This release contains a lot of fixes and enhancements. >>>> >>>> A new feature has been introduced to enable bulk device registrations. >>>> >>>> Openshift Online >>>> >>>> The 1.0.1 release of the UnifiedPush Server is available on Openshift. >>>> >>>> Client SDKs >>>> >>>> Cordova Plugin >>>> >>>> The Apache Cordova Push Plugin 1.0.1 contains an important fix for the Android Platform. >>>> >>>> The AeroGear team, >>>> >>>> http://aerogear.org/news/2014/09/17/aerogear-push-1.0.1-is-out/index.html >>> >>> >>> -- >>> Sent from Gmail Mobile >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140919/1abe919b/attachment-0001.html From lukas.fryc at gmail.com Fri Sep 19 10:16:44 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Fri, 19 Sep 2014 16:16:44 +0200 Subject: [aerogear-dev] [android] Removing AGAuthenticationModule In-Reply-To: References: <54185AF9.4080501@redhat.com> <8BABC9FE-7CB1-470F-9907-660EAD62FE11@gmail.com> <541C2E0A.1080802@redhat.com> Message-ID: Then we may want to remove it in 2.0 until we have a use case for it. WDYT Luke? On Fri, Sep 19, 2014 at 3:28 PM, Lucas Holmquist wrote: > > On Sep 19, 2014, at 9:22 AM, Summers Pittman wrote: > > On Friday, September 19, 2014 7:12:01 AM, Luk?? Fry? wrote: > > Right now Auth module does not seem to serve any purpose anymore, > > but as we have discussed on JS meeting, > > there may possibility to integrate with third-party endpoints such as > Keycloak, Auth0, Mozilla Personas, etc. > > > As I can foresee it, Auth module may serve a purpose of single point > holding authentication data such as tokens, > that can be used for setting up authentication of either third-party > frameworks we use (e.g. in demos, such as in AngularJS this can be > used to register itself to HTTP request interceptor), > > or it may handle authentication for our modules, e.g. Data Sync. > > I'm not saying we shouldn't remove it at this point, but my question > is rather what do we recommend instead? > > I'm not saying we remove the auth module system. I'm just proposing we > remove that one implementation because it doesn't do anything. > > > right, we, JS, only have 1 adapter, REST, so it might be that we just > remove it totally > > > > > > ~ Lukas > > On Tue, Sep 16, 2014 at 6:07 PM, Christos Vasilakis > >> > wrote: > > +1 don?t think it makes sense to keep it, for iOS it was used > only for the Controller case since basic/digest was already > handled by the platform > > - > Christos > > On Sep 16, 2014, at 6:44 PM, Summers Pittman >> wrote: > > AGAuthenticationModule was originally made to > > login/logout/register with > > the AeroGear controller. Since controller is dead in a ditch > > somewhere, > > for AGDroid 2.0 I'm proposing we remove it from the platform. > > This will > > leave HttpBasicAuthenticationModule and > > HttpDigestAuthenticationModule. > > However I know this also exists for iOS and Javascript so I'm > > putting > > this post up for discussion. > > wdyt? > _______________________________________________ > 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 > > > > > _______________________________________________ > 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 > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140919/d429c718/attachment.html From miguel21op at gmail.com Fri Sep 19 10:17:54 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Fri, 19 Sep 2014 15:17:54 +0100 Subject: [aerogear-dev] [Aerogear-users] [RELEASE] UnifiedPush Server 1.0.1 has been released In-Reply-To: References: Message-ID: Seb, Please can you tell me how can I access the new console and if you don't mind give me a link (if there's one) where I can reed about it. Thanks M Enviado do meu iPhone No dia 19/09/2014, ?s 14:47, Sebastien Blanc escreveu: > Hi Miguel ! Welcome back :) ! > > I see that your UPS instance is still an old one (0.9.0) and to be honest I'm not sure the password is recoverable. > You shoudl try our latest version ;) We have a brand new console + user management ! > > Seb > > >> On Fri, Sep 19, 2014 at 3:03 PM, Miguel Lemos wrote: >> Hi, hello! >> >> Congrats for your work and progresses. >> >> I've been out for a while but I'd like to retake the work (WIP...) with your push notifications service and see how it's doing now. >> >> Well, I don't know where I stored my credentials to access my account here: >> >> https://aerogear-metalpush.rhcloud.com/#/login >> >> I don't remember where I saved it. Since there's no password recovery tool, how can I solve this? >> >> Thanks >> >> Miguel >> >> >> >>> On Fri, Sep 19, 2014 at 9:55 AM, Matthias Wessendorf wrote: >>> Yay! >>> >>> Congrats folks! >>> >>> >>>> On Thursday, September 18, 2014, Sebastien Blanc wrote: >>>> Dear community, >>>> >>>> We?re happy to announce the availability of AeroGear Mobile Push 1.0.1! >>>> >>>> UnifiedPush Server >>>> >>>> This release contains a lot of fixes and enhancements. >>>> >>>> A new feature has been introduced to enable bulk device registrations. >>>> >>>> Openshift Online >>>> >>>> The 1.0.1 release of the UnifiedPush Server is available on Openshift. >>>> >>>> Client SDKs >>>> >>>> Cordova Plugin >>>> >>>> The Apache Cordova Push Plugin 1.0.1 contains an important fix for the Android Platform. >>>> >>>> The AeroGear team, >>>> >>>> http://aerogear.org/news/2014/09/17/aerogear-push-1.0.1-is-out/index.html >>> >>> >>> -- >>> Sent from Gmail Mobile >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140919/4f976dd7/attachment.html From lholmqui at redhat.com Fri Sep 19 10:21:35 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 19 Sep 2014 10:21:35 -0400 Subject: [aerogear-dev] [android] Removing AGAuthenticationModule In-Reply-To: References: <54185AF9.4080501@redhat.com> <8BABC9FE-7CB1-470F-9907-660EAD62FE11@gmail.com> <541C2E0A.1080802@redhat.com> Message-ID: On Sep 19, 2014, at 10:16 AM, Luk?? Fry? wrote: > Then we may want to remove it in 2.0 until we have a use case for it. WDYT Luke? yup, lets deprecate, that is, not include it in the build, or we can just delete it > > On Fri, Sep 19, 2014 at 3:28 PM, Lucas Holmquist wrote: > > On Sep 19, 2014, at 9:22 AM, Summers Pittman wrote: > >> On Friday, September 19, 2014 7:12:01 AM, Luk?? Fry? wrote: >>> Right now Auth module does not seem to serve any purpose anymore, >>> >>> but as we have discussed on JS meeting, >>> >>> there may possibility to integrate with third-party endpoints such as >>> Keycloak, Auth0, Mozilla Personas, etc. >>> >>> >>> As I can foresee it, Auth module may serve a purpose of single point >>> holding authentication data such as tokens, >>> that can be used for setting up authentication of either third-party >>> frameworks we use (e.g. in demos, such as in AngularJS this can be >>> used to register itself to HTTP request interceptor), >>> >>> or it may handle authentication for our modules, e.g. Data Sync. >>> >>> I'm not saying we shouldn't remove it at this point, but my question >>> is rather what do we recommend instead? >> I'm not saying we remove the auth module system. I'm just proposing we >> remove that one implementation because it doesn't do anything. > > right, we, JS, only have 1 adapter, REST, so it might be that we just remove it totally > >> >> >> >>> >>> ~ Lukas >>> >>> On Tue, Sep 16, 2014 at 6:07 PM, Christos Vasilakis >>> > wrote: >>> >>> +1 don?t think it makes sense to keep it, for iOS it was used >>> only for the Controller case since basic/digest was already >>> handled by the platform >>> >>> - >>> Christos >>> >>> On Sep 16, 2014, at 6:44 PM, Summers Pittman >> > wrote: >>> >>>> AGAuthenticationModule was originally made to >>> login/logout/register with >>>> the AeroGear controller. Since controller is dead in a ditch >>> somewhere, >>>> for AGDroid 2.0 I'm proposing we remove it from the platform. >>> This will >>>> leave HttpBasicAuthenticationModule and >>> HttpDigestAuthenticationModule. >>>> However I know this also exists for iOS and Javascript so I'm >>> putting >>>> this post up for discussion. >>>> >>>> wdyt? >>>> _______________________________________________ >>>> 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 >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140919/22bfb2fc/attachment-0001.html From scm.blanc at gmail.com Fri Sep 19 10:23:56 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Fri, 19 Sep 2014 16:23:56 +0200 Subject: [aerogear-dev] [Aerogear-users] [RELEASE] UnifiedPush Server 1.0.1 has been released In-Reply-To: References: Message-ID: Links are in my first email of this thread ;) but you can Juste create a new instance of the UnifiedPush server on Openshift , you will have the latest. About your old data, you could access MySQL data and export it. In the new UPS we have a rest endpoint to import devices metadata (link also in my first message). Further, I will be able to help your more after the weekend. Seb Envoy? de mon iPhone > Le 19 sept. 2014 ? 16:17, Miguel Lemos a ?crit : > > Seb, > > Please can you tell me how can I access the new console and if you don't mind give me a link (if there's one) where I can reed about it. > > Thanks > > M > > Enviado do meu iPhone > > No dia 19/09/2014, ?s 14:47, Sebastien Blanc escreveu: > >> Hi Miguel ! Welcome back :) ! >> >> I see that your UPS instance is still an old one (0.9.0) and to be honest I'm not sure the password is recoverable. >> You shoudl try our latest version ;) We have a brand new console + user management ! >> >> Seb >> >> >>> On Fri, Sep 19, 2014 at 3:03 PM, Miguel Lemos wrote: >>> Hi, hello! >>> >>> Congrats for your work and progresses. >>> >>> I've been out for a while but I'd like to retake the work (WIP...) with your push notifications service and see how it's doing now. >>> >>> Well, I don't know where I stored my credentials to access my account here: >>> >>> https://aerogear-metalpush.rhcloud.com/#/login >>> >>> I don't remember where I saved it. Since there's no password recovery tool, how can I solve this? >>> >>> Thanks >>> >>> Miguel >>> >>> >>> >>>> On Fri, Sep 19, 2014 at 9:55 AM, Matthias Wessendorf wrote: >>>> Yay! >>>> >>>> Congrats folks! >>>> >>>> >>>>> On Thursday, September 18, 2014, Sebastien Blanc wrote: >>>>> Dear community, >>>>> >>>>> We?re happy to announce the availability of AeroGear Mobile Push 1.0.1! >>>>> >>>>> UnifiedPush Server >>>>> >>>>> This release contains a lot of fixes and enhancements. >>>>> >>>>> A new feature has been introduced to enable bulk device registrations. >>>>> >>>>> Openshift Online >>>>> >>>>> The 1.0.1 release of the UnifiedPush Server is available on Openshift. >>>>> >>>>> Client SDKs >>>>> >>>>> Cordova Plugin >>>>> >>>>> The Apache Cordova Push Plugin 1.0.1 contains an important fix for the Android Platform. >>>>> >>>>> The AeroGear team, >>>>> >>>>> http://aerogear.org/news/2014/09/17/aerogear-push-1.0.1-is-out/index.html >>>> >>>> >>>> -- >>>> Sent from Gmail Mobile >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140919/f7aabcc0/attachment.html From miguel21op at gmail.com Fri Sep 19 10:55:33 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Fri, 19 Sep 2014 15:55:33 +0100 Subject: [aerogear-dev] [Aerogear-users] [RELEASE] UnifiedPush Server 1.0.1 has been released In-Reply-To: References: Message-ID: <665DD6E6-12A4-413E-A117-9B5917D4D16E@gmail.com> OK. I'll give it a try. Thank you so much. Have a nice weekend ;) M Enviado do meu iPhone No dia 19/09/2014, ?s 15:23, S?bastien Blanc escreveu: > Links are in my first email of this thread ;) but you can Juste create a new instance of the UnifiedPush server on Openshift , you will have the latest. > About your old data, you could access MySQL data and export it. In the new UPS we have a rest endpoint to import devices metadata (link also in my first message). > > Further, I will be able to help your more after the weekend. > > Seb > Envoy? de mon iPhone > >> Le 19 sept. 2014 ? 16:17, Miguel Lemos a ?crit : >> >> Seb, >> >> Please can you tell me how can I access the new console and if you don't mind give me a link (if there's one) where I can reed about it. >> >> Thanks >> >> M >> >> Enviado do meu iPhone >> >> No dia 19/09/2014, ?s 14:47, Sebastien Blanc escreveu: >> >>> Hi Miguel ! Welcome back :) ! >>> >>> I see that your UPS instance is still an old one (0.9.0) and to be honest I'm not sure the password is recoverable. >>> You shoudl try our latest version ;) We have a brand new console + user management ! >>> >>> Seb >>> >>> >>>> On Fri, Sep 19, 2014 at 3:03 PM, Miguel Lemos wrote: >>>> Hi, hello! >>>> >>>> Congrats for your work and progresses. >>>> >>>> I've been out for a while but I'd like to retake the work (WIP...) with your push notifications service and see how it's doing now. >>>> >>>> Well, I don't know where I stored my credentials to access my account here: >>>> >>>> https://aerogear-metalpush.rhcloud.com/#/login >>>> >>>> I don't remember where I saved it. Since there's no password recovery tool, how can I solve this? >>>> >>>> Thanks >>>> >>>> Miguel >>>> >>>> >>>> >>>>> On Fri, Sep 19, 2014 at 9:55 AM, Matthias Wessendorf wrote: >>>>> Yay! >>>>> >>>>> Congrats folks! >>>>> >>>>> >>>>>> On Thursday, September 18, 2014, Sebastien Blanc wrote: >>>>>> Dear community, >>>>>> >>>>>> We?re happy to announce the availability of AeroGear Mobile Push 1.0.1! >>>>>> >>>>>> UnifiedPush Server >>>>>> >>>>>> This release contains a lot of fixes and enhancements. >>>>>> >>>>>> A new feature has been introduced to enable bulk device registrations. >>>>>> >>>>>> Openshift Online >>>>>> >>>>>> The 1.0.1 release of the UnifiedPush Server is available on Openshift. >>>>>> >>>>>> Client SDKs >>>>>> >>>>>> Cordova Plugin >>>>>> >>>>>> The Apache Cordova Push Plugin 1.0.1 contains an important fix for the Android Platform. >>>>>> >>>>>> The AeroGear team, >>>>>> >>>>>> http://aerogear.org/news/2014/09/17/aerogear-push-1.0.1-is-out/index.html >>>>> >>>>> >>>>> -- >>>>> Sent from Gmail Mobile >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________ >>> 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 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140919/698bdd4f/attachment-0001.html From daniel at passos.me Fri Sep 19 13:50:33 2014 From: daniel at passos.me (Daniel Passos) Date: Fri, 19 Sep 2014 14:50:33 -0300 Subject: [aerogear-dev] In which version include Data Sync? 2.0 or 1.x? In-Reply-To: <541C2D95.9050108@redhat.com> References: <541C2D95.9050108@redhat.com> Message-ID: Summers you're never wrong :) BTW, I'm not sure about 2.0 or 2.1, we are in the middle of a BIG refactoring for 2.0 -- Passos On Fri, Sep 19, 2014 at 10:20 AM, Summers Pittman wrote: > On 9/19/2014 7:25 AM, Luk?? Fry? wrote: > > Hey guys, > > on yesterday's Aerogear.js meeting we have discussed in which version we > should include Data Sync module. Since we are starting works on ES6 > compatibility, which is one of the big features for 2.0, it make sense to > continue with Data Sync there. > > What about Android and iOS SDKs? Do you plan to include new module in > 2.0 or start that in 1.x and later backport to 2.0? > > It will be part of 2.0. We don't have any plans to back port this to the > 1.x branches of things. > Passos, feel free to correct me if I am wrong. > > > > Cheers! > > ~ Lukas > > > _______________________________________________ > aerogear-dev mailing listaerogear-dev at lists.jboss.orghttps://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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140919/9291a646/attachment.html From daniel.bevenius at gmail.com Mon Sep 22 03:03:12 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 22 Sep 2014 09:03:12 +0200 Subject: [aerogear-dev] Team Meeting Message-ID: Agenda: http://oksoclap.com/p/aerogear-team-mgt-20140922 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140922/86d1d167/attachment.html From info at ahead-itec.com Mon Sep 22 03:44:31 2014 From: info at ahead-itec.com (Majster Ahead) Date: Mon, 22 Sep 2014 09:44:31 +0200 Subject: [aerogear-dev] type of push notification - WP Message-ID: Hello, is it possible to send RAW push notification using aerogear to Windows Phone 8.1 device? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140922/6af479af/attachment.html From edewit at redhat.com Mon Sep 22 03:50:21 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 22 Sep 2014 09:50:21 +0200 Subject: [aerogear-dev] type of push notification - WP In-Reply-To: References: Message-ID: <3D84283A-C8FE-43ED-B439-DECCFCDD6A34@redhat.com> Not yet, now only toast is supported, but in the future will support RAW as well. On 22 Sep,2014, at 9:44 , Majster Ahead wrote: > Hello, > is it possible to send RAW push notification using aerogear to Windows Phone 8.1 device? > > Thanks > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From daniel.bevenius at gmail.com Mon Sep 22 04:39:26 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 22 Sep 2014 10:39:26 +0200 Subject: [aerogear-dev] SimplePush Server 0.12.0 Staged Message-ID: We have staged AeroGear SimplePush Server 0.12.0: https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3895/ The following JIRAs are included in this staged release: https://issues.jboss.org/issues/?filter=12322070 The tag for this staged release can be found here: https://github.com/aerogear/aerogear-simplepush-server/tree/0.12.0 If you have time, please take it for a spin and report back any issues. Example of testing the Netty server from the command line: 1. Start the server cd server-netty && mvn exec:java 2. Register a channel Open a new terminal window: open src/test/resources/sockjs-client.html Send the hello message and then register a channel by specifying a value for channelID property. Copy the returned pushEndpoint value. 3. Send a notification >From your terminal window, use curl to send a notification: curl -3 -i --header "Content-Type:application/x-www-form-urlencoded" -X PUT Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140922/a03d24ff/attachment.html From cvasilak at gmail.com Mon Sep 22 08:04:59 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 22 Sep 2014 15:04:59 +0300 Subject: [aerogear-dev] SimplePush Server 0.12.0 Staged In-Reply-To: References: Message-ID: Hi Dan, awesome work! tested using your accompanied instructions and worked like a charm! +1 - Christos On Mon, Sep 22, 2014 at 11:39 AM, Daniel Bevenius wrote: > We have staged AeroGear SimplePush Server 0.12.0: > > https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3895/ > > The following JIRAs are included in this staged release: > https://issues.jboss.org/issues/?filter=12322070 > > The tag for this staged release can be found here: > https://github.com/aerogear/aerogear-simplepush-server/tree/0.12.0 > > If you have time, please take it for a spin and report back any issues. > > Example of testing the Netty server from the command line: > 1. Start the server > cd server-netty && mvn exec:java > > 2. Register a channel > Open a new terminal window: > open src/test/resources/sockjs-client.html > Send the hello message and then register a channel by specifying a value > for channelID property. > Copy the returned pushEndpoint value. > > 3. Send a notification > From your terminal window, use curl to send a notification: > curl -3 -i --header "Content-Type:application/x-www-form-urlencoded" -X > PUT > > > Thanks, > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140922/1590bfae/attachment.html From scm.blanc at gmail.com Mon Sep 22 08:16:15 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 22 Sep 2014 14:16:15 +0200 Subject: [aerogear-dev] SimplePush Server 0.12.0 Staged In-Reply-To: References: Message-ID: I haven't tested yet but I was thinking about the UPS Cartridge, since we ship SPS with it. Could we update the cartridge with 0.12 or should we wait for the next UPS release (1.0.2) ? On Mon, Sep 22, 2014 at 2:04 PM, Christos Vasilakis wrote: > Hi Dan, > > awesome work! > > tested using your accompanied instructions and worked like a charm! > > +1 > > - > Christos > > On Mon, Sep 22, 2014 at 11:39 AM, Daniel Bevenius < > daniel.bevenius at gmail.com> wrote: > >> We have staged AeroGear SimplePush Server 0.12.0: >> >> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3895/ >> >> The following JIRAs are included in this staged release: >> https://issues.jboss.org/issues/?filter=12322070 >> >> The tag for this staged release can be found here: >> https://github.com/aerogear/aerogear-simplepush-server/tree/0.12.0 >> >> If you have time, please take it for a spin and report back any issues. >> >> Example of testing the Netty server from the command line: >> 1. Start the server >> cd server-netty && mvn exec:java >> >> 2. Register a channel >> Open a new terminal window: >> open src/test/resources/sockjs-client.html >> Send the hello message and then register a channel by specifying a value >> for channelID property. >> Copy the returned pushEndpoint value. >> >> 3. Send a notification >> From your terminal window, use curl to send a notification: >> curl -3 -i --header "Content-Type:application/x-www-form-urlencoded" -X >> PUT >> >> >> Thanks, >> >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140922/02815288/attachment-0001.html From daniel.bevenius at gmail.com Mon Sep 22 08:24:09 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Mon, 22 Sep 2014 14:24:09 +0200 Subject: [aerogear-dev] SimplePush Server 0.12.0 Staged In-Reply-To: References: Message-ID: I think we can wait with updating the OpenShift cartridge until the next UPS release. But if there is demand for it earlier we can certainly do a separate updated. On 22 September 2014 14:16, Sebastien Blanc wrote: > I haven't tested yet but I was thinking about the UPS Cartridge, since we > ship SPS with it. Could we update the cartridge with 0.12 or should we wait > for the next UPS release (1.0.2) ? > > > On Mon, Sep 22, 2014 at 2:04 PM, Christos Vasilakis > wrote: > >> Hi Dan, >> >> awesome work! >> >> tested using your accompanied instructions and worked like a charm! >> >> +1 >> >> - >> Christos >> >> On Mon, Sep 22, 2014 at 11:39 AM, Daniel Bevenius < >> daniel.bevenius at gmail.com> wrote: >> >>> We have staged AeroGear SimplePush Server 0.12.0: >>> >>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3895/ >>> >>> The following JIRAs are included in this staged release: >>> https://issues.jboss.org/issues/?filter=12322070 >>> >>> The tag for this staged release can be found here: >>> https://github.com/aerogear/aerogear-simplepush-server/tree/0.12.0 >>> >>> If you have time, please take it for a spin and report back any issues. >>> >>> Example of testing the Netty server from the command line: >>> 1. Start the server >>> cd server-netty && mvn exec:java >>> >>> 2. Register a channel >>> Open a new terminal window: >>> open src/test/resources/sockjs-client.html >>> Send the hello message and then register a channel by specifying a value >>> for channelID property. >>> Copy the returned pushEndpoint value. >>> >>> 3. Send a notification >>> From your terminal window, use curl to send a notification: >>> curl -3 -i --header "Content-Type:application/x-www-form-urlencoded" -X >>> PUT >>> >>> >>> Thanks, >>> >>> >>> _______________________________________________ >>> 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 >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140922/1eea75a8/attachment.html From supittma at redhat.com Mon Sep 22 09:17:25 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 22 Sep 2014 09:17:25 -0400 Subject: [aerogear-dev] In which version include Data Sync? 2.0 or 1.x? In-Reply-To: References: <541C2D95.9050108@redhat.com> Message-ID: <54202165.10802@redhat.com> On Friday, September 19, 2014 1:50:33 PM, Daniel Passos wrote: > Summers you're never wrong :) > > BTW, I'm not sure about 2.0 or 2.1, we are in the middle of a BIG > refactoring for 2.0 Can we make a areogear-android-datasync:0.1 then? > > -- Passos > > On Fri, Sep 19, 2014 at 10:20 AM, Summers Pittman > wrote: > > On 9/19/2014 7:25 AM, Luk?? Fry? wrote: >> Hey guys, >> >> on yesterday's Aerogear.js meeting we have discussed in which >> version we should include Data Sync module. Since we are starting >> works on ES6 compatibility, which is one of the big features for >> 2.0, it make sense to continue with Data Sync there. >> >> What about Android and iOS SDKs? Do you plan to include new >> module in 2.0 or start that in 1.x and later backport to 2.0? > It will be part of 2.0. We don't have any plans to back port this > to the 1.x branches of things. > Passos, feel free to correct me if I am wrong. >> >> >> Cheers! >> >> ~ Lukas >> >> >> _______________________________________________ >> 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 > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From daniel at passos.me Mon Sep 22 09:27:02 2014 From: daniel at passos.me (Daniel Passos) Date: Mon, 22 Sep 2014 10:27:02 -0300 Subject: [aerogear-dev] In which version include Data Sync? 2.0 or 1.x? In-Reply-To: <54202165.10802@redhat.com> References: <541C2D95.9050108@redhat.com> <54202165.10802@redhat.com> Message-ID: On Mon, Sep 22, 2014 at 10:17 AM, Summers Pittman wrote: > On Friday, September 19, 2014 1:50:33 PM, Daniel Passos wrote: > >> Summers you're never wrong :) >> >> BTW, I'm not sure about 2.0 or 2.1, we are in the middle of a BIG >> refactoring for 2.0 >> > > Can we make a areogear-android-datasync:0.1 then? > Sure -- Passos >> >> On Fri, Sep 19, 2014 at 10:20 AM, Summers Pittman > > wrote: >> >> On 9/19/2014 7:25 AM, Luk?? Fry? wrote: >> >>> Hey guys, >>> >>> on yesterday's Aerogear.js meeting we have discussed in which >>> version we should include Data Sync module. Since we are starting >>> works on ES6 compatibility, which is one of the big features for >>> 2.0, it make sense to continue with Data Sync there. >>> >>> What about Android and iOS SDKs? Do you plan to include new >>> module in 2.0 or start that in 1.x and later backport to 2.0? >>> >> It will be part of 2.0. We don't have any plans to back port this >> to the 1.x branches of things. >> Passos, feel free to correct me if I am wrong. >> >>> >>> >>> Cheers! >>> >>> ~ Lukas >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140922/3318eb36/attachment.html From cvasilak at gmail.com Mon Sep 22 10:14:32 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 22 Sep 2014 17:14:32 +0300 Subject: [aerogear-dev] Team Meeting In-Reply-To: References: Message-ID: fyi, meeting minutes: Meeting ended Mon Sep 22 14:12:09 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-09-22-14.00.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-09-22-14.00.txt http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-09-22-14.00.log.html On Mon, Sep 22, 2014 at 10:03 AM, Daniel Bevenius wrote: > Agenda: > http://oksoclap.com/p/aerogear-team-mgt-20140922 > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140922/32e026cd/attachment.html From miguel21op at gmail.com Mon Sep 22 11:33:54 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Mon, 22 Sep 2014 16:33:54 +0100 Subject: [aerogear-dev] [RELEASE] UnifiedPush Server 1.0.1 has been released In-Reply-To: References: Message-ID: Hi! I created a new Aerogear application in OpenShift. Then I went to the new Push Server console and created as before the Android variant. So far so good... Then I tried to create my iOS variant, but here I got a problem. I uploaded my certificate and then I'm asked for a passphrase. I assume it's from my Apple account; right? Well, I got an error 400 message when I try to record my settings. What am I doing wrong? Thanks M On Thu, Sep 18, 2014 at 9:20 PM, Sebastien Blanc wrote: > Dear community, > > We?re happy to announce the availability of AeroGear Mobile Push 1.0.1! > UnifiedPush Server > > This release contains a lot of fixes and enhancements > > . > > A new feature has been introduced to enable bulk device registrations > > . > Openshift Online > > The 1.0.1 release of the UnifiedPush Server is available on Openshift > > . > Client SDKsCordova Plugin > > The Apache Cordova Push Plugin 1.0.1 > contains > an important fix for the Android Platform. > > The AeroGear team, > > http://aerogear.org/news/2014/09/17/aerogear-push-1.0.1-is-out/index.html > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140922/88428490/attachment-0001.html From scm.blanc at gmail.com Mon Sep 22 11:45:15 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 22 Sep 2014 17:45:15 +0200 Subject: [aerogear-dev] [RELEASE] UnifiedPush Server 1.0.1 has been released In-Reply-To: References: Message-ID: Hi Miguel ! The passphrase is not from your Apple account. It's the passphrase you created when you exported your certifcate to the p12 format , it's explained here http://aerogear.org/docs/unifiedpush/aerogear-push-ios/app-id-ssl-certificate-apns/ (almost at the end of the page). Seb On Mon, Sep 22, 2014 at 5:33 PM, Miguel Lemos wrote: > Hi! > > I created a new Aerogear application in OpenShift. Then I went to the new > Push Server console and created as before the Android variant. So far so > good... > Then I tried to create my iOS variant, but here I got a problem. I > uploaded my certificate and then I'm asked for a passphrase. I assume it's > from my Apple account; right? > Well, I got an error 400 message when I try to record my settings. > > What am I doing wrong? > > Thanks > > M > > On Thu, Sep 18, 2014 at 9:20 PM, Sebastien Blanc > wrote: > >> Dear community, >> >> We?re happy to announce the availability of AeroGear Mobile Push 1.0.1! >> UnifiedPush Server >> >> This release contains a lot of fixes and enhancements >> >> . >> >> A new feature has been introduced to enable bulk device registrations >> >> . >> Openshift Online >> >> The 1.0.1 release of the UnifiedPush Server is available on Openshift >> >> . >> Client SDKsCordova Plugin >> >> The Apache Cordova Push Plugin 1.0.1 >> contains >> an important fix for the Android Platform. >> >> The AeroGear team, >> >> http://aerogear.org/news/2014/09/17/aerogear-push-1.0.1-is-out/index.html >> >> >> >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140922/adeaa0df/attachment.html From miguel21op at gmail.com Mon Sep 22 12:46:47 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Mon, 22 Sep 2014 17:46:47 +0100 Subject: [aerogear-dev] [RELEASE] UnifiedPush Server 1.0.1 has been released In-Reply-To: References: Message-ID: OK. Thanks. I'll see that. Enviado do meu iPhone No dia 22/09/2014, ?s 16:45, Sebastien Blanc escreveu: > Hi Miguel ! > > The passphrase is not from your Apple account. It's the passphrase you created when you exported your certifcate to the p12 format , it's explained here http://aerogear.org/docs/unifiedpush/aerogear-push-ios/app-id-ssl-certificate-apns/ (almost at the end of the page). > > Seb > > >> On Mon, Sep 22, 2014 at 5:33 PM, Miguel Lemos wrote: >> Hi! >> >> I created a new Aerogear application in OpenShift. Then I went to the new Push Server console and created as before the Android variant. So far so good... >> Then I tried to create my iOS variant, but here I got a problem. I uploaded my certificate and then I'm asked for a passphrase. I assume it's from my Apple account; right? >> Well, I got an error 400 message when I try to record my settings. >> >> What am I doing wrong? >> >> Thanks >> >> M >> >>> On Thu, Sep 18, 2014 at 9:20 PM, Sebastien Blanc wrote: >>> Dear community, >>> >>> We?re happy to announce the availability of AeroGear Mobile Push 1.0.1! >>> >>> UnifiedPush Server >>> >>> This release contains a lot of fixes and enhancements. >>> >>> A new feature has been introduced to enable bulk device registrations. >>> >>> Openshift Online >>> >>> The 1.0.1 release of the UnifiedPush Server is available on Openshift. >>> >>> Client SDKs >>> >>> Cordova Plugin >>> >>> The Apache Cordova Push Plugin 1.0.1 contains an important fix for the Android Platform. >>> >>> The AeroGear team, >>> >>> http://aerogear.org/news/2014/09/17/aerogear-push-1.0.1-is-out/index.html >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140922/dcaca808/attachment.html From lholmqui at redhat.com Tue Sep 23 10:39:38 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 23 Sep 2014 10:39:38 -0400 Subject: [aerogear-dev] Javascript moving to 2.0 Message-ID: Hello all, As the subject implies, we will be moving the 2.0 branch of AeroGear.js to master very shortly. So all current development in the master branch will be for 2.0 and BEYOND!!!11!!!one!11! There is 1.x branch that will be maintained for bug fixes and such. Some highlights that will be coming in the 2.x series: * Removal of Pipeline and Authentication * Promisfying the Whole Library( where it makes sense ) * ES6 Modules * Data Sync/Conflict Resolution * and more?. -Luke From daniel.bevenius at gmail.com Thu Sep 25 04:01:58 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Thu, 25 Sep 2014 10:01:58 +0200 Subject: [aerogear-dev] SimplePush Server 0.12.0 Staged In-Reply-To: References: Message-ID: I've pressed the button and 0.12.0 should be available on Maven Central any hour/day now. Sebi and Christos, thanks for testing and feedback! On 22 September 2014 14:24, Daniel Bevenius wrote: > I think we can wait with updating the OpenShift cartridge until the next > UPS release. But if there is demand for it earlier we can certainly do a > separate updated. > > > > On 22 September 2014 14:16, Sebastien Blanc wrote: > >> I haven't tested yet but I was thinking about the UPS Cartridge, since we >> ship SPS with it. Could we update the cartridge with 0.12 or should we wait >> for the next UPS release (1.0.2) ? >> >> >> On Mon, Sep 22, 2014 at 2:04 PM, Christos Vasilakis >> wrote: >> >>> Hi Dan, >>> >>> awesome work! >>> >>> tested using your accompanied instructions and worked like a charm! >>> >>> +1 >>> >>> - >>> Christos >>> >>> On Mon, Sep 22, 2014 at 11:39 AM, Daniel Bevenius < >>> daniel.bevenius at gmail.com> wrote: >>> >>>> We have staged AeroGear SimplePush Server 0.12.0: >>>> >>>> https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-3895/ >>>> >>>> The following JIRAs are included in this staged release: >>>> https://issues.jboss.org/issues/?filter=12322070 >>>> >>>> The tag for this staged release can be found here: >>>> https://github.com/aerogear/aerogear-simplepush-server/tree/0.12.0 >>>> >>>> If you have time, please take it for a spin and report back any issues. >>>> >>>> Example of testing the Netty server from the command line: >>>> 1. Start the server >>>> cd server-netty && mvn exec:java >>>> >>>> 2. Register a channel >>>> Open a new terminal window: >>>> open src/test/resources/sockjs-client.html >>>> Send the hello message and then register a channel by specifying a >>>> value for channelID property. >>>> Copy the returned pushEndpoint value. >>>> >>>> 3. Send a notification >>>> From your terminal window, use curl to send a notification: >>>> curl -3 -i --header "Content-Type:application/x-www-form-urlencoded" -X >>>> PUT >>>> >>>> >>>> Thanks, >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140925/97010f50/attachment-0001.html From lukas.fryc at gmail.com Thu Sep 25 07:16:20 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Thu, 25 Sep 2014 13:16:20 +0200 Subject: [aerogear-dev] Deprecation of WebSQL adapter Message-ID: Hey guys, during F2F we have been discussing deprecation of WebSQL DataManager in AeroGear.js, because its "rival", IndexedDB, is already supported in all browsers (WebSQL isn't). http://caniuse.com/#search=indexeddb http://caniuse.com/#search=websql I suggest we make IndexedDB adapter Stable and supported and Deprecate WebSQL. Actually both are Experimental in 1.5.2, so there is no reason for deprecation. We can also leave it around as long as it does not diverge from other DataManagers. What are your feelings? Cheers, ~ Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140925/8d3e978e/attachment.html From lukas.fryc at gmail.com Thu Sep 25 07:36:36 2014 From: lukas.fryc at gmail.com (=?UTF-8?B?THVrw6HFoSBGcnnEjQ==?=) Date: Thu, 25 Sep 2014 13:36:36 +0200 Subject: [aerogear-dev] Karma runner for Aerogear.js tests Message-ID: Hey guys, I was thinking about adopting Karma runner for running QUnit tests in AeroGear.js project. Currently we use grunt-contrib-qunit, but this runner is able to run tests just on PhantomJS and PhantomJS itself has some defficiencies, such as it does not support IndexedDB. Karma, on the other hand, is able to run in all mainstream browsers [1], headless browsers such as PhantomJS, and it has even support for cloud-driven browsers such as BrowserStack or SauceLabs (through those we could actually test inside mobile browsers; at least SauceLabs offers free hours for open source projects). This would give us pretty good coverage in terms of compatibility testing. What do you think? Cheers! ~ Lukas [1] http://karma-runner.github.io/0.12/config/browsers.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140925/4e1d2754/attachment.html From lholmqui at redhat.com Thu Sep 25 08:30:28 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Thu, 25 Sep 2014 08:30:28 -0400 Subject: [aerogear-dev] Deprecation of WebSQL adapter In-Reply-To: References: Message-ID: On Sep 25, 2014, at 7:16 AM, Luk?? Fry? wrote: > Hey guys, > > during F2F we have been discussing deprecation of WebSQL DataManager in AeroGear.js, > > because its "rival", IndexedDB, is already supported in all browsers (WebSQL isn't). i would like to keep it around, just deprecated in the docs. > > http://caniuse.com/#search=indexeddb > http://caniuse.com/#search=websql > > I suggest we make IndexedDB adapter Stable and supported and Deprecate WebSQL. > > Actually both are Experimental in 1.5.2, so there is no reason for deprecation. > > We can also leave it around as long as it does not diverge from other DataManagers. > > > What are your feelings? > > > Cheers, > > ~ Lukas > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140925/12894235/attachment.html From miguel21op at gmail.com Thu Sep 25 09:07:18 2014 From: miguel21op at gmail.com (Miguel Lemos) Date: Thu, 25 Sep 2014 14:07:18 +0100 Subject: [aerogear-dev] Deprecation of WebSQL adapter In-Reply-To: References: Message-ID: Many people still prefer to use WebSQL. Enviado do meu iPhone No dia 25/09/2014, ?s 13:30, Lucas Holmquist escreveu: > >> On Sep 25, 2014, at 7:16 AM, Luk?? Fry? wrote: >> >> Hey guys, >> >> during F2F we have been discussing deprecation of WebSQL DataManager in AeroGear.js, >> >> because its "rival", IndexedDB, is already supported in all browsers (WebSQL isn't). > > i would like to keep it around, just deprecated in the docs. > >> >> http://caniuse.com/#search=indexeddb >> http://caniuse.com/#search=websql >> >> I suggest we make IndexedDB adapter Stable and supported and Deprecate WebSQL. >> >> Actually both are Experimental in 1.5.2, so there is no reason for deprecation. >> >> We can also leave it around as long as it does not diverge from other DataManagers. >> >> >> What are your feelings? >> >> >> Cheers, >> >> ~ Lukas >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140925/ade436e6/attachment.html From daniel.bevenius at gmail.com Fri Sep 26 03:20:13 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 26 Sep 2014 09:20:13 +0200 Subject: [aerogear-dev] Team meeting Message-ID: Agenda for Mondays team meeting: http://oksoclap.com/p/aerogear-team-mgt-20140929 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140926/bcb75c23/attachment.html From cvasilak at gmail.com Mon Sep 29 10:10:36 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 29 Sep 2014 17:10:36 +0300 Subject: [aerogear-dev] Team meeting In-Reply-To: References: Message-ID: fyi, meeting minutes: Meeting ended Mon Sep 29 14:08:43 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-09-29-14.00.html Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-09-29-14.00.txt Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-09-29-14.00.log.html On Sep 26, 2014, at 10:20 AM, Daniel Bevenius wrote: > Agenda for Mondays team meeting: > http://oksoclap.com/p/aerogear-team-mgt-20140929 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140929/a00e256d/attachment.html From bruno at abstractj.org Tue Sep 30 19:12:58 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 30 Sep 2014 16:12:58 -0700 Subject: [aerogear-dev] Security meeting next week? Message-ID: <20140930231258.GB26685@abstractj.org> Good morning guys, I would like to set up a meeting Wednesday next week (same time of our official meeting) if possible. Only to stay up to date with what you have been doing/planning. I can dig into repositories but not into your brain :). Also, plan the next steps for security. -- abstractj PGP: 0x84DC9914 From scm.blanc at gmail.com Tue Sep 30 19:18:01 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Tue, 30 Sep 2014 16:18:01 -0700 Subject: [aerogear-dev] Security meeting next week? In-Reply-To: <20140930231258.GB26685@abstractj.org> References: <20140930231258.GB26685@abstractj.org> Message-ID: <9305F238-822C-447A-9612-FC34FBEA8015@gmail.com> +1 sounds good ! Envoy? de mon iPhone > Le 30 sept. 2014 ? 16:12, Bruno Oliveira a ?crit : > > Good morning guys, I would like to set up a meeting Wednesday next week > (same time of our official meeting) if possible. > > Only to stay up to date with what you have been doing/planning. I can > dig into repositories but not into your brain :). > > Also, plan the next steps for security. > > -- > > abstractj > PGP: 0x84DC9914 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From bruno at abstractj.org Tue Sep 30 19:27:56 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 30 Sep 2014 16:27:56 -0700 Subject: [aerogear-dev] [android] Removing AGAuthenticationModule In-Reply-To: <54185AF9.4080501@redhat.com> References: <54185AF9.4080501@redhat.com> Message-ID: <20140930232756.GC26685@abstractj.org> Kill it. On 2014-09-16, Summers Pittman wrote: > AGAuthenticationModule was originally made to login/logout/register with > the AeroGear controller. Since controller is dead in a ditch somewhere, > for AGDroid 2.0 I'm proposing we remove it from the platform. This will > leave HttpBasicAuthenticationModule and HttpDigestAuthenticationModule. > However I know this also exists for iOS and Javascript so I'm putting > this post up for discussion. > > wdyt? > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Tue Sep 30 19:29:00 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 30 Sep 2014 16:29:00 -0700 Subject: [aerogear-dev] [android] Removing AGAuthenticationModule In-Reply-To: References: <54185AF9.4080501@redhat.com> <8BABC9FE-7CB1-470F-9907-660EAD62FE11@gmail.com> Message-ID: <20140930232900.GD26685@abstractj.org> Persona is pretty much dead, but I think is doable for the further releases. Meanwhile I would remove until we have the full integration with Keycloak. On 2014-09-19, Luk?? Fry? wrote: > Right now Auth module does not seem to serve any purpose anymore, > > but as we have discussed on JS meeting, > > there may possibility to integrate with third-party endpoints such as > Keycloak, Auth0, Mozilla Personas, etc. > > > As I can foresee it, Auth module may serve a purpose of single point > holding authentication data such as tokens, > that can be used for setting up authentication of either third-party > frameworks we use (e.g. in demos, such as in AngularJS this can be used to > register itself to HTTP request interceptor), > > or it may handle authentication for our modules, e.g. Data Sync. > > I'm not saying we shouldn't remove it at this point, but my question is > rather what do we recommend instead? > > ~ Lukas > > On Tue, Sep 16, 2014 at 6:07 PM, Christos Vasilakis > wrote: > > > +1 don?t think it makes sense to keep it, for iOS it was used only for > > the Controller case since basic/digest was already handled by the platform > > > > - > > Christos > > > > On Sep 16, 2014, at 6:44 PM, Summers Pittman wrote: > > > > > AGAuthenticationModule was originally made to login/logout/register with > > > the AeroGear controller. Since controller is dead in a ditch somewhere, > > > for AGDroid 2.0 I'm proposing we remove it from the platform. This will > > > leave HttpBasicAuthenticationModule and HttpDigestAuthenticationModule. > > > However I know this also exists for iOS and Javascript so I'm putting > > > this post up for discussion. > > > > > > wdyt? > > > _______________________________________________ > > > 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 > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Tue Sep 30 19:32:01 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 30 Sep 2014 16:32:01 -0700 Subject: [aerogear-dev] [android] Removing AGAuthenticationModule In-Reply-To: References: <54185AF9.4080501@redhat.com> <8BABC9FE-7CB1-470F-9907-660EAD62FE11@gmail.com> <541C2E0A.1080802@redhat.com> Message-ID: <20140930233201.GE26685@abstractj.org> Deprecation also works, although we don't have aerogear-security or controller. Not sure if you guys need it for https://github.com/aerogear/aerogear-push-quickstarts. Once it make use of PicketLink https://github.com/aerogear/aerogear-push-quickstarts/blob/fb97b9ed981b8bf78943758e15ef321ee34bdc77/server/contacts-mobile-picketlink-secured/src/test/resources/web.xml#L30. Sorry for getting late on the train. On 2014-09-19, Lucas Holmquist wrote: > > On Sep 19, 2014, at 10:16 AM, Luk?? Fry? wrote: > > > Then we may want to remove it in 2.0 until we have a use case for it. WDYT Luke? > yup, lets deprecate, that is, not include it in the build, or we can just delete it > > > > > On Fri, Sep 19, 2014 at 3:28 PM, Lucas Holmquist wrote: > > > > On Sep 19, 2014, at 9:22 AM, Summers Pittman wrote: > > > >> On Friday, September 19, 2014 7:12:01 AM, Luk?? Fry? wrote: > >>> Right now Auth module does not seem to serve any purpose anymore, > >>> > >>> but as we have discussed on JS meeting, > >>> > >>> there may possibility to integrate with third-party endpoints such as > >>> Keycloak, Auth0, Mozilla Personas, etc. > >>> > >>> > >>> As I can foresee it, Auth module may serve a purpose of single point > >>> holding authentication data such as tokens, > >>> that can be used for setting up authentication of either third-party > >>> frameworks we use (e.g. in demos, such as in AngularJS this can be > >>> used to register itself to HTTP request interceptor), > >>> > >>> or it may handle authentication for our modules, e.g. Data Sync. > >>> > >>> I'm not saying we shouldn't remove it at this point, but my question > >>> is rather what do we recommend instead? > >> I'm not saying we remove the auth module system. I'm just proposing we > >> remove that one implementation because it doesn't do anything. > > > > right, we, JS, only have 1 adapter, REST, so it might be that we just remove it totally > > > >> > >> > >> > >>> > >>> ~ Lukas > >>> > >>> On Tue, Sep 16, 2014 at 6:07 PM, Christos Vasilakis > >>> > wrote: > >>> > >>> +1 don?t think it makes sense to keep it, for iOS it was used > >>> only for the Controller case since basic/digest was already > >>> handled by the platform > >>> > >>> - > >>> Christos > >>> > >>> On Sep 16, 2014, at 6:44 PM, Summers Pittman >>> > wrote: > >>> > >>>> AGAuthenticationModule was originally made to > >>> login/logout/register with > >>>> the AeroGear controller. Since controller is dead in a ditch > >>> somewhere, > >>>> for AGDroid 2.0 I'm proposing we remove it from the platform. > >>> This will > >>>> leave HttpBasicAuthenticationModule and > >>> HttpDigestAuthenticationModule. > >>>> However I know this also exists for iOS and Javascript so I'm > >>> putting > >>>> this post up for discussion. > >>>> > >>>> wdyt? > >>>> _______________________________________________ > >>>> 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 > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > > > _______________________________________________ > > 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 > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From bruno at abstractj.org Tue Sep 30 19:34:14 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 30 Sep 2014 16:34:14 -0700 Subject: [aerogear-dev] Data Sync / Conflict Resolution: Kick Off In-Reply-To: References: Message-ID: <20140930233414.GF26685@abstractj.org> Hi Luk??, I would like to add my security sauce to the dance if possible. May I? On 2014-09-18, Luk?? Fry? wrote: > Hey guys, > > we have finished a ritual dance around Conflict Resolution Roadmap and this > is the final draft: > > https://github.com/aerogear/aerogear.org/blob/data-sync-rebirth-roadmap/docs/planning/roadmaps/AeroGearConflictResolution.asciidoc > > > Can I ask all the component leads to do a final review and +1 to > acknowledge we can start works here? > > Off course every review & feedback will be more than welcomed! > > > Cheers, > > ~ Lukas > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- abstractj PGP: 0x84DC9914 From sps.1431990 at gmail.com Thu Sep 18 06:27:29 2014 From: sps.1431990 at gmail.com (infiniteloop) Date: Thu, 18 Sep 2014 03:27:29 -0700 (PDT) Subject: [aerogear-dev] Unable to configure SSL by self signed certificate on remote IP Message-ID: <1411036049385-9213.post@n5.nabble.com> I am trying to configure SSL with self signed certificate on remote IP. I am using wildly 8.1 and aerogear push 1.0 jars. I get SSLHandshakeException when trying to send register request on port 8443. I tried the image mounted with docker created by abstractj but still no luck. Please suggest a way out. Moreover when i try to build the source with maven, build is successful but war files are not being generated. Have i missed something? -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Unable-to-configure-SSL-by-self-signed-certificate-on-remote-IP-tp9213.html Sent from the aerogear-dev mailing list archive at Nabble.com.