From kpiwko at redhat.com Thu Jan 2 03:48:10 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Thu, 2 Jan 2014 09:48:10 +0100 Subject: [aerogear-dev] AeroGear Android 1.3.1 Staged In-Reply-To: <20131219121133.4edd38f8@kapy-ntb-x220> References: <20131219121133.4edd38f8@kapy-ntb-x220> Message-ID: <20140102094810.67add1b5@kapy-ntb-x220> On Thu, 19 Dec 2013 12:11:33 +0100 Karel Piwko wrote: > Awesome! > > I plan to run regression tests but we'll probably not be able to test key > services, as everybody is out these days. Regression tests passed. Crypto key services are not yet covered. > > On Wed, 18 Dec 2013 18:06:56 -0200 > Daniel Passos wrote: > > > Hey Everyone, > > > > AeroGear Android 1.3.1 was staged on Nexus. \o/ > > > > This release introduces key services and fixes some bugs[1] > > > > Feel free to test it[2]! > > > > [1]?https://issues.jboss.org/issues/?filter=12320567 > > [2]?https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-2306/ > > > > --? > > Daniel Passos > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From kpiwko at redhat.com Thu Jan 2 07:59:22 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Thu, 2 Jan 2014 13:59:22 +0100 Subject: [aerogear-dev] OAuth2 Adapter In-Reply-To: References: <1C771957-D239-4BDB-B837-00A4A4E02702@redhat.com> <940734E6-6C13-49E7-B044-753E19300F7C@redhat.com> <2A3B92C8-430C-4BE2-BDCC-FB5867743898@redhat.com> <521B91D9.6040806@abstractj.org> <9A9EB7B1-64E7-40D8-8172-51623EDF2470@redhat.com> <521CD70D.9070502@abstractj.org> <8E6B69AB-3FB4-4486-B40A-7ED3CA7B9B7B@redhat.com> <4C215076-003F-4200-B316-14622036079A@redhat.com> <0EABA5A2-A352-40AD-9A91-2F929C4FE9C4@redhat.com> <0120B639-CA96-4BDD-94AB-5BFC4813BB48@redhat.com> <1A14D527-BD5D-4BB4-83ED-69B69B09625A@redhat.com> Message-ID: <20140102135922.5eb49952@kapy-ntb-x220> Looks good and works fine with FF24 and Chrome27. I was missing instruction how to enable client access in Google Console though, so I added them here: https://github.com/lholmquist/ag-google-drive/pull/1 Other interesting fact is that FF shows "delete" text while Chrome shows wastebin icon, I wasn't looking deeper into that though. Karel On Wed, 18 Dec 2013 14:45:39 -0500 Lucas Holmquist wrote: > i've created a new example here, https://github.com/lholmquist/ag-google-drive > > that hopefully shows the flow a bit > On Aug 29, 2013, at 2:05 PM, Lucas Holmquist wrote: > > > i did get it to work > > On Aug 29, 2013, at 2:04 PM, Sebastien Blanc wrote: > > > >> This update is really cool, is the pipe test flow working ? > >> > >> > >> On Thu, Aug 29, 2013 at 7:57 PM, Lucas Holmquist > >> wrote: i've updated the sample again > >> https://github.com/lholmquist/oauth2test > >> > >> this time i added a pipe object and used pipe.read to see how the flow > >> would be > >> > >> > >> On Aug 29, 2013, at 11:55 AM, Lucas Holmquist wrote: > >> > >>> i've updated the sample app with the new flow > >>> > >>> https://github.com/lholmquist/oauth2test > >>> > >>> > >>> On Aug 29, 2013, at 9:23 AM, Lucas Holmquist wrote: > >>> > >>>> ok, Kris had some thoughts on a better flow, so i refactored the code a > >>>> bit and i think i like this way a bit better. > >>>> > >>>> New Flow - Client Flow - Standalone for now, possible integration with > >>>> pipes > >>>> > >>>> First Time - No Access Token stored( in localStorage ) > >>>> > >>>> User will create the Authorization Object stuff with settings/options > >>>> > >>>> var thing = AeroGear.Authorization(); > >>>> > >>>> thing.add({ > >>>> name: "coolThing", > >>>> settings: { > >>>> clientId: "12345.apps.googleusercontent.com", > >>>> redirectURL: "http://localhost:8000/redirector.html", > >>>> tokenValidationEndpoint: > >>>> "https://www.googleapis.com/oauth2/v1/tokeninfo", authEndpoint: > >>>> "https://accounts.google.com/o/oauth2/auth", revokeURL: > >>>> "https://accounts.google.com/o/oauth2/revoke", scopes: > >>>> "https://www.googleapis.com/auth/userinfo.profile", prompt: "force" > >>>> } > >>>> }); > >>>> should have the ability to specify more settings, based on the spec > >>>> > >>>> The user would then call some method( currently not good names are > >>>> coming to me, maybe validate ) that takes success and error callbacks. > >>>> > >>>> thing.services.coolThing.validate({ > >>>> success: function( response ){ > >>>> console.log( "Should be response from Validating the access > >>>> token", response ); }, > >>>> error: function( error ) { > >>>> //should contain a constructed URL for the user > >>>> console.log( "error", error ); > >>>> } > >>>> }); > >>>> Since this is the first time, the error callback will be called and will > >>>> contain the constructed URL that the user should do the popup redirect > >>>> dance with to get an access token. > >>>> > >>>> what "dance" they do is up to the developer > >>>> > >>>> Once that happens and they have the access token, they would call the > >>>> validate method again. > >>>> > >>>> this makes sure that the token they recieved is validated and will also > >>>> return some other meta data related to the token, like refresh time. > >>>> > >>>> Once the token has been validated, it will be stored in localStorage and > >>>> would be accessable with the key of ag-oauth2-whatever_the_client_ID_is . > >>>> > >>>> so in this example it would be something like: > >>>> > >>>> ag-oauth2-12345.apps.googleusercontent.com > >>>> There is one problem i can see here though. If the user has to > >>>> applications with the same client ID but different scopes assigned, this > >>>> would be a problem. That use case could be considered bad practice anyway > >>>> > >>>> The user can then call the "callService"( yes, again, crappy name ) > >>>> method to get access to the service they want. > >>>> > >>>> thing.services.coolThing.callService({ > >>>> serviceURL: "https://www.googleapis.com/oauth2/v2/userinfo", > >>>> success: function( response ){ > >>>> console.log( "Should be the response from the call", response ); > >>>> }, > >>>> error: function( error ) { > >>>> console.log( "error", error ); > >>>> } > >>>> }); > >>>> All these methods would have success/error callbacks. > >>>> > >>>> Token Expiration > >>>> > >>>> If the user makes a call to a service, using the callService method, and > >>>> they recieve an error such as not authorized or token invalid or token > >>>> expired, I'm thinking we send what the "contructed URL" should be, > >>>> similar to the validate method described above. > >>>> > >>>> Since this is a Client Side flow, there is no refresh token, so the > >>>> client wouldn't be able to refresh the access token without doing the > >>>> "dance" again. > >>>> > >>>> > >>>> > >>>> > >>>> On Aug 27, 2013, at 1:57 PM, Lucas Holmquist wrote: > >>>> > >>>>> i've hacked together a sample app that shows sort of the flow. > >>>>> > >>>>> https://github.com/lholmquist/oauth2test > >>>>> > >>>>> it is still very rough > >>>>> > >>>>> On Aug 27, 2013, at 12:42 PM, Bruno Oliveira > >>>>> wrote: > >>>>> > >>>>>> +1 keep it simple, please > >>>>>> > >>>>>> Lucas Holmquist wrote: > >>>>>>> > >>>>>>> On Aug 27, 2013, at 3:39 AM, Sebastien Blanc >>>>>>> > wrote: > >>>>>>> > >>>>>>>> Hi, > >>>>>>>> That sounds good ! > >>>>>>>> Just one question, instead of using the callApi function couldn't we > >>>>>>>> pass the oauth module (called 'thing' in your example) to the pipe > >>>>>>>> directly, using the 'authenticator' setting. Behind the scene, the > >>>>>>>> pipe manager will append the oauth token to the query or add the > >>>>>>>> bearer header ? > >>>>>>> > >>>>>>> I'm not sure if that is what this is going to do. This is more of an > >>>>>>> Authorization thing and i don't think it totally fits the pipeline > >>>>>>> stuff. ( or it would make it a bit more complicated, and we want to > >>>>>>> keep it simple ) > >>>>>>> > >>>>>>> > >>>>>>> i should probably change the method to be "authorize" instead > >>>>>>> > >>>>>>>> Seb > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Mon, Aug 26, 2013 at 8:05 PM, Lucas Holmquist >>>>>>>> > wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> OAuth2 AeroGear Workflow - High Level > >>>>>>>> > >>>>>>>> > >>>>>>>> Using Google api's > >>>>>>>> > >>>>>>>> /Server Side/ > >>>>>>>> > >>>>>>>> 1. user needs to first create an "application/project" to get an > >>>>>>>> api key > >>>>>>>> 2. Then they would choose the services/api's then would like > >>>>>>>> there application to access > >>>>>>>> 3. other google server related items.... > >>>>>>>> > >>>>>>>> /Client Side/ > >>>>>>>> > >>>>>>>> 1. Create a new OAuth2 module thing > >>>>>>>> 2. Get access token for the services would need to specify the > >>>>>>>> services they would like to access > >>>>>>>> 3. validate the token > >>>>>>>> 4. make calls to the service > >>>>>>>> > >>>>>>>> > >>>>>>>> API > >>>>>>>> > >>>>>>>> |var thing = AerGear.OAuth2({ > >>>>>>>> name: googleEndPoints, //Just a Name > >>>>>>>> clientID: "12345" //The client ID of the app from > >>>>>>>> the API console settings: { > >>>>>>>> permissions: "..", > >>>>>>>> ... > >>>>>>>> } > >>>>>>>> }).somecoolmodulename.googleEndPoints; > >>>>>>>> | > >>>>>>>> > >>>>>>>> /Settings: Multiple settings based on paramters here > >>>>>>>> / > >>>>>>>> > >>>>>>>> /Methods/ > >>>>>>>> > >>>>>>>> > >>>>>>>> authenticate > >>>>>>>> > >>>>>>>> this will authenticate with the server to get the access token and > >>>>>>>> then validate the token, once that is all good then the response > >>>>>>>> is returned. > >>>>>>>> > >>>>>>>> |thing.authenticate({ > >>>>>>>> success:{}, > >>>>>>>> error:{}, > >>>>>>>> settings: { > >>>>>>>> //probably some settings here, like URL overides and such > >>>>>>>> } > >>>>>>>> }); > >>>>>>>> | > >>>>>>>> > >>>>>>>> > >>>>>>>> callApi > >>>>>>>> > >>>>>>>> not really a good name, but it would basically call the remote > >>>>>>>> api/services. we could either do a query string option or a Head > >>>>>>>> option > >>>>>>>> > >>>>>>>> example: > >>>>>>>> > >>>>>>>> |curl > >>>>>>>> 'https://www.googleapis.com/oauth2/v1/userinfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg' > >>>>>>>> | > >>>>>>>> > >>>>>>>> or > >>>>>>>> > >>>>>>>> |curl -H "Authorization: Bearer {accessToken}" > >>>>>>>> https://www.googleapis.com/oauth2/v1/userinfo | > >>>>>>>> > >>>>>>>> code: > >>>>>>>> > >>>>>>>> |thing.callApi({ > >>>>>>>> service: "userinfo", //don't really like this name either > >>>>>>>> success:{}, > >>>>>>>> error:{}, > >>>>>>>> settings: { > >>>>>>>> ... //overridable baseURLs? > >>>>>>>> } > >>>>>>>> }); > >>>>>>>> | > >>>>>>>> > >>>>>>>> > >>>>>>>> revoke > >>>>>>>> > >>>>>>>> again, maybe not the best name. calls the "revoke" service, to > >>>>>>>> remove access to permissions > >>>>>>>> > >>>>>>>> |thing.revoke({ > >>>>>>>> success: {}, > >>>>>>>> error: {}, > >>>>>>>> settings: {} > >>>>>>>> }); > >>>>>>>> | > >>>>>>>> > >>>>>>>> Behind the scenes on all these calls, the "access_token" is > >>>>>>>> beining used and possibly refreshed for the user, so they don't > >>>>>>>> have to worry about it. They just need to call authenticate first. > >>>>>>>> Maybe we can have a refresh method if the user wants to refresh > >>>>>>>> the tokens themselves. this would do the token "dance" > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Aug 26, 2013, at 1:35 PM, Bruno Oliveira >>>>>>>> > wrote: > >>>>>>>> > >>>>>>>>> +1 I think is a good start to us. > >>>>>>>>> > >>>>>>>>> Kris Borchers wrote: > >>>>>>>>>> I would like to see that but what you are saying makes sense. It > >>>>>>>>>> sounds like where I was headed with the Basic and Digest > >>>>>>>>>> adapters before I ran into browser security issues with headers. > >>>>>>>>>> I think and authorization API that basically just wraps itself > >>>>>>>>>> around secured endpoints works for me. > >>>>>>>>> > >>>>>>>>> -- > >>>>>>>>> abstractj > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> _______________________________________________ > >>>>>>>>> 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 > >>>>>> > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > From lholmqui at redhat.com Thu Jan 2 08:30:24 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Thu, 2 Jan 2014 08:30:24 -0500 Subject: [aerogear-dev] OAuth2 Adapter In-Reply-To: <20140102135922.5eb49952@kapy-ntb-x220> References: <1C771957-D239-4BDB-B837-00A4A4E02702@redhat.com> <940734E6-6C13-49E7-B044-753E19300F7C@redhat.com> <2A3B92C8-430C-4BE2-BDCC-FB5867743898@redhat.com> <521B91D9.6040806@abstractj.org> <9A9EB7B1-64E7-40D8-8172-51623EDF2470@redhat.com> <521CD70D.9070502@abstractj.org> <8E6B69AB-3FB4-4486-B40A-7ED3CA7B9B7B@redhat.com> <4C215076-003F-4200-B316-14622036079A@redhat.com> <0EABA5A2-A352-40AD-9A91-2F929C4FE9C4@redhat.com> <0120B639-CA96-4BDD-94AB-5BFC4813BB48@redhat.com> <1A14D527-BD5D-4BB4-83ED-69B69B09625A@redhat.com> <20140102135922.5eb49952@kapy-ntb-x220> Message-ID: <6EBB06FA-2CDB-4486-B155-778B71FDE732@redhat.com> On Jan 2, 2014, at 7:59 AM, Karel Piwko wrote: > Looks good and works fine with FF24 and Chrome27. I was missing instruction how > to enable client access in Google Console though, so I added them here: https://github.com/lholmquist/ag-google-drive/pull/1 cool > > Other interesting fact is that FF shows "delete" text while Chrome shows > wastebin icon, I wasn't looking deeper into that though. > > Karel > > On Wed, 18 Dec 2013 14:45:39 -0500 > Lucas Holmquist wrote: > >> i've created a new example here, https://github.com/lholmquist/ag-google-drive >> >> that hopefully shows the flow a bit >> On Aug 29, 2013, at 2:05 PM, Lucas Holmquist wrote: >> >>> i did get it to work >>> On Aug 29, 2013, at 2:04 PM, Sebastien Blanc wrote: >>> >>>> This update is really cool, is the pipe test flow working ? >>>> >>>> >>>> On Thu, Aug 29, 2013 at 7:57 PM, Lucas Holmquist >>>> wrote: i've updated the sample again >>>> https://github.com/lholmquist/oauth2test >>>> >>>> this time i added a pipe object and used pipe.read to see how the flow >>>> would be >>>> >>>> >>>> On Aug 29, 2013, at 11:55 AM, Lucas Holmquist wrote: >>>> >>>>> i've updated the sample app with the new flow >>>>> >>>>> https://github.com/lholmquist/oauth2test >>>>> >>>>> >>>>> On Aug 29, 2013, at 9:23 AM, Lucas Holmquist wrote: >>>>> >>>>>> ok, Kris had some thoughts on a better flow, so i refactored the code a >>>>>> bit and i think i like this way a bit better. >>>>>> >>>>>> New Flow - Client Flow - Standalone for now, possible integration with >>>>>> pipes >>>>>> >>>>>> First Time - No Access Token stored( in localStorage ) >>>>>> >>>>>> User will create the Authorization Object stuff with settings/options >>>>>> >>>>>> var thing = AeroGear.Authorization(); >>>>>> >>>>>> thing.add({ >>>>>> name: "coolThing", >>>>>> settings: { >>>>>> clientId: "12345.apps.googleusercontent.com", >>>>>> redirectURL: "http://localhost:8000/redirector.html", >>>>>> tokenValidationEndpoint: >>>>>> "https://www.googleapis.com/oauth2/v1/tokeninfo", authEndpoint: >>>>>> "https://accounts.google.com/o/oauth2/auth", revokeURL: >>>>>> "https://accounts.google.com/o/oauth2/revoke", scopes: >>>>>> "https://www.googleapis.com/auth/userinfo.profile", prompt: "force" >>>>>> } >>>>>> }); >>>>>> should have the ability to specify more settings, based on the spec >>>>>> >>>>>> The user would then call some method( currently not good names are >>>>>> coming to me, maybe validate ) that takes success and error callbacks. >>>>>> >>>>>> thing.services.coolThing.validate({ >>>>>> success: function( response ){ >>>>>> console.log( "Should be response from Validating the access >>>>>> token", response ); }, >>>>>> error: function( error ) { >>>>>> //should contain a constructed URL for the user >>>>>> console.log( "error", error ); >>>>>> } >>>>>> }); >>>>>> Since this is the first time, the error callback will be called and will >>>>>> contain the constructed URL that the user should do the popup redirect >>>>>> dance with to get an access token. >>>>>> >>>>>> what "dance" they do is up to the developer >>>>>> >>>>>> Once that happens and they have the access token, they would call the >>>>>> validate method again. >>>>>> >>>>>> this makes sure that the token they recieved is validated and will also >>>>>> return some other meta data related to the token, like refresh time. >>>>>> >>>>>> Once the token has been validated, it will be stored in localStorage and >>>>>> would be accessable with the key of ag-oauth2-whatever_the_client_ID_is . >>>>>> >>>>>> so in this example it would be something like: >>>>>> >>>>>> ag-oauth2-12345.apps.googleusercontent.com >>>>>> There is one problem i can see here though. If the user has to >>>>>> applications with the same client ID but different scopes assigned, this >>>>>> would be a problem. That use case could be considered bad practice anyway >>>>>> >>>>>> The user can then call the "callService"( yes, again, crappy name ) >>>>>> method to get access to the service they want. >>>>>> >>>>>> thing.services.coolThing.callService({ >>>>>> serviceURL: "https://www.googleapis.com/oauth2/v2/userinfo", >>>>>> success: function( response ){ >>>>>> console.log( "Should be the response from the call", response ); >>>>>> }, >>>>>> error: function( error ) { >>>>>> console.log( "error", error ); >>>>>> } >>>>>> }); >>>>>> All these methods would have success/error callbacks. >>>>>> >>>>>> Token Expiration >>>>>> >>>>>> If the user makes a call to a service, using the callService method, and >>>>>> they recieve an error such as not authorized or token invalid or token >>>>>> expired, I'm thinking we send what the "contructed URL" should be, >>>>>> similar to the validate method described above. >>>>>> >>>>>> Since this is a Client Side flow, there is no refresh token, so the >>>>>> client wouldn't be able to refresh the access token without doing the >>>>>> "dance" again. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Aug 27, 2013, at 1:57 PM, Lucas Holmquist wrote: >>>>>> >>>>>>> i've hacked together a sample app that shows sort of the flow. >>>>>>> >>>>>>> https://github.com/lholmquist/oauth2test >>>>>>> >>>>>>> it is still very rough >>>>>>> >>>>>>> On Aug 27, 2013, at 12:42 PM, Bruno Oliveira >>>>>>> wrote: >>>>>>> >>>>>>>> +1 keep it simple, please >>>>>>>> >>>>>>>> Lucas Holmquist wrote: >>>>>>>>> >>>>>>>>> On Aug 27, 2013, at 3:39 AM, Sebastien Blanc >>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> That sounds good ! >>>>>>>>>> Just one question, instead of using the callApi function couldn't we >>>>>>>>>> pass the oauth module (called 'thing' in your example) to the pipe >>>>>>>>>> directly, using the 'authenticator' setting. Behind the scene, the >>>>>>>>>> pipe manager will append the oauth token to the query or add the >>>>>>>>>> bearer header ? >>>>>>>>> >>>>>>>>> I'm not sure if that is what this is going to do. This is more of an >>>>>>>>> Authorization thing and i don't think it totally fits the pipeline >>>>>>>>> stuff. ( or it would make it a bit more complicated, and we want to >>>>>>>>> keep it simple ) >>>>>>>>> >>>>>>>>> >>>>>>>>> i should probably change the method to be "authorize" instead >>>>>>>>> >>>>>>>>>> Seb >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Mon, Aug 26, 2013 at 8:05 PM, Lucas Holmquist >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> OAuth2 AeroGear Workflow - High Level >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Using Google api's >>>>>>>>>> >>>>>>>>>> /Server Side/ >>>>>>>>>> >>>>>>>>>> 1. user needs to first create an "application/project" to get an >>>>>>>>>> api key >>>>>>>>>> 2. Then they would choose the services/api's then would like >>>>>>>>>> there application to access >>>>>>>>>> 3. other google server related items.... >>>>>>>>>> >>>>>>>>>> /Client Side/ >>>>>>>>>> >>>>>>>>>> 1. Create a new OAuth2 module thing >>>>>>>>>> 2. Get access token for the services would need to specify the >>>>>>>>>> services they would like to access >>>>>>>>>> 3. validate the token >>>>>>>>>> 4. make calls to the service >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> API >>>>>>>>>> >>>>>>>>>> |var thing = AerGear.OAuth2({ >>>>>>>>>> name: googleEndPoints, //Just a Name >>>>>>>>>> clientID: "12345" //The client ID of the app from >>>>>>>>>> the API console settings: { >>>>>>>>>> permissions: "..", >>>>>>>>>> ... >>>>>>>>>> } >>>>>>>>>> }).somecoolmodulename.googleEndPoints; >>>>>>>>>> | >>>>>>>>>> >>>>>>>>>> /Settings: Multiple settings based on paramters here >>>>>>>>>> / >>>>>>>>>> >>>>>>>>>> /Methods/ >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> authenticate >>>>>>>>>> >>>>>>>>>> this will authenticate with the server to get the access token and >>>>>>>>>> then validate the token, once that is all good then the response >>>>>>>>>> is returned. >>>>>>>>>> >>>>>>>>>> |thing.authenticate({ >>>>>>>>>> success:{}, >>>>>>>>>> error:{}, >>>>>>>>>> settings: { >>>>>>>>>> //probably some settings here, like URL overides and such >>>>>>>>>> } >>>>>>>>>> }); >>>>>>>>>> | >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> callApi >>>>>>>>>> >>>>>>>>>> not really a good name, but it would basically call the remote >>>>>>>>>> api/services. we could either do a query string option or a Head >>>>>>>>>> option >>>>>>>>>> >>>>>>>>>> example: >>>>>>>>>> >>>>>>>>>> |curl >>>>>>>>>> 'https://www.googleapis.com/oauth2/v1/userinfo?access_token=1/fFBGRNJru1FQd44AzqT3Zg' >>>>>>>>>> | >>>>>>>>>> >>>>>>>>>> or >>>>>>>>>> >>>>>>>>>> |curl -H "Authorization: Bearer {accessToken}" >>>>>>>>>> https://www.googleapis.com/oauth2/v1/userinfo | >>>>>>>>>> >>>>>>>>>> code: >>>>>>>>>> >>>>>>>>>> |thing.callApi({ >>>>>>>>>> service: "userinfo", //don't really like this name either >>>>>>>>>> success:{}, >>>>>>>>>> error:{}, >>>>>>>>>> settings: { >>>>>>>>>> ... //overridable baseURLs? >>>>>>>>>> } >>>>>>>>>> }); >>>>>>>>>> | >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> revoke >>>>>>>>>> >>>>>>>>>> again, maybe not the best name. calls the "revoke" service, to >>>>>>>>>> remove access to permissions >>>>>>>>>> >>>>>>>>>> |thing.revoke({ >>>>>>>>>> success: {}, >>>>>>>>>> error: {}, >>>>>>>>>> settings: {} >>>>>>>>>> }); >>>>>>>>>> | >>>>>>>>>> >>>>>>>>>> Behind the scenes on all these calls, the "access_token" is >>>>>>>>>> beining used and possibly refreshed for the user, so they don't >>>>>>>>>> have to worry about it. They just need to call authenticate first. >>>>>>>>>> Maybe we can have a refresh method if the user wants to refresh >>>>>>>>>> the tokens themselves. this would do the token "dance" >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Aug 26, 2013, at 1:35 PM, Bruno Oliveira >>>>>>>>> > wrote: >>>>>>>>>> >>>>>>>>>>> +1 I think is a good start to us. >>>>>>>>>>> >>>>>>>>>>> Kris Borchers wrote: >>>>>>>>>>>> I would like to see that but what you are saying makes sense. It >>>>>>>>>>>> sounds like where I was headed with the Basic and Digest >>>>>>>>>>>> adapters before I ran into browser security issues with headers. >>>>>>>>>>>> I think and authorization API that basically just wraps itself >>>>>>>>>>>> around secured endpoints works for me. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> abstractj >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >> > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From supittma at redhat.com Thu Jan 2 10:13:50 2014 From: supittma at redhat.com (Summers Pittman) Date: Thu, 02 Jan 2014 10:13:50 -0500 Subject: [aerogear-dev] sync In-Reply-To: References: Message-ID: <52C5822E.5080407@redhat.com> On 12/20/2013 06:34 AM, Erik Jan de Wit wrote: > So we already agreed that CouchDB has some nice features, but why wouldn?t we just use pouchdb for javascript and touchdb? I?ve just tested the javascript and it syncs with the server perfectly, even if there are some things missing we could add them because these projects are open source. Because wrapping CouchDB and friends to AeroGear with no other reason than to create a org.jboss.sync name space is dumb. Also the how of sync is still a bit far off. I'm still interested in the "what" of sync. What use cases are we supporting, what features are we supporting, what are our goals, what does a working finished sync impl look like, etc. > > Cheers, > Erik Jan > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Fri Jan 3 07:52:17 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 3 Jan 2014 13:52:17 +0100 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: References: Message-ID: Hello, it's nice to see an effort for integrating keycloak. Especially the User Management part is something which sounds very promising. For instance I like how a request against "http://push-abstractj.rhcloud.com/ag-push" redirects me to the Keycloak server and after a sucessful login back to the AdminUI. Sweet! I understand this is an early PoC, but the user login bits already look good! A few things I noticed: * After login, I get a list of PushApplications, but I can't click into them to see details (I assume this is due to your changes to the ember interface - with is perfectly fine) * Sending Push Notifications (e.g. using the CURL command) does not work (used the PushAppID/MasterSecret from the HTTP REST response on AdminUI overview page ;-)) I assume this is because the endpoint for sending is also protected by the SSO/Keycloak facility, hence the HTTP Basic auth is not triggered there (guess). Since the HTTP Basic is also used when a device tries to register against a variant, I am guess the same issue is present there as well. Perhaps the HTTP-Basic for SENDING and DEVICE-REGISTRATION could be done w/ something else, e.g. OAuth2 Greetings, Matthias On Fri, Dec 20, 2013 at 1:11 PM, Bruno Oliveira wrote: > Good morning peeps, yesterday I started to replace AeroGear Security on > Unified Push server by Keycloak and you might be asking: ?Why??. Keycloak > is a SSO with some handy features like TOTP, OAuth2, user management > support and I think we have too much to contribute, is the only way to have > some success with security, ?divide to conquer" (at least for authorization > and authentication). > > So will ag-security be discontinued? No! Keycloak is still on Alpha and we > have to test it against our projects before fully replace ag-security, but > the only way to upstream our needs, is to using it. > > This replacement only applies to authentication/authorization features, we > still have a ton of projects which Keycloak is not able to replace like: > TOTP, crypto and OAuth2 on mobile, our focus. > > - PoC > > So let?s talk about this replacement, any dependency on ag-security was > removed from the push server and replaced by Keycloak: > https://github.com/abstractj/aerogear-unifiedpush-server/tree/openshift > > Based on Keycloak examples, I just did copy & paste from one of the demos ( > https://github.com/abstractj/auth-server/tree/openshift) to create a > server. Keycloak requires Resteasy 3.0.4, for this reason I had to manually > replace some modules on JBoss. > > To test it go to: http://push-abstractj.rhcloud.com/ag-push/ you must be > redirected to Keycloak, enter: > > username: john at doe.com > password: password > > You must be redirected to agpush console, keep in mind that I took some > shortcuts to get this demo working, so for example the create will fail > because I removed everything related into the ember interface. > > Is also possible to enable TOTP, user?s registration and whatever you want. > > So what do you think? > > -- > abstractj > > _______________________________________________ > 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/20140103/54c3fa66/attachment.html From daniel at passos.me Fri Jan 3 12:17:46 2014 From: daniel at passos.me (Daniel Passos) Date: Fri, 3 Jan 2014 15:17:46 -0200 Subject: [aerogear-dev] AeroGear Android 1.3.1 Staged In-Reply-To: <20140102094810.67add1b5@kapy-ntb-x220> References: <20131219121133.4edd38f8@kapy-ntb-x220> <20140102094810.67add1b5@kapy-ntb-x220> Message-ID: AeroGear Android 1.3.1 was released on Maven Central --? Daniel Passos On January 2, 2014 at 6:48:24 AM, Karel Piwko (kpiwko at redhat.com) wrote: On Thu, 19 Dec 2013 12:11:33 +0100 Karel Piwko wrote: > Awesome! > > I plan to run regression tests but we'll probably not be able to test key > services, as everybody is out these days. Regression tests passed. Crypto key services are not yet covered. > > On Wed, 18 Dec 2013 18:06:56 -0200 > Daniel Passos wrote: > > > Hey Everyone, > > > > AeroGear Android 1.3.1 was staged on Nexus. \o/ > > > > This release introduces key services and fixes some bugs[1] > > > > Feel free to test it[2]! > > > > [1]?https://issues.jboss.org/issues/?filter=12320567 > > [2]?https://repository.jboss.org/nexus/content/repositories/jboss_releases_staging_profile-2306/ > > > > --? > > Daniel Passos > > > > > _______________________________________________ > 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/20140103/e0f5c5d7/attachment-0001.html From qmx at qmx.me Sun Jan 5 23:42:33 2014 From: qmx at qmx.me (Douglas Campos) Date: Mon, 6 Jan 2014 02:42:33 -0200 Subject: [aerogear-dev] sync In-Reply-To: <52C5822E.5080407@redhat.com> References: <52C5822E.5080407@redhat.com> Message-ID: <20140106044233.GA70219@rohan.local> On Thu, Jan 02, 2014 at 10:13:50AM -0500, Summers Pittman wrote: > On 12/20/2013 06:34 AM, Erik Jan de Wit wrote: > > So we already agreed that CouchDB has some nice features, but why > > wouldn?t we just use pouchdb for javascript and touchdb? I?ve just > > tested the javascript and it syncs with the server perfectly, even > > if there are some things missing we could add them because these > > projects are open source. > Because wrapping CouchDB and friends to AeroGear with no other reason > than to create a org.jboss.sync name space is dumb. can't +9001 enough > Also the how of sync is still a bit far off. I'm still interested in the > "what" of sync. What use cases are we supporting, what features are we > supporting, what are our goals, what does a working finished sync impl > look like, etc. drafted here: https://gist.github.com/qmx/8278287 # aerogear-sync While I was reviewing Summers' code and ideas, I realized that I really wanted everything he did, but as a second step after we nail down the basics. ## basics? Since we've been catering the enterprise market, this essentially means we need to get the __boring__ stuff right first, then move over to the __shiny__ stuff, like realtime data sync, update policies & friends. ### data model For starters, I think that the most important thing that needs to be agreed upon is the data model and the atomic operations around it. As previous discussed, I really like CouchDB's datamodel -- and hate erlang ;) `{_id:, content:, rev:}` #### JS Well, it's JSON, it _Just Works_™ #### Java I didn't want to pick on Java, but since its fame forces me to it. First stab (a courtesy of our friend Dan Bevenius): public interface Document { public String id; public String content; public String rev; } We naturally want to kick this a notch, and use objects instead of plain strings: public interface Document { public ID id; public T content; public String rev; } In this case, we can use the convention requiring that `T` is any **object serializable to JSON**. `ID` is a convenience shorthand since it's a **GUID/UUID**. I think this key isn't necessarily a natural key (a surrogate key instead). #### Objective-C ;) ### API levels As soon as we have a rough data-model defined, we can start dabbling around different API levels to be served: (parts **I think** are potentially deliverable for a 1.0) - level 0: explodes when there's a conflict - level 1: semi-automatic conflict resolution via something like google's diff-match-patch - level 2: business rules determine who wins a conflicting update (supervisor wins over normal user) (parts **I think** are potentially deliverable for a 2.0) - level 3: real-time updates via diff-match-patch - level 4: real-time updates via OT/EC All those proposed API operations should be serializable, meaning I can potentially keep doing changes offline then just replying them to the server when online. ### transport Since we know about the future-looking ideas on v2.0, it would be really nice for us to specify a very simple/dumb JSON-based protocol for those change messages. Something that could accomodate both the full document updates and the OT/EC incremental bits too. I have no ideas on this, tbh. ## boring usecases ### scenario 1 Building inspector system - we have mobile apps that store relevant info and are bound to be accessed on places where we won't have any kind of connection, or very poor signal. You can have several inspectors screening the same building simultaneously. Let's say we have Agnes and Joe are doing the fire extinguisher inspection in a new hospital building. Technically each fire extinguisher has its own identifier and can be an independent document. In this case we would have no conflict happening. Now they start finding expired fire extinguishers and start to add them to the report. This report could potentially have two divergent lists of fire extinguishers to be replenished/revalidated, as the building's compliance status. ### scenario 2 Census system - we have mobile apps focused on offline data collection. We have the previous year's info that needs to be updated on the server. The interviewee needs to take a call, then asks the interviewer to come back later. This results in two sets of changes for the same document, stacked together, which should work flawlessly. Any other ideas/comments? -- qmx -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 527 bytes Desc: not available Url : http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140106/79148d94/attachment.bin From daniel at passos.me Mon Jan 6 07:01:36 2014 From: daniel at passos.me (Daniel Passos) Date: Mon, 6 Jan 2014 10:01:36 -0200 Subject: [aerogear-dev] Team Meeting Agenda Message-ID: Feel free to add to the agenda[1] [1]?http://oksoclap.com/p/OAp3G5dpd6 --? Daniel Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140106/0accecb2/attachment.html From lholmqui at redhat.com Mon Jan 6 09:29:43 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 6 Jan 2014 09:29:43 -0500 Subject: [aerogear-dev] sync In-Reply-To: <20140106044233.GA70219@rohan.local> References: <52C5822E.5080407@redhat.com> <20140106044233.GA70219@rohan.local> Message-ID: <20CD72E5-2A13-4D8E-AA54-2E3D29EC630F@redhat.com> On Jan 5, 2014, at 11:42 PM, Douglas Campos wrote: > On Thu, Jan 02, 2014 at 10:13:50AM -0500, Summers Pittman wrote: >> On 12/20/2013 06:34 AM, Erik Jan de Wit wrote: >>> So we already agreed that CouchDB has some nice features, but why >>> wouldn?t we just use pouchdb for javascript and touchdb? I?ve just >>> tested the javascript and it syncs with the server perfectly, even >>> if there are some things missing we could add them because these >>> projects are open source. >> Because wrapping CouchDB and friends to AeroGear with no other reason >> than to create a org.jboss.sync name space is dumb. > > can't +9001 enough > >> Also the how of sync is still a bit far off. I'm still interested in the >> "what" of sync. What use cases are we supporting, what features are we >> supporting, what are our goals, what does a working finished sync impl >> look like, etc. > > drafted here: https://gist.github.com/qmx/8278287 > > # aerogear-sync > > While I was reviewing Summers' code and ideas, I realized that I really wanted > everything he did, but as a second step after we nail down the basics. > > ## basics? > > Since we've been catering the enterprise market, this essentially means we need > to get the __boring__ stuff right first, then move over to the __shiny__ stuff, > like realtime data sync, update policies & friends. > > ### data model > > For starters, I think that the most important thing that needs to be agreed > upon is the data model and the atomic operations around it. As previous > discussed, I really like CouchDB's datamodel -- and hate erlang ;) > > `{_id:, content:, rev:}` > > #### JS > > Well, it's JSON, it _Just Works_™ > > #### Java > > I didn't want to pick on Java, but since its fame forces me to it. First stab > (a courtesy of our friend Dan Bevenius): > > public interface Document { > public String id; > public String content; > public String rev; > } > > We naturally want to kick this a notch, and use objects instead of plain strings: > > public interface Document { > public ID id; > public T content; > public String rev; > } > > In this case, we can use the convention requiring that `T` is any **object > serializable to JSON**. `ID` is a convenience shorthand since it's a > **GUID/UUID**. I think this key isn't necessarily a natural key (a surrogate > key instead). > > #### Objective-C > > ;) > > ### API levels > > As soon as we have a rough data-model defined, we can start dabbling around > different API levels to be served: > > (parts **I think** are potentially deliverable for a 1.0) > > - level 0: explodes when there's a conflict > - level 1: semi-automatic conflict resolution via something like google's diff-match-patch > - level 2: business rules determine who wins a conflicting update (supervisor > wins over normal user) > > (parts **I think** are potentially deliverable for a 2.0) > > - level 3: real-time updates via diff-match-patch > - level 4: real-time updates via OT/EC > where does the more than 2 users editing something fall. so if say 4 people are editing something offline and then come back online, who wins that one. > All those proposed API operations should be serializable, meaning I can > potentially keep doing changes offline then just replying them to the server > when online. > > ### transport > > Since we know about the future-looking ideas on v2.0, it would be really nice > for us to specify a very simple/dumb JSON-based protocol for those change > messages. Something that could accomodate both the full document updates and > the OT/EC incremental bits too. I have no ideas on this, tbh. > > ## boring usecases > > ### scenario 1 > > Building inspector system - we have mobile apps that store relevant info and > are bound to be accessed on places where we won't have any kind of connection, > or very poor signal. > > You can have several inspectors screening the same building simultaneously. > > Let's say we have Agnes and Joe are doing the fire extinguisher inspection in a > new hospital building. Technically each fire extinguisher has its own > identifier and can be an independent document. In this case we would have no > conflict happening. > > Now they start finding expired fire extinguishers and start to add them to the > report. This report could potentially have two divergent lists of fire > extinguishers to be replenished/revalidated, as the building's compliance > status. > > ### scenario 2 > > Census system - we have mobile apps focused on offline data collection. We have > the previous year's info that needs to be updated on the server. The > interviewee needs to take a call, then asks the interviewer to come back later. > This results in two sets of changes for the same document, stacked together, > which should work flawlessly. > > Any other ideas/comments? > > -- > qmx_______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From supittma at redhat.com Mon Jan 6 10:21:42 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 06 Jan 2014 10:21:42 -0500 Subject: [aerogear-dev] Auth Authz and OAuth Message-ID: <52CACA06.1000508@redhat.com> So in JS land and iOS land we have or will soon have OAuth2 handling. To handle OAuth2 a new API was created, AGAuthorizationModule. I understand and agree with the separation of concerns between Authentication and Authorization, but I am worried that this introduces two APIs now. Before Authz was added Authentication (login, logout, etc) and Authorization(here are my keys and permissions) were both handled by AGAuthenticationModules. With Authz now being a thing we should probably remove and deprecate the authz parts of the old AuthenticationModules. see iOS https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/AeroGear-iOS/pipeline/AGRESTPipe.m#L307 see Android https://github.com/aerogear/aerogear-android/blob/master/src/org/jboss/aerogear/android/impl/pipeline/RestRunner.java#L319 see Javascript: I couldn't actually find this in javascript... wdyt? From supittma at redhat.com Mon Jan 6 10:28:28 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 06 Jan 2014 10:28:28 -0500 Subject: [aerogear-dev] sync In-Reply-To: <20140106044233.GA70219@rohan.local> References: <52C5822E.5080407@redhat.com> <20140106044233.GA70219@rohan.local> Message-ID: <52CACB9C.3090602@redhat.com> On 01/05/2014 11:42 PM, Douglas Campos wrote: > On Thu, Jan 02, 2014 at 10:13:50AM -0500, Summers Pittman wrote: >> On 12/20/2013 06:34 AM, Erik Jan de Wit wrote: >>> So we already agreed that CouchDB has some nice features, but why >>> wouldn't we just use pouchdb for javascript and touchdb? I've just >>> tested the javascript and it syncs with the server perfectly, even >>> if there are some things missing we could add them because these >>> projects are open source. >> Because wrapping CouchDB and friends to AeroGear with no other reason >> than to create a org.jboss.sync name space is dumb. > can't +9001 enough > >> Also the how of sync is still a bit far off. I'm still interested in the >> "what" of sync. What use cases are we supporting, what features are we >> supporting, what are our goals, what does a working finished sync impl >> look like, etc. > drafted here: https://gist.github.com/qmx/8278287 > > # aerogear-sync > > While I was reviewing Summers' code and ideas, I realized that I really wanted > everything he did, but as a second step after we nail down the basics. > > ## basics? > > Since we've been catering the enterprise market, this essentially means we need > to get the __boring__ stuff right first, then move over to the __shiny__ stuff, > like realtime data sync, update policies & friends. > > ### data model > > For starters, I think that the most important thing that needs to be agreed > upon is the data model and the atomic operations around it. As previous > discussed, I really like CouchDB's datamodel -- and hate erlang ;) > > `{_id:, content:, rev:}` So the id is the id of the sync message, the content is some implementation specific message/content (could be a diff, could be a whole new object etc), and the rev is the current revision of the document on the device? What is the scope of a revision number? IE if there are multiple users with multiple clients on multiple devices is a revision unique per session, user, or document? > > #### JS > > Well, it's JSON, it _Just Works_™ > > #### Java > > I didn't want to pick on Java, but since its fame forces me to it. First stab > (a courtesy of our friend Dan Bevenius): > > public interface Document { > public String id; > public String content; > public String rev; > } > > We naturally want to kick this a notch, and use objects instead of plain strings: > > public interface Document { > public ID id; > public T content; > public String rev; > } > > In this case, we can use the convention requiring that `T` is any **object > serializable to JSON**. `ID` is a convenience shorthand since it's a > **GUID/UUID**. I think this key isn't necessarily a natural key (a surrogate > key instead). > > #### Objective-C > > ;) > > ### API levels > > As soon as we have a rough data-model defined, we can start dabbling around > different API levels to be served: > > (parts **I think** are potentially deliverable for a 1.0) > > - level 0: explodes when there's a conflict > - level 1: semi-automatic conflict resolution via something like google's diff-match-patch > - level 2: business rules determine who wins a conflicting update (supervisor > wins over normal user) > > (parts **I think** are potentially deliverable for a 2.0) > > - level 3: real-time updates via diff-match-patch > - level 4: real-time updates via OT/EC > > All those proposed API operations should be serializable, meaning I can > potentially keep doing changes offline then just replying them to the server > when online. > > ### transport > > Since we know about the future-looking ideas on v2.0, it would be really nice > for us to specify a very simple/dumb JSON-based protocol for those change > messages. Something that could accomodate both the full document updates and > the OT/EC incremental bits too. I have no ideas on this, tbh. > > ## boring usecases > > ### scenario 1 > > Building inspector system - we have mobile apps that store relevant info and > are bound to be accessed on places where we won't have any kind of connection, > or very poor signal. > > You can have several inspectors screening the same building simultaneously. > > Let's say we have Agnes and Joe are doing the fire extinguisher inspection in a > new hospital building. Technically each fire extinguisher has its own > identifier and can be an independent document. In this case we would have no > conflict happening. > > Now they start finding expired fire extinguishers and start to add them to the > report. This report could potentially have two divergent lists of fire > extinguishers to be replenished/revalidated, as the building's compliance > status. > > ### scenario 2 > > Census system - we have mobile apps focused on offline data collection. We have > the previous year's info that needs to be updated on the server. The > interviewee needs to take a call, then asks the interviewer to come back later. > This results in two sets of changes for the same document, stacked together, > which should work flawlessly. > > Any other ideas/comments? Does the developer work with their objects and AeroGear create/manage the Document objects behind the scenes or does the developer have to manage the Document objects themselves? Is the Document object a change instance or a full implementation of an instance of the document? What does the server request/response lifecycle look like? How are updates from outside of the client handled? Are we including a server implementation ala unified push or are we only focusing on a spec that a server will implement? > > > _______________________________________________ > 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/20140106/839de2ec/attachment-0001.html From lholmqui at redhat.com Mon Jan 6 10:33:13 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 6 Jan 2014 10:33:13 -0500 Subject: [aerogear-dev] Auth Authz and OAuth In-Reply-To: <52CACA06.1000508@redhat.com> References: <52CACA06.1000508@redhat.com> Message-ID: <2E21E3DB-DD8C-44B3-9132-7D1588334B07@redhat.com> On Jan 6, 2014, at 10:21 AM, Summers Pittman wrote: > So in JS land and iOS land we have or will soon have OAuth2 handling. > To handle OAuth2 a new API was created, AGAuthorizationModule. I > understand and agree with the separation of concerns between > Authentication and Authorization, but I am worried that this introduces > two APIs now. > > Before Authz was added Authentication (login, logout, etc) and > Authorization(here are my keys and permissions) were both handled by > AGAuthenticationModules. With Authz now being a thing we should > probably remove and deprecate the authz parts of the old > AuthenticationModules. > > see iOS > https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/AeroGear-iOS/pipeline/AGRESTPipe.m#L307 > > see Android > https://github.com/aerogear/aerogear-android/blob/master/src/org/jboss/aerogear/android/impl/pipeline/RestRunner.java#L319 > > see Javascript: I couldn't actually find this in javascript? We didn't have authz in our auth stuff, so it made sense to create a separate thing. > > wdyt? > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From cvasilak at gmail.com Mon Jan 6 10:34:18 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 6 Jan 2014 17:34:18 +0200 Subject: [aerogear-dev] Team Meeting Agenda In-Reply-To: References: Message-ID: fyi meeting notes can be found here: [5:30pm]jbott:Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-01-06-14.52.html [5:30pm]jbott:Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-01-06-14.52.txt [5:30pm]jbott:Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-01-06-14.52.log.html > Feel free to add to the agenda[1] > > [1] http://oksoclap.com/p/OAp3G5dpd6 > > -- > Daniel Passos > > _______________________________________________ > 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/20140106/7d8d512f/attachment.html From supittma at redhat.com Mon Jan 6 10:35:41 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 06 Jan 2014 10:35:41 -0500 Subject: [aerogear-dev] Auth Authz and OAuth In-Reply-To: <2E21E3DB-DD8C-44B3-9132-7D1588334B07@redhat.com> References: <52CACA06.1000508@redhat.com> <2E21E3DB-DD8C-44B3-9132-7D1588334B07@redhat.com> Message-ID: <52CACD4D.9080803@redhat.com> On Mon 06 Jan 2014 10:33:13 AM EST, Lucas Holmquist wrote: > > On Jan 6, 2014, at 10:21 AM, Summers Pittman wrote: > >> So in JS land and iOS land we have or will soon have OAuth2 handling. >> To handle OAuth2 a new API was created, AGAuthorizationModule. I >> understand and agree with the separation of concerns between >> Authentication and Authorization, but I am worried that this introduces >> two APIs now. >> >> Before Authz was added Authentication (login, logout, etc) and >> Authorization(here are my keys and permissions) were both handled by >> AGAuthenticationModules. With Authz now being a thing we should >> probably remove and deprecate the authz parts of the old >> AuthenticationModules. >> >> see iOS >> https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/AeroGear-iOS/pipeline/AGRESTPipe.m#L307 >> >> see Android >> https://github.com/aerogear/aerogear-android/blob/master/src/org/jboss/aerogear/android/impl/pipeline/RestRunner.java#L319 >> >> see Javascript: I couldn't actually find this in javascript? > > We didn't have authz in our auth stuff, so it made sense to create a separate thing. How was JavaScript handling tokens in Auth then? > >> >> 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 From corinnekrych at gmail.com Mon Jan 6 10:36:32 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 6 Jan 2014 16:36:32 +0100 Subject: [aerogear-dev] Auth Authz and OAuth In-Reply-To: <2E21E3DB-DD8C-44B3-9132-7D1588334B07@redhat.com> References: <52CACA06.1000508@redhat.com> <2E21E3DB-DD8C-44B3-9132-7D1588334B07@redhat.com> Message-ID: <1645A48F-12E4-451C-A1DF-562556D53F13@gmail.com> Summers, Do you mean, should we refactor and treat authToken and accessTokens in a similar way for the implementation of OAuth2? ++ Corinne On Jan 6, 2014, at 4:33 PM, Lucas Holmquist wrote: > > On Jan 6, 2014, at 10:21 AM, Summers Pittman wrote: > >> So in JS land and iOS land we have or will soon have OAuth2 handling. >> To handle OAuth2 a new API was created, AGAuthorizationModule. I >> understand and agree with the separation of concerns between >> Authentication and Authorization, but I am worried that this introduces >> two APIs now. >> >> Before Authz was added Authentication (login, logout, etc) and >> Authorization(here are my keys and permissions) were both handled by >> AGAuthenticationModules. With Authz now being a thing we should >> probably remove and deprecate the authz parts of the old >> AuthenticationModules. >> >> see iOS >> https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/AeroGear-iOS/pipeline/AGRESTPipe.m#L307 >> >> see Android >> https://github.com/aerogear/aerogear-android/blob/master/src/org/jboss/aerogear/android/impl/pipeline/RestRunner.java#L319 >> >> see Javascript: I couldn't actually find this in javascript? > > We didn't have authz in our auth stuff, so it made sense to create a separate thing. > >> >> 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 From supittma at redhat.com Mon Jan 6 10:39:31 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 06 Jan 2014 10:39:31 -0500 Subject: [aerogear-dev] Auth Authz and OAuth In-Reply-To: <1645A48F-12E4-451C-A1DF-562556D53F13@gmail.com> References: <52CACA06.1000508@redhat.com> <2E21E3DB-DD8C-44B3-9132-7D1588334B07@redhat.com> <1645A48F-12E4-451C-A1DF-562556D53F13@gmail.com> Message-ID: <52CACE33.6070807@redhat.com> On Mon 06 Jan 2014 10:36:32 AM EST, Corinne Krych wrote: > Summers, > > Do you mean, should we refactor and treat authToken and accessTokens in a similar way for the implementation of OAuth2? Yes. That is what I am proposing. > > ++ > Corinne > On Jan 6, 2014, at 4:33 PM, Lucas Holmquist wrote: > >> >> On Jan 6, 2014, at 10:21 AM, Summers Pittman wrote: >> >>> So in JS land and iOS land we have or will soon have OAuth2 handling. >>> To handle OAuth2 a new API was created, AGAuthorizationModule. I >>> understand and agree with the separation of concerns between >>> Authentication and Authorization, but I am worried that this introduces >>> two APIs now. >>> >>> Before Authz was added Authentication (login, logout, etc) and >>> Authorization(here are my keys and permissions) were both handled by >>> AGAuthenticationModules. With Authz now being a thing we should >>> probably remove and deprecate the authz parts of the old >>> AuthenticationModules. >>> >>> see iOS >>> https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/AeroGear-iOS/pipeline/AGRESTPipe.m#L307 >>> >>> see Android >>> https://github.com/aerogear/aerogear-android/blob/master/src/org/jboss/aerogear/android/impl/pipeline/RestRunner.java#L319 >>> >>> see Javascript: I couldn't actually find this in javascript? >> >> We didn't have authz in our auth stuff, so it made sense to create a separate thing. >> >>> >>> 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 Mon Jan 6 10:40:55 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 6 Jan 2014 10:40:55 -0500 Subject: [aerogear-dev] Auth Authz and OAuth In-Reply-To: <52CACD4D.9080803@redhat.com> References: <52CACA06.1000508@redhat.com> <2E21E3DB-DD8C-44B3-9132-7D1588334B07@redhat.com> <52CACD4D.9080803@redhat.com> Message-ID: On Jan 6, 2014, at 10:35 AM, Summers Pittman wrote: > On Mon 06 Jan 2014 10:33:13 AM EST, Lucas Holmquist wrote: >> >> On Jan 6, 2014, at 10:21 AM, Summers Pittman wrote: >> >>> So in JS land and iOS land we have or will soon have OAuth2 handling. >>> To handle OAuth2 a new API was created, AGAuthorizationModule. I >>> understand and agree with the separation of concerns between >>> Authentication and Authorization, but I am worried that this introduces >>> two APIs now. >>> >>> Before Authz was added Authentication (login, logout, etc) and >>> Authorization(here are my keys and permissions) were both handled by >>> AGAuthenticationModules. With Authz now being a thing we should >>> probably remove and deprecate the authz parts of the old >>> AuthenticationModules. >>> >>> see iOS >>> https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/AeroGear-iOS/pipeline/AGRESTPipe.m#L307 >>> >>> see Android >>> https://github.com/aerogear/aerogear-android/blob/master/src/org/jboss/aerogear/android/impl/pipeline/RestRunner.java#L319 >>> >>> see Javascript: I couldn't actually find this in javascript? >> >> We didn't have authz in our auth stuff, so it made sense to create a separate thing. > > How was JavaScript handling tokens in Auth then? the browser > >> >>> >>> 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 > > From supittma at redhat.com Mon Jan 6 10:41:28 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 06 Jan 2014 10:41:28 -0500 Subject: [aerogear-dev] sync In-Reply-To: <20CD72E5-2A13-4D8E-AA54-2E3D29EC630F@redhat.com> References: <52C5822E.5080407@redhat.com> <20140106044233.GA70219@rohan.local> <20CD72E5-2A13-4D8E-AA54-2E3D29EC630F@redhat.com> Message-ID: <52CACEA8.2060603@redhat.com> On 01/06/2014 09:29 AM, Lucas Holmquist wrote: > On Jan 5, 2014, at 11:42 PM, Douglas Campos wrote: > >> On Thu, Jan 02, 2014 at 10:13:50AM -0500, Summers Pittman wrote: >>> On 12/20/2013 06:34 AM, Erik Jan de Wit wrote: >>>> So we already agreed that CouchDB has some nice features, but why >>>> wouldn?t we just use pouchdb for javascript and touchdb? I?ve just >>>> tested the javascript and it syncs with the server perfectly, even >>>> if there are some things missing we could add them because these >>>> projects are open source. >>> Because wrapping CouchDB and friends to AeroGear with no other reason >>> than to create a org.jboss.sync name space is dumb. >> can't +9001 enough >> >>> Also the how of sync is still a bit far off. I'm still interested in the >>> "what" of sync. What use cases are we supporting, what features are we >>> supporting, what are our goals, what does a working finished sync impl >>> look like, etc. >> drafted here: https://gist.github.com/qmx/8278287 >> >> # aerogear-sync >> >> While I was reviewing Summers' code and ideas, I realized that I really wanted >> everything he did, but as a second step after we nail down the basics. >> >> ## basics? >> >> Since we've been catering the enterprise market, this essentially means we need >> to get the __boring__ stuff right first, then move over to the __shiny__ stuff, >> like realtime data sync, update policies & friends. >> >> ### data model >> >> For starters, I think that the most important thing that needs to be agreed >> upon is the data model and the atomic operations around it. As previous >> discussed, I really like CouchDB's datamodel -- and hate erlang ;) >> >> `{_id:, content:, rev:}` >> >> #### JS >> >> Well, it's JSON, it _Just Works_™ >> >> #### Java >> >> I didn't want to pick on Java, but since its fame forces me to it. First stab >> (a courtesy of our friend Dan Bevenius): >> >> public interface Document { >> public String id; >> public String content; >> public String rev; >> } >> >> We naturally want to kick this a notch, and use objects instead of plain strings: >> >> public interface Document { >> public ID id; >> public T content; >> public String rev; >> } >> >> In this case, we can use the convention requiring that `T` is any **object >> serializable to JSON**. `ID` is a convenience shorthand since it's a >> **GUID/UUID**. I think this key isn't necessarily a natural key (a surrogate >> key instead). >> >> #### Objective-C >> >> ;) >> >> ### API levels >> >> As soon as we have a rough data-model defined, we can start dabbling around >> different API levels to be served: >> >> (parts **I think** are potentially deliverable for a 1.0) >> >> - level 0: explodes when there's a conflict >> - level 1: semi-automatic conflict resolution via something like google's diff-match-patch >> - level 2: business rules determine who wins a conflicting update (supervisor >> wins over normal user) >> >> (parts **I think** are potentially deliverable for a 2.0) >> >> - level 3: real-time updates via diff-match-patch >> - level 4: real-time updates via OT/EC >> > where does the more than 2 users editing something fall. > > so if say 4 people are editing something offline and then come back online, who wins that one. I think that would be level 2. Either the developer would write a business rule or choose a provided conflict resolution strategy object. I think AbstractConflictResolutionStrategyFactory is too awesome of a class name to miss out on now :) > > >> All those proposed API operations should be serializable, meaning I can >> potentially keep doing changes offline then just replying them to the server >> when online. >> >> ### transport >> >> Since we know about the future-looking ideas on v2.0, it would be really nice >> for us to specify a very simple/dumb JSON-based protocol for those change >> messages. Something that could accomodate both the full document updates and >> the OT/EC incremental bits too. I have no ideas on this, tbh. >> >> ## boring usecases >> >> ### scenario 1 >> >> Building inspector system - we have mobile apps that store relevant info and >> are bound to be accessed on places where we won't have any kind of connection, >> or very poor signal. >> >> You can have several inspectors screening the same building simultaneously. >> >> Let's say we have Agnes and Joe are doing the fire extinguisher inspection in a >> new hospital building. Technically each fire extinguisher has its own >> identifier and can be an independent document. In this case we would have no >> conflict happening. >> >> Now they start finding expired fire extinguishers and start to add them to the >> report. This report could potentially have two divergent lists of fire >> extinguishers to be replenished/revalidated, as the building's compliance >> status. >> >> ### scenario 2 >> >> Census system - we have mobile apps focused on offline data collection. We have >> the previous year's info that needs to be updated on the server. The >> interviewee needs to take a call, then asks the interviewer to come back later. >> This results in two sets of changes for the same document, stacked together, >> which should work flawlessly. >> >> Any other ideas/comments? >> >> -- >> qmx_______________________________________________ >> 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 Mon Jan 6 10:42:50 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 06 Jan 2014 10:42:50 -0500 Subject: [aerogear-dev] Auth Authz and OAuth In-Reply-To: References: <52CACA06.1000508@redhat.com> <2E21E3DB-DD8C-44B3-9132-7D1588334B07@redhat.com> <52CACD4D.9080803@redhat.com> Message-ID: <52CACEFA.1010607@redhat.com> On Mon 06 Jan 2014 10:40:55 AM EST, Lucas Holmquist wrote: > > On Jan 6, 2014, at 10:35 AM, Summers Pittman wrote: > >> On Mon 06 Jan 2014 10:33:13 AM EST, Lucas Holmquist wrote: >>> >>> On Jan 6, 2014, at 10:21 AM, Summers Pittman wrote: >>> >>>> So in JS land and iOS land we have or will soon have OAuth2 handling. >>>> To handle OAuth2 a new API was created, AGAuthorizationModule. I >>>> understand and agree with the separation of concerns between >>>> Authentication and Authorization, but I am worried that this introduces >>>> two APIs now. >>>> >>>> Before Authz was added Authentication (login, logout, etc) and >>>> Authorization(here are my keys and permissions) were both handled by >>>> AGAuthenticationModules. With Authz now being a thing we should >>>> probably remove and deprecate the authz parts of the old >>>> AuthenticationModules. >>>> >>>> see iOS >>>> https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/AeroGear-iOS/pipeline/AGRESTPipe.m#L307 >>>> >>>> see Android >>>> https://github.com/aerogear/aerogear-android/blob/master/src/org/jboss/aerogear/android/impl/pipeline/RestRunner.java#L319 >>>> >>>> see Javascript: I couldn't actually find this in javascript? >>> >>> We didn't have authz in our auth stuff, so it made sense to create a separate thing. >> >> How was JavaScript handling tokens in Auth then? > > the browser ... That's brilliant! >> >>> >>>> >>>> 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 >> >> > From corinnekrych at gmail.com Mon Jan 6 10:48:44 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 6 Jan 2014 16:48:44 +0100 Subject: [aerogear-dev] Auth Authz and OAuth In-Reply-To: <52CACE33.6070807@redhat.com> References: <52CACA06.1000508@redhat.com> <2E21E3DB-DD8C-44B3-9132-7D1588334B07@redhat.com> <1645A48F-12E4-451C-A1DF-562556D53F13@gmail.com> <52CACE33.6070807@redhat.com> Message-ID: Agreed. We could find a common way to treat both tokens and apply them. Make a proposal for android and I'll create a JIRA for iOS. this is at implementation level though and should not affect interfaces. Different interfaces still needed for auth and authz though. ++ Corinne On Jan 6, 2014, at 4:39 PM, Summers Pittman wrote: > On Mon 06 Jan 2014 10:36:32 AM EST, Corinne Krych wrote: >> Summers, >> >> Do you mean, should we refactor and treat authToken and accessTokens in a similar way for the implementation of OAuth2? > > Yes. That is what I am proposing. > >> >> ++ >> Corinne >> On Jan 6, 2014, at 4:33 PM, Lucas Holmquist wrote: >> >>> >>> On Jan 6, 2014, at 10:21 AM, Summers Pittman wrote: >>> >>>> So in JS land and iOS land we have or will soon have OAuth2 handling. >>>> To handle OAuth2 a new API was created, AGAuthorizationModule. I >>>> understand and agree with the separation of concerns between >>>> Authentication and Authorization, but I am worried that this introduces >>>> two APIs now. >>>> >>>> Before Authz was added Authentication (login, logout, etc) and >>>> Authorization(here are my keys and permissions) were both handled by >>>> AGAuthenticationModules. With Authz now being a thing we should >>>> probably remove and deprecate the authz parts of the old >>>> AuthenticationModules. >>>> >>>> see iOS >>>> https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/AeroGear-iOS/pipeline/AGRESTPipe.m#L307 >>>> >>>> see Android >>>> https://github.com/aerogear/aerogear-android/blob/master/src/org/jboss/aerogear/android/impl/pipeline/RestRunner.java#L319 >>>> >>>> see Javascript: I couldn't actually find this in javascript? >>> >>> We didn't have authz in our auth stuff, so it made sense to create a separate thing. >>> >>>> >>>> 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 Mon Jan 6 10:53:48 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 6 Jan 2014 10:53:48 -0500 Subject: [aerogear-dev] Auth Authz and OAuth In-Reply-To: <52CACD4D.9080803@redhat.com> References: <52CACA06.1000508@redhat.com> <2E21E3DB-DD8C-44B3-9132-7D1588334B07@redhat.com> <52CACD4D.9080803@redhat.com> Message-ID: On Jan 6, 2014, at 10:35 AM, Summers Pittman wrote: > On Mon 06 Jan 2014 10:33:13 AM EST, Lucas Holmquist wrote: >> >> On Jan 6, 2014, at 10:21 AM, Summers Pittman wrote: >> >>> So in JS land and iOS land we have or will soon have OAuth2 handling. >>> To handle OAuth2 a new API was created, AGAuthorizationModule. I >>> understand and agree with the separation of concerns between >>> Authentication and Authorization, but I am worried that this introduces >>> two APIs now. >>> >>> Before Authz was added Authentication (login, logout, etc) and >>> Authorization(here are my keys and permissions) were both handled by >>> AGAuthenticationModules. With Authz now being a thing we should >>> probably remove and deprecate the authz parts of the old >>> AuthenticationModules. >>> >>> see iOS >>> https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/AeroGear-iOS/pipeline/AGRESTPipe.m#L307 >>> >>> see Android >>> https://github.com/aerogear/aerogear-android/blob/master/src/org/jboss/aerogear/android/impl/pipeline/RestRunner.java#L319 >>> >>> see Javascript: I couldn't actually find this in javascript? >> >> We didn't have authz in our auth stuff, so it made sense to create a separate thing. > > How was JavaScript handling tokens in Auth then? also when me and Kris were discussing the benefits of an OAuth2 adapter, we came to the conclusion that it should not really used by itself, although it could, but instead integrate it into pipeline > >> >>> >>> 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 > > From supittma at redhat.com Mon Jan 6 11:03:13 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 06 Jan 2014 11:03:13 -0500 Subject: [aerogear-dev] Auth Authz and OAuth In-Reply-To: References: <52CACA06.1000508@redhat.com> <2E21E3DB-DD8C-44B3-9132-7D1588334B07@redhat.com> <52CACD4D.9080803@redhat.com> Message-ID: <52CAD3C1.6070100@redhat.com> On Mon 06 Jan 2014 10:53:48 AM EST, Lucas Holmquist wrote: > > On Jan 6, 2014, at 10:35 AM, Summers Pittman wrote: > >> On Mon 06 Jan 2014 10:33:13 AM EST, Lucas Holmquist wrote: >>> >>> On Jan 6, 2014, at 10:21 AM, Summers Pittman wrote: >>> >>>> So in JS land and iOS land we have or will soon have OAuth2 handling. >>>> To handle OAuth2 a new API was created, AGAuthorizationModule. I >>>> understand and agree with the separation of concerns between >>>> Authentication and Authorization, but I am worried that this introduces >>>> two APIs now. >>>> >>>> Before Authz was added Authentication (login, logout, etc) and >>>> Authorization(here are my keys and permissions) were both handled by >>>> AGAuthenticationModules. With Authz now being a thing we should >>>> probably remove and deprecate the authz parts of the old >>>> AuthenticationModules. >>>> >>>> see iOS >>>> https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/AeroGear-iOS/pipeline/AGRESTPipe.m#L307 >>>> >>>> see Android >>>> https://github.com/aerogear/aerogear-android/blob/master/src/org/jboss/aerogear/android/impl/pipeline/RestRunner.java#L319 >>>> >>>> see Javascript: I couldn't actually find this in javascript? >>> >>> We didn't have authz in our auth stuff, so it made sense to create a separate thing. >> >> How was JavaScript handling tokens in Auth then? > also when me and Kris were discussing the benefits of an OAuth2 adapter, we came to the conclusion that it should not really used by itself, although it could, but instead integrate it into pipeline That is how the auth stuff works on iOS and Android > >> >>> >>>> >>>> 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 >> >> > From supittma at redhat.com Mon Jan 6 11:04:11 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 06 Jan 2014 11:04:11 -0500 Subject: [aerogear-dev] Auth Authz and OAuth In-Reply-To: References: <52CACA06.1000508@redhat.com> <2E21E3DB-DD8C-44B3-9132-7D1588334B07@redhat.com> <1645A48F-12E4-451C-A1DF-562556D53F13@gmail.com> <52CACE33.6070807@redhat.com> Message-ID: <52CAD3FB.6060408@redhat.com> On 01/06/2014 10:48 AM, Corinne Krych wrote: > Agreed. We could find a common way to treat both tokens and apply them. > Make a proposal for android and I'll create a JIRA for iOS. > this is at implementation level though and should not affect interfaces. > Different interfaces still needed for auth and authz though. True. But it may simplify both interfaces (like removing login/logoff/enroll from authz) > > ++ > Corinne > On Jan 6, 2014, at 4:39 PM, Summers Pittman wrote: > >> On Mon 06 Jan 2014 10:36:32 AM EST, Corinne Krych wrote: >>> Summers, >>> >>> Do you mean, should we refactor and treat authToken and accessTokens in a similar way for the implementation of OAuth2? >> Yes. That is what I am proposing. >> >>> ++ >>> Corinne >>> On Jan 6, 2014, at 4:33 PM, Lucas Holmquist wrote: >>> >>>> On Jan 6, 2014, at 10:21 AM, Summers Pittman wrote: >>>> >>>>> So in JS land and iOS land we have or will soon have OAuth2 handling. >>>>> To handle OAuth2 a new API was created, AGAuthorizationModule. I >>>>> understand and agree with the separation of concerns between >>>>> Authentication and Authorization, but I am worried that this introduces >>>>> two APIs now. >>>>> >>>>> Before Authz was added Authentication (login, logout, etc) and >>>>> Authorization(here are my keys and permissions) were both handled by >>>>> AGAuthenticationModules. With Authz now being a thing we should >>>>> probably remove and deprecate the authz parts of the old >>>>> AuthenticationModules. >>>>> >>>>> see iOS >>>>> https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/AeroGear-iOS/pipeline/AGRESTPipe.m#L307 >>>>> >>>>> see Android >>>>> https://github.com/aerogear/aerogear-android/blob/master/src/org/jboss/aerogear/android/impl/pipeline/RestRunner.java#L319 >>>>> >>>>> see Javascript: I couldn't actually find this in javascript? >>>> We didn't have authz in our auth stuff, so it made sense to create a separate thing. >>>> >>>>> 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 supittma at redhat.com Mon Jan 6 11:31:28 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 06 Jan 2014 11:31:28 -0500 Subject: [aerogear-dev] sync In-Reply-To: <20140106044233.GA70219@rohan.local> References: <52C5822E.5080407@redhat.com> <20140106044233.GA70219@rohan.local> Message-ID: <52CADA60.70807@redhat.com> On 01/05/2014 11:42 PM, Douglas Campos wrote: > On Thu, Jan 02, 2014 at 10:13:50AM -0500, Summers Pittman wrote: >> On 12/20/2013 06:34 AM, Erik Jan de Wit wrote: >>> So we already agreed that CouchDB has some nice features, but why >>> wouldn't we just use pouchdb for javascript and touchdb? I've just >>> tested the javascript and it syncs with the server perfectly, even >>> if there are some things missing we could add them because these >>> projects are open source. >> Because wrapping CouchDB and friends to AeroGear with no other reason >> than to create a org.jboss.sync name space is dumb. > can't +9001 enough > >> Also the how of sync is still a bit far off. I'm still interested in the >> "what" of sync. What use cases are we supporting, what features are we >> supporting, what are our goals, what does a working finished sync impl >> look like, etc. > drafted here: https://gist.github.com/qmx/8278287 > > # aerogear-sync > > While I was reviewing Summers' code and ideas, I realized that I really wanted > everything he did, but as a second step after we nail down the basics. > > ## basics? > > Since we've been catering the enterprise market, this essentially means we need > to get the __boring__ stuff right first, then move over to the __shiny__ stuff, > like realtime data sync, update policies & friends. > > ### data model > > For starters, I think that the most important thing that needs to be agreed > upon is the data model and the atomic operations around it. As previous > discussed, I really like CouchDB's datamodel -- and hate erlang ;) > > `{_id:, content:, rev:}` > > #### JS > > Well, it's JSON, it _Just Works_™ > > #### Java > > I didn't want to pick on Java, but since its fame forces me to it. First stab > (a courtesy of our friend Dan Bevenius): > > public interface Document { > public String id; > public String content; > public String rev; > } > > We naturally want to kick this a notch, and use objects instead of plain strings: > > public interface Document { > public ID id; > public T content; > public String rev; > } > > In this case, we can use the convention requiring that `T` is any **object > serializable to JSON**. `ID` is a convenience shorthand since it's a > **GUID/UUID**. I think this key isn't necessarily a natural key (a surrogate > key instead). > > #### Objective-C > > ;) > > ### API levels > > As soon as we have a rough data-model defined, we can start dabbling around > different API levels to be served: > > (parts **I think** are potentially deliverable for a 1.0) > > - level 0: explodes when there's a conflict > - level 1: semi-automatic conflict resolution via something like google's diff-match-patch > - level 2: business rules determine who wins a conflicting update (supervisor > wins over normal user) > > (parts **I think** are potentially deliverable for a 2.0) > > - level 3: real-time updates via diff-match-patch > - level 4: real-time updates via OT/EC > > All those proposed API operations should be serializable, meaning I can > potentially keep doing changes offline then just replying them to the server > when online. > > ### transport > > Since we know about the future-looking ideas on v2.0, it would be really nice > for us to specify a very simple/dumb JSON-based protocol for those change > messages. Something that could accomodate both the full document updates and > the OT/EC incremental bits too. I have no ideas on this, tbh. A good transport will include the change to sync (this can be a diff or a whole object), the revision on the client, and a checksum so the server can be sure that the object was updated correctly. > > ## boring usecases > > ### scenario 1 > > Building inspector system - we have mobile apps that store relevant info and > are bound to be accessed on places where we won't have any kind of connection, > or very poor signal. > > You can have several inspectors screening the same building simultaneously. > > Let's say we have Agnes and Joe are doing the fire extinguisher inspection in a > new hospital building. Technically each fire extinguisher has its own > identifier and can be an independent document. In this case we would have no > conflict happening. > > Now they start finding expired fire extinguishers and start to add them to the > report. This report could potentially have two divergent lists of fire > extinguishers to be replenished/revalidated, as the building's compliance > status. > > ### scenario 2 > > Census system - we have mobile apps focused on offline data collection. We have > the previous year's info that needs to be updated on the server. The > interviewee needs to take a call, then asks the interviewer to come back later. > This results in two sets of changes for the same document, stacked together, > which should work flawlessly. > > Any other ideas/comments? > > > > _______________________________________________ > 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/20140106/ff8e67e3/attachment-0001.html From corinnekrych at gmail.com Mon Jan 6 12:04:16 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 6 Jan 2014 18:04:16 +0100 Subject: [aerogear-dev] Auth Authz and OAuth In-Reply-To: <52CAD3FB.6060408@redhat.com> References: <52CACA06.1000508@redhat.com> <2E21E3DB-DD8C-44B3-9132-7D1588334B07@redhat.com> <1645A48F-12E4-451C-A1DF-562556D53F13@gmail.com> <52CACE33.6070807@redhat.com> <52CAD3FB.6060408@redhat.com> Message-ID: <5835F3DC-6BF9-4FD7-9188-26E755C97407@gmail.com> login/logoff/enroll is not part of authz already ++ Corinne On Jan 6, 2014, at 5:04 PM, Summers Pittman wrote: > On 01/06/2014 10:48 AM, Corinne Krych wrote: >> Agreed. We could find a common way to treat both tokens and apply them. >> Make a proposal for android and I'll create a JIRA for iOS. >> this is at implementation level though and should not affect interfaces. >> Different interfaces still needed for auth and authz though. > True. But it may simplify both interfaces (like removing login/logoff/enroll from authz) >> >> ++ >> Corinne >> On Jan 6, 2014, at 4:39 PM, Summers Pittman wrote: >> >>> On Mon 06 Jan 2014 10:36:32 AM EST, Corinne Krych wrote: >>>> Summers, >>>> >>>> Do you mean, should we refactor and treat authToken and accessTokens in a similar way for the implementation of OAuth2? >>> Yes. That is what I am proposing. >>> >>>> ++ >>>> Corinne >>>> On Jan 6, 2014, at 4:33 PM, Lucas Holmquist wrote: >>>> >>>>> On Jan 6, 2014, at 10:21 AM, Summers Pittman wrote: >>>>> >>>>>> So in JS land and iOS land we have or will soon have OAuth2 handling. >>>>>> To handle OAuth2 a new API was created, AGAuthorizationModule. I >>>>>> understand and agree with the separation of concerns between >>>>>> Authentication and Authorization, but I am worried that this introduces >>>>>> two APIs now. >>>>>> >>>>>> Before Authz was added Authentication (login, logout, etc) and >>>>>> Authorization(here are my keys and permissions) were both handled by >>>>>> AGAuthenticationModules. With Authz now being a thing we should >>>>>> probably remove and deprecate the authz parts of the old >>>>>> AuthenticationModules. >>>>>> >>>>>> see iOS >>>>>> https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/AeroGear-iOS/pipeline/AGRESTPipe.m#L307 >>>>>> >>>>>> see Android >>>>>> https://github.com/aerogear/aerogear-android/blob/master/src/org/jboss/aerogear/android/impl/pipeline/RestRunner.java#L319 >>>>>> >>>>>> see Javascript: I couldn't actually find this in javascript? >>>>> We didn't have authz in our auth stuff, so it made sense to create a separate thing. >>>>> >>>>>> 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 supittma at redhat.com Mon Jan 6 11:30:09 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 06 Jan 2014 11:30:09 -0500 Subject: [aerogear-dev] sync In-Reply-To: <20140106044233.GA70219@rohan.local> References: <52C5822E.5080407@redhat.com> <20140106044233.GA70219@rohan.local> Message-ID: <52CADA11.5070402@redhat.com> On 01/05/2014 11:42 PM, Douglas Campos wrote: > On Thu, Jan 02, 2014 at 10:13:50AM -0500, Summers Pittman wrote: >> On 12/20/2013 06:34 AM, Erik Jan de Wit wrote: >>> So we already agreed that CouchDB has some nice features, but why >>> wouldn't we just use pouchdb for javascript and touchdb? I've just >>> tested the javascript and it syncs with the server perfectly, even >>> if there are some things missing we could add them because these >>> projects are open source. >> Because wrapping CouchDB and friends to AeroGear with no other reason >> than to create a org.jboss.sync name space is dumb. > can't +9001 enough > >> Also the how of sync is still a bit far off. I'm still interested in the >> "what" of sync. What use cases are we supporting, what features are we >> supporting, what are our goals, what does a working finished sync impl >> look like, etc. > drafted here: https://gist.github.com/qmx/8278287 > > # aerogear-sync > > While I was reviewing Summers' code and ideas, I realized that I really wanted > everything he did, but as a second step after we nail down the basics. > > ## basics? > > Since we've been catering the enterprise market, this essentially means we need > to get the __boring__ stuff right first, then move over to the __shiny__ stuff, > like realtime data sync, update policies & friends. > > ### data model > > For starters, I think that the most important thing that needs to be agreed > upon is the data model and the atomic operations around it. As previous > discussed, I really like CouchDB's datamodel -- and hate erlang ;) > > `{_id:, content:, rev:}` > > #### JS > > Well, it's JSON, it _Just Works_™ > > #### Java > > I didn't want to pick on Java, but since its fame forces me to it. First stab > (a courtesy of our friend Dan Bevenius): > > public interface Document { > public String id; > public String content; > public String rev; > } > > We naturally want to kick this a notch, and use objects instead of plain strings: > > public interface Document { > public ID id; > public T content; > public String rev; > } > > In this case, we can use the convention requiring that `T` is any **object > serializable to JSON**. `ID` is a convenience shorthand since it's a > **GUID/UUID**. I think this key isn't necessarily a natural key (a surrogate > key instead). > > #### Objective-C > > ;) > > ### API levels > > As soon as we have a rough data-model defined, we can start dabbling around > different API levels to be served: > > (parts **I think** are potentially deliverable for a 1.0) > > - level 0: explodes when there's a conflict > - level 1: semi-automatic conflict resolution via something like google's diff-match-patch > - level 2: business rules determine who wins a conflicting update (supervisor > wins over normal user) > > (parts **I think** are potentially deliverable for a 2.0) > > - level 3: real-time updates via diff-match-patch > - level 4: real-time updates via OT/EC > > All those proposed API operations should be serializable, meaning I can > potentially keep doing changes offline then just replying them to the server > when online. > > ### transport > > Since we know about the future-looking ideas on v2.0, it would be really nice > for us to specify a very simple/dumb JSON-based protocol for those change > messages. Something that could accomodate both the full document updates and > the OT/EC incremental bits too. I have no ideas on this, tbh. > > ## boring usecases > > ### scenario 1 > > Building inspector system - we have mobile apps that store relevant info and > are bound to be accessed on places where we won't have any kind of connection, > or very poor signal. > > You can have several inspectors screening the same building simultaneously. > > Let's say we have Agnes and Joe are doing the fire extinguisher inspection in a > new hospital building. Technically each fire extinguisher has its own > identifier and can be an independent document. In this case we would have no > conflict happening. > > Now they start finding expired fire extinguishers and start to add them to the > report. This report could potentially have two divergent lists of fire > extinguishers to be replenished/revalidated, as the building's compliance > status. > > ### scenario 2 > > Census system - we have mobile apps focused on offline data collection. We have > the previous year's info that needs to be updated on the server. The > interviewee needs to take a call, then asks the interviewer to come back later. > This results in two sets of changes for the same document, stacked together, > which should work flawlessly. > > Any other ideas/comments? I'll add now :) ## Transactions These are the most basic parts of sync I can think of that our system should be able to do/manage. Our internal representation of the client documents and collections should make implementing this automatically and without user intervention as simple as possible * Detect Change When a user changes her local data, the system should note the change and generate a sync message to send to the server. This can be done automatically or manually but SHOULD be done automatically. * Send update When a sync message is ready to be sent, and the system allows for it to be sent (network available, not in blackout window from exponential backoff, etc) then sync message should be sent. This SHOULD be done automatically. * Receive Update When a client updates it data and successfully syncs to the remote server, the remote server will notify all of the relevant clients. The client must automatically and without user intervention receive this update and either act on it or store it for later processing. * Apply Update Once a client application has an update message from the server, it can apply the message correctly to the data on it. This should be done automatically as part of receiving the update, but it may be done manually or may be delayed and automatically executed later. * Detect Conflict When applying an update fails, the system must detect this. The system will provide state to the application and/or the user to handle the conflict. The user MUST NOT have to check for conflicts on her own. * Resolve Conflict There must be a mechanism for resolving a conflict. The CAN be done automatically using default resolvers provided by AeroGear, by using a resolver provided by the developer/user, or by the app user selecting the correct merge. This will probably generate a new sync message. > > > > _______________________________________________ > 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/20140106/e3c7bbec/attachment.html From supittma at redhat.com Mon Jan 6 12:16:45 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 06 Jan 2014 12:16:45 -0500 Subject: [aerogear-dev] Auth Authz and OAuth In-Reply-To: <5835F3DC-6BF9-4FD7-9188-26E755C97407@gmail.com> References: <52CACA06.1000508@redhat.com> <2E21E3DB-DD8C-44B3-9132-7D1588334B07@redhat.com> <1645A48F-12E4-451C-A1DF-562556D53F13@gmail.com> <52CACE33.6070807@redhat.com> <52CAD3FB.6060408@redhat.com> <5835F3DC-6BF9-4FD7-9188-26E755C97407@gmail.com> Message-ID: <52CAE4FD.1030802@redhat.com> On Mon 06 Jan 2014 12:04:16 PM EST, Corinne Krych wrote: > login/logoff/enroll is not part of authz already Oh, I misread your files this morning and this makes a lot more sense now. Note to self, don't review ObjC until I have had at least 3 cups of coffee. > ++ > Corinne > On Jan 6, 2014, at 5:04 PM, Summers Pittman wrote: > >> On 01/06/2014 10:48 AM, Corinne Krych wrote: >>> Agreed. We could find a common way to treat both tokens and apply them. >>> Make a proposal for android and I'll create a JIRA for iOS. >>> this is at implementation level though and should not affect interfaces. >>> Different interfaces still needed for auth and authz though. >> True. But it may simplify both interfaces (like removing login/logoff/enroll from authz) >>> >>> ++ >>> Corinne >>> On Jan 6, 2014, at 4:39 PM, Summers Pittman wrote: >>> >>>> On Mon 06 Jan 2014 10:36:32 AM EST, Corinne Krych wrote: >>>>> Summers, >>>>> >>>>> Do you mean, should we refactor and treat authToken and accessTokens in a similar way for the implementation of OAuth2? >>>> Yes. That is what I am proposing. >>>> >>>>> ++ >>>>> Corinne >>>>> On Jan 6, 2014, at 4:33 PM, Lucas Holmquist wrote: >>>>> >>>>>> On Jan 6, 2014, at 10:21 AM, Summers Pittman wrote: >>>>>> >>>>>>> So in JS land and iOS land we have or will soon have OAuth2 handling. >>>>>>> To handle OAuth2 a new API was created, AGAuthorizationModule. I >>>>>>> understand and agree with the separation of concerns between >>>>>>> Authentication and Authorization, but I am worried that this introduces >>>>>>> two APIs now. >>>>>>> >>>>>>> Before Authz was added Authentication (login, logout, etc) and >>>>>>> Authorization(here are my keys and permissions) were both handled by >>>>>>> AGAuthenticationModules. With Authz now being a thing we should >>>>>>> probably remove and deprecate the authz parts of the old >>>>>>> AuthenticationModules. >>>>>>> >>>>>>> see iOS >>>>>>> https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/AeroGear-iOS/pipeline/AGRESTPipe.m#L307 >>>>>>> >>>>>>> see Android >>>>>>> https://github.com/aerogear/aerogear-android/blob/master/src/org/jboss/aerogear/android/impl/pipeline/RestRunner.java#L319 >>>>>>> >>>>>>> see Javascript: I couldn't actually find this in javascript? >>>>>> We didn't have authz in our auth stuff, so it made sense to create a separate thing. >>>>>> >>>>>>> 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 scm.blanc at gmail.com Tue Jan 7 02:53:00 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 7 Jan 2014 08:53:00 +0100 Subject: [aerogear-dev] UnifiedPush 0.10.0 Release Scope Message-ID: Hi Folks, According to the roadmap, the UPS 0.10.0 released will be the 15/01, meaning next week ... Looking at the items still open in jira[1] , let's be realistic, all of them won't be included. If we take the current roadmap : 0.10.0 (Mid January 2014) - *User Management (1)* - *Admin UI fixes and improvements (2)* - *New Server Features* - Proxy Server Settings (3) - iOS silent messages (4) - IP Whitelisting (5) - Re-try of sending (6) - SendCriteria: Support device token (7) (1), (2) and (7) will probably make it. We already decided to move (3) for the next release. I was wondering about the other items, in particular (5) which is quite a big one. Any feedback welcome ! Sebi [1] http://bit.ly/1klX90Q -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140107/877bff10/attachment-0001.html From matzew at apache.org Tue Jan 7 03:31:01 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 7 Jan 2014 09:31:01 +0100 Subject: [aerogear-dev] UnifiedPush 0.10.0 Release Scope In-Reply-To: References: Message-ID: I am fine with moving 3 and 5 to some later release cycle. Both also need a UI based update, hence also we need Mockups. Looks like there was also nothing done in this direction so far. For 1) and 2), not sure what probably means, but it would be sad if it does not make it, especially these items are discussed since quite a long time -Matthias On Tue, Jan 7, 2014 at 8:53 AM, Sebastien Blanc wrote: > Hi Folks, > According to the roadmap, the UPS 0.10.0 released will be the 15/01, > meaning next week ... Looking at the items still open in jira[1] , let's be > realistic, all of them won't be included. > > If we take the current roadmap : > 0.10.0 (Mid January 2014) > > - > > *User Management (1)* > - > > *Admin UI fixes and improvements (2)* > - > > *New Server Features* > - > > Proxy Server Settings > (3) > - > > iOS silent messages (4) > - > > IP Whitelisting (5) > - > > Re-try of sending (6) > - > > SendCriteria: Support device token > (7) > > (1), (2) and (7) will probably make it. We already decided to move (3) > for the next release. > I was wondering about the other items, in particular (5) which is quite a > big one. Any feedback welcome ! > > Sebi > > [1] http://bit.ly/1klX90Q > > _______________________________________________ > 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/20140107/5d2722e7/attachment.html From scm.blanc at gmail.com Tue Jan 7 04:03:16 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 7 Jan 2014 10:03:16 +0100 Subject: [aerogear-dev] UnifiedPush 0.10.0 Release Scope In-Reply-To: References: Message-ID: On Tue, Jan 7, 2014 at 9:31 AM, Matthias Wessendorf wrote: > I am fine with moving 3 and 5 to some later release cycle. Both also need > a UI based update, hence also we need Mockups. Looks like there was also > nothing done in this direction so far. > > For 1) and 2), not sure what probably means, but it would be sad if it > does not make it, especially these items are discussed since quite a long > time > Let me rephrase it : 1) and 2) *will be part *of 0.10.0 ;) > > -Matthias > > > On Tue, Jan 7, 2014 at 8:53 AM, Sebastien Blanc wrote: > >> Hi Folks, >> According to the roadmap, the UPS 0.10.0 released will be the 15/01, >> meaning next week ... Looking at the items still open in jira[1] , let's be >> realistic, all of them won't be included. >> >> If we take the current roadmap : >> 0.10.0 (Mid January 2014) >> >> - >> >> *User Management (1)* >> - >> >> *Admin UI fixes and improvements (2)* >> - >> >> *New Server Features* >> - >> >> Proxy Server Settings >> (3) >> - >> >> iOS silent messages >> (4) >> - >> >> IP Whitelisting (5) >> - >> >> Re-try of sending (6) >> - >> >> SendCriteria: Support device token >> (7) >> >> (1), (2) and (7) will probably make it. We already decided to move (3) >> for the next release. >> I was wondering about the other items, in particular (5) which is quite a >> big one. Any feedback welcome ! >> >> Sebi >> >> [1] http://bit.ly/1klX90Q >> >> _______________________________________________ >> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140107/d6bbd45e/attachment.html From matzew at apache.org Tue Jan 7 06:33:54 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 7 Jan 2014 12:33:54 +0100 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: References: Message-ID: Something that also comes to mind is: If the UPS relies on KeyCloak, it's one more complex component that is required for the installation process. Meaning: At least a running server instance of Keycloak is required. Not sure if that helps in simplifying things :-) On Fri, Jan 3, 2014 at 1:52 PM, Matthias Wessendorf wrote: > Hello, > > it's nice to see an effort for integrating keycloak. Especially the User > Management part is something which sounds very promising. For instance I > like how a request against "http://push-abstractj.rhcloud.com/ag-push" > redirects me to the Keycloak server and after a sucessful login back to the > AdminUI. Sweet! > > I understand this is an early PoC, but the user login bits already look > good! > > > A few things I noticed: > > * After login, I get a list of PushApplications, but I can't click into > them to see details (I assume this is due to your changes to the ember > interface - with is perfectly fine) > * Sending Push Notifications (e.g. using the CURL command) does not work > (used the PushAppID/MasterSecret from the HTTP REST response on AdminUI > overview page ;-)) > I assume this is because the endpoint for sending is also protected by the > SSO/Keycloak facility, hence the HTTP Basic auth is not triggered there > (guess). > > Since the HTTP Basic is also used when a device tries to register against > a variant, I am guess the same issue is present there as well. > > Perhaps the HTTP-Basic for SENDING and DEVICE-REGISTRATION could be done > w/ something else, e.g. OAuth2 > > > > Greetings, > Matthias > > > > > > On Fri, Dec 20, 2013 at 1:11 PM, Bruno Oliveira wrote: > >> Good morning peeps, yesterday I started to replace AeroGear Security on >> Unified Push server by Keycloak and you might be asking: ?Why??. Keycloak >> is a SSO with some handy features like TOTP, OAuth2, user management >> support and I think we have too much to contribute, is the only way to have >> some success with security, ?divide to conquer" (at least for authorization >> and authentication). >> >> So will ag-security be discontinued? No! Keycloak is still on Alpha and >> we have to test it against our projects before fully replace ag-security, >> but the only way to upstream our needs, is to using it. >> >> This replacement only applies to authentication/authorization features, >> we still have a ton of projects which Keycloak is not able to replace like: >> TOTP, crypto and OAuth2 on mobile, our focus. >> >> - PoC >> >> So let?s talk about this replacement, any dependency on ag-security was >> removed from the push server and replaced by Keycloak: >> https://github.com/abstractj/aerogear-unifiedpush-server/tree/openshift >> >> Based on Keycloak examples, I just did copy & paste from one of the demos >> (https://github.com/abstractj/auth-server/tree/openshift) to create a >> server. Keycloak requires Resteasy 3.0.4, for this reason I had to manually >> replace some modules on JBoss. >> >> To test it go to: http://push-abstractj.rhcloud.com/ag-push/ you must be >> redirected to Keycloak, enter: >> >> username: john at doe.com >> password: password >> >> You must be redirected to agpush console, keep in mind that I took some >> shortcuts to get this demo working, so for example the create will fail >> because I removed everything related into the ember interface. >> >> Is also possible to enable TOTP, user?s registration and whatever you >> want. >> >> So what do you think? >> >> -- >> abstractj >> >> _______________________________________________ >> 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 > -- 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/20140107/067d774f/attachment-0001.html From bruno at abstractj.org Tue Jan 7 06:54:09 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 7 Jan 2014 09:54:09 -0200 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: References: Message-ID: I can't see any huge problem on relying in an external project if we provide instructions about how to use it. Keycloak is a project completely focused on SSO, user management, auth methods and most of the needs required for AeroGear. I don?t want to reinvent a SSO inside UPS, that?s the reason why we should look at this. The project is still Alpha, so of course is necessary be cautious and check what?s missing.? -- abstractj On January 7, 2014 at 9:34:02 AM, Matthias Wessendorf (matzew at apache.org) wrote: > > Something that also comes to mind is: If the UPS relies on KeyCloak, > it's one more complex component that is required for the installation > process. Meaning: At least a running server instance of Keycloak > is required. Not sure if that helps in simplifying things :-) From kpiwko at redhat.com Tue Jan 7 07:13:44 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Tue, 7 Jan 2014 13:13:44 +0100 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: References: Message-ID: <20140107131344.03fd7bf0@kapy-ntb-x220> That should not be that difficult, only steps needed are updating RESTEasy (in AS/EAP, not sure what version is in WF) and deploying more than a single WAR to the server along to UPS. Pretty similar to steps used in keycloak examples: https://github.com/kpiwko/keycloak/commit/2c93f787b60c0ec1f437983c83b79aff4a593f90 That said, it might make our OpenShift cartridge setup more complicated but again that's not something users(read consumers) should hit. Karel On Tue, 7 Jan 2014 12:33:54 +0100 Matthias Wessendorf wrote: > Something that also comes to mind is: If the UPS relies on KeyCloak, it's > one more complex component that is required for the installation process. > Meaning: At least a running server instance of Keycloak is required. Not > sure if that helps in simplifying things :-) > > > On Fri, Jan 3, 2014 at 1:52 PM, Matthias Wessendorf wrote: > > > Hello, > > > > it's nice to see an effort for integrating keycloak. Especially the User > > Management part is something which sounds very promising. For instance I > > like how a request against "http://push-abstractj.rhcloud.com/ag-push" > > redirects me to the Keycloak server and after a sucessful login back to the > > AdminUI. Sweet! > > > > I understand this is an early PoC, but the user login bits already look > > good! > > > > > > A few things I noticed: > > > > * After login, I get a list of PushApplications, but I can't click into > > them to see details (I assume this is due to your changes to the ember > > interface - with is perfectly fine) > > * Sending Push Notifications (e.g. using the CURL command) does not work > > (used the PushAppID/MasterSecret from the HTTP REST response on AdminUI > > overview page ;-)) > > I assume this is because the endpoint for sending is also protected by the > > SSO/Keycloak facility, hence the HTTP Basic auth is not triggered there > > (guess). > > > > Since the HTTP Basic is also used when a device tries to register against > > a variant, I am guess the same issue is present there as well. > > > > Perhaps the HTTP-Basic for SENDING and DEVICE-REGISTRATION could be done > > w/ something else, e.g. OAuth2 > > > > > > > > Greetings, > > Matthias > > > > > > > > > > > > On Fri, Dec 20, 2013 at 1:11 PM, Bruno Oliveira wrote: > > > >> Good morning peeps, yesterday I started to replace AeroGear Security on > >> Unified Push server by Keycloak and you might be asking: ?Why??. Keycloak > >> is a SSO with some handy features like TOTP, OAuth2, user management > >> support and I think we have too much to contribute, is the only way to have > >> some success with security, ?divide to conquer" (at least for authorization > >> and authentication). > >> > >> So will ag-security be discontinued? No! Keycloak is still on Alpha and > >> we have to test it against our projects before fully replace ag-security, > >> but the only way to upstream our needs, is to using it. > >> > >> This replacement only applies to authentication/authorization features, > >> we still have a ton of projects which Keycloak is not able to replace like: > >> TOTP, crypto and OAuth2 on mobile, our focus. > >> > >> - PoC > >> > >> So let?s talk about this replacement, any dependency on ag-security was > >> removed from the push server and replaced by Keycloak: > >> https://github.com/abstractj/aerogear-unifiedpush-server/tree/openshift > >> > >> Based on Keycloak examples, I just did copy & paste from one of the demos > >> (https://github.com/abstractj/auth-server/tree/openshift) to create a > >> server. Keycloak requires Resteasy 3.0.4, for this reason I had to manually > >> replace some modules on JBoss. > >> > >> To test it go to: http://push-abstractj.rhcloud.com/ag-push/ you must be > >> redirected to Keycloak, enter: > >> > >> username: john at doe.com > >> password: password > >> > >> You must be redirected to agpush console, keep in mind that I took some > >> shortcuts to get this demo working, so for example the create will fail > >> because I removed everything related into the ember interface. > >> > >> Is also possible to enable TOTP, user?s registration and whatever you > >> want. > >> > >> So what do you think? > >>https://github.com/kpiwko/keycloak/commit/2c93f787b60c0ec1f437983c83b79aff4a593f90 > >> -- > >> abstractj > >> > >> _______________________________________________ > >> 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 > > > > > From supittma at redhat.com Tue Jan 7 09:17:48 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 07 Jan 2014 09:17:48 -0500 Subject: [aerogear-dev] Android and JDK 1.6 Message-ID: <52CC0C8C.6070601@redhat.com> Karel brought up the fact that the Android project relies on classes from Java 7. I would like for the Android project to compile using JDK 6, but I was wondering what the rest of the project thought. For a little back story, until recently the dexer (Android Java byte code to Dex byte code compiler) could only consume Java 6 byte code. That was very recently fixed and almost all Java 7 features are supported on Android version greater than Gingerbread. The exception is try with resources which is only supported on KitKat. I havn't looked at the project yet to even get an idea for how much work it would be, but I suspect it will be rather minimal. From supittma at redhat.com Tue Jan 7 09:21:28 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 07 Jan 2014 09:21:28 -0500 Subject: [aerogear-dev] sync spec strawman Message-ID: <52CC0D68.6030305@redhat.com> I've updated the sync spec on the data-sync branch on aerogear.org with what qmx posted yesterday and some ideas I had as well. If I don't get any tomatoes I will try to see what a POC on Android looks like this afternoon. Sync doc follows. # Status: Experimental # AeroGear Data Sync ## basics? Since we've been catering the enterprise market, this essentially means we need to get the __boring__ stuff right first, then move over to the __shiny__ stuff, like realtime data sync, update policies & friends. ### data model For starters, I think that the most important thing that needs to be agreed upon is the data model and the atomic operations around it. As previous discussed, I really like CouchDB's datamodel -- and hate erlang ;) `{_id:, content:, rev:}` #### JS Well, it's JSON, it _Just Works_™ #### Java I didn't want to pick on Java, but since its fame forces me to it. First stab (a courtesy of our friend Dan Bevenius): public interface Document { public String id; public String content; public String rev; } We naturally want to kick this a notch, and use objects instead of plain strings: public interface Document { public ID id; public T content; public String rev; } In this case, we can use the convention requiring that `T` is any **object serializable to JSON**. `ID` is a convenience shorthand since it's a **GUID/UUID**. I think this key isn't necessarily a natural key (a surrogate key instead). #### Objective-C volunteers needed ;) ### Transactions These are the most basic parts of sync I can think of that our system should be able to do/manage. Our internal representation of the client documents and collections should make implementing this automatically and without user intervention as simple as possible * Detect Change When a user changes her local data, the system should note the change and generate a sync message to send to the server. This can be done automatically or manually but SHOULD be done automatically. * Send update When a sync message is ready to be sent, and the system allows for it to be sent (network available, not in blackout window from exponential backoff, etc) then sync message should be sent. This being done automatically should be the default, but the developer can override this behavior. * Receive Update When a client updates it data and successfully syncs to the remote server, the remote server will notify all of the relevant clients. The client must automatically and without user intervention receive this update and either act on it or store it for later processing. * Apply Update Once a client application has an update message from the server, it can apply the message correctly to the data on it. This should be done automatically as part of receiving the update, but it may be done manually or may be delayed and automatically executed later. * Detect Conflict When applying an update fails, the system must detect this. The system will provide state to the application and/or the user to handle the conflict. The user MUST NOT have to check for conflicts on her own. * Resolve Conflict There must be a mechanism for resolving a conflict. The CAN be done automatically using default resolvers provided by AeroGear, by using a resolver provided by the developer/user, or by the app user selecting the correct merge. This will possibly generate a new sync message. ### API levels As soon as we have a rough data-model defined, we can start dabbling around different API levels to be served: (parts **I think** are potentially deliverable for a 1.0) - level 0: explodes when there's a conflict - level 1: semi-automatic conflict resolution via something like google's diff-match-patch - level 2: business rules determine who wins a conflicting update (supervisor wins over normal user) (parts **I think** are potentially deliverable for a 2.0) - level 3: real-time updates via diff-match-patch - level 4: real-time updates via OT/EC All those proposed API operations should be serializable, meaning I can potentially keep doing changes offline then just replying them to the server when online. ### transport Since we know about the future-looking ideas on v2.0, it would be really nice for us to specify a very simple/dumb JSON-based protocol for those change messages. Something that could accomodate both the full document updates and the OT/EC incremental bits too. I have no ideas on this, tbh. #### Strawman - Summers {id : Object, data : String, checksum: long} **id** : This is the global identifier for the object. This field is optional. **data** : This is the sync data for the application. It may be a diff, a whole object, etc. This field is required. **checksum** : This is the client's idea of what a known good sync will look like. If, post merge, the server's checksum and client's check sum do not match then the client is out of sync and must resync and handle the conflict. ## Appendix Use Cases: Here are a few contrived use cases that we may want to keep in mind. 1. Legacy Bug Trackers From Hell a. It is a webapp written in COBOL, no one will ever EVER update or change the code b. It has TONS of legacy but important data c. It has TONS of users d. It only has a few transactions per day, all creating and updating bug reports e. Multiple users can edit the same report 2. Slacker Gallery a. Each User has a multiple galleries, each gallery has multiple photos b. A Gallery has only one user, but the user may be on multiple devices c. Galleries may be renamed, created, and deleted d. Photos may only be created or deleted. Photos also have meta data which may be updated, but its creation and deletion is tied to the Photo object. 3. Dropbox clone a. A folder of files may be shared among users b. There is a size limit to files and how much storage may be used per folder c. Files are not updated. If there is a new file, there is an atomic delete and create operation 4. Email client a. This is an AG-controller which accesses a mail account. b. There are mobile offline and sync enabled clients which connect to this controller. 5. Google Docs clone a. Operational Transform out the wazzoo b. What would the server need? c. What would the client need? 6. Building Inspector app Building inspector system - we have mobile apps that store relevant info and are bound to be accessed on places where we won't have any kind of connection, or very poor signal. You can have several inspectors screening the same building simultaneously. Let's say we have Agnes and Joe are doing the fire extinguisher inspection in a new hospital building. Technically each fire extinguisher has its own identifier and can be an independent document. In this case we would have no conflict happening. Now they start finding expired fire extinguishers and start to add them to the report. This report could potentially have two divergent lists of fire extinguishers to be replenished/revalidated, as the building's compliance status. 7. Census App Census system - we have mobile apps focused on offline data collection. We have the previous year's info that needs to be updated on the server. The interviewee needs to take a call, then asks the interviewer to come back later. This results in two sets of changes for the same document, stacked together, which should work flawlessly. # Appendix Reference (Open Source) Products: - Wave-in-a-box - CouchDB - Google Drive RealtimeAPI - [diff-merge-patch algorithm](http://code.google.com/p/google-diff-match-patch/) - [Summers' Realtime Sync Demo](http://www.youtube.com/watch?v=WEkZGbVk4Lc) - [Summers' Devnexus Sync Demo](https://plus.google.com/103442292643366117394/posts/HGVHwtPArPW) - Google Android Sync Architecture From daniel at passos.me Tue Jan 7 10:50:18 2014 From: daniel at passos.me (Daniel Passos) Date: Tue, 7 Jan 2014 13:50:18 -0200 Subject: [aerogear-dev] Android and JDK 1.6 In-Reply-To: <52CC0C8C.6070601@redhat.com> References: <52CC0C8C.6070601@redhat.com> Message-ID: I don?t see any problem for use 1.6 or 1.7 --? Daniel Passos On January 7, 2014 at 12:18:05 PM, Summers Pittman (supittma at redhat.com) wrote: Karel brought up the fact that the Android project relies on classes from Java 7. I would like for the Android project to compile using JDK 6, but I was wondering what the rest of the project thought. For a little back story, until recently the dexer (Android Java byte code to Dex byte code compiler) could only consume Java 6 byte code. That was very recently fixed and almost all Java 7 features are supported on Android version greater than Gingerbread. The exception is try with resources which is only supported on KitKat. I havn't looked at the project yet to even get an idea for how much work it would be, but I suspect it will be rather minimal. _______________________________________________ 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/20140107/3ed26cda/attachment.html From lholmqui at redhat.com Tue Jan 7 11:32:22 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 7 Jan 2014 11:32:22 -0500 Subject: [aerogear-dev] Browser Targets Message-ID: <79E19B64-A584-4821-A1BA-EA3B49E08344@redhat.com> So after looking at the Global stats for browsers( desktop ), it looks like IE 9 is below 4% I think we need to consider dropping this support. I've been +9001 from the beginning but now that it is this low, i'm +9002 on this same topic, what % should we be looking at when thinking about dropping support for other platforms, like android and iOS link to the stats: http://gs.statcounter.com/#browser_version_partially_combined-ww-monthly-201212-201312 From matzew at apache.org Tue Jan 7 11:43:57 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 7 Jan 2014 17:43:57 +0100 Subject: [aerogear-dev] Browser Targets In-Reply-To: <79E19B64-A584-4821-A1BA-EA3B49E08344@redhat.com> References: <79E19B64-A584-4821-A1BA-EA3B49E08344@redhat.com> Message-ID: On Tue, Jan 7, 2014 at 5:32 PM, Lucas Holmquist wrote: > So after looking at the Global stats for browsers( desktop ), it looks > like IE 9 is below 4% > +1 on dropping that; off topic: This would also help us regarding PouchDB, right ? I think I recall there was something working only IE 10+ > > I think we need to consider dropping this support. I've been +9001 from > the beginning but now that it is this low, i'm +9002 > > > on this same topic, what % should we be looking at when thinking about > dropping support for other platforms, like android and iOS > +1 > > link to the stats: > > http://gs.statcounter.com/#browser_version_partially_combined-ww-monthly-201212-201312 thx for sharing > > _______________________________________________ > 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/20140107/f3afb37f/attachment.html From supittma at redhat.com Tue Jan 7 11:45:22 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 07 Jan 2014 11:45:22 -0500 Subject: [aerogear-dev] Browser Targets In-Reply-To: <79E19B64-A584-4821-A1BA-EA3B49E08344@redhat.com> References: <79E19B64-A584-4821-A1BA-EA3B49E08344@redhat.com> Message-ID: <52CC2F22.7040200@redhat.com> On 01/07/2014 11:32 AM, Lucas Holmquist wrote: > So after looking at the Global stats for browsers( desktop ), it looks like IE 9 is below 4% > > I think we need to consider dropping this support. I've been +9001 from the beginning but now that it is this low, i'm +9002 > > > on this same topic, what % should we be looking at when thinking about dropping support for other platforms, like android and iOS > > link to the stats: > http://gs.statcounter.com/#browser_version_partially_combined-ww-monthly-201212-201312 Wrt Android, when we can drop Gingerbread and still support 85% of Android devices we should put dropping Gingerbread on our roadmap. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From kpiwko at redhat.com Tue Jan 7 11:59:16 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Tue, 7 Jan 2014 17:59:16 +0100 Subject: [aerogear-dev] Android and JDK 1.6 In-Reply-To: <52CC0C8C.6070601@redhat.com> References: <52CC0C8C.6070601@redhat.com> Message-ID: <20140107175916.0cf31252@kapy-ntb-x220> The more stuff we can get running on JDK 1.6, the better. However, there is no reason to ride roughshod over functionality we *need* available only in JDK7 but such cases must be known, documented and should not be cluttering usage experience. If that helps, I can create AEROGEAR jira to add animal-sniffer-plugin [1] to aerogear-parent to ensure projects are using API JDK of a specific version (configurable per project) and send PR. Karel [1] http://mojo.codehaus.org/animal-sniffer-maven-plugin/usage.html On Tue, 07 Jan 2014 09:17:48 -0500 Summers Pittman wrote: > Karel brought up the fact that the Android project relies on classes > from Java 7. I would like for the Android project to compile using JDK > 6, but I was wondering what the rest of the project thought. > > For a little back story, until recently the dexer (Android Java byte > code to Dex byte code compiler) could only consume Java 6 byte code. > That was very recently fixed and almost all Java 7 features are > supported on Android version greater than Gingerbread. The exception is > try with resources which is only supported on KitKat. > > I havn't looked at the project yet to even get an idea for how much work > it would be, but I suspect it will be rather minimal. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From bruno at abstractj.org Wed Jan 8 03:49:21 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 8 Jan 2014 06:49:21 -0200 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: <20140107131344.03fd7bf0@kapy-ntb-x220> References: <20140107131344.03fd7bf0@kapy-ntb-x220> Message-ID: Hijacking the thread, maybe we can think about a keycloak cartridge on OpenShift in the future. Wdyt? -- abstractj On January 7, 2014 at 10:13:52 AM, Karel Piwko (kpiwko at redhat.com) wrote: > > That said, it might make our OpenShift cartridge setup more > complicated but > again that's not something users(read consumers) should hit. > > Karel From matzew at apache.org Wed Jan 8 03:51:19 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 8 Jan 2014 09:51:19 +0100 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: References: <20140107131344.03fd7bf0@kapy-ntb-x220> Message-ID: On Wed, Jan 8, 2014 at 9:49 AM, Bruno Oliveira wrote: > Hijacking the thread, maybe we can think about a keycloak cartridge on > OpenShift in the future. > +1 I'd like that > > Wdyt? > > -- > abstractj > > On January 7, 2014 at 10:13:52 AM, Karel Piwko (kpiwko at redhat.com) wrote: > > > That said, it might make our OpenShift cartridge setup more > > complicated but > > again that's not something users(read consumers) should hit. > > > > Karel > > _______________________________________________ > 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/20140108/9518e67e/attachment.html From scm.blanc at gmail.com Wed Jan 8 03:54:19 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 8 Jan 2014 09:54:19 +0100 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: References: <20140107131344.03fd7bf0@kapy-ntb-x220> Message-ID: +9001 , really like this idea. On Wed, Jan 8, 2014 at 9:49 AM, Bruno Oliveira wrote: > Hijacking the thread, maybe we can think about a keycloak cartridge on > OpenShift in the future. > > Wdyt? > > -- > abstractj > > On January 7, 2014 at 10:13:52 AM, Karel Piwko (kpiwko at redhat.com) wrote: > > > That said, it might make our OpenShift cartridge setup more > > complicated but > > again that's not something users(read consumers) should hit. > > > > Karel > > _______________________________________________ > 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/20140108/e9e6d5bc/attachment.html From cvasilak at gmail.com Wed Jan 8 03:57:10 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Wed, 8 Jan 2014 10:57:10 +0200 Subject: [aerogear-dev] Browser Targets In-Reply-To: <52CC2F22.7040200@redhat.com> References: <79E19B64-A584-4821-A1BA-EA3B49E08344@redhat.com> <52CC2F22.7040200@redhat.com> Message-ID: <2EEB455F-F714-453B-9920-750DC897C192@gmail.com> according to stats iOS 7 is soon to become king (78%) but my view is that it makes sense to target iOS 6 and iOS 7 in this ?conversion? period (it won?t take long though as apple history taught us) - Christos [1] http://appleinsider.com/articles/13/12/31/ios-7-now-installed-on-78-of-active-apple-handheld-devices On Jan 7, 2014, at 6:45 PM, Summers Pittman wrote: > On 01/07/2014 11:32 AM, Lucas Holmquist wrote: >> So after looking at the Global stats for browsers( desktop ), it looks like IE 9 is below 4% >> >> I think we need to consider dropping this support. I've been +9001 from the beginning but now that it is this low, i'm +9002 >> >> >> on this same topic, what % should we be looking at when thinking about dropping support for other platforms, like android and iOS >> >> link to the stats: >> http://gs.statcounter.com/#browser_version_partially_combined-ww-monthly-201212-201312 > > Wrt Android, when we can drop Gingerbread and still support 85% of > Android devices we should put dropping Gingerbread on our roadmap. > >> _______________________________________________ >> 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 kpiwko at redhat.com Wed Jan 8 04:04:34 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Wed, 8 Jan 2014 10:04:34 +0100 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: References: <20140107131344.03fd7bf0@kapy-ntb-x220> Message-ID: <20140108100434.738dc940@kapy-ntb-x220> Keycloak cartridge is already in progress, based on top of WF 8.0.0.CR1: https://issues.jboss.org/browse/KEYCLOAK-78 CC'ed keycloak-dev. Maybe if we join our cartridge efforts, it could be beneficial to everybody. Karel On Wed, 8 Jan 2014 09:51:19 +0100 Matthias Wessendorf wrote: > On Wed, Jan 8, 2014 at 9:49 AM, Bruno Oliveira wrote: > > > Hijacking the thread, maybe we can think about a keycloak cartridge on > > OpenShift in the future. > > > > +1 I'd like that > > > > > > Wdyt? > > > > -- > > abstractj > > > > On January 7, 2014 at 10:13:52 AM, Karel Piwko (kpiwko at redhat.com) wrote: > > > > That said, it might make our OpenShift cartridge setup more > > > complicated but > > > again that's not something users(read consumers) should hit. > > > > > > Karel > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > From bruno at abstractj.org Wed Jan 8 04:56:05 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 8 Jan 2014 07:56:05 -0200 Subject: [aerogear-dev] sync spec strawman In-Reply-To: <52CC0D68.6030305@redhat.com> References: <52CC0D68.6030305@redhat.com> Message-ID: Good morning Summers, I was reviewing the whole document and I think is the great start. Either way that looked a bit confuse to me, so here comes my attempt to reorganize it (is just a suggestion): https://github.com/aerogear/aerogear.org/pull/227 Another change that I would suggest is the inclusion of the field ?revision? like Qmx already suggested, with your idea of the checksum. And also the inclusion of the field ?signature? to make sure that data is not corrupted or tampered. Thoughts?? -- abstractj On January 7, 2014 at 12:21:35 PM, Summers Pittman (supittma at redhat.com) wrote: > > I've updated the sync spec on the data-sync branch on aerogear.org > with > what qmx posted yesterday and some ideas I had as well. If I don't > get > any tomatoes I will try to see what a POC on Android looks like this > afternoon. > > Sync doc follows. > > # Status: Experimental > > # AeroGear Data Sync > > > ## basics? > > Since we've been catering the enterprise market, this essentially > means > we need to get the __boring__ stuff right first, then move over > to the > __shiny__ stuff, like realtime data sync, update policies & > friends. > > ### data model > > For starters, I think that the most important thing that needs > to be > agreed upon is the data model and the atomic operations around > it. As > previous discussed, I really like CouchDB's datamodel -- and > hate erlang ;) > > `{_id:, content:, rev:}` > > #### JS > > Well, it's JSON, it _Just Works_? > > #### Java > > I didn't want to pick on Java, but since its fame forces me to it. > First > stab (a courtesy of our friend Dan Bevenius): > > public interface Document { > public String id; > public String content; > public String rev; > } > > We naturally want to kick this a notch, and use objects instead > of plain > strings: > > public interface Document { > public ID id; > public T content; > public String rev; > } > > In this case, we can use the convention requiring that `T` is any > **object serializable to JSON**. `ID` is a convenience shorthand > since > it's a **GUID/UUID**. I think this key isn't necessarily a natural > key > (a surrogate key instead). > > #### Objective-C > > volunteers needed ;) > > ### Transactions > > These are the most basic parts of sync I can think of that our system > should be able to do/manage. Our internal representation of > the client > documents and collections should make implementing this automatically > and without user intervention as simple as possible > > * Detect Change > > When a user changes her local data, the system should note the > change and generate a sync message to send to the server. This > can be > done automatically or manually but SHOULD be done automatically. > > * Send update > > When a sync message is ready to be sent, and the system allows for > it to be sent (network available, not in blackout window from > exponential backoff, etc) then sync message should be sent. > This being > done automatically should be the default, but the developer > can override > this behavior. > > * Receive Update > > When a client updates it data and successfully syncs to the remote > server, the remote server will notify all of the relevant clients. > The > client must automatically and without user intervention receive > this > update and either act on it or store it for later processing. > > * Apply Update > > Once a client application has an update message from the server, > it > can apply the message correctly to the data on it. This should > be done > automatically as part of receiving the update, but it may be done > manually or may be delayed and automatically executed later. > > * Detect Conflict > > When applying an update fails, the system must detect this. The > system will provide state to the application and/or the user > to handle > the conflict. The user MUST NOT have to check for conflicts on > her own. > > * Resolve Conflict > > There must be a mechanism for resolving a conflict. The CAN be > done automatically using default resolvers provided by AeroGear, > by > using a resolver provided by the developer/user, or by the app > user > selecting the correct merge. This will possibly generate a new > sync > message. > > > ### API levels > > As soon as we have a rough data-model defined, we can start dabbling > around different API levels to be served: > > (parts **I think** are potentially deliverable for a 1.0) > > - level 0: explodes when there's a conflict > - level 1: semi-automatic conflict resolution via something > like > google's diff-match-patch > - level 2: business rules determine who wins a conflicting update > (supervisor wins over normal user) > > (parts **I think** are potentially deliverable for a 2.0) > > - level 3: real-time updates via diff-match-patch > - level 4: real-time updates via OT/EC > > All those proposed API operations should be serializable, meaning > I can > potentially keep doing changes offline then just replying them > to the > server when online. > > ### transport > > Since we know about the future-looking ideas on v2.0, it would > be really > nice for us to specify a very simple/dumb JSON-based protocol > for those > change messages. Something that could accomodate both the full > document > updates and the OT/EC incremental bits too. I have no ideas on > this, tbh. > > #### Strawman - Summers > > {id : Object, data : String, checksum: long} > > **id** : > This is the global identifier for the object. This field is optional. > > **data** : > This is the sync data for the application. It may be a diff, a whole > object, etc. This field is required. > > **checksum** : > This is the client's idea of what a known good sync will look like. > If, post merge, the server's checksum and client's check sum > do not > match then the client is out of sync and must resync and handle > the > conflict. > > > > ## Appendix Use Cases: > > > Here are a few contrived use cases that we may want to keep in mind. > > 1. Legacy Bug Trackers From Hell > > a. It is a webapp written in COBOL, no one will ever EVER update > or > change the code > > b. It has TONS of legacy but important data > > c. It has TONS of users > > d. It only has a few transactions per day, all creating and > updating > bug reports > > e. Multiple users can edit the same report > > > 2. Slacker Gallery > > a. Each User has a multiple galleries, each gallery has multiple > photos > > b. A Gallery has only one user, but the user may be on multiple > devices > > c. Galleries may be renamed, created, and deleted > > d. Photos may only be created or deleted. Photos also have meta > data > which may be updated, but its creation and deletion is tied to > the Photo > object. > > > 3. Dropbox clone > > a. A folder of files may be shared among users > > b. There is a size limit to files and how much storage may be used > per folder > > c. Files are not updated. If there is a new file, there is an > atomic > delete and create operation > > > 4. Email client > > a. This is an AG-controller which accesses a mail account. > > b. There are mobile offline and sync enabled clients which connect > to this controller. > > > 5. Google Docs clone > > a. Operational Transform out the wazzoo > > b. What would the server need? > > c. What would the client need? > > > 6. Building Inspector app > > Building inspector system - we have mobile apps that store relevant > info > and are bound to be accessed on places where we won't have any kind > of > connection, or very poor signal. > > You can have several inspectors screening the same building > simultaneously. > > Let's say we have Agnes and Joe are doing the fire extinguisher > inspection in a new hospital building. Technically each fire > extinguisher has its own identifier and can be an independent > document. > In this case we would have no conflict happening. > > Now they start finding expired fire extinguishers and start > to add them > to the report. This report could potentially have two divergent > lists of > fire extinguishers to be replenished/revalidated, as the building's > compliance status. > > 7. Census App > > Census system - we have mobile apps focused on offline data collection. > We have the previous year's info that needs to be updated on the > server. > The interviewee needs to take a call, then asks the interviewer > to come > back later. This results in two sets of changes for the same document, > stacked together, which should work flawlessly. > > > # Appendix Reference (Open Source) Products: > > > - Wave-in-a-box > > - CouchDB > > - Google Drive RealtimeAPI > > - [diff-merge-patch > algorithm](http://code.google.com/p/google-diff-match-patch/) > > - [Summers' Realtime Sync Demo](http://www.youtube.com/watch?v=WEkZGbVk4Lc) > > - [Summers' Devnexus Sync > Demo](https://plus.google.com/103442292643366117394/posts/HGVHwtPArPW) > > - Google Android Sync Architecture > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > From edewit at redhat.com Wed Jan 8 05:28:08 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Wed, 8 Jan 2014 11:28:08 +0100 Subject: [aerogear-dev] Browser Targets In-Reply-To: <79E19B64-A584-4821-A1BA-EA3B49E08344@redhat.com> References: <79E19B64-A584-4821-A1BA-EA3B49E08344@redhat.com> Message-ID: <9682E781-175D-4BD7-A193-1593509416D8@redhat.com> > > on this same topic, what % should we be looking at when thinking about dropping support for other platforms, like android and iOS Don?t think we should have a hard (written in stone) rule, but try and to be pragmatic about what we support. Because if 10% would be the limit for browsers we could drop IE support all together ;) From tkriz at redhat.com Wed Jan 8 05:51:23 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Wed, 8 Jan 2014 11:51:23 +0100 Subject: [aerogear-dev] [aerogear-android] DataManager API inconsistency + solution Message-ID: Hey everyone, I?ve been recently going through the DataManager API in aerogear-android. In this email, I?d like to suggest addiction of two method (or possibly three) into the `Store` interface. These would be: ```java /** * If store is open, it can be read or written to. */ boolean isOpen(); /** * Opens store in current thread (blocking). */ Store open(); /** * Opens store in background thread and then callback#onSuccess is called. */ void open(Callback> callback); ``` >From my point of view, this makes sense to be in the `Store` so I can switch between stores easily during development with no need to change other code. Also, if `read` or `write` operations are done with closed store, there are two possible workflows. First one is, that I?d fail and throw an exception. Second (and for me a preferred one) is, that all those methods would internally check if the store is open and if not, they?d call the `open` method. This also leads me to another API change for `Store`. ```java /** * Reads all the data from the underlying storage system asynchronously. */ void readAll(Callback> callback); /** * Reads a specific object/record from the underlying storage system asynchronously. */ void read(Serializable id, Callback callback); /** * Search for objects/records from the underlying storage system asynchronously. */ void readWithFilter(ReadFilter filter, Callback> callback); /** * Saves the given object in the underlying storage system asynchronously. */ void save(T item, Callback callback); /** * Resets the entire storage system asynchronously. */ void reset(Callback callback); /** * Removes a specific object/record from the underlying storage system asynchronously. */ void remove(Serializable id, Callback callback); /** * Checks if the storage system contains no stored elements asynchronously. */ void isEmpty(Callback callback); ``` That?s right, async methods for easy access to the storage from background thread, without the pain of writing it myself (for example, it makes no sense if I want to just call `store.save(..)` and I?d have to write all the `AsyncTask` boilerplate). So, what do you think? PS: You can find the whole text with highlighted syntax here: ? Tadeas Kriz tkriz at redhat.com From tkriz at redhat.com Wed Jan 8 05:53:47 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Wed, 8 Jan 2014 11:53:47 +0100 Subject: [aerogear-dev] [aerogear-android] DataManager API inconsistency + solution In-Reply-To: References: Message-ID: <46966149-A653-4112-BE3E-5D8C258704A6@redhat.com> Forgot to include the link to gist: https://gist.github.com/TadeasKriz/499e8ae51102887a38ae ? Tadeas Kriz tkriz at redhat.com On 08 Jan 2014, at 11:51, Tadeas Kriz wrote: > Hey everyone, > > I?ve been recently going through the DataManager API in aerogear-android. In this email, I?d like to suggest addiction of two method (or possibly three) into the `Store` interface. These would be: > > ```java > /** > * If store is open, it can be read or written to. > */ > boolean isOpen(); > > /** > * Opens store in current thread (blocking). > */ > Store open(); > > /** > * Opens store in background thread and then callback#onSuccess is called. > */ > void open(Callback> callback); > ``` > > From my point of view, this makes sense to be in the `Store` so I can switch between stores easily during development with no need to change other code. Also, if `read` or `write` operations are done with closed store, there are two possible workflows. First one is, that I?d fail and throw an exception. Second (and for me a preferred one) is, that all those methods would internally check if the store is open and if not, they?d call the `open` method. This also leads me to another API change for `Store`. > > ```java > /** > * Reads all the data from the underlying storage system asynchronously. > */ > void readAll(Callback> callback); > > /** > * Reads a specific object/record from the underlying storage system asynchronously. > */ > void read(Serializable id, Callback callback); > > /** > * Search for objects/records from the underlying storage system asynchronously. > */ > void readWithFilter(ReadFilter filter, Callback> callback); > > /** > * Saves the given object in the underlying storage system asynchronously. > */ > void save(T item, Callback callback); > > /** > * Resets the entire storage system asynchronously. > */ > void reset(Callback callback); > > /** > * Removes a specific object/record from the underlying storage system asynchronously. > */ > void remove(Serializable id, Callback callback); > > /** > * Checks if the storage system contains no stored elements asynchronously. > */ > void isEmpty(Callback callback); > ``` > > That?s right, async methods for easy access to the storage from background thread, without the pain of writing it myself (for example, it makes no sense if I want to just call `store.save(..)` and I?d have to write all the `AsyncTask` boilerplate). > > So, what do you think? > > PS: You can find the whole text with highlighted syntax here: > > ? > Tadeas Kriz > tkriz at redhat.com > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140108/decd35da/attachment.html From matzew at apache.org Wed Jan 8 07:41:37 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 8 Jan 2014 13:41:37 +0100 Subject: [aerogear-dev] sync spec strawman In-Reply-To: References: <52CC0D68.6030305@redhat.com> Message-ID: On Wed, Jan 8, 2014 at 10:56 AM, Bruno Oliveira wrote: > Good morning Summers, I was reviewing the whole document and I think is > the great start. Either way that looked a bit confuse to me, so here comes > my attempt to reorganize it (is just a suggestion): > https://github.com/aerogear/aerogear.org/pull/227 thanks for putting the PR together - reads fine so far > > > Another change that I would suggest is the inclusion of the field > ?revision? like Qmx already suggested, with your idea of the checksum. And > also the inclusion of the field ?signature? to make sure that data is not > corrupted or tampered. > that sounds reasonable to me > > Thoughts? > > -- > abstractj > > On January 7, 2014 at 12:21:35 PM, Summers Pittman (supittma at redhat.com) > wrote: > > > > I've updated the sync spec on the data-sync branch on aerogear.org > > with > > what qmx posted yesterday and some ideas I had as well. If I don't > > get > > any tomatoes I will try to see what a POC on Android looks like this > > afternoon. > > > > Sync doc follows. > > > > # Status: Experimental > > > > # AeroGear Data Sync > > > > > > ## basics? > > > > Since we've been catering the enterprise market, this essentially > > means > > we need to get the __boring__ stuff right first, then move over > > to the > > __shiny__ stuff, like realtime data sync, update policies & > > friends. > > > > ### data model > > > > For starters, I think that the most important thing that needs > > to be > > agreed upon is the data model and the atomic operations around > > it. As > > previous discussed, I really like CouchDB's datamodel -- and > > hate erlang ;) > > > > `{_id:, content:, rev:}` > > > > #### JS > > > > Well, it's JSON, it _Just Works_? > > > > #### Java > > > > I didn't want to pick on Java, but since its fame forces me to it. > > First > > stab (a courtesy of our friend Dan Bevenius): > > > > public interface Document { > > public String id; > > public String content; > > public String rev; > > } > > > > We naturally want to kick this a notch, and use objects instead > > of plain > > strings: > > > > public interface Document { > > public ID id; > > public T content; > > public String rev; > > } > > > > In this case, we can use the convention requiring that `T` is any > > **object serializable to JSON**. `ID` is a convenience shorthand > > since > > it's a **GUID/UUID**. I think this key isn't necessarily a natural > > key > > (a surrogate key instead). > > > > #### Objective-C > > > > volunteers needed ;) > > > > ### Transactions > > > > These are the most basic parts of sync I can think of that our system > > should be able to do/manage. Our internal representation of > > the client > > documents and collections should make implementing this automatically > > and without user intervention as simple as possible > > > > * Detect Change > > > > When a user changes her local data, the system should note the > > change and generate a sync message to send to the server. This > > can be > > done automatically or manually but SHOULD be done automatically. > > > > * Send update > > > > When a sync message is ready to be sent, and the system allows for > > it to be sent (network available, not in blackout window from > > exponential backoff, etc) then sync message should be sent. > > This being > > done automatically should be the default, but the developer > > can override > > this behavior. > > > > * Receive Update > > > > When a client updates it data and successfully syncs to the remote > > server, the remote server will notify all of the relevant clients. > > The > > client must automatically and without user intervention receive > > this > > update and either act on it or store it for later processing. > > > > * Apply Update > > > > Once a client application has an update message from the server, > > it > > can apply the message correctly to the data on it. This should > > be done > > automatically as part of receiving the update, but it may be done > > manually or may be delayed and automatically executed later. > > > > * Detect Conflict > > > > When applying an update fails, the system must detect this. The > > system will provide state to the application and/or the user > > to handle > > the conflict. The user MUST NOT have to check for conflicts on > > her own. > > > > * Resolve Conflict > > > > There must be a mechanism for resolving a conflict. The CAN be > > done automatically using default resolvers provided by AeroGear, > > by > > using a resolver provided by the developer/user, or by the app > > user > > selecting the correct merge. This will possibly generate a new > > sync > > message. > > > > > > ### API levels > > > > As soon as we have a rough data-model defined, we can start dabbling > > around different API levels to be served: > > > > (parts **I think** are potentially deliverable for a 1.0) > > > > - level 0: explodes when there's a conflict > > - level 1: semi-automatic conflict resolution via something > > like > > google's diff-match-patch > > - level 2: business rules determine who wins a conflicting update > > (supervisor wins over normal user) > > > > (parts **I think** are potentially deliverable for a 2.0) > > > > - level 3: real-time updates via diff-match-patch > > - level 4: real-time updates via OT/EC > > > > All those proposed API operations should be serializable, meaning > > I can > > potentially keep doing changes offline then just replying them > > to the > > server when online. > > > > ### transport > > > > Since we know about the future-looking ideas on v2.0, it would > > be really > > nice for us to specify a very simple/dumb JSON-based protocol > > for those > > change messages. Something that could accomodate both the full > > document > > updates and the OT/EC incremental bits too. I have no ideas on > > this, tbh. > > > > #### Strawman - Summers > > > > {id : Object, data : String, checksum: long} > > > > **id** : > > This is the global identifier for the object. This field is optional. > > > > **data** : > > This is the sync data for the application. It may be a diff, a whole > > object, etc. This field is required. > > > > **checksum** : > > This is the client's idea of what a known good sync will look like. > > If, post merge, the server's checksum and client's check sum > > do not > > match then the client is out of sync and must resync and handle > > the > > conflict. > > > > > > > > ## Appendix Use Cases: > > > > > > Here are a few contrived use cases that we may want to keep in mind. > > > > 1. Legacy Bug Trackers From Hell > > > > a. It is a webapp written in COBOL, no one will ever EVER update > > or > > change the code > > > > b. It has TONS of legacy but important data > > > > c. It has TONS of users > > > > d. It only has a few transactions per day, all creating and > > updating > > bug reports > > > > e. Multiple users can edit the same report > > > > > > 2. Slacker Gallery > > > > a. Each User has a multiple galleries, each gallery has multiple > > photos > > > > b. A Gallery has only one user, but the user may be on multiple > > devices > > > > c. Galleries may be renamed, created, and deleted > > > > d. Photos may only be created or deleted. Photos also have meta > > data > > which may be updated, but its creation and deletion is tied to > > the Photo > > object. > > > > > > 3. Dropbox clone > > > > a. A folder of files may be shared among users > > > > b. There is a size limit to files and how much storage may be used > > per folder > > > > c. Files are not updated. If there is a new file, there is an > > atomic > > delete and create operation > > > > > > 4. Email client > > > > a. This is an AG-controller which accesses a mail account. > > > > b. There are mobile offline and sync enabled clients which connect > > to this controller. > > > > > > 5. Google Docs clone > > > > a. Operational Transform out the wazzoo > > > > b. What would the server need? > > > > c. What would the client need? > > > > > > 6. Building Inspector app > > > > Building inspector system - we have mobile apps that store relevant > > info > > and are bound to be accessed on places where we won't have any kind > > of > > connection, or very poor signal. > > > > You can have several inspectors screening the same building > > simultaneously. > > > > Let's say we have Agnes and Joe are doing the fire extinguisher > > inspection in a new hospital building. Technically each fire > > extinguisher has its own identifier and can be an independent > > document. > > In this case we would have no conflict happening. > > > > Now they start finding expired fire extinguishers and start > > to add them > > to the report. This report could potentially have two divergent > > lists of > > fire extinguishers to be replenished/revalidated, as the building's > > compliance status. > > > > 7. Census App > > > > Census system - we have mobile apps focused on offline data collection. > > We have the previous year's info that needs to be updated on the > > server. > > The interviewee needs to take a call, then asks the interviewer > > to come > > back later. This results in two sets of changes for the same document, > > stacked together, which should work flawlessly. > > > > > > # Appendix Reference (Open Source) Products: > > > > > > - Wave-in-a-box > > > > - CouchDB > > > > - Google Drive RealtimeAPI > > > > - [diff-merge-patch > > algorithm](http://code.google.com/p/google-diff-match-patch/) > > > > - [Summers' Realtime Sync Demo]( > http://www.youtube.com/watch?v=WEkZGbVk4Lc) > > > > - [Summers' Devnexus Sync > > Demo](https://plus.google.com/103442292643366117394/posts/HGVHwtPArPW) > > > > - Google Android Sync Architecture > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140108/b89f7371/attachment-0001.html From jbalunas at redhat.com Wed Jan 8 08:31:10 2014 From: jbalunas at redhat.com (Jay Balunas) Date: Wed, 8 Jan 2014 08:31:10 -0500 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: <20140108100434.738dc940@kapy-ntb-x220> References: <20140107131344.03fd7bf0@kapy-ntb-x220> <20140108100434.738dc940@kapy-ntb-x220> Message-ID: On Jan 8, 2014, at 4:04 AM, Karel Piwko wrote: > Keycloak cartridge is already in progress, based on top of WF 8.0.0.CR1: > > https://issues.jboss.org/browse/KEYCLOAK-78 > > CC'ed keycloak-dev. Maybe if we join our cartridge efforts, it could be > beneficial to everybody. +1 was going to suggest the same. They want and need a cartridge much like ours :-) Both of them together could be really neat. i.e. Fire up my SSO, fire up my push server, and go! > > Karel > > On Wed, 8 Jan 2014 09:51:19 +0100 > Matthias Wessendorf wrote: > >> On Wed, Jan 8, 2014 at 9:49 AM, Bruno Oliveira wrote: >> >>> Hijacking the thread, maybe we can think about a keycloak cartridge on >>> OpenShift in the future. >>> >> >> +1 I'd like that >> >> >>> >>> Wdyt? >>> >>> -- >>> abstractj >>> >>> On January 7, 2014 at 10:13:52 AM, Karel Piwko (kpiwko at redhat.com) wrote: >>>>> That said, it might make our OpenShift cartridge setup more >>>> complicated but >>>> again that's not something users(read consumers) should hit. >>>> >>>> Karel >>> >>> _______________________________________________ >>> 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 Wed Jan 8 09:13:36 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 08 Jan 2014 09:13:36 -0500 Subject: [aerogear-dev] sync spec strawman In-Reply-To: References: <52CC0D68.6030305@redhat.com> Message-ID: <52CD5D10.40505@redhat.com> On 01/08/2014 04:56 AM, Bruno Oliveira wrote: > Good morning Summers, I was reviewing the whole document and I think is the great start. Either way that looked a bit confuse to me, so here comes my attempt to reorganize it (is just a suggestion): https://github.com/aerogear/aerogear.org/pull/227 > > Another change that I would suggest is the inclusion of the field ?revision? like Qmx already suggested, with your idea of the checksum. And also the inclusion of the field ?signature? to make sure that data is not corrupted or tampered. Would signature be an optional field? And is revision a checksum now? > > Thoughts? I feel like we are going forward now. > > -- > abstractj > > On January 7, 2014 at 12:21:35 PM, Summers Pittman (supittma at redhat.com) wrote: >> >> I've updated the sync spec on the data-sync branch on aerogear.org >> with >> what qmx posted yesterday and some ideas I had as well. If I don't >> get >> any tomatoes I will try to see what a POC on Android looks like this >> afternoon. >> >> Sync doc follows. >> >> # Status: Experimental >> >> # AeroGear Data Sync >> >> >> ## basics? >> >> Since we've been catering the enterprise market, this essentially >> means >> we need to get the __boring__ stuff right first, then move over >> to the >> __shiny__ stuff, like realtime data sync, update policies & >> friends. >> >> ### data model >> >> For starters, I think that the most important thing that needs >> to be >> agreed upon is the data model and the atomic operations around >> it. As >> previous discussed, I really like CouchDB's datamodel -- and >> hate erlang ;) >> >> `{_id:, content:, rev:}` >> >> #### JS >> >> Well, it's JSON, it _Just Works_? >> >> #### Java >> >> I didn't want to pick on Java, but since its fame forces me to it. >> First >> stab (a courtesy of our friend Dan Bevenius): >> >> public interface Document { >> public String id; >> public String content; >> public String rev; >> } >> >> We naturally want to kick this a notch, and use objects instead >> of plain >> strings: >> >> public interface Document { >> public ID id; >> public T content; >> public String rev; >> } >> >> In this case, we can use the convention requiring that `T` is any >> **object serializable to JSON**. `ID` is a convenience shorthand >> since >> it's a **GUID/UUID**. I think this key isn't necessarily a natural >> key >> (a surrogate key instead). >> >> #### Objective-C >> >> volunteers needed ;) >> >> ### Transactions >> >> These are the most basic parts of sync I can think of that our system >> should be able to do/manage. Our internal representation of >> the client >> documents and collections should make implementing this automatically >> and without user intervention as simple as possible >> >> * Detect Change >> >> When a user changes her local data, the system should note the >> change and generate a sync message to send to the server. This >> can be >> done automatically or manually but SHOULD be done automatically. >> >> * Send update >> >> When a sync message is ready to be sent, and the system allows for >> it to be sent (network available, not in blackout window from >> exponential backoff, etc) then sync message should be sent. >> This being >> done automatically should be the default, but the developer >> can override >> this behavior. >> >> * Receive Update >> >> When a client updates it data and successfully syncs to the remote >> server, the remote server will notify all of the relevant clients. >> The >> client must automatically and without user intervention receive >> this >> update and either act on it or store it for later processing. >> >> * Apply Update >> >> Once a client application has an update message from the server, >> it >> can apply the message correctly to the data on it. This should >> be done >> automatically as part of receiving the update, but it may be done >> manually or may be delayed and automatically executed later. >> >> * Detect Conflict >> >> When applying an update fails, the system must detect this. The >> system will provide state to the application and/or the user >> to handle >> the conflict. The user MUST NOT have to check for conflicts on >> her own. >> >> * Resolve Conflict >> >> There must be a mechanism for resolving a conflict. The CAN be >> done automatically using default resolvers provided by AeroGear, >> by >> using a resolver provided by the developer/user, or by the app >> user >> selecting the correct merge. This will possibly generate a new >> sync >> message. >> >> >> ### API levels >> >> As soon as we have a rough data-model defined, we can start dabbling >> around different API levels to be served: >> >> (parts **I think** are potentially deliverable for a 1.0) >> >> - level 0: explodes when there's a conflict >> - level 1: semi-automatic conflict resolution via something >> like >> google's diff-match-patch >> - level 2: business rules determine who wins a conflicting update >> (supervisor wins over normal user) >> >> (parts **I think** are potentially deliverable for a 2.0) >> >> - level 3: real-time updates via diff-match-patch >> - level 4: real-time updates via OT/EC >> >> All those proposed API operations should be serializable, meaning >> I can >> potentially keep doing changes offline then just replying them >> to the >> server when online. >> >> ### transport >> >> Since we know about the future-looking ideas on v2.0, it would >> be really >> nice for us to specify a very simple/dumb JSON-based protocol >> for those >> change messages. Something that could accomodate both the full >> document >> updates and the OT/EC incremental bits too. I have no ideas on >> this, tbh. >> >> #### Strawman - Summers >> >> {id : Object, data : String, checksum: long} >> >> **id** : >> This is the global identifier for the object. This field is optional. >> >> **data** : >> This is the sync data for the application. It may be a diff, a whole >> object, etc. This field is required. >> >> **checksum** : >> This is the client's idea of what a known good sync will look like. >> If, post merge, the server's checksum and client's check sum >> do not >> match then the client is out of sync and must resync and handle >> the >> conflict. >> >> >> >> ## Appendix Use Cases: >> >> >> Here are a few contrived use cases that we may want to keep in mind. >> >> 1. Legacy Bug Trackers From Hell >> >> a. It is a webapp written in COBOL, no one will ever EVER update >> or >> change the code >> >> b. It has TONS of legacy but important data >> >> c. It has TONS of users >> >> d. It only has a few transactions per day, all creating and >> updating >> bug reports >> >> e. Multiple users can edit the same report >> >> >> 2. Slacker Gallery >> >> a. Each User has a multiple galleries, each gallery has multiple >> photos >> >> b. A Gallery has only one user, but the user may be on multiple >> devices >> >> c. Galleries may be renamed, created, and deleted >> >> d. Photos may only be created or deleted. Photos also have meta >> data >> which may be updated, but its creation and deletion is tied to >> the Photo >> object. >> >> >> 3. Dropbox clone >> >> a. A folder of files may be shared among users >> >> b. There is a size limit to files and how much storage may be used >> per folder >> >> c. Files are not updated. If there is a new file, there is an >> atomic >> delete and create operation >> >> >> 4. Email client >> >> a. This is an AG-controller which accesses a mail account. >> >> b. There are mobile offline and sync enabled clients which connect >> to this controller. >> >> >> 5. Google Docs clone >> >> a. Operational Transform out the wazzoo >> >> b. What would the server need? >> >> c. What would the client need? >> >> >> 6. Building Inspector app >> >> Building inspector system - we have mobile apps that store relevant >> info >> and are bound to be accessed on places where we won't have any kind >> of >> connection, or very poor signal. >> >> You can have several inspectors screening the same building >> simultaneously. >> >> Let's say we have Agnes and Joe are doing the fire extinguisher >> inspection in a new hospital building. Technically each fire >> extinguisher has its own identifier and can be an independent >> document. >> In this case we would have no conflict happening. >> >> Now they start finding expired fire extinguishers and start >> to add them >> to the report. This report could potentially have two divergent >> lists of >> fire extinguishers to be replenished/revalidated, as the building's >> compliance status. >> >> 7. Census App >> >> Census system - we have mobile apps focused on offline data collection. >> We have the previous year's info that needs to be updated on the >> server. >> The interviewee needs to take a call, then asks the interviewer >> to come >> back later. This results in two sets of changes for the same document, >> stacked together, which should work flawlessly. >> >> >> # Appendix Reference (Open Source) Products: >> >> >> - Wave-in-a-box >> >> - CouchDB >> >> - Google Drive RealtimeAPI >> >> - [diff-merge-patch >> algorithm](http://code.google.com/p/google-diff-match-patch/) >> >> - [Summers' Realtime Sync Demo](http://www.youtube.com/watch?v=WEkZGbVk4Lc) >> >> - [Summers' Devnexus Sync >> Demo](https://plus.google.com/103442292643366117394/posts/HGVHwtPArPW) >> >> - Google Android Sync Architecture >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> From supittma at redhat.com Wed Jan 8 09:22:31 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 08 Jan 2014 09:22:31 -0500 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: References: <20140107131344.03fd7bf0@kapy-ntb-x220> Message-ID: <52CD5F27.5070202@redhat.com> On 01/08/2014 03:49 AM, Bruno Oliveira wrote: > Hijacking the thread, maybe we can think about a keycloak cartridge on OpenShift in the future. > > Wdyt? > +9001 From supittma at redhat.com Wed Jan 8 09:30:48 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 08 Jan 2014 09:30:48 -0500 Subject: [aerogear-dev] [aerogear-android] DataManager API inconsistency + solution In-Reply-To: References: Message-ID: <52CD6118.8050504@redhat.com> On 01/08/2014 05:51 AM, Tadeas Kriz wrote: > Hey everyone, > > I?ve been recently going through the DataManager API in aerogear-android. In this email, I?d like to suggest addiction of two method (or possibly three) into the `Store` interface. These would be: > > ```java > /** > * If store is open, it can be read or written to. > */ > boolean isOpen(); > > /** > * Opens store in current thread (blocking). > */ > Store open(); > > /** > * Opens store in background thread and then callback#onSuccess is called. > */ > void open(Callback> callback); > ``` I think those are fine. Feel free to JIRA it up and Passos and I will review. > > >From my point of view, this makes sense to be in the `Store` so I can switch between stores easily during development with no need to change other code. Also, if `read` or `write` operations are done with closed store, there are two possible workflows. First one is, that I?d fail and throw an exception. Second (and for me a preferred one) is, that all those methods would internally check if the store is open and if not, they?d call the `open` method. This also leads me to another API change for `Store`. > > ```java > /** > * Reads all the data from the underlying storage system asynchronously. > */ > void readAll(Callback> callback); > > /** > * Reads a specific object/record from the underlying storage system asynchronously. > */ > void read(Serializable id, Callback callback); > > /** > * Search for objects/records from the underlying storage system asynchronously. > */ > void readWithFilter(ReadFilter filter, Callback> callback); > > /** > * Saves the given object in the underlying storage system asynchronously. > */ > void save(T item, Callback callback); > > /** > * Resets the entire storage system asynchronously. > */ > void reset(Callback callback); > > /** > * Removes a specific object/record from the underlying storage system asynchronously. > */ > void remove(Serializable id, Callback callback); > > /** > * Checks if the storage system contains no stored elements asynchronously. > */ > void isEmpty(Callback callback); > ``` > > That?s right, async methods for easy access to the storage from background thread, without the pain of writing it myself (for example, it makes no sense if I want to just call `store.save(..)` and I?d have to write all the `AsyncTask` boilerplate). > > So, what do you think? I would rather throw an exception than open a database when you call read and friends. That way a developer doesn't accidentally open a database he meant to be closed. I don't have that strong of a feeling on that point one way or another however. My stronger feeling is on adding callbacks to the stores methods. I prefer for the Store to be synchronous and Pipes to be asynchronous. We could add a StorePipe to our PypeTipes which may solve some of the headache. Passos, wdyt? > > PS: You can find the whole text with highlighted syntax here: > > ? > Tadeas Kriz > tkriz at redhat.com > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From bruno at abstractj.org Wed Jan 8 09:37:02 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 8 Jan 2014 12:37:02 -0200 Subject: [aerogear-dev] sync spec strawman In-Reply-To: <52CD5D10.40505@redhat.com> References: <52CC0D68.6030305@redhat.com> <52CD5D10.40505@redhat.com> Message-ID: Is just a suggestion, but if I understood correctly your previous proposal ?checksum? was able to check or validate outdated information. Amirite?! Or to avoid confusion we can: 1. Get rid of checksum and make use of revisions like CouchDB does. 2. Use the checksum and get rid of revisions 3. Keep both (might exist some overlapping between two concepts) What do you guys prefer?? -- abstractj On January 8, 2014 at 12:13:42 PM, Summers Pittman (supittma at redhat.com) wrote: > > And is revision a checksum now? From stian at redhat.com Wed Jan 8 09:38:02 2014 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 8 Jan 2014 09:38:02 -0500 (EST) Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: <52CD5F27.5070202@redhat.com> References: <20140107131344.03fd7bf0@kapy-ntb-x220> <52CD5F27.5070202@redhat.com> Message-ID: <2142127385.46221521.1389191882016.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Summers Pittman" > To: aerogear-dev at lists.jboss.org > Sent: Wednesday, 8 January, 2014 2:22:31 PM > Subject: Re: [aerogear-dev] Keycloak on AeroGear > > On 01/08/2014 03:49 AM, Bruno Oliveira wrote: > > Hijacking the thread, maybe we can think about a keycloak cartridge on > > OpenShift in the future. > > > > Wdyt? > > > +9001 +9003 ;) Push runs on WildFly doesn't it? I wonder if Push and Keycloak could be add-on cartridges to the WildFly cartridge making it possible to add one or both. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > From tkriz at redhat.com Wed Jan 8 09:42:59 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Wed, 8 Jan 2014 15:42:59 +0100 Subject: [aerogear-dev] [aerogear-android] DataManager API inconsistency + solution In-Reply-To: <52CD6118.8050504@redhat.com> References: <52CD6118.8050504@redhat.com> Message-ID: <0BE571A7-F030-4561-AEE8-FF87406E5877@redhat.com> On 08 Jan 2014, at 15:30, Summers Pittman wrote: > On 01/08/2014 05:51 AM, Tadeas Kriz wrote: >> Hey everyone, >> >> I?ve been recently going through the DataManager API in aerogear-android. In this email, I?d like to suggest addiction of two method (or possibly three) into the `Store` interface. These would be: >> >> ```java >> /** >> * If store is open, it can be read or written to. >> */ >> boolean isOpen(); >> >> /** >> * Opens store in current thread (blocking). >> */ >> Store open(); >> >> /** >> * Opens store in background thread and then callback#onSuccess is called. >> */ >> void open(Callback> callback); >> ``` > I think those are fine. Feel free to JIRA it up and Passos and I will > review. >> >>> From my point of view, this makes sense to be in the `Store` so I can switch between stores easily during development with no need to change other code. Also, if `read` or `write` operations are done with closed store, there are two possible workflows. First one is, that I?d fail and throw an exception. Second (and for me a preferred one) is, that all those methods would internally check if the store is open and if not, they?d call the `open` method. This also leads me to another API change for `Store`. >> >> ```java >> /** >> * Reads all the data from the underlying storage system asynchronously. >> */ >> void readAll(Callback> callback); >> >> /** >> * Reads a specific object/record from the underlying storage system asynchronously. >> */ >> void read(Serializable id, Callback callback); >> >> /** >> * Search for objects/records from the underlying storage system asynchronously. >> */ >> void readWithFilter(ReadFilter filter, Callback> callback); >> >> /** >> * Saves the given object in the underlying storage system asynchronously. >> */ >> void save(T item, Callback callback); >> >> /** >> * Resets the entire storage system asynchronously. >> */ >> void reset(Callback callback); >> >> /** >> * Removes a specific object/record from the underlying storage system asynchronously. >> */ >> void remove(Serializable id, Callback callback); >> >> /** >> * Checks if the storage system contains no stored elements asynchronously. >> */ >> void isEmpty(Callback callback); >> ``` >> >> That?s right, async methods for easy access to the storage from background thread, without the pain of writing it myself (for example, it makes no sense if I want to just call `store.save(..)` and I?d have to write all the `AsyncTask` boilerplate). >> >> So, what do you think? > > I would rather throw an exception than open a database when you call > read and friends. That way a developer doesn't accidentally open a > database he meant to be closed. I don't have that strong of a feeling on > that point one way or another however. That?s right, it?s probably less error prone in scenarios when you want the store closed. > > My stronger feeling is on adding callbacks to the stores methods. I > prefer for the Store to be synchronous and Pipes to be asynchronous. We > could add a StorePipe to our PypeTipes which may solve some of the headache. > Would ?void open(Callback> callback);? make sense then? I mean, that would add another inconsistency in the API, as one method would be async and the rest would be only synchronous, wouldn?t it? > Passos, wdyt? > > >> >> PS: You can find the whole text with highlighted syntax here: >> >> ? >> Tadeas Kriz >> tkriz at redhat.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/20140108/a47185ad/attachment-0001.html From bruno at abstractj.org Wed Jan 8 09:49:40 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 8 Jan 2014 12:49:40 -0200 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: <2142127385.46221521.1389191882016.JavaMail.root@redhat.com> References: <20140107131344.03fd7bf0@kapy-ntb-x220> <52CD5F27.5070202@redhat.com> <2142127385.46221521.1389191882016.JavaMail.root@redhat.com> Message-ID: Ahoy Stian, I can help on it. Maybe we can talk with Farah (coordinate with balunasj too), she is the best person on AeroGear to speak about OpenShift. Matthias also worked hard to make this happen for UPS. -- abstractj On January 8, 2014 at 12:38:05 PM, Stian Thorgersen (stian at redhat.com) wrote: > > +9003 ;) > > Push runs on WildFly doesn't it? I wonder if Push and Keycloak > could be add-on cartridges to the WildFly cartridge making it > possible to add one or both. From supittma at redhat.com Wed Jan 8 09:53:33 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 08 Jan 2014 09:53:33 -0500 Subject: [aerogear-dev] [aerogear-android] DataManager API inconsistency + solution In-Reply-To: <0BE571A7-F030-4561-AEE8-FF87406E5877@redhat.com> References: <52CD6118.8050504@redhat.com> <0BE571A7-F030-4561-AEE8-FF87406E5877@redhat.com> Message-ID: <52CD666D.8060003@redhat.com> On 01/08/2014 09:42 AM, Tadeas Kriz wrote: > > On 08 Jan 2014, at 15:30, Summers Pittman > wrote: > >> On 01/08/2014 05:51 AM, Tadeas Kriz wrote: >>> Hey everyone, >>> >>> I've been recently going through the DataManager API in >>> aerogear-android. In this email, I'd like to suggest addiction of >>> two method (or possibly three) into the `Store` interface. These >>> would be: >>> >>> ```java >>> /** >>> * If store is open, it can be read or written to. >>> */ >>> boolean isOpen(); >>> >>> /** >>> * Opens store in current thread (blocking). >>> */ >>> Store open(); >>> >>> /** >>> * Opens store in background thread and then callback#onSuccess is >>> called. >>> */ >>> void open(Callback> callback); >>> ``` >> I think those are fine. Feel free to JIRA it up and Passos and I will >> review. >>> >>>> From my point of view, this makes sense to be in the `Store` so >>>> I can switch between stores easily during development with no need >>>> to change other code. Also, if `read` or `write` operations are >>>> done with closed store, there are two possible workflows. First one >>>> is, that I'd fail and throw an exception. Second (and for me a >>>> preferred one) is, that all those methods would internally check if >>>> the store is open and if not, they'd call the `open` method. This >>>> also leads me to another API change for `Store`. >>> >>> ```java >>> /** >>> * Reads all the data from the underlying storage system asynchronously. >>> */ >>> void readAll(Callback> callback); >>> >>> /** >>> * Reads a specific object/record from the underlying storage system >>> asynchronously. >>> */ >>> void read(Serializable id, Callback callback); >>> >>> /** >>> * Search for objects/records from the underlying storage system >>> asynchronously. >>> */ >>> void readWithFilter(ReadFilter filter, Callback> callback); >>> >>> /** >>> * Saves the given object in the underlying storage system >>> asynchronously. >>> */ >>> void save(T item, Callback callback); >>> >>> /** >>> * Resets the entire storage system asynchronously. >>> */ >>> void reset(Callback callback); >>> >>> /** >>> * Removes a specific object/record from the underlying storage >>> system asynchronously. >>> */ >>> void remove(Serializable id, Callback callback); >>> >>> /** >>> * Checks if the storage system contains no stored elements >>> asynchronously. >>> */ >>> void isEmpty(Callback callback); >>> ``` >>> >>> That's right, async methods for easy access to the storage from >>> background thread, without the pain of writing it myself (for >>> example, it makes no sense if I want to just call `store.save(..)` >>> and I'd have to write all the `AsyncTask` boilerplate). >>> >>> So, what do you think? >> >> I would rather throw an exception than open a database when you call >> read and friends. That way a developer doesn't accidentally open a >> database he meant to be closed. I don't have that strong of a feeling on >> that point one way or another however. > > That's right, it's probably less error prone in scenarios when you > want the store closed. > >> >> My stronger feeling is on adding callbacks to the stores methods. I >> prefer for the Store to be synchronous and Pipes to be asynchronous. We >> could add a StorePipe to our PypeTipes which may solve some of the >> headache. >> > > Would "void open(Callback> callback);" make sense then? I > mean, that would add another inconsistency in the API, as one method > would be async and the rest would be only synchronous, wouldn't it? True. The reason for the exception here was that opening a SQL store or an encrypted store COULD take significant amount of time. For in Memory data stores this is instant of course. > >> Passos, wdyt? >> >> >>> >>> PS: You can find the whole text with highlighted syntax here: >>> >>> --- >>> Tadeas Kriz >>> tkriz at redhat.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/20140108/473d5a5a/attachment.html From matzew at apache.org Wed Jan 8 09:55:03 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 8 Jan 2014 15:55:03 +0100 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: <2142127385.46221521.1389191882016.JavaMail.root@redhat.com> References: <20140107131344.03fd7bf0@kapy-ntb-x220> <52CD5F27.5070202@redhat.com> <2142127385.46221521.1389191882016.JavaMail.root@redhat.com> Message-ID: On Wed, Jan 8, 2014 at 3:38 PM, Stian Thorgersen wrote: > > > ----- Original Message ----- > > From: "Summers Pittman" > > To: aerogear-dev at lists.jboss.org > > Sent: Wednesday, 8 January, 2014 2:22:31 PM > > Subject: Re: [aerogear-dev] Keycloak on AeroGear > > > > On 01/08/2014 03:49 AM, Bruno Oliveira wrote: > > > Hijacking the thread, maybe we can think about a keycloak cartridge on > > > OpenShift in the future. > > > > > > Wdyt? > > > > > +9001 > > +9003 ;) > > Push runs on WildFly doesn't it? yep - it does (should :-)) > I wonder if Push and Keycloak could be add-on cartridges to the WildFly > cartridge making it possible to add one or both. > sounds interesting to me > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140108/25e44fc8/attachment.html From supittma at redhat.com Wed Jan 8 09:55:21 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 08 Jan 2014 09:55:21 -0500 Subject: [aerogear-dev] sync spec strawman In-Reply-To: References: <52CC0D68.6030305@redhat.com> <52CD5D10.40505@redhat.com> Message-ID: <52CD66D9.8050902@redhat.com> On Wed 08 Jan 2014 09:37:02 AM EST, Bruno Oliveira wrote: > Is just a suggestion, but if I understood correctly your previous proposal ?checksum? was able to check or validate outdated information. Amirite?! In my proposal checksum was for the transport. When you send your new data include the checksum so the server can validate the merge happened correctly. It wasn't for the storage mechanism. > > Or to avoid confusion we can: > > 1. Get rid of checksum and make use of revisions like CouchDB does. > 2. Use the checksum and get rid of revisions > 3. Keep both (might exist some overlapping between two concepts) > > What do you guys prefer? > > -- > abstractj > > On January 8, 2014 at 12:13:42 PM, Summers Pittman (supittma at redhat.com) wrote: >>> And is revision a checksum now? > From tkriz at redhat.com Wed Jan 8 09:57:20 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Wed, 8 Jan 2014 15:57:20 +0100 Subject: [aerogear-dev] [aerogear-android] DataManager API inconsistency + solution In-Reply-To: <52CD666D.8060003@redhat.com> References: <52CD6118.8050504@redhat.com> <0BE571A7-F030-4561-AEE8-FF87406E5877@redhat.com> <52CD666D.8060003@redhat.com> Message-ID: On 08 Jan 2014, at 15:53, Summers Pittman wrote: > On 01/08/2014 09:42 AM, Tadeas Kriz wrote: >> >> On 08 Jan 2014, at 15:30, Summers Pittman wrote: >> >>> On 01/08/2014 05:51 AM, Tadeas Kriz wrote: >>>> Hey everyone, >>>> >>>> I?ve been recently going through the DataManager API in aerogear-android. In this email, I?d like to suggest addiction of two method (or possibly three) into the `Store` interface. These would be: >>>> >>>> ```java >>>> /** >>>> * If store is open, it can be read or written to. >>>> */ >>>> boolean isOpen(); >>>> >>>> /** >>>> * Opens store in current thread (blocking). >>>> */ >>>> Store open(); >>>> >>>> /** >>>> * Opens store in background thread and then callback#onSuccess is called. >>>> */ >>>> void open(Callback> callback); >>>> ``` >>> I think those are fine. Feel free to JIRA it up and Passos and I will >>> review. >>>> >>>>> From my point of view, this makes sense to be in the `Store` so I can switch between stores easily during development with no need to change other code. Also, if `read` or `write` operations are done with closed store, there are two possible workflows. First one is, that I?d fail and throw an exception. Second (and for me a preferred one) is, that all those methods would internally check if the store is open and if not, they?d call the `open` method. This also leads me to another API change for `Store`. >>>> >>>> ```java >>>> /** >>>> * Reads all the data from the underlying storage system asynchronously. >>>> */ >>>> void readAll(Callback> callback); >>>> >>>> /** >>>> * Reads a specific object/record from the underlying storage system asynchronously. >>>> */ >>>> void read(Serializable id, Callback callback); >>>> >>>> /** >>>> * Search for objects/records from the underlying storage system asynchronously. >>>> */ >>>> void readWithFilter(ReadFilter filter, Callback> callback); >>>> >>>> /** >>>> * Saves the given object in the underlying storage system asynchronously. >>>> */ >>>> void save(T item, Callback callback); >>>> >>>> /** >>>> * Resets the entire storage system asynchronously. >>>> */ >>>> void reset(Callback callback); >>>> >>>> /** >>>> * Removes a specific object/record from the underlying storage system asynchronously. >>>> */ >>>> void remove(Serializable id, Callback callback); >>>> >>>> /** >>>> * Checks if the storage system contains no stored elements asynchronously. >>>> */ >>>> void isEmpty(Callback callback); >>>> ``` >>>> >>>> That?s right, async methods for easy access to the storage from background thread, without the pain of writing it myself (for example, it makes no sense if I want to just call `store.save(..)` and I?d have to write all the `AsyncTask` boilerplate). >>>> >>>> So, what do you think? >>> >>> I would rather throw an exception than open a database when you call >>> read and friends. That way a developer doesn't accidentally open a >>> database he meant to be closed. I don't have that strong of a feeling on >>> that point one way or another however. >> >> That?s right, it?s probably less error prone in scenarios when you want the store closed. >> >>> >>> My stronger feeling is on adding callbacks to the stores methods. I >>> prefer for the Store to be synchronous and Pipes to be asynchronous. We >>> could add a StorePipe to our PypeTipes which may solve some of the headache. >>> >> >> Would ?void open(Callback> callback);? make sense then? I mean, that would add another inconsistency in the API, as one method would be async and the rest would be only synchronous, wouldn?t it? > True. The reason for the exception here was that opening a SQL store or an encrypted store COULD take significant amount of time. For in Memory data stores this is instant of course. I understand, but that?s just an assumption. Let?s say that there?s a storage, that?d take an instant to load data from, but a lot of time to save data (like XML file based store). What?s the main reason to not have async ?read?/?write? methods? >> >>> Passos, wdyt? >>> >>> >>>> >>>> PS: You can find the whole text with highlighted syntax here: >>>> >>>> ? >>>> Tadeas Kriz >>>> tkriz at redhat.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 > > _______________________________________________ > 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/20140108/710c5cbf/attachment-0001.html From lholmqui at redhat.com Wed Jan 8 09:59:12 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 8 Jan 2014 09:59:12 -0500 Subject: [aerogear-dev] [aerogear-android] DataManager API inconsistency + solution In-Reply-To: <52CD666D.8060003@redhat.com> References: <52CD6118.8050504@redhat.com> <0BE571A7-F030-4561-AEE8-FF87406E5877@redhat.com> <52CD666D.8060003@redhat.com> Message-ID: On Jan 8, 2014, at 9:53 AM, Summers Pittman wrote: > On 01/08/2014 09:42 AM, Tadeas Kriz wrote: >> >> On 08 Jan 2014, at 15:30, Summers Pittman wrote: >> >>> On 01/08/2014 05:51 AM, Tadeas Kriz wrote: >>>> Hey everyone, >>>> >>>> I?ve been recently going through the DataManager API in aerogear-android. In this email, I?d like to suggest addiction of two method (or possibly three) into the `Store` interface. These would be: >>>> >>>> ```java >>>> /** >>>> * If store is open, it can be read or written to. >>>> */ >>>> boolean isOpen(); >>>> >>>> /** >>>> * Opens store in current thread (blocking). >>>> */ >>>> Store open(); >>>> >>>> /** >>>> * Opens store in background thread and then callback#onSuccess is called. >>>> */ >>>> void open(Callback> callback); >>>> ``` >>> I think those are fine. Feel free to JIRA it up and Passos and I will >>> review. >>>> >>>>> From my point of view, this makes sense to be in the `Store` so I can switch between stores easily during development with no need to change other code. Also, if `read` or `write` operations are done with closed store, there are two possible workflows. First one is, that I?d fail and throw an exception. Second (and for me a preferred one) is, that all those methods would internally check if the store is open and if not, they?d call the `open` method. This also leads me to another API change for `Store`. >>>> >>>> ```java >>>> /** >>>> * Reads all the data from the underlying storage system asynchronously. >>>> */ >>>> void readAll(Callback> callback); >>>> >>>> /** >>>> * Reads a specific object/record from the underlying storage system asynchronously. >>>> */ >>>> void read(Serializable id, Callback callback); >>>> >>>> /** >>>> * Search for objects/records from the underlying storage system asynchronously. >>>> */ >>>> void readWithFilter(ReadFilter filter, Callback> callback); >>>> >>>> /** >>>> * Saves the given object in the underlying storage system asynchronously. >>>> */ >>>> void save(T item, Callback callback); >>>> >>>> /** >>>> * Resets the entire storage system asynchronously. >>>> */ >>>> void reset(Callback callback); >>>> >>>> /** >>>> * Removes a specific object/record from the underlying storage system asynchronously. >>>> */ >>>> void remove(Serializable id, Callback callback); >>>> >>>> /** >>>> * Checks if the storage system contains no stored elements asynchronously. >>>> */ >>>> void isEmpty(Callback callback); >>>> ``` >>>> >>>> That?s right, async methods for easy access to the storage from background thread, without the pain of writing it myself (for example, it makes no sense if I want to just call `store.save(..)` and I?d have to write all the `AsyncTask` boilerplate). >>>> >>>> So, what do you think? >>> >>> I would rather throw an exception than open a database when you call >>> read and friends. That way a developer doesn't accidentally open a >>> database he meant to be closed. I don't have that strong of a feeling on >>> that point one way or another however. >> >> That?s right, it?s probably less error prone in scenarios when you want the store closed. >> >>> >>> My stronger feeling is on adding callbacks to the stores methods. I >>> prefer for the Store to be synchronous and Pipes to be asynchronous. We >>> could add a StorePipe to our PypeTipes which may solve some of the headache. >>> >> >> Would ?void open(Callback> callback);? make sense then? I mean, that would add another inconsistency in the API, as one method would be async and the rest would be only synchronous, wouldn?t it? > True. The reason for the exception here was that opening a SQL store or an encrypted store COULD take significant amount of time. For in Memory data stores this is instant of course. In JS, once we added IndexedDB and WebSql which are async, we deprecated the sync api and made everything "async" >> >>> Passos, wdyt? >>> >>> >>>> >>>> PS: You can find the whole text with highlighted syntax here: >>>> >>>> ? >>>> Tadeas Kriz >>>> tkriz at redhat.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 > > _______________________________________________ > 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/20140108/94c5db2a/attachment.html From kpiwko at redhat.com Wed Jan 8 10:02:49 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Wed, 8 Jan 2014 16:02:49 +0100 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: <2142127385.46221521.1389191882016.JavaMail.root@redhat.com> References: <20140107131344.03fd7bf0@kapy-ntb-x220> <52CD5F27.5070202@redhat.com> <2142127385.46221521.1389191882016.JavaMail.root@redhat.com> Message-ID: <20140108160249.173b8801@kapy-ntb-x220> If you need some QE on top of cartridge, count me in. Karel On Wed, 8 Jan 2014 09:38:02 -0500 (EST) Stian Thorgersen wrote: > > > ----- Original Message ----- > > From: "Summers Pittman" > > To: aerogear-dev at lists.jboss.org > > Sent: Wednesday, 8 January, 2014 2:22:31 PM > > Subject: Re: [aerogear-dev] Keycloak on AeroGear > > > > On 01/08/2014 03:49 AM, Bruno Oliveira wrote: > > > Hijacking the thread, maybe we can think about a keycloak cartridge on > > > OpenShift in the future. > > > > > > Wdyt? > > > > > +9001 > > +9003 ;) > > Push runs on WildFly doesn't it? I wonder if Push and Keycloak could be > add-on cartridges to the WildFly cartridge making it possible to add one or > both. > > > _______________________________________________ > > 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 Wed Jan 8 10:04:18 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 08 Jan 2014 10:04:18 -0500 Subject: [aerogear-dev] [aerogear-android] DataManager API inconsistency + solution In-Reply-To: References: <52CD6118.8050504@redhat.com> <0BE571A7-F030-4561-AEE8-FF87406E5877@redhat.com> <52CD666D.8060003@redhat.com> Message-ID: <52CD68F2.4080804@redhat.com> On 01/08/2014 09:57 AM, Tadeas Kriz wrote: > > > On 08 Jan 2014, at 15:53, Summers Pittman > wrote: > >> On 01/08/2014 09:42 AM, Tadeas Kriz wrote: >>> >>> On 08 Jan 2014, at 15:30, Summers Pittman >> > wrote: >>> >>>> On 01/08/2014 05:51 AM, Tadeas Kriz wrote: >>>>> Hey everyone, >>>>> >>>>> I've been recently going through the DataManager API in >>>>> aerogear-android. In this email, I'd like to suggest addiction of >>>>> two method (or possibly three) into the `Store` interface. >>>>> These would be: >>>>> >>>>> ```java >>>>> /** >>>>> * If store is open, it can be read or written to. >>>>> */ >>>>> boolean isOpen(); >>>>> >>>>> /** >>>>> * Opens store in current thread (blocking). >>>>> */ >>>>> Store open(); >>>>> >>>>> /** >>>>> * Opens store in background thread and then callback#onSuccess is >>>>> called. >>>>> */ >>>>> void open(Callback> callback); >>>>> ``` >>>> I think those are fine. Feel free to JIRA it up and Passos and I will >>>> review. >>>>> >>>>>> From my point of view, this makes sense to be in the `Store` >>>>>> so I can switch between stores easily during development with no >>>>>> need to change other code. Also, if `read` or `write` operations >>>>>> are done with closed store, there are two possible workflows. >>>>>> First one is, that I'd fail and throw an exception. Second (and >>>>>> for me a preferred one) is, that all those methods would >>>>>> internally check if the store is open and if not, they'd call the >>>>>> `open` method. This also leads me to another API change for >>>>>> `Store`. >>>>> >>>>> ```java >>>>> /** >>>>> * Reads all the data from the underlying storage system >>>>> asynchronously. >>>>> */ >>>>> void readAll(Callback> callback); >>>>> >>>>> /** >>>>> * Reads a specific object/record from the underlying storage >>>>> system asynchronously. >>>>> */ >>>>> void read(Serializable id, Callback callback); >>>>> >>>>> /** >>>>> * Search for objects/records from the underlying storage system >>>>> asynchronously. >>>>> */ >>>>> void readWithFilter(ReadFilter filter, Callback> callback); >>>>> >>>>> /** >>>>> * Saves the given object in the underlying storage system >>>>> asynchronously. >>>>> */ >>>>> void save(T item, Callback callback); >>>>> >>>>> /** >>>>> * Resets the entire storage system asynchronously. >>>>> */ >>>>> void reset(Callback callback); >>>>> >>>>> /** >>>>> * Removes a specific object/record from the underlying storage >>>>> system asynchronously. >>>>> */ >>>>> void remove(Serializable id, Callback callback); >>>>> >>>>> /** >>>>> * Checks if the storage system contains no stored elements >>>>> asynchronously. >>>>> */ >>>>> void isEmpty(Callback callback); >>>>> ``` >>>>> >>>>> That's right, async methods for easy access to the storage from >>>>> background thread, without the pain of writing it myself (for >>>>> example, it makes no sense if I want to just call `store.save(..)` >>>>> and I'd have to write all the `AsyncTask` boilerplate). >>>>> >>>>> So, what do you think? >>>> >>>> I would rather throw an exception than open a database when you call >>>> read and friends. That way a developer doesn't accidentally open a >>>> database he meant to be closed. I don't have that strong of a >>>> feeling on >>>> that point one way or another however. >>> >>> That's right, it's probably less error prone in scenarios when you >>> want the store closed. >>> >>>> >>>> My stronger feeling is on adding callbacks to the stores methods. I >>>> prefer for the Store to be synchronous and Pipes to be asynchronous. We >>>> could add a StorePipe to our PypeTipes which may solve some of the >>>> headache. >>>> >>> >>> Would "void open(Callback> callback);" make sense then? I >>> mean, that would add another inconsistency in the API, as one method >>> would be async and the rest would be only synchronous, wouldn't it? >> True. The reason for the exception here was that opening a SQL store >> or an encrypted store COULD take significant amount of time. For in >> Memory data stores this is instant of course. > I understand, but that's just an assumption. Let's say that there's a > storage, that'd take an instant to load data from, but a lot of time > to save data (like XML file based store). What's the main reason to > not have async "read"/"write" methods? The best reason I can give is if your Store implementation will be that slow either a) Write a Pipe instead or b) Manage the latency yourself. In Android land you want code on your main thread to be fast or non blocking. If we are working off the main thread then having things be slow and blocking is less of an issue. Synchronous code is easier to debug (in Java) and easier to write (in Java) and faster (because we don't have to route through callback classes). Having either or, in my opinion, clouds what your usage target should be. Also this is the most though Stores have been given in a long time. Anything we come up with we will probably need to get the other platforms alerted to as well. >>> >>>> Passos, wdyt? >>>> >>>> >>>>> >>>>> PS: You can find the whole text with highlighted syntax here: >>>>> >>>>> --- >>>>> Tadeas Kriz >>>>> tkriz at redhat.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 >> >> _______________________________________________ >> 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/20140108/6529fdd0/attachment-0001.html From tkriz at redhat.com Wed Jan 8 10:05:13 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Wed, 8 Jan 2014 16:05:13 +0100 Subject: [aerogear-dev] [aerogear-android] DataManager API inconsistency + solution In-Reply-To: References: <52CD6118.8050504@redhat.com> <0BE571A7-F030-4561-AEE8-FF87406E5877@redhat.com> <52CD666D.8060003@redhat.com> Message-ID: ? Tadeas Kriz tkriz at redhat.com On 08 Jan 2014, at 15:59, Lucas Holmquist wrote: > > On Jan 8, 2014, at 9:53 AM, Summers Pittman wrote: > >> On 01/08/2014 09:42 AM, Tadeas Kriz wrote: >>> >>> On 08 Jan 2014, at 15:30, Summers Pittman wrote: >>> >>>> On 01/08/2014 05:51 AM, Tadeas Kriz wrote: >>>>> Hey everyone, >>>>> >>>>> I?ve been recently going through the DataManager API in aerogear-android. In this email, I?d like to suggest addiction of two method (or possibly three) into the `Store` interface. These would be: >>>>> >>>>> ```java >>>>> /** >>>>> * If store is open, it can be read or written to. >>>>> */ >>>>> boolean isOpen(); >>>>> >>>>> /** >>>>> * Opens store in current thread (blocking). >>>>> */ >>>>> Store open(); >>>>> >>>>> /** >>>>> * Opens store in background thread and then callback#onSuccess is called. >>>>> */ >>>>> void open(Callback> callback); >>>>> ``` >>>> I think those are fine. Feel free to JIRA it up and Passos and I will >>>> review. >>>>> >>>>>> From my point of view, this makes sense to be in the `Store` so I can switch between stores easily during development with no need to change other code. Also, if `read` or `write` operations are done with closed store, there are two possible workflows. First one is, that I?d fail and throw an exception. Second (and for me a preferred one) is, that all those methods would internally check if the store is open and if not, they?d call the `open` method. This also leads me to another API change for `Store`. >>>>> >>>>> ```java >>>>> /** >>>>> * Reads all the data from the underlying storage system asynchronously. >>>>> */ >>>>> void readAll(Callback> callback); >>>>> >>>>> /** >>>>> * Reads a specific object/record from the underlying storage system asynchronously. >>>>> */ >>>>> void read(Serializable id, Callback callback); >>>>> >>>>> /** >>>>> * Search for objects/records from the underlying storage system asynchronously. >>>>> */ >>>>> void readWithFilter(ReadFilter filter, Callback> callback); >>>>> >>>>> /** >>>>> * Saves the given object in the underlying storage system asynchronously. >>>>> */ >>>>> void save(T item, Callback callback); >>>>> >>>>> /** >>>>> * Resets the entire storage system asynchronously. >>>>> */ >>>>> void reset(Callback callback); >>>>> >>>>> /** >>>>> * Removes a specific object/record from the underlying storage system asynchronously. >>>>> */ >>>>> void remove(Serializable id, Callback callback); >>>>> >>>>> /** >>>>> * Checks if the storage system contains no stored elements asynchronously. >>>>> */ >>>>> void isEmpty(Callback callback); >>>>> ``` >>>>> >>>>> That?s right, async methods for easy access to the storage from background thread, without the pain of writing it myself (for example, it makes no sense if I want to just call `store.save(..)` and I?d have to write all the `AsyncTask` boilerplate). >>>>> >>>>> So, what do you think? >>>> >>>> I would rather throw an exception than open a database when you call >>>> read and friends. That way a developer doesn't accidentally open a >>>> database he meant to be closed. I don't have that strong of a feeling on >>>> that point one way or another however. >>> >>> That?s right, it?s probably less error prone in scenarios when you want the store closed. >>> >>>> >>>> My stronger feeling is on adding callbacks to the stores methods. I >>>> prefer for the Store to be synchronous and Pipes to be asynchronous. We >>>> could add a StorePipe to our PypeTipes which may solve some of the headache. >>>> >>> >>> Would ?void open(Callback> callback);? make sense then? I mean, that would add another inconsistency in the API, as one method would be async and the rest would be only synchronous, wouldn?t it? >> True. The reason for the exception here was that opening a SQL store or an encrypted store COULD take significant amount of time. For in Memory data stores this is instant of course. > > In JS, once we added IndexedDB and WebSql which are async, we deprecated the sync api and made everything "async" Well, from my experience with Android development, you don?t always want everything async. You should be able to easily select. Sometimes you're already in background thread, so you want the data to be loaded/saved synchronously. >>> >>>> Passos, wdyt? >>>> >>>> >>>>> >>>>> PS: You can find the whole text with highlighted syntax here: >>>>> >>>>> ? >>>>> Tadeas Kriz >>>>> tkriz at redhat.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 >> >> _______________________________________________ >> 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/20140108/e0a7ba79/attachment.html From supittma at redhat.com Wed Jan 8 10:06:37 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 08 Jan 2014 10:06:37 -0500 Subject: [aerogear-dev] [aerogear-android] DataManager API inconsistency + solution In-Reply-To: References: <52CD6118.8050504@redhat.com> <0BE571A7-F030-4561-AEE8-FF87406E5877@redhat.com> <52CD666D.8060003@redhat.com> Message-ID: <52CD697D.8030208@redhat.com> On 01/08/2014 09:59 AM, Lucas Holmquist wrote: > > On Jan 8, 2014, at 9:53 AM, Summers Pittman > wrote: > >> On 01/08/2014 09:42 AM, Tadeas Kriz wrote: >>> >>> On 08 Jan 2014, at 15:30, Summers Pittman >> > wrote: >>> >>>> On 01/08/2014 05:51 AM, Tadeas Kriz wrote: >>>>> Hey everyone, >>>>> >>>>> I've been recently going through the DataManager API in >>>>> aerogear-android. In this email, I'd like to suggest addiction of >>>>> two method (or possibly three) into the `Store` interface. >>>>> These would be: >>>>> >>>>> ```java >>>>> /** >>>>> * If store is open, it can be read or written to. >>>>> */ >>>>> boolean isOpen(); >>>>> >>>>> /** >>>>> * Opens store in current thread (blocking). >>>>> */ >>>>> Store open(); >>>>> >>>>> /** >>>>> * Opens store in background thread and then callback#onSuccess is >>>>> called. >>>>> */ >>>>> void open(Callback> callback); >>>>> ``` >>>> I think those are fine. Feel free to JIRA it up and Passos and I will >>>> review. >>>>> >>>>>> From my point of view, this makes sense to be in the `Store` >>>>>> so I can switch between stores easily during development with no >>>>>> need to change other code. Also, if `read` or `write` operations >>>>>> are done with closed store, there are two possible workflows. >>>>>> First one is, that I'd fail and throw an exception. Second (and >>>>>> for me a preferred one) is, that all those methods would >>>>>> internally check if the store is open and if not, they'd call the >>>>>> `open` method. This also leads me to another API change for >>>>>> `Store`. >>>>> >>>>> ```java >>>>> /** >>>>> * Reads all the data from the underlying storage system >>>>> asynchronously. >>>>> */ >>>>> void readAll(Callback> callback); >>>>> >>>>> /** >>>>> * Reads a specific object/record from the underlying storage >>>>> system asynchronously. >>>>> */ >>>>> void read(Serializable id, Callback callback); >>>>> >>>>> /** >>>>> * Search for objects/records from the underlying storage system >>>>> asynchronously. >>>>> */ >>>>> void readWithFilter(ReadFilter filter, Callback> callback); >>>>> >>>>> /** >>>>> * Saves the given object in the underlying storage system >>>>> asynchronously. >>>>> */ >>>>> void save(T item, Callback callback); >>>>> >>>>> /** >>>>> * Resets the entire storage system asynchronously. >>>>> */ >>>>> void reset(Callback callback); >>>>> >>>>> /** >>>>> * Removes a specific object/record from the underlying storage >>>>> system asynchronously. >>>>> */ >>>>> void remove(Serializable id, Callback callback); >>>>> >>>>> /** >>>>> * Checks if the storage system contains no stored elements >>>>> asynchronously. >>>>> */ >>>>> void isEmpty(Callback callback); >>>>> ``` >>>>> >>>>> That's right, async methods for easy access to the storage from >>>>> background thread, without the pain of writing it myself (for >>>>> example, it makes no sense if I want to just call `store.save(..)` >>>>> and I'd have to write all the `AsyncTask` boilerplate). >>>>> >>>>> So, what do you think? >>>> >>>> I would rather throw an exception than open a database when you call >>>> read and friends. That way a developer doesn't accidentally open a >>>> database he meant to be closed. I don't have that strong of a >>>> feeling on >>>> that point one way or another however. >>> >>> That's right, it's probably less error prone in scenarios when you >>> want the store closed. >>> >>>> >>>> My stronger feeling is on adding callbacks to the stores methods. I >>>> prefer for the Store to be synchronous and Pipes to be asynchronous. We >>>> could add a StorePipe to our PypeTipes which may solve some of the >>>> headache. >>>> >>> >>> Would "void open(Callback> callback);" make sense then? I >>> mean, that would add another inconsistency in the API, as one method >>> would be async and the rest would be only synchronous, wouldn't it? >> True. The reason for the exception here was that opening a SQL store >> or an encrypted store COULD take significant amount of time. For in >> Memory data stores this is instant of course. > > In JS, once we added IndexedDB and WebSql which are async, we > deprecated the sync api and made everything "async" I didn't realize you guys were deprecating the sync methods. I thought you were just adding the aysnc methods because that* is what JS developers expect. *That = callback hell :-p > >>> >>>> Passos, wdyt? >>>> >>>> >>>>> >>>>> PS: You can find the whole text with highlighted syntax here: >>>>> >>>>> --- >>>>> Tadeas Kriz >>>>> tkriz at redhat.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 >> >> _______________________________________________ >> 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/20140108/e1eef34e/attachment-0001.html From tkriz at redhat.com Wed Jan 8 10:09:58 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Wed, 8 Jan 2014 16:09:58 +0100 Subject: [aerogear-dev] [aerogear-android] DataManager API inconsistency + solution In-Reply-To: <52CD68F2.4080804@redhat.com> References: <52CD6118.8050504@redhat.com> <0BE571A7-F030-4561-AEE8-FF87406E5877@redhat.com> <52CD666D.8060003@redhat.com> <52CD68F2.4080804@redhat.com> Message-ID: ? Tadeas Kriz tkriz at redhat.com On 08 Jan 2014, at 16:04, Summers Pittman wrote: > On 01/08/2014 09:57 AM, Tadeas Kriz wrote: >> >> >> On 08 Jan 2014, at 15:53, Summers Pittman wrote: >> >>> On 01/08/2014 09:42 AM, Tadeas Kriz wrote: >>>> >>>> On 08 Jan 2014, at 15:30, Summers Pittman wrote: >>>> >>>>> On 01/08/2014 05:51 AM, Tadeas Kriz wrote: >>>>>> Hey everyone, >>>>>> >>>>>> I?ve been recently going through the DataManager API in aerogear-android. In this email, I?d like to suggest addiction of two method (or possibly three) into the `Store` interface. These would be: >>>>>> >>>>>> ```java >>>>>> /** >>>>>> * If store is open, it can be read or written to. >>>>>> */ >>>>>> boolean isOpen(); >>>>>> >>>>>> /** >>>>>> * Opens store in current thread (blocking). >>>>>> */ >>>>>> Store open(); >>>>>> >>>>>> /** >>>>>> * Opens store in background thread and then callback#onSuccess is called. >>>>>> */ >>>>>> void open(Callback> callback); >>>>>> ``` >>>>> I think those are fine. Feel free to JIRA it up and Passos and I will >>>>> review. >>>>>> >>>>>>> From my point of view, this makes sense to be in the `Store` so I can switch between stores easily during development with no need to change other code. Also, if `read` or `write` operations are done with closed store, there are two possible workflows. First one is, that I?d fail and throw an exception. Second (and for me a preferred one) is, that all those methods would internally check if the store is open and if not, they?d call the `open` method. This also leads me to another API change for `Store`. >>>>>> >>>>>> ```java >>>>>> /** >>>>>> * Reads all the data from the underlying storage system asynchronously. >>>>>> */ >>>>>> void readAll(Callback> callback); >>>>>> >>>>>> /** >>>>>> * Reads a specific object/record from the underlying storage system asynchronously. >>>>>> */ >>>>>> void read(Serializable id, Callback callback); >>>>>> >>>>>> /** >>>>>> * Search for objects/records from the underlying storage system asynchronously. >>>>>> */ >>>>>> void readWithFilter(ReadFilter filter, Callback> callback); >>>>>> >>>>>> /** >>>>>> * Saves the given object in the underlying storage system asynchronously. >>>>>> */ >>>>>> void save(T item, Callback callback); >>>>>> >>>>>> /** >>>>>> * Resets the entire storage system asynchronously. >>>>>> */ >>>>>> void reset(Callback callback); >>>>>> >>>>>> /** >>>>>> * Removes a specific object/record from the underlying storage system asynchronously. >>>>>> */ >>>>>> void remove(Serializable id, Callback callback); >>>>>> >>>>>> /** >>>>>> * Checks if the storage system contains no stored elements asynchronously. >>>>>> */ >>>>>> void isEmpty(Callback callback); >>>>>> ``` >>>>>> >>>>>> That?s right, async methods for easy access to the storage from background thread, without the pain of writing it myself (for example, it makes no sense if I want to just call `store.save(..)` and I?d have to write all the `AsyncTask` boilerplate). >>>>>> >>>>>> So, what do you think? >>>>> >>>>> I would rather throw an exception than open a database when you call >>>>> read and friends. That way a developer doesn't accidentally open a >>>>> database he meant to be closed. I don't have that strong of a feeling on >>>>> that point one way or another however. >>>> >>>> That?s right, it?s probably less error prone in scenarios when you want the store closed. >>>> >>>>> >>>>> My stronger feeling is on adding callbacks to the stores methods. I >>>>> prefer for the Store to be synchronous and Pipes to be asynchronous. We >>>>> could add a StorePipe to our PypeTipes which may solve some of the headache. >>>>> >>>> >>>> Would ?void open(Callback> callback);? make sense then? I mean, that would add another inconsistency in the API, as one method would be async and the rest would be only synchronous, wouldn?t it? >>> True. The reason for the exception here was that opening a SQL store or an encrypted store COULD take significant amount of time. For in Memory data stores this is instant of course. >> I understand, but that?s just an assumption. Let?s say that there?s a storage, that?d take an instant to load data from, but a lot of time to save data (like XML file based store). What?s the main reason to not have async ?read?/?write? methods? > > The best reason I can give is if your Store implementation will be that slow either a) Write a Pipe instead or b) Manage the latency yourself. > > In Android land you want code on your main thread to be fast or non blocking. If we are working off the main thread then having things be slow and blocking is less of an issue. Synchronous code is easier to debug (in Java) and easier to write (in Java) and faster (because we don't have to route through callback classes). > > Having either or, in my opinion, clouds what your usage target should be. > > Also this is the most though Stores have been given in a long time. Anything we come up with we will probably need to get the other platforms alerted to as well. > Well, sometimes you want to reload a ListView data and it?d make it so easy to just call ?store.readAll(callback)? where in callback#onSuccess you?d remove progress indicator and notify the ListView about new data. BTW, I?ve been working on new DataManager API, which would be a lot more interesting for users (right now the need to cast it and also that it?s not easily extendable is a pain), so when I?m done with that, I?ll start another thread here on ML ;) > >>>> >>>>> Passos, wdyt? >>>>> >>>>> >>>>>> >>>>>> PS: You can find the whole text with highlighted syntax here: >>>>>> >>>>>> ? >>>>>> Tadeas Kriz >>>>>> tkriz at redhat.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 >>> >>> _______________________________________________ >>> 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/20140108/a3521107/attachment.html From supittma at redhat.com Wed Jan 8 10:15:06 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 08 Jan 2014 10:15:06 -0500 Subject: [aerogear-dev] [aerogear-android] DataManager API inconsistency + solution In-Reply-To: References: <52CD6118.8050504@redhat.com> <0BE571A7-F030-4561-AEE8-FF87406E5877@redhat.com> <52CD666D.8060003@redhat.com> <52CD68F2.4080804@redhat.com> Message-ID: <52CD6B7A.7080703@redhat.com> On 01/08/2014 10:09 AM, Tadeas Kriz wrote: > > --- > Tadeas Kriz > tkriz at redhat.com > > On 08 Jan 2014, at 16:04, Summers Pittman > wrote: > >> On 01/08/2014 09:57 AM, Tadeas Kriz wrote: >>> >>> >>> On 08 Jan 2014, at 15:53, Summers Pittman >> > wrote: >>> >>>> On 01/08/2014 09:42 AM, Tadeas Kriz wrote: >>>>> >>>>> On 08 Jan 2014, at 15:30, Summers Pittman >>>> > wrote: >>>>> >>>>>> On 01/08/2014 05:51 AM, Tadeas Kriz wrote: >>>>>>> Hey everyone, >>>>>>> >>>>>>> I've been recently going through the DataManager API in >>>>>>> aerogear-android. In this email, I'd like to suggest addiction >>>>>>> of two method (or possibly three) into the `Store` interface. >>>>>>> These would be: >>>>>>> >>>>>>> ```java >>>>>>> /** >>>>>>> * If store is open, it can be read or written to. >>>>>>> */ >>>>>>> boolean isOpen(); >>>>>>> >>>>>>> /** >>>>>>> * Opens store in current thread (blocking). >>>>>>> */ >>>>>>> Store open(); >>>>>>> >>>>>>> /** >>>>>>> * Opens store in background thread and then callback#onSuccess >>>>>>> is called. >>>>>>> */ >>>>>>> void open(Callback> callback); >>>>>>> ``` >>>>>> I think those are fine. Feel free to JIRA it up and Passos and I will >>>>>> review. >>>>>>> >>>>>>>> From my point of view, this makes sense to be in the `Store` >>>>>>>> so I can switch between stores easily during development with >>>>>>>> no need to change other code. Also, if `read` or `write` >>>>>>>> operations are done with closed store, there are two possible >>>>>>>> workflows. First one is, that I'd fail and throw an exception. >>>>>>>> Second (and for me a preferred one) is, that all those methods >>>>>>>> would internally check if the store is open and if not, they'd >>>>>>>> call the `open` method. This also leads me to another API >>>>>>>> change for `Store`. >>>>>>> >>>>>>> ```java >>>>>>> /** >>>>>>> * Reads all the data from the underlying storage system >>>>>>> asynchronously. >>>>>>> */ >>>>>>> void readAll(Callback> callback); >>>>>>> >>>>>>> /** >>>>>>> * Reads a specific object/record from the underlying storage >>>>>>> system asynchronously. >>>>>>> */ >>>>>>> void read(Serializable id, Callback callback); >>>>>>> >>>>>>> /** >>>>>>> * Search for objects/records from the underlying storage system >>>>>>> asynchronously. >>>>>>> */ >>>>>>> void readWithFilter(ReadFilter filter, Callback> callback); >>>>>>> >>>>>>> /** >>>>>>> * Saves the given object in the underlying storage system >>>>>>> asynchronously. >>>>>>> */ >>>>>>> void save(T item, Callback callback); >>>>>>> >>>>>>> /** >>>>>>> * Resets the entire storage system asynchronously. >>>>>>> */ >>>>>>> void reset(Callback callback); >>>>>>> >>>>>>> /** >>>>>>> * Removes a specific object/record from the underlying storage >>>>>>> system asynchronously. >>>>>>> */ >>>>>>> void remove(Serializable id, Callback callback); >>>>>>> >>>>>>> /** >>>>>>> * Checks if the storage system contains no stored elements >>>>>>> asynchronously. >>>>>>> */ >>>>>>> void isEmpty(Callback callback); >>>>>>> ``` >>>>>>> >>>>>>> That's right, async methods for easy access to the storage from >>>>>>> background thread, without the pain of writing it myself (for >>>>>>> example, it makes no sense if I want to just call >>>>>>> `store.save(..)` and I'd have to write all the `AsyncTask` >>>>>>> boilerplate). >>>>>>> >>>>>>> So, what do you think? >>>>>> >>>>>> I would rather throw an exception than open a database when you call >>>>>> read and friends. That way a developer doesn't accidentally open a >>>>>> database he meant to be closed. I don't have that strong of a >>>>>> feeling on >>>>>> that point one way or another however. >>>>> >>>>> That's right, it's probably less error prone in scenarios when you >>>>> want the store closed. >>>>> >>>>>> >>>>>> My stronger feeling is on adding callbacks to the stores methods. I >>>>>> prefer for the Store to be synchronous and Pipes to be >>>>>> asynchronous. We >>>>>> could add a StorePipe to our PypeTipes which may solve some of >>>>>> the headache. >>>>>> >>>>> >>>>> Would "void open(Callback> callback);" make sense then? I >>>>> mean, that would add another inconsistency in the API, as one >>>>> method would be async and the rest would be only synchronous, >>>>> wouldn't it? >>>> True. The reason for the exception here was that opening a SQL >>>> store or an encrypted store COULD take significant amount of time. >>>> For in Memory data stores this is instant of course. >>> I understand, but that's just an assumption. Let's say that there's >>> a storage, that'd take an instant to load data from, but a lot of >>> time to save data (like XML file based store). What's the main >>> reason to not have async "read"/"write" methods? >> >> The best reason I can give is if your Store implementation will be >> that slow either a) Write a Pipe instead or b) Manage the latency >> yourself. >> >> In Android land you want code on your main thread to be fast or non >> blocking. If we are working off the main thread then having things >> be slow and blocking is less of an issue. Synchronous code is easier >> to debug (in Java) and easier to write (in Java) and faster (because >> we don't have to route through callback classes). >> >> Having either or, in my opinion, clouds what your usage target should be. >> >> Also this is the most though Stores have been given in a long time. >> Anything we come up with we will probably need to get the other >> platforms alerted to as well. >> > Well, sometimes you want to reload a ListView data and it'd make it so > easy to just call "store.readAll(callback)" where in > callback#onSuccess you'd remove progress indicator and notify the > ListView about new data. > > BTW, I've been working on new DataManager API, which would be a lot > more interesting for users (right now the need to cast it and also > that it's not easily extendable is a pain), so when I'm done with > that, I'll start another thread here on ML ;) Awesome. I'm actually running into / ran into some of these issues with the DevNexus app I wrote. One of my original ideas for the Store implementations on Android would be they are very easy to integrated into ContentProviders which are async on their own. I never actually tested this idea so when you get your new Datamanage API up we can think about lots of things. >> >>>>> >>>>>> Passos, wdyt? >>>>>> >>>>>> >>>>>>> >>>>>>> PS: You can find the whole text with highlighted syntax here: >>>>>>> >>>>>>> --- >>>>>>> Tadeas Kriz >>>>>>> tkriz at redhat.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 >>>> >>>> _______________________________________________ >>>> 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/20140108/7a4bf767/attachment-0001.html From lholmqui at redhat.com Wed Jan 8 11:12:58 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 8 Jan 2014 11:12:58 -0500 Subject: [aerogear-dev] AG JS 1.3.2 Message-ID: <95321F51-20FA-46BA-B04B-4279549A8B7B@redhat.com> hi peeps, so i found a bug in our DataManager WebSQL adapter, https://issues.jboss.org/browse/AGJS-123 It's been fixed and merged, so i'm going to do a 1.3.2 release -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140108/d612c323/attachment.html From lholmqui at redhat.com Wed Jan 8 14:27:47 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 8 Jan 2014 14:27:47 -0500 Subject: [aerogear-dev] sync In-Reply-To: <52CADA11.5070402@redhat.com> References: <52C5822E.5080407@redhat.com> <20140106044233.GA70219@rohan.local> <52CADA11.5070402@redhat.com> Message-ID: i might be getting ahead of things, but i put together an initial thought of what i think the JS lib will sort of look like for sync https://gist.github.com/lholmquist/ae12f397dcfaa1fb7e2c i know there are somethings i still need to add, but i needed to get the thoughts out of my head On Jan 6, 2014, at 11:30 AM, Summers Pittman wrote: > On 01/05/2014 11:42 PM, Douglas Campos wrote: >> On Thu, Jan 02, 2014 at 10:13:50AM -0500, Summers Pittman wrote: >>> On 12/20/2013 06:34 AM, Erik Jan de Wit wrote: >>>> So we already agreed that CouchDB has some nice features, but why >>>> wouldn?t we just use pouchdb for javascript and touchdb? I?ve just >>>> tested the javascript and it syncs with the server perfectly, even >>>> if there are some things missing we could add them because these >>>> projects are open source. >>> Because wrapping CouchDB and friends to AeroGear with no other reason >>> than to create a org.jboss.sync name space is dumb. >> can't +9001 enough >> >>> Also the how of sync is still a bit far off. I'm still interested in the >>> "what" of sync. What use cases are we supporting, what features are we >>> supporting, what are our goals, what does a working finished sync impl >>> look like, etc. >> drafted here: https://gist.github.com/qmx/8278287 >> >> # aerogear-sync >> >> While I was reviewing Summers' code and ideas, I realized that I really wanted >> everything he did, but as a second step after we nail down the basics. >> >> ## basics? >> >> Since we've been catering the enterprise market, this essentially means we need >> to get the __boring__ stuff right first, then move over to the __shiny__ stuff, >> like realtime data sync, update policies & friends. >> >> ### data model >> >> For starters, I think that the most important thing that needs to be agreed >> upon is the data model and the atomic operations around it. As previous >> discussed, I really like CouchDB's datamodel -- and hate erlang ;) >> >> `{_id:, content:, rev:}` >> >> #### JS >> >> Well, it's JSON, it _Just Works_™ >> >> #### Java >> >> I didn't want to pick on Java, but since its fame forces me to it. First stab >> (a courtesy of our friend Dan Bevenius): >> >> public interface Document { >> public String id; >> public String content; >> public String rev; >> } >> >> We naturally want to kick this a notch, and use objects instead of plain strings: >> >> public interface Document { >> public ID id; >> public T content; >> public String rev; >> } >> >> In this case, we can use the convention requiring that `T` is any **object >> serializable to JSON**. `ID` is a convenience shorthand since it's a >> **GUID/UUID**. I think this key isn't necessarily a natural key (a surrogate >> key instead). >> >> #### Objective-C >> >> ;) >> >> ### API levels >> >> As soon as we have a rough data-model defined, we can start dabbling around >> different API levels to be served: >> >> (parts **I think** are potentially deliverable for a 1.0) >> >> - level 0: explodes when there's a conflict >> - level 1: semi-automatic conflict resolution via something like google's diff-match-patch >> - level 2: business rules determine who wins a conflicting update (supervisor >> wins over normal user) >> >> (parts **I think** are potentially deliverable for a 2.0) >> >> - level 3: real-time updates via diff-match-patch >> - level 4: real-time updates via OT/EC >> >> All those proposed API operations should be serializable, meaning I can >> potentially keep doing changes offline then just replying them to the server >> when online. >> >> ### transport >> >> Since we know about the future-looking ideas on v2.0, it would be really nice >> for us to specify a very simple/dumb JSON-based protocol for those change >> messages. Something that could accomodate both the full document updates and >> the OT/EC incremental bits too. I have no ideas on this, tbh. >> >> ## boring usecases >> >> ### scenario 1 >> >> Building inspector system - we have mobile apps that store relevant info and >> are bound to be accessed on places where we won't have any kind of connection, >> or very poor signal. >> >> You can have several inspectors screening the same building simultaneously. >> >> Let's say we have Agnes and Joe are doing the fire extinguisher inspection in a >> new hospital building. Technically each fire extinguisher has its own >> identifier and can be an independent document. In this case we would have no >> conflict happening. >> >> Now they start finding expired fire extinguishers and start to add them to the >> report. This report could potentially have two divergent lists of fire >> extinguishers to be replenished/revalidated, as the building's compliance >> status. >> >> ### scenario 2 >> >> Census system - we have mobile apps focused on offline data collection. We have >> the previous year's info that needs to be updated on the server. The >> interviewee needs to take a call, then asks the interviewer to come back later. >> This results in two sets of changes for the same document, stacked together, >> which should work flawlessly. >> >> Any other ideas/comments? > > I'll add now :) > > ## Transactions > > These are the most basic parts of sync I can think of that our system should be able to do/manage. Our internal representation of the client documents and collections should make implementing this automatically and without user intervention as simple as possible > > * Detect Change > When a user changes her local data, the system should note the change and generate a sync message to send to the server. This can be done automatically or manually but SHOULD be done automatically. > > * Send update > When a sync message is ready to be sent, and the system allows for it to be sent (network available, not in blackout window from exponential backoff, etc) then sync message should be sent. This SHOULD be done automatically. > > * Receive Update > When a client updates it data and successfully syncs to the remote server, the remote server will notify all of the relevant clients. The client must automatically and without user intervention receive this update and either act on it or store it for later processing. > > * Apply Update > Once a client application has an update message from the server, it can apply the message correctly to the data on it. This should be done automatically as part of receiving the update, but it may be done manually or may be delayed and automatically executed later. > > * Detect Conflict > When applying an update fails, the system must detect this. The system will provide state to the application and/or the user to handle the conflict. The user MUST NOT have to check for conflicts on her own. > > * Resolve Conflict > There must be a mechanism for resolving a conflict. The CAN be done automatically using default resolvers provided by AeroGear, by using a resolver provided by the developer/user, or by the app user selecting the correct merge. This will probably generate a new sync message. > > > >> >> >> >> _______________________________________________ >> 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/20140108/b713a195/attachment.html From supittma at redhat.com Wed Jan 8 16:07:33 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 08 Jan 2014 16:07:33 -0500 Subject: [aerogear-dev] Sync data model comparison Message-ID: <52CDBE15.1040902@redhat.com> So I'm not sure I see how the data model in the current sync spec helps with syncing data. Also the current spec draft is lacking a transport format as well. I propose using the dual shadow data model described here: https://neil.fraser.name/writing/sync/ ## Data Model: and Transport: Client side each piece of data which is currently in active synchronization (ie the client is sending AND receiving updates at the same time) has a copy of her data which represents the current assumed good synchronized state. She also has the copy of the data she is editing. When she has finished her edit (for an use case specific defined by the developer definition of finish) the system will generate a diff based on the JSON representations of her shadow and her model. The model will replace the shadow and a diff of her data as well as a checksum of her data will be sent to the server for processing. Server side the server will maintain its own model of the shared data, as well as shadows for each session currently sync the data. When it receives a sync, the diff will be applied to the server's shadow of the session which sent the diff. If the diff merges cleanly and the checksum of the server shadow matches the checksum in the transport, then the server will update the canonical model of the data against what was in the session's updated shadow. The server will then diff all of its sessions' shadows against its model and send out diff messages to the clients. I've made a spreadsheet* where I follow one of QMX's sample applications and step through a few workflows with my proposed data model. (This is the data model I use in the DevNexus sync demo and the real time text demo). I would welcome someone to implement the use case with QMX's proposed data model. * https://docs.google.com/spreadsheet/ccc?key=0AjSy-Z4v4qE-dGhESFU5R1BSWTF3RnliMjVic3JnbXc#gid=1 wdyt? Who would mind doing the data flow for the other model? From bruno at abstractj.org Thu Jan 9 01:43:42 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 9 Jan 2014 04:43:42 -0200 Subject: [aerogear-dev] Sync data model comparison In-Reply-To: <52CDBE15.1040902@redhat.com> References: <52CDBE15.1040902@redhat.com> Message-ID: Good morning Summers, it sounds like a fancy good idea. Out of curiosity do you know where such method was applied for real? Not advocating in favor of CouchDB, but might be interesting to look at: http://wiki.apache.org/couchdb/Replication_and_conflicts and http://guide.couchdb.org/draft/consistency.html#figure/6. One open question still in my mind. For the server side bits. Why not just make use of a provider? For example on SPS for data stores Dan have implemented something like this:?https://github.com/aerogear/aerogear-simplepush-server/tree/master/datastores ps: I?m not against us implementing anything new. -- abstractj On January 8, 2014 at 7:07:40 PM, Summers Pittman (supittma at redhat.com) wrote: > > So I'm not sure I see how the data model in the current sync spec > helps > with syncing data. Also the current spec draft is lacking a transport > format as well. > > I propose using the dual shadow data model described here: > https://neil.fraser.name/writing/sync/ > > ## Data Model: and Transport: > > Client side each piece of data which is currently in active > synchronization (ie the client is sending AND receiving updates > at the > same time) has a copy of her data which represents the current > assumed > good synchronized state. She also has the copy of the data she > is > editing. When she has finished her edit (for an use case specific > defined by the developer definition of finish) the system will > generate > a diff based on the JSON representations of her shadow and her > model. > The model will replace the shadow and a diff of her data as well > as a > checksum of her data will be sent to the server for processing. > > Server side the server will maintain its own model of the shared > data, > as well as shadows for each session currently sync the data. When > it > receives a sync, the diff will be applied to the server's shadow > of the > session which sent the diff. If the diff merges cleanly and the > checksum of the server shadow matches the checksum in the transport, > then the server will update the canonical model of the data against > what > was in the session's updated shadow. The server will then diff > all of > its sessions' shadows against its model and send out diff messages > to > the clients. > > I've made a spreadsheet* where I follow one of QMX's sample applications > and step through a few workflows with my proposed data model. > (This is > the data model I use in the DevNexus sync demo and the real time > text > demo). I would welcome someone to implement the use case with > QMX's > proposed data model. > > * > https://docs.google.com/spreadsheet/ccc?key=0AjSy-Z4v4qE-dGhESFU5R1BSWTF3RnliMjVic3JnbXc#gid=1 > > wdyt? Who would mind doing the data flow for the other model? > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > From corinnekrych at gmail.com Thu Jan 9 04:50:17 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 9 Jan 2014 10:50:17 +0100 Subject: [aerogear-dev] Planning iOS 1.4.0 release Message-ID: <1DE09130-F636-48D5-B970-7DF9B14A8EBE@gmail.com> Hello Guys, I've started an agenda for our next iOS meeting. http://oksoclap.com/p/iOS-team-meeting-10-01-2014 Feel free to add to it. ++ Corinne From tkriz at redhat.com Thu Jan 9 06:11:33 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Thu, 9 Jan 2014 12:11:33 +0100 Subject: [aerogear-dev] DataManager API draft Message-ID: <257882D2-B914-485C-B9BB-EE0926448376@redhat.com> Hey, It?s me again with more changes to the DataManager API. I?ve tried many different approaches and this one is basically the only one I got to work as intended (these are only interfaces, no real implementation, but that?s not a problem as it won?t make it much difficult to change current implementations to match those interfaces). Basically, it?s not the best and I had better APIs, but they unfortunately weren?t possible because of restrictions in Java. You can find the draft here: https://gist.github.com/TadeasKriz/e0f5583e2a24c32dc253 What can I say about this API is, that in this approach the user shouldn?t need to cast the Store (which is real pain in current API) unless he really needs to (like some methods that?ll be available only for the store he wants). In other cases, when the cast is not needed, users will be able to just work with the Store and change the underlying store as they like. So let?s say they?ll be working with MemoryStore in development, because it?s easier to debug. Then the release will be closing in, they?ll just switch to SQLStore very easily. So, what do you think guys? ? Tadeas Kriz tkriz at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140109/5f08955d/attachment.html From supittma at redhat.com Thu Jan 9 09:37:15 2014 From: supittma at redhat.com (Summers Pittman) Date: Thu, 09 Jan 2014 09:37:15 -0500 Subject: [aerogear-dev] Sync data model comparison In-Reply-To: References: <52CDBE15.1040902@redhat.com> Message-ID: <52CEB41B.30604@redhat.com> On Thu 09 Jan 2014 01:43:42 AM EST, Bruno Oliveira wrote: > Good morning Summers, it sounds like a fancy good idea. Out of curiosity do you know where such method was applied for real? > > Not advocating in favor of CouchDB, but might be interesting to look at: http://wiki.apache.org/couchdb/Replication_and_conflicts and http://guide.couchdb.org/draft/consistency.html#figure/6. > > One open question still in my mind. For the server side bits. Why not just make use of a provider? For example on SPS for data stores Dan have implemented something like this: https://github.com/aerogear/aerogear-simplepush-server/tree/master/datastores > > ps: I?m not against us implementing anything new. One of the things about using a provider that I don't like is the "using a provider". One of the things I hope sync to become is a collection of tools, utilities, and patterns that our developers can adopt to add in sync to their web apps without having to add extra services like couch, pouch, etc and without having to significantly alter their application. HOWEVER, I am still reading up on / playing with Couch so don't count me out on thinking it is a good way to go forward; I just havn't seen any code to get the feel for how it will interact inside of AeroGear. It is entirely possible that it will be / can be one of the tools that we use for some of our sync solution. > > -- > abstractj > > On January 8, 2014 at 7:07:40 PM, Summers Pittman (supittma at redhat.com) wrote: >> >> So I'm not sure I see how the data model in the current sync spec >> helps >> with syncing data. Also the current spec draft is lacking a transport >> format as well. >> >> I propose using the dual shadow data model described here: >> https://neil.fraser.name/writing/sync/ >> >> ## Data Model: and Transport: >> >> Client side each piece of data which is currently in active >> synchronization (ie the client is sending AND receiving updates >> at the >> same time) has a copy of her data which represents the current >> assumed >> good synchronized state. She also has the copy of the data she >> is >> editing. When she has finished her edit (for an use case specific >> defined by the developer definition of finish) the system will >> generate >> a diff based on the JSON representations of her shadow and her >> model. >> The model will replace the shadow and a diff of her data as well >> as a >> checksum of her data will be sent to the server for processing. >> >> Server side the server will maintain its own model of the shared >> data, >> as well as shadows for each session currently sync the data. When >> it >> receives a sync, the diff will be applied to the server's shadow >> of the >> session which sent the diff. If the diff merges cleanly and the >> checksum of the server shadow matches the checksum in the transport, >> then the server will update the canonical model of the data against >> what >> was in the session's updated shadow. The server will then diff >> all of >> its sessions' shadows against its model and send out diff messages >> to >> the clients. >> >> I've made a spreadsheet* where I follow one of QMX's sample applications >> and step through a few workflows with my proposed data model. >> (This is >> the data model I use in the DevNexus sync demo and the real time >> text >> demo). I would welcome someone to implement the use case with >> QMX's >> proposed data model. >> >> * >> https://docs.google.com/spreadsheet/ccc?key=0AjSy-Z4v4qE-dGhESFU5R1BSWTF3RnliMjVic3JnbXc#gid=1 >> >> wdyt? Who would mind doing the data flow for the other model? >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > From bruno at abstractj.org Thu Jan 9 11:06:26 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 9 Jan 2014 14:06:26 -0200 Subject: [aerogear-dev] Sync data model comparison In-Reply-To: <52CEB41B.30604@redhat.com> References: <52CDBE15.1040902@redhat.com> <52CEB41B.30604@redhat.com> Message-ID: Makes sense, I think that?s a great start is to integrate your idea against what Dan already did to the server, into this way we can start to put together our puzzle. -- abstractj On January 9, 2014 at 12:37:19 PM, Summers Pittman (supittma at redhat.com) wrote: > > One of the things about using a provider that I don't like is the > "using a provider". One of the things I hope sync to become is a > collection of tools, utilities, and patterns that our developers > can > adopt to add in sync to their web apps without having to add extra > services like couch, pouch, etc and without having to significantly > alter their application. > > HOWEVER, I am still reading up on / playing with Couch so don't > count > me out on thinking it is a good way to go forward; I just havn't seen > any code to get the feel for how it will interact inside of AeroGear. > It is entirely possible that it will be / can be one of the tools > that > we use for some of our sync solution. From supittma at redhat.com Thu Jan 9 11:07:02 2014 From: supittma at redhat.com (Summers Pittman) Date: Thu, 09 Jan 2014 11:07:02 -0500 Subject: [aerogear-dev] Sync data model comparison In-Reply-To: References: <52CDBE15.1040902@redhat.com> <52CEB41B.30604@redhat.com> Message-ID: <52CEC926.8070804@redhat.com> On Thu 09 Jan 2014 11:06:26 AM EST, Bruno Oliveira wrote: > Makes sense, I think that?s a great start is to integrate your idea against what Dan already did to the server, into this way we can start to put together our puzzle. Yup, just got Danbev's server up and running. I'll see what happens :) > > -- > abstractj > > On January 9, 2014 at 12:37:19 PM, Summers Pittman (supittma at redhat.com) wrote: >>> One of the things about using a provider that I don't like is the >> "using a provider". One of the things I hope sync to become is a >> collection of tools, utilities, and patterns that our developers >> can >> adopt to add in sync to their web apps without having to add extra >> services like couch, pouch, etc and without having to significantly >> alter their application. >> >> HOWEVER, I am still reading up on / playing with Couch so don't >> count >> me out on thinking it is a good way to go forward; I just havn't seen >> any code to get the feel for how it will interact inside of AeroGear. >> It is entirely possible that it will be / can be one of the tools >> that >> we use for some of our sync solution. > From Wolfgang.Frank at arconsis.com Fri Jan 10 06:05:22 2014 From: Wolfgang.Frank at arconsis.com (Wolfgang) Date: Fri, 10 Jan 2014 03:05:22 -0800 (PST) Subject: [aerogear-dev] Unified Push Server integration capabilities Message-ID: <1389351922848-5755.post@n5.nabble.com> Hello dear aerogear dev team, a couple of weeks ago we had to integrate a PushServer for iOS and Android into our solution. We used the UPS out-of-the-box for a first prototype to figure out better the capabilities and to be able to better define the requirements in regards to push. So far we are very excited about the product! The drawback is that some piece of information like devices, users, apps as are represented in another system (i.e. MongoDB) or capabilities like authorization/authentication are already present. Thus there is some redundancy and overhead and the UPS is a little bit alien in regards to the rest of the existing architecture/infrastructure. This has pre and cons -- I know ... I thought that maybe a "simple"/exchangable mechanisms (e.g. persistence layer) of defined integration interfaces and mechanisms would be great in order to be able to better integrate the UPS in existing or already constrained system environments. This might also help in regards to scalability and flexibility of the existing design/architecture. Wondered if that would make sense in your opinion ... ? ~Wolfgang -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/Unified-Push-Server-integration-capabilities-tp5755.html Sent from the aerogear-dev mailing list archive at Nabble.com. From daniel.bevenius at gmail.com Fri Jan 10 08:06:13 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 10 Jan 2014 14:06:13 +0100 Subject: [aerogear-dev] Team meeting agenda Message-ID: Proposed agenda for Mondays team meeting: http://oksoclap.com/p/aerogear-team-mgt-20140113 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140110/6a7941cd/attachment.html From matzew at apache.org Fri Jan 10 08:44:06 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 10 Jan 2014 14:44:06 +0100 Subject: [aerogear-dev] Unified Push Server integration capabilities In-Reply-To: <1389351922848-5755.post@n5.nabble.com> References: <1389351922848-5755.post@n5.nabble.com> Message-ID: Hello Wolfgang, thanks for using our UnifiedPush Server! We are happy that you guys are excited about it so far. The drawbacks you mention make sense, and sharing these requirements is important feedback for us. For Feb/March we already have some refactorings on our agenda ([1]) and we also recently started looking at Keycloak for auth management (as one option). So yes, your request seems very reasonable, and it does make sense to take a deeper look at a "plugable" system. Thanks again for sharing this valuable feedback. Greetings, Matthias [1] http://aerogear.org/docs/planning/roadmaps/UnifiedPush/ On Fri, Jan 10, 2014 at 12:05 PM, Wolfgang wrote: > Hello dear aerogear dev team, > > a couple of weeks ago we had to integrate a PushServer for iOS and Android > into our solution. We used the UPS out-of-the-box for a first prototype to > figure out better the capabilities and to be able to better define the > requirements in regards to push. So far we are very excited about the > product! > > The drawback is that some piece of information like devices, users, apps as > are represented in another system (i.e. MongoDB) or capabilities like > authorization/authentication are already present. Thus there is some > redundancy and overhead and the UPS is a little bit alien in regards to the > rest of the existing architecture/infrastructure. This has pre and cons -- > I > know ... > > I thought that maybe a "simple"/exchangable mechanisms (e.g. persistence > layer) of defined integration interfaces and mechanisms would be great in > order to be able to better integrate the UPS in existing or already > constrained system environments. This might also help in regards to > scalability and flexibility of the existing design/architecture. > > Wondered if that would make sense in your opinion ... ? > > ~Wolfgang > > > > -- > View this message in context: > http://aerogear-dev.1069024.n5.nabble.com/Unified-Push-Server-integration-capabilities-tp5755.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 > -- 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/20140110/0dacec8a/attachment-0001.html From lholmqui at redhat.com Fri Jan 10 10:29:52 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 10 Jan 2014 10:29:52 -0500 Subject: [aerogear-dev] Sync data model comparison In-Reply-To: <52CEC926.8070804@redhat.com> References: <52CDBE15.1040902@redhat.com> <52CEB41B.30604@redhat.com> <52CEC926.8070804@redhat.com> Message-ID: <9B8CB3DA-A401-4849-9529-62226F92E493@redhat.com> after playing with dan's server a bit, a question has popped up. lets say a user has 10 pieces of data, is this considered 1 "document", so like this: { id: "1234567890-0987654321-1234567890", rev: "12345678909876543456787654", content: [ { ... }, { ... } ] //make believe there are 10 things there } or is each piece of data a "document", and each piece has its own id and revision? I think i like the first option, but i'm not sure On Jan 9, 2014, at 11:07 AM, Summers Pittman wrote: > On Thu 09 Jan 2014 11:06:26 AM EST, Bruno Oliveira wrote: >> Makes sense, I think that?s a great start is to integrate your idea against what Dan already did to the server, into this way we can start to put together our puzzle. > > Yup, just got Danbev's server up and running. I'll see what happens :) > >> >> -- >> abstractj >> >> On January 9, 2014 at 12:37:19 PM, Summers Pittman (supittma at redhat.com) wrote: >>>> One of the things about using a provider that I don't like is the >>> "using a provider". One of the things I hope sync to become is a >>> collection of tools, utilities, and patterns that our developers >>> can >>> adopt to add in sync to their web apps without having to add extra >>> services like couch, pouch, etc and without having to significantly >>> alter their application. >>> >>> HOWEVER, I am still reading up on / playing with Couch so don't >>> count >>> me out on thinking it is a good way to go forward; I just havn't seen >>> any code to get the feel for how it will interact inside of AeroGear. >>> It is entirely possible that it will be / can be one of the tools >>> that >>> we use for some of our sync solution. >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From daniel.bevenius at gmail.com Fri Jan 10 10:32:17 2014 From: daniel.bevenius at gmail.com (Daniel Bevenius) Date: Fri, 10 Jan 2014 16:32:17 +0100 Subject: [aerogear-dev] Sync data model comparison In-Reply-To: <9B8CB3DA-A401-4849-9529-62226F92E493@redhat.com> References: <52CDBE15.1040902@redhat.com> <52CEB41B.30604@redhat.com> <52CEC926.8070804@redhat.com> <9B8CB3DA-A401-4849-9529-62226F92E493@redhat.com> Message-ID: In the current implementation that would be considered one document. On 10 January 2014 16:29, Lucas Holmquist wrote: > after playing with dan's server a bit, a question has popped up. > > lets say a user has 10 pieces of data, is this considered 1 "document", > so like this: > > { > id: "1234567890-0987654321-1234567890", > rev: "12345678909876543456787654", > content: [ { ... }, { ... } ] //make believe there are 10 things there > } > > or is each piece of data a "document", and each piece has its own id and > revision? > > I think i like the first option, but i'm not sure > > > On Jan 9, 2014, at 11:07 AM, Summers Pittman wrote: > > > On Thu 09 Jan 2014 11:06:26 AM EST, Bruno Oliveira wrote: > >> Makes sense, I think that?s a great start is to integrate your idea > against what Dan already did to the server, into this way we can start to > put together our puzzle. > > > > Yup, just got Danbev's server up and running. I'll see what happens :) > > > >> > >> -- > >> abstractj > >> > >> On January 9, 2014 at 12:37:19 PM, Summers Pittman (supittma at redhat.com) > wrote: > >>>> One of the things about using a provider that I don't like is the > >>> "using a provider". One of the things I hope sync to become is a > >>> collection of tools, utilities, and patterns that our developers > >>> can > >>> adopt to add in sync to their web apps without having to add extra > >>> services like couch, pouch, etc and without having to significantly > >>> alter their application. > >>> > >>> HOWEVER, I am still reading up on / playing with Couch so don't > >>> count > >>> me out on thinking it is a good way to go forward; I just havn't seen > >>> any code to get the feel for how it will interact inside of AeroGear. > >>> It is entirely possible that it will be / can be one of the tools > >>> that > >>> we use for some of our sync solution. > >> > > > > > > _______________________________________________ > > 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/20140110/e8c53989/attachment.html From corinnekrych at gmail.com Mon Jan 13 03:49:15 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 13 Jan 2014 09:49:15 +0100 Subject: [aerogear-dev] Planning iOS 1.4.0 release In-Reply-To: <1DE09130-F636-48D5-B970-7DF9B14A8EBE@gmail.com> References: <1DE09130-F636-48D5-B970-7DF9B14A8EBE@gmail.com> Message-ID: <59FC7D1C-5241-4610-B836-2AAC30440A27@gmail.com> What about panning it for tuesday 2pm (usual iOS meeting slot)? ++ Corinne On Jan 9, 2014, at 10:50 AM, Corinne Krych wrote: > Hello Guys, > > I've started an agenda for our next iOS meeting. > http://oksoclap.com/p/iOS-team-meeting-10-01-2014 > > Feel free to add to it. > > ++ > Corinne From matzew at apache.org Mon Jan 13 04:12:35 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 13 Jan 2014 10:12:35 +0100 Subject: [aerogear-dev] Planning iOS 1.4.0 release In-Reply-To: <59FC7D1C-5241-4610-B836-2AAC30440A27@gmail.com> References: <1DE09130-F636-48D5-B970-7DF9B14A8EBE@gmail.com> <59FC7D1C-5241-4610-B836-2AAC30440A27@gmail.com> Message-ID: +1 On Mon, Jan 13, 2014 at 9:49 AM, Corinne Krych wrote: > What about panning it for tuesday 2pm (usual iOS meeting slot)? > > ++ > Corinne > On Jan 9, 2014, at 10:50 AM, Corinne Krych wrote: > > > Hello Guys, > > > > I've started an agenda for our next iOS meeting. > > http://oksoclap.com/p/iOS-team-meeting-10-01-2014 > > > > Feel free to add to it. > > > > ++ > > Corinne > > _______________________________________________ > 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/20140113/c01c7869/attachment.html From cvasilak at gmail.com Mon Jan 13 04:29:31 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 13 Jan 2014 11:29:31 +0200 Subject: [aerogear-dev] Planning iOS 1.4.0 release In-Reply-To: References: <1DE09130-F636-48D5-B970-7DF9B14A8EBE@gmail.com> <59FC7D1C-5241-4610-B836-2AAC30440A27@gmail.com> Message-ID: +1 - Christos On Jan 13, 2014, at 11:12 AM, Matthias Wessendorf wrote: > +1 > > > On Mon, Jan 13, 2014 at 9:49 AM, Corinne Krych wrote: > What about panning it for tuesday 2pm (usual iOS meeting slot)? > > ++ > Corinne > On Jan 9, 2014, at 10:50 AM, Corinne Krych wrote: > > > Hello Guys, > > > > I've started an agenda for our next iOS meeting. > > http://oksoclap.com/p/iOS-team-meeting-10-01-2014 > > > > Feel free to add to it. > > > > ++ > > Corinne > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140113/85a351d2/attachment.html From edewit at redhat.com Mon Jan 13 04:36:38 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 13 Jan 2014 10:36:38 +0100 Subject: [aerogear-dev] java simple push / unified client Message-ID: Hi, I just finished a quick POC to see how hard it would be to create a simple push java client. And guess what it wasn?t hard at all only 20 / 30 lines of code. Now to make this a proper lib I was struggling a bit with how to name this thing. So I?m keeping close to the JS version as this is the same functionality. So I also have a UnifiedPushClient, that enables you to register your simple push endpoint. This would be about one class so I don?t think we would need a separate module for this. But that does make the naming of this module harder :) I was thinking just calling it aerogear-simplepush-java so what do you think? Cheers, Erik Jan From scm.blanc at gmail.com Mon Jan 13 04:47:32 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 13 Jan 2014 10:47:32 +0100 Subject: [aerogear-dev] java simple push / unified client In-Reply-To: References: Message-ID: Since Aerogear also offers a SPS "server" maybe it will be more clear if we specify it's a client lib like : aerogear-simplepush-java-client . Concerning the UPS bits, let's keep it in the same module as long we document it. On Mon, Jan 13, 2014 at 10:36 AM, Erik Jan de Wit wrote: > Hi, > > I just finished a quick POC to see how hard it would be to create a simple > push java client. And guess what it wasn?t hard at all only 20 / 30 lines > of code. Now to make this a proper lib I was struggling a bit with how to > name this thing. So I?m keeping close to the JS version as this is the same > functionality. So I also have a UnifiedPushClient, that enables you to > register your simple push endpoint. This would be about one class so I > don?t think we would need a separate module for this. But that does make > the naming of this module harder :) > > I was thinking just calling it aerogear-simplepush-java so 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/20140113/b6788e87/attachment-0001.html From daniel at passos.me Mon Jan 13 07:05:06 2014 From: daniel at passos.me (Daniel Passos) Date: Mon, 13 Jan 2014 10:05:06 -0200 Subject: [aerogear-dev] DataManager API draft In-Reply-To: <257882D2-B914-485C-B9BB-EE0926448376@redhat.com> References: <257882D2-B914-485C-B9BB-EE0926448376@redhat.com> Message-ID: I don?t know if I like the configuration know how create store, but I really like the registration approach?instead of ugly factory --? Daniel Passos On January 9, 2014 at 9:11:41 AM, Tadeas Kriz (tkriz at redhat.com) wrote: Hey, It?s me again with more changes to the DataManager API. I?ve tried many different approaches and this one is basically the only one I got to work as intended (these are only interfaces, no real implementation, but that?s not a problem as it won?t make it much difficult to change current implementations to match those interfaces). Basically, it?s not the best and I had better APIs, but they unfortunately weren?t possible because of restrictions in Java. You can find the draft here:?https://gist.github.com/TadeasKriz/e0f5583e2a24c32dc253 What can I say about this API is, that in this approach the user shouldn?t need to cast the Store (which is real pain in current API) unless he really needs to (like some methods that?ll be available only for the store he wants). In other cases, when the cast is not needed, users will be able to just work with the Store and change the underlying store as they like. So let?s say they?ll be working with MemoryStore in development, because it?s easier to debug. Then the release will be closing in, they?ll just switch to SQLStore very easily. So, what do you think guys? ? Tadeas Kriz tkriz at redhat.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/20140113/f2e17e56/attachment.html From edewit at redhat.com Mon Jan 13 09:21:01 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 13 Jan 2014 15:21:01 +0100 Subject: [aerogear-dev] java simple push / unified client In-Reply-To: References: Message-ID: <72F02973-9DAC-4CE3-A920-7AD2BB13119E@redhat.com> So it will be renamed but here is an initial version: https://github.com/edewit/aerogear-simplepush-java On 13 Jan,2014, at 10:47 , Sebastien Blanc wrote: > Since Aerogear also offers a SPS "server" maybe it will be more clear if we specify it's a client lib like : aerogear-simplepush-java-client . > Concerning the UPS bits, let's keep it in the same module as long we document it. > > > On Mon, Jan 13, 2014 at 10:36 AM, Erik Jan de Wit wrote: > Hi, > > I just finished a quick POC to see how hard it would be to create a simple push java client. And guess what it wasn?t hard at all only 20 / 30 lines of code. Now to make this a proper lib I was struggling a bit with how to name this thing. So I?m keeping close to the JS version as this is the same functionality. So I also have a UnifiedPushClient, that enables you to register your simple push endpoint. This would be about one class so I don?t think we would need a separate module for this. But that does make the naming of this module harder :) > > I was thinking just calling it aerogear-simplepush-java so 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 > > _______________________________________________ > 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/20140113/d01e0461/attachment.html From tkriz at redhat.com Mon Jan 13 09:23:52 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Mon, 13 Jan 2014 15:23:52 +0100 Subject: [aerogear-dev] DataManager API draft In-Reply-To: References: <257882D2-B914-485C-B9BB-EE0926448376@redhat.com> Message-ID: <796041FB-0F83-4283-AF35-DE2F2C36DE57@redhat.com> It might not be named ?Configuration?. It could be a ?Builder? instead, how about that? ? Tadeas Kriz tkriz at redhat.com On 13 Jan 2014, at 13:05, Daniel Passos wrote: > I don?t know if I like the configuration know how create store, but I really like the registration approach instead of ugly factory > > -- > Daniel Passos > > On January 9, 2014 at 9:11:41 AM, Tadeas Kriz (tkriz at redhat.com) wrote: > >> Hey, >> >> It?s me again with more changes to the DataManager API. I?ve tried many different approaches and this one is basically the only one I got to work as intended (these are only interfaces, no real implementation, but that?s not a problem as it won?t make it much difficult to change current implementations to match those interfaces). Basically, it?s not the best and I had better APIs, but they unfortunately weren?t possible because of restrictions in Java. >> >> You can find the draft here: https://gist.github.com/TadeasKriz/e0f5583e2a24c32dc253 >> >> What can I say about this API is, that in this approach the user shouldn?t need to cast the Store (which is real pain in current API) unless he really needs to (like some methods that?ll be available only for the store he wants). In other cases, when the cast is not needed, users will be able to just work with the Store and change the underlying store as they like. So let?s say they?ll be working with MemoryStore in development, because it?s easier to debug. Then the release will be closing in, they?ll just switch to SQLStore very easily. >> >> So, what do you think guys? >> >> ? >> Tadeas Kriz >> tkriz at redhat.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/20140113/be9a7ec0/attachment.html From daniel at passos.me Mon Jan 13 09:52:19 2014 From: daniel at passos.me (Daniel Passos) Date: Mon, 13 Jan 2014 12:52:19 -0200 Subject: [aerogear-dev] DataManager API draft In-Reply-To: <796041FB-0F83-4283-AF35-DE2F2C36DE57@redhat.com> References: <257882D2-B914-485C-B9BB-EE0926448376@redhat.com> <796041FB-0F83-4283-AF35-DE2F2C36DE57@redhat.com> Message-ID: +1 --? Daniel Passos On January 13, 2014 at 12:23:53 PM, Tadeas Kriz (tkriz at redhat.com) wrote: It might not be named ?Configuration?. It could be a ?Builder? instead, how about that? ? Tadeas Kriz tkriz at redhat.com On 13 Jan 2014, at 13:05, Daniel Passos wrote: I don?t know if I like the configuration know how create store, but I really like the registration approach?instead of ugly factory --? Daniel Passos On January 9, 2014 at 9:11:41 AM, Tadeas Kriz (tkriz at redhat.com) wrote: Hey, It?s me again with more changes to the DataManager API. I?ve tried many different approaches and this one is basically the only one I got to work as intended (these are only interfaces, no real implementation, but that?s not a problem as it won?t make it much difficult to change current implementations to match those interfaces). Basically, it?s not the best and I had better APIs, but they unfortunately weren?t possible because of restrictions in Java. You can find the draft here:?https://gist.github.com/TadeasKriz/e0f5583e2a24c32dc253 What can I say about this API is, that in this approach the user shouldn?t need to cast the Store (which is real pain in current API) unless he really needs to (like some methods that?ll be available only for the store he wants). In other cases, when the cast is not needed, users will be able to just work with the Store and change the underlying store as they like. So let?s say they?ll be working with MemoryStore in development, because it?s easier to debug. Then the release will be closing in, they?ll just switch to SQLStore very easily. So, what do you think guys? ? Tadeas Kriz tkriz at redhat.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/20140113/6215443c/attachment-0001.html From scm.blanc at gmail.com Mon Jan 13 10:25:35 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 13 Jan 2014 16:25:35 +0100 Subject: [aerogear-dev] Team meeting agenda In-Reply-To: References: Message-ID: Et voila ! (04:24:59 PM) jbott: Meeting ended Mon Jan 13 15:13:08 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) (04:24:59 PM) jbott: Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-01-13-14.52.html (04:24:59 PM) jbott: Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-01-13-14.52.txt (04:24:59 PM) jbott: Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-01-13-14.52.log.html On Fri, Jan 10, 2014 at 2:06 PM, Daniel Bevenius wrote: > Proposed agenda for Mondays team meeting: > > http://oksoclap.com/p/aerogear-team-mgt-20140113 > > > > _______________________________________________ > 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/20140113/6edb45d7/attachment.html From matzew at apache.org Mon Jan 13 11:56:37 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 13 Jan 2014 17:56:37 +0100 Subject: [aerogear-dev] [iOS] Simple draft of HTTP API to talk to ag-sync server Message-ID: Hi, based on the ag.org "sync-branch" (see [1]), I created a SIMPLE first iOS hack of a "document" API with a HTTP client that talks to Dan's Server. The model ([2]) is quite easy/simple and the HTTP client supports CREATE/READ/REMOVE ([3]), based on the protocol defined on the README of the server. The usage is covered in a test (like [4]). Next: I guess next (if we continue using Dan's Server) is to see how this project can we weaved into the exisiting stores - but first I really wanted to get some client (like Luke's JS client) which executes against our current server draft/implementation. BTW. the lib is based on AFN2.x (not sure we should use AFN 2.x at THIS point - switching to 1.x should not be that hard) -Matthias [1] https://github.com/aerogear/aerogear.org/pull/230 [2] https://github.com/matzew/AGSyncKit/blob/master/SyncKit/AGDocument.h [3] https://github.com/matzew/AGSyncKit/blob/master/SyncKit/AGSyncClient.h [4] https://github.com/matzew/AGSyncKit/blob/master/SyncKitTests/SyncKitTests.m#L37-L61 -- 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/20140113/076e2234/attachment.html From tkriz at redhat.com Mon Jan 13 12:43:50 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Mon, 13 Jan 2014 18:43:50 +0100 Subject: [aerogear-dev] Strange encrypted store behavior Message-ID: <9933FC87-65AE-4A35-9894-4A2F92F51083@redhat.com> Hi there, in December, I?ve reported [1] and today Passos asked me if I could rather send it here to discuss it, as this behavior is the same in other platform?s implementations (which I wasn?t aware of before). So please read the description on that JIRA issue. Basically I have nothing more to say about it, what?s not in the description already. So, what do you think? 1 - https://issues.jboss.org/browse/AGDROID-173 ? Tadeas Kriz tkriz at redhat.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140113/45f7bd06/attachment.html From bruno at abstractj.org Mon Jan 13 20:23:19 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 13 Jan 2014 20:23:19 -0500 Subject: [aerogear-dev] Strange encrypted store behavior In-Reply-To: <9933FC87-65AE-4A35-9894-4A2F92F51083@redhat.com> References: <9933FC87-65AE-4A35-9894-4A2F92F51083@redhat.com> Message-ID: Hi Tadeas, replied on the same issue. On Mon, Jan 13, 2014 at 12:43 PM, Tadeas Kriz wrote: > Hi there, > > in December, I?ve reported [1] and today Passos asked me if I could rather > send it here to discuss it, as this behavior is the same in other > platform?s implementations (which I wasn?t aware of before). So please read > the description on that JIRA issue. Basically I have nothing more to say > about it, what?s not in the description already. So, what do you think? > > 1 - https://issues.jboss.org/browse/AGDROID-173 > > ? > Tadeas Kriz > tkriz at redhat.com > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140113/7370e3c6/attachment.html From corinnekrych at gmail.com Tue Jan 14 03:46:38 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 14 Jan 2014 09:46:38 +0100 Subject: [aerogear-dev] Strange encrypted store behavior In-Reply-To: References: <9933FC87-65AE-4A35-9894-4A2F92F51083@redhat.com> Message-ID: Hi Tadeas, I think you bring back on the table an unfinished discussion on the topic of AGPassphraseKeyServices(used in password demo app) vs. AGPasswordKeyServices (not used in any demo yet). In AGPasswordKeyServices the password is stored in secure local storage (KeyChain for iOS, KeyStore for Android), therefore you could do a password check at login time as stated in your workflow. I think we intended to have 2 diffences EncryptionServices for those differents usage. http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-Crypto-API-sample-td5306.html More work is needed for AGPasswordKeyServices and adding a demo/recipe app for it would be nice. @summers @cvasilak do you remember the discussion? As for the problem of encrypting with one passphrase then another one and not be able to decrypt any data afterward, I think this is an issue that should be fixed. JIRA needed. ++ Corinne On Jan 14, 2014, at 2:23 AM, Bruno Oliveira wrote: > Hi Tadeas, replied on the same issue. > > > On Mon, Jan 13, 2014 at 12:43 PM, Tadeas Kriz wrote: > Hi there, > > in December, I?ve reported [1] and today Passos asked me if I could rather send it here to discuss it, as this behavior is the same in other platform?s implementations (which I wasn?t aware of before). So please read the description on that JIRA issue. Basically I have nothing more to say about it, what?s not in the description already. So, what do you think? > > 1 - https://issues.jboss.org/browse/AGDROID-173 > > ? > Tadeas Kriz > tkriz at redhat.com > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From corinnekrych at gmail.com Tue Jan 14 06:45:56 2014 From: corinnekrych at gmail.com (Corinne) Date: Tue, 14 Jan 2014 12:45:56 +0100 Subject: [aerogear-dev] Planning iOS 1.4.0 release In-Reply-To: References: <1DE09130-F636-48D5-B970-7DF9B14A8EBE@gmail.com> <59FC7D1C-5241-4610-B836-2AAC30440A27@gmail.com> Message-ID: <2337FC5B-A256-4B31-9F41-81AA82E0A2AA@gmail.com> I might run late, sorry about that :( To be on the safe side, could we move it to 2:30pm? from my iPhone On 13 janv. 2014, at 10:29, Christos Vasilakis wrote: > +1 > > - > Christos > > > On Jan 13, 2014, at 11:12 AM, Matthias Wessendorf wrote: > >> +1 >> >> >> On Mon, Jan 13, 2014 at 9:49 AM, Corinne Krych wrote: >>> What about panning it for tuesday 2pm (usual iOS meeting slot)? >>> >>> ++ >>> Corinne >>> On Jan 9, 2014, at 10:50 AM, Corinne Krych wrote: >>> >>> > Hello Guys, >>> > >>> > I've started an agenda for our next iOS meeting. >>> > http://oksoclap.com/p/iOS-team-meeting-10-01-2014 >>> > >>> > Feel free to add to it. >>> > >>> > ++ >>> > Corinne >>> >>> _______________________________________________ >>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140114/a73cbf3a/attachment-0001.html From cvasilak at gmail.com Tue Jan 14 07:01:44 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 14 Jan 2014 14:01:44 +0200 Subject: [aerogear-dev] Planning iOS 1.4.0 release In-Reply-To: <2337FC5B-A256-4B31-9F41-81AA82E0A2AA@gmail.com> References: <1DE09130-F636-48D5-B970-7DF9B14A8EBE@gmail.com> <59FC7D1C-5241-4610-B836-2AAC30440A27@gmail.com> <2337FC5B-A256-4B31-9F41-81AA82E0A2AA@gmail.com> Message-ID: I am ok with that from my side - Christos On Jan 14, 2014, at 1:45 PM, Corinne wrote: > I might run late, sorry about that :( > To be on the safe side, could we move it to 2:30pm? > > from my iPhone > > On 13 janv. 2014, at 10:29, Christos Vasilakis wrote: > >> +1 >> >> - >> Christos >> >> >> On Jan 13, 2014, at 11:12 AM, Matthias Wessendorf wrote: >> >>> +1 >>> >>> >>> On Mon, Jan 13, 2014 at 9:49 AM, Corinne Krych wrote: >>> What about panning it for tuesday 2pm (usual iOS meeting slot)? >>> >>> ++ >>> Corinne >>> On Jan 9, 2014, at 10:50 AM, Corinne Krych wrote: >>> >>> > Hello Guys, >>> > >>> > I've started an agenda for our next iOS meeting. >>> > http://oksoclap.com/p/iOS-team-meeting-10-01-2014 >>> > >>> > Feel free to add to it. >>> > >>> > ++ >>> > Corinne >>> >>> _______________________________________________ >>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140114/7d882701/attachment.html From matzew at apache.org Tue Jan 14 07:09:06 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 14 Jan 2014 13:09:06 +0100 Subject: [aerogear-dev] Planning iOS 1.4.0 release In-Reply-To: References: <1DE09130-F636-48D5-B970-7DF9B14A8EBE@gmail.com> <59FC7D1C-5241-4610-B836-2AAC30440A27@gmail.com> <2337FC5B-A256-4B31-9F41-81AA82E0A2AA@gmail.com> Message-ID: yo, works for me On Tue, Jan 14, 2014 at 1:01 PM, Christos Vasilakis wrote: > I am ok with that from my side > > - > Christos > > On Jan 14, 2014, at 1:45 PM, Corinne wrote: > > I might run late, sorry about that :( > To be on the safe side, could we move it to 2:30pm? > > from my iPhone > > On 13 janv. 2014, at 10:29, Christos Vasilakis wrote: > > +1 > > - > Christos > > > On Jan 13, 2014, at 11:12 AM, Matthias Wessendorf > wrote: > > +1 > > > On Mon, Jan 13, 2014 at 9:49 AM, Corinne Krych wrote: > >> What about panning it for tuesday 2pm (usual iOS meeting slot)? >> >> ++ >> Corinne >> On Jan 9, 2014, at 10:50 AM, Corinne Krych >> wrote: >> >> > Hello Guys, >> > >> > I've started an agenda for our next iOS meeting. >> > http://oksoclap.com/p/iOS-team-meeting-10-01-2014 >> > >> > Feel free to add to it. >> > >> > ++ >> > Corinne >> >> _______________________________________________ >> 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 > -- 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/20140114/52fcc995/attachment.html From hbons at redhat.com Tue Jan 14 08:04:46 2014 From: hbons at redhat.com (Hylke Bons) Date: Tue, 14 Jan 2014 13:04:46 +0000 Subject: [aerogear-dev] Initial UPS user management wireframes In-Reply-To: References: <52A65258.4010406@redhat.com> Message-ID: <52D535EE.1060303@redhat.com> On 10/12/2013 13:48, Lucas Holmquist wrote: > > On Dec 10, 2013, at 2:45 AM, Sebastien Blanc > wrote: > >> Great job Hylke, I think you captured all the things defined in the >> spec draft. >> >> Just 2 remarks : >> >> - When creating an user , you added a "tip" saying you can create >> multiple users by separate them ";" , could be a nice feature, not >> sure it will be included in the first version. > > yea, could be nice, but not for 1.0 That's fine. I thought I saw this as a requirement in the spec? I could be wrong. Anyway it's not essential now. >> - The "last seen/login" field : not sure if it's really useful, wdyt ? >> > agree that it probably isn't useful > Fine, we can drop that. Thanks for the feedback. Hylke >> >> >> >> On Tue, Dec 10, 2013 at 12:29 AM, Hylke Bons > > wrote: >> >> Hey everyone, >> >> Let's discuss the wireframes: >> https://github.com/hbons/aerogear-design/blob/master/aerogear_unified_push_server_admin_ui_baseline.png >> based on https://gist.github.com/sebastienblanc/6547605. >> >> The mockup is getting a little big and confusing now, so I've >> marked the >> new parts in orange. :) >> >> Feature wise we should be there. Let me know if you have any >> comments or >> if things are unclear, so they can be improved. >> >> Thanks, >> >> Hylke >> _______________________________________________ >> 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/20140114/79bc46e7/attachment.html From bruno at abstractj.org Tue Jan 14 08:11:13 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 14 Jan 2014 08:11:13 -0500 Subject: [aerogear-dev] Strange encrypted store behavior In-Reply-To: References: <9933FC87-65AE-4A35-9894-4A2F92F51083@redhat.com> Message-ID: Again, storing passwords no matter how super safe is the KeyChain is a terrible idea. Don't do it, please. > As for the problem of encrypting with one passphrase then another one and not be able to decrypt any data afterward, I think this is an issue that should be fixed. JIRA needed. This is mostly because you have to add a feature of passphrase change first. On Tue, Jan 14, 2014 at 3:46 AM, Corinne Krych wrote: > Hi Tadeas, > > I think you bring back on the table an unfinished discussion on the topic > of AGPassphraseKeyServices(used in password demo app) vs. > AGPasswordKeyServices (not used in any demo yet). > > In AGPasswordKeyServices the password is stored in secure local storage > (KeyChain for iOS, KeyStore for Android), therefore you could do a password > check at login time as stated in your workflow. I think we intended to have > 2 diffences EncryptionServices for those differents usage. > > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-Crypto-API-sample-td5306.html > More work is needed for AGPasswordKeyServices and adding a demo/recipe app > for it would be nice. > @summers @cvasilak do you remember the discussion? > > As for the problem of encrypting with one passphrase then another one and > not be able to decrypt any data afterward, I think this is an issue that > should be fixed. JIRA needed. > > ++ > Corinne > On Jan 14, 2014, at 2:23 AM, Bruno Oliveira wrote: > > > Hi Tadeas, replied on the same issue. > > > > > > On Mon, Jan 13, 2014 at 12:43 PM, Tadeas Kriz wrote: > > Hi there, > > > > in December, I?ve reported [1] and today Passos asked me if I could > rather send it here to discuss it, as this behavior is the same in other > platform?s implementations (which I wasn?t aware of before). So please read > the description on that JIRA issue. Basically I have nothing more to say > about it, what?s not in the description already. So, what do you think? > > > > 1 - https://issues.jboss.org/browse/AGDROID-173 > > > > ? > > Tadeas Kriz > > tkriz at redhat.com > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > -- > > > > -- > > "The measure of a man is what he does with power" - Plato > > - > > @abstractj > > - > > Volenti Nihil Difficile > > _______________________________________________ > > 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 > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140114/cb0dd687/attachment-0001.html From daniel at passos.me Tue Jan 14 08:20:43 2014 From: daniel at passos.me (Daniel Passos) Date: Tue, 14 Jan 2014 11:20:43 -0200 Subject: [aerogear-dev] Backend (jax-rs) Project Message-ID: Hi folks, I started a new backend project[1] using jax-rs. The idea of this project is provide some endpoints to use in the demos, integration tests and cookbooks. I have tried to fix and add new features to the old project[2], but the legacy is big and hard to fix I created a jira for it[3]. Feel free to add (and take) new sub tasks and send PRs [1]?https://github.com/danielpassos/aerogear-integration-tests-server [2]?https://github.com/aerogear/aerogear-jaxrs-demo? [3]?https://issues.jboss.org/browse/AEROGEAR-1388 --? Daniel Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140114/e9bb95d9/attachment.html From corinnekrych at gmail.com Tue Jan 14 08:50:18 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 14 Jan 2014 14:50:18 +0100 Subject: [aerogear-dev] Strange encrypted store behavior In-Reply-To: References: <9933FC87-65AE-4A35-9894-4A2F92F51083@redhat.com> Message-ID: On Jan 14, 2014, at 2:11 PM, Bruno Oliveira wrote: > Again, storing passwords no matter how super safe is the KeyChain is a terrible idea. Don't do it, please. Sorry not password but key. > > > As for the problem of encrypting with one passphrase then another one and not be able to decrypt any data afterward, I think this is an issue that should be fixed. JIRA needed. > > This is mostly because you have to add a feature of passphrase change first. +1 make sense i > > > On Tue, Jan 14, 2014 at 3:46 AM, Corinne Krych wrote: > Hi Tadeas, > > I think you bring back on the table an unfinished discussion on the topic of AGPassphraseKeyServices(used in password demo app) vs. AGPasswordKeyServices (not used in any demo yet). > > In AGPasswordKeyServices the password is stored in secure local storage (KeyChain for iOS, KeyStore for Android), therefore you could do a password check at login time as stated in your workflow. I think we intended to have 2 diffences EncryptionServices for those differents usage. > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-Crypto-API-sample-td5306.html > More work is needed for AGPasswordKeyServices and adding a demo/recipe app for it would be nice. > @summers @cvasilak do you remember the discussion? > > As for the problem of encrypting with one passphrase then another one and not be able to decrypt any data afterward, I think this is an issue that should be fixed. JIRA needed. > > ++ > Corinne > On Jan 14, 2014, at 2:23 AM, Bruno Oliveira wrote: > > > Hi Tadeas, replied on the same issue. > > > > > > On Mon, Jan 13, 2014 at 12:43 PM, Tadeas Kriz wrote: > > Hi there, > > > > in December, I?ve reported [1] and today Passos asked me if I could rather send it here to discuss it, as this behavior is the same in other platform?s implementations (which I wasn?t aware of before). So please read the description on that JIRA issue. Basically I have nothing more to say about it, what?s not in the description already. So, what do you think? > > > > 1 - https://issues.jboss.org/browse/AGDROID-173 > > > > ? > > Tadeas Kriz > > tkriz at redhat.com > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > -- > > > > -- > > "The measure of a man is what he does with power" - Plato > > - > > @abstractj > > - > > Volenti Nihil Difficile > > _______________________________________________ > > 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 > > > > -- > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From qmx at qmx.me Tue Jan 14 08:53:43 2014 From: qmx at qmx.me (Douglas Campos) Date: Tue, 14 Jan 2014 11:53:43 -0200 Subject: [aerogear-dev] Strange encrypted store behavior In-Reply-To: References: <9933FC87-65AE-4A35-9894-4A2F92F51083@redhat.com> Message-ID: <20140114135343.GG640@rohan> On Tue, Jan 14, 2014 at 09:46:38AM +0100, Corinne Krych wrote: > In AGPasswordKeyServices the password is stored in secure local > storage (KeyChain for iOS, KeyStore for Android), therefore you could > do a password check at login time as stated in your workflow. I think Wait, password is stored? ouch - we need to fix this! No matter how secure is the keystore, it's mandatory for us to use a key-derivation scheme, or at least the traditional salt+hash. Reversible encryption is asking for trouble :P -- qmx From matzew at apache.org Tue Jan 14 09:02:26 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 14 Jan 2014 15:02:26 +0100 Subject: [aerogear-dev] AeroGear Security: Version numbers in pom files Message-ID: Hi, I have a question regarding the version numbers in the pom files of the ag-security repos. They are listed as 1.3.1-SNAPSHOT, but I also see a 1.3.1 tag on our github repo, matching a release. Should we (manually?) increase them to 1.3.2-SNAPSHOT or was the version left at 1.3.1-SNAPSHOT for a reason ? Thanks! 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/20140114/5b5bcda9/attachment.html From qmx at qmx.me Tue Jan 14 09:03:04 2014 From: qmx at qmx.me (Douglas Campos) Date: Tue, 14 Jan 2014 12:03:04 -0200 Subject: [aerogear-dev] Strange encrypted store behavior In-Reply-To: References: <9933FC87-65AE-4A35-9894-4A2F92F51083@redhat.com> Message-ID: <20140114140304.GH640@rohan> On Tue, Jan 14, 2014 at 02:50:18PM +0100, Corinne Krych wrote: > > On Jan 14, 2014, at 2:11 PM, Bruno Oliveira wrote: > > > Again, storing passwords no matter how super safe is the KeyChain is > > a terrible idea. Don't do it, please. > > Sorry not password but key. You mean the keys derived from PBKDF2? > > > > > > As for the problem of encrypting with one passphrase then another one and not be able to decrypt any data afterward, I think this is an issue that should be fixed. JIRA needed. > > > > This is mostly because you have to add a feature of passphrase change first. > > +1 make sense > i > > > > > > On Tue, Jan 14, 2014 at 3:46 AM, Corinne Krych wrote: > > Hi Tadeas, > > > > I think you bring back on the table an unfinished discussion on the topic of AGPassphraseKeyServices(used in password demo app) vs. AGPasswordKeyServices (not used in any demo yet). > > > > In AGPasswordKeyServices the password is stored in secure local storage (KeyChain for iOS, KeyStore for Android), therefore you could do a password check at login time as stated in your workflow. I think we intended to have 2 diffences EncryptionServices for those differents usage. > > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-Crypto-API-sample-td5306.html > > More work is needed for AGPasswordKeyServices and adding a demo/recipe app for it would be nice. > > @summers @cvasilak do you remember the discussion? > > > > As for the problem of encrypting with one passphrase then another one and not be able to decrypt any data afterward, I think this is an issue that should be fixed. JIRA needed. > > > > ++ > > Corinne > > On Jan 14, 2014, at 2:23 AM, Bruno Oliveira wrote: > > > > > Hi Tadeas, replied on the same issue. > > > > > > > > > On Mon, Jan 13, 2014 at 12:43 PM, Tadeas Kriz wrote: > > > Hi there, > > > > > > in December, I?ve reported [1] and today Passos asked me if I could rather send it here to discuss it, as this behavior is the same in other platform?s implementations (which I wasn?t aware of before). So please read the description on that JIRA issue. Basically I have nothing more to say about it, what?s not in the description already. So, what do you think? > > > > > > 1 - https://issues.jboss.org/browse/AGDROID-173 > > > > > > ? > > > Tadeas Kriz > > > tkriz at redhat.com > > > > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > > > > -- > > > > > > -- > > > "The measure of a man is what he does with power" - Plato > > > - > > > @abstractj > > > - > > > Volenti Nihil Difficile > > > _______________________________________________ > > > 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 > > > > > > > > -- > > > > -- > > "The measure of a man is what he does with power" - Plato > > - > > @abstractj > > - > > Volenti Nihil Difficile > > _______________________________________________ > > 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 -- qmx From corinnekrych at gmail.com Tue Jan 14 09:11:12 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 14 Jan 2014 15:11:12 +0100 Subject: [aerogear-dev] Strange encrypted store behavior In-Reply-To: <20140114140304.GH640@rohan> References: <9933FC87-65AE-4A35-9894-4A2F92F51083@redhat.com> <20140114140304.GH640@rohan> Message-ID: Yep! On Jan 14, 2014, at 3:03 PM, Douglas Campos wrote: > On Tue, Jan 14, 2014 at 02:50:18PM +0100, Corinne Krych wrote: >> >> On Jan 14, 2014, at 2:11 PM, Bruno Oliveira wrote: >> >>> Again, storing passwords no matter how super safe is the KeyChain is >>> a terrible idea. Don't do it, please. >> >> Sorry not password but key. > > You mean the keys derived from PBKDF2? > >> >>> >>>> As for the problem of encrypting with one passphrase then another one and not be able to decrypt any data afterward, I think this is an issue that should be fixed. JIRA needed. >>> >>> This is mostly because you have to add a feature of passphrase change first. >> >> +1 make sense >> i >>> >>> >>> On Tue, Jan 14, 2014 at 3:46 AM, Corinne Krych wrote: >>> Hi Tadeas, >>> >>> I think you bring back on the table an unfinished discussion on the topic of AGPassphraseKeyServices(used in password demo app) vs. AGPasswordKeyServices (not used in any demo yet). >>> >>> In AGPasswordKeyServices the password is stored in secure local storage (KeyChain for iOS, KeyStore for Android), therefore you could do a password check at login time as stated in your workflow. I think we intended to have 2 diffences EncryptionServices for those differents usage. >>> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-Crypto-API-sample-td5306.html >>> More work is needed for AGPasswordKeyServices and adding a demo/recipe app for it would be nice. >>> @summers @cvasilak do you remember the discussion? >>> >>> As for the problem of encrypting with one passphrase then another one and not be able to decrypt any data afterward, I think this is an issue that should be fixed. JIRA needed. >>> >>> ++ >>> Corinne >>> On Jan 14, 2014, at 2:23 AM, Bruno Oliveira wrote: >>> >>>> Hi Tadeas, replied on the same issue. >>>> >>>> >>>> On Mon, Jan 13, 2014 at 12:43 PM, Tadeas Kriz wrote: >>>> Hi there, >>>> >>>> in December, I?ve reported [1] and today Passos asked me if I could rather send it here to discuss it, as this behavior is the same in other platform?s implementations (which I wasn?t aware of before). So please read the description on that JIRA issue. Basically I have nothing more to say about it, what?s not in the description already. So, what do you think? >>>> >>>> 1 - https://issues.jboss.org/browse/AGDROID-173 >>>> >>>> ? >>>> Tadeas Kriz >>>> tkriz at redhat.com >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> -- >>>> >>>> -- >>>> "The measure of a man is what he does with power" - Plato >>>> - >>>> @abstractj >>>> - >>>> Volenti Nihil Difficile >>>> _______________________________________________ >>>> 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 >>> >>> >>> >>> -- >>> >>> -- >>> "The measure of a man is what he does with power" - Plato >>> - >>> @abstractj >>> - >>> Volenti Nihil Difficile >>> _______________________________________________ >>> 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 > > -- > qmx > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From qmx at qmx.me Tue Jan 14 09:21:00 2014 From: qmx at qmx.me (Douglas Campos) Date: Tue, 14 Jan 2014 12:21:00 -0200 Subject: [aerogear-dev] AeroGear Security: Version numbers in pom files In-Reply-To: References: Message-ID: <20140114142100.GI640@rohan> On Tue, Jan 14, 2014 at 03:02:26PM +0100, Matthias Wessendorf wrote: > Hi, > > I have a question regarding the version numbers in the pom files of the > ag-security repos. They are listed as 1.3.1-SNAPSHOT, but I also see a > 1.3.1 tag on our github repo, matching a release. > > Should we (manually?) increase them to 1.3.2-SNAPSHOT or was the version > left at 1.3.1-SNAPSHOT for a reason ? I think abstractj pushed the tag but forgot to push master afterwards :P > > Thanks! > Matthias > > > -- > 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 -- qmx From matzew at apache.org Tue Jan 14 09:25:23 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 14 Jan 2014 15:25:23 +0100 Subject: [aerogear-dev] AeroGear Security: Version numbers in pom files In-Reply-To: <20140114142100.GI640@rohan> References: <20140114142100.GI640@rohan> Message-ID: OK, I will send PR to fix that On Tue, Jan 14, 2014 at 3:21 PM, Douglas Campos wrote: > On Tue, Jan 14, 2014 at 03:02:26PM +0100, Matthias Wessendorf wrote: > > Hi, > > > > I have a question regarding the version numbers in the pom files of the > > ag-security repos. They are listed as 1.3.1-SNAPSHOT, but I also see a > > 1.3.1 tag on our github repo, matching a release. > > > > Should we (manually?) increase them to 1.3.2-SNAPSHOT or was the version > > left at 1.3.1-SNAPSHOT for a reason ? > > I think abstractj pushed the tag but forgot to push master afterwards :P > > > > > Thanks! > > Matthias > > > > > > -- > > 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 > > > -- > qmx > _______________________________________________ > 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/20140114/b27f783f/attachment.html From bruno at abstractj.org Tue Jan 14 09:38:21 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 14 Jan 2014 09:38:21 -0500 Subject: [aerogear-dev] Strange encrypted store behavior In-Reply-To: References: <9933FC87-65AE-4A35-9894-4A2F92F51083@redhat.com> Message-ID: > Sorry not password but key. We don't need to store the key once we have the salt, IV, iterations and the passphrase provided by our user is perfectly possible to generate again that key. If this is not happening we need to revisit our code and figure out what's going on. On Tue, Jan 14, 2014 at 8:50 AM, Corinne Krych wrote: > > On Jan 14, 2014, at 2:11 PM, Bruno Oliveira wrote: > > > Again, storing passwords no matter how super safe is the KeyChain is a > terrible idea. Don't do it, please. > > Sorry not password but key. > > > > > > As for the problem of encrypting with one passphrase then another one > and not be able to decrypt any data afterward, I think this is an issue > that should be fixed. JIRA needed. > > > > This is mostly because you have to add a feature of passphrase change > first. > > +1 make sense > i > > > > > > On Tue, Jan 14, 2014 at 3:46 AM, Corinne Krych > wrote: > > Hi Tadeas, > > > > I think you bring back on the table an unfinished discussion on the > topic of AGPassphraseKeyServices(used in password demo app) vs. > AGPasswordKeyServices (not used in any demo yet). > > > > In AGPasswordKeyServices the password is stored in secure local storage > (KeyChain for iOS, KeyStore for Android), therefore you could do a password > check at login time as stated in your workflow. I think we intended to have > 2 diffences EncryptionServices for those differents usage. > > > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Android-Crypto-API-sample-td5306.html > > More work is needed for AGPasswordKeyServices and adding a demo/recipe > app for it would be nice. > > @summers @cvasilak do you remember the discussion? > > > > As for the problem of encrypting with one passphrase then another one > and not be able to decrypt any data afterward, I think this is an issue > that should be fixed. JIRA needed. > > > > ++ > > Corinne > > On Jan 14, 2014, at 2:23 AM, Bruno Oliveira wrote: > > > > > Hi Tadeas, replied on the same issue. > > > > > > > > > On Mon, Jan 13, 2014 at 12:43 PM, Tadeas Kriz > wrote: > > > Hi there, > > > > > > in December, I?ve reported [1] and today Passos asked me if I could > rather send it here to discuss it, as this behavior is the same in other > platform?s implementations (which I wasn?t aware of before). So please read > the description on that JIRA issue. Basically I have nothing more to say > about it, what?s not in the description already. So, what do you think? > > > > > > 1 - https://issues.jboss.org/browse/AGDROID-173 > > > > > > ? > > > Tadeas Kriz > > > tkriz at redhat.com > > > > > > > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > > > > -- > > > > > > -- > > > "The measure of a man is what he does with power" - Plato > > > - > > > @abstractj > > > - > > > Volenti Nihil Difficile > > > _______________________________________________ > > > 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 > > > > > > > > -- > > > > -- > > "The measure of a man is what he does with power" - Plato > > - > > @abstractj > > - > > Volenti Nihil Difficile > > _______________________________________________ > > 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 > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140114/df602e1e/attachment.html From cvasilak at gmail.com Tue Jan 14 10:31:21 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Tue, 14 Jan 2014 17:31:21 +0200 Subject: [aerogear-dev] Planning iOS 1.4.0 release In-Reply-To: <1DE09130-F636-48D5-B970-7DF9B14A8EBE@gmail.com> References: <1DE09130-F636-48D5-B970-7DF9B14A8EBE@gmail.com> Message-ID: <2FFC9FB5-D3CA-4DE1-B406-6F292507800C@gmail.com> fyi meeting notes: [5:29pm]jbott:Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-01-14-13.51.html [5:29pm]jbott:Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-01-14-13.51.txt [5:29pm]jbott:Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-01-14-13.51.log.html On Jan 9, 2014, at 11:50 AM, Corinne Krych wrote: > Hello Guys, > > I've started an agenda for our next iOS meeting. > http://oksoclap.com/p/iOS-team-meeting-10-01-2014 > > Feel free to add to it. > > ++ > Corinne > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From bruno at abstractj.org Tue Jan 14 12:45:11 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 14 Jan 2014 12:45:11 -0500 Subject: [aerogear-dev] AeroGear Security: Version numbers in pom files In-Reply-To: References: <20140114142100.GI640@rohan> Message-ID: Fixed. On Tue, Jan 14, 2014 at 9:25 AM, Matthias Wessendorf wrote: > OK, > > I will send PR to fix that > > > On Tue, Jan 14, 2014 at 3:21 PM, Douglas Campos wrote: > >> On Tue, Jan 14, 2014 at 03:02:26PM +0100, Matthias Wessendorf wrote: >> > Hi, >> > >> > I have a question regarding the version numbers in the pom files of the >> > ag-security repos. They are listed as 1.3.1-SNAPSHOT, but I also see a >> > 1.3.1 tag on our github repo, matching a release. >> > >> > Should we (manually?) increase them to 1.3.2-SNAPSHOT or was the version >> > left at 1.3.1-SNAPSHOT for a reason ? >> >> I think abstractj pushed the tag but forgot to push master afterwards :P >> >> > >> > Thanks! >> > Matthias >> > >> > >> > -- >> > 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 >> >> >> -- >> qmx >> _______________________________________________ >> 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 > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140114/d236f038/attachment-0001.html From lgraham at redhat.com Tue Jan 14 14:21:55 2014 From: lgraham at redhat.com (Lee Graham) Date: Tue, 14 Jan 2014 14:21:55 -0500 (EST) Subject: [aerogear-dev] Getting Involved in AG? In-Reply-To: <200900014.1308856.1389727226644.JavaMail.root@redhat.com> Message-ID: <1996257990.1309286.1389727315824.JavaMail.root@redhat.com> Hi All, I was hoping to find a way to get plugged into the AeroGear project. I've looked at the AG roadmaps, talked with Jay and Steve, and I'm really excited about what you've been doing! I wanted to see how I could get plugged in. I was thinking of working on a quickstart or two, and possibly even some blogging. To start topics like "what if" scenarios for companies to see how they could potentially use AG to extend current IT infrastructures to mobile. These are just my ideas. I'm open to your thought on what are the needs of the community and how I can help. Brief background... I've worked at Red Hat since March 2012 , and have been leading a small team to develop a RH mobile learning app. We are using Cordova + OpenShift.com. Once we get our SAML auth working, we will integrate push via AG. I'm most comfortable w/ PHP and JavaScript. I have a few hobbies, but my most recent exploration has been brewing beer (just finished a vanilla witbier, and before that a belgium tripel). Happy Tuesday ! Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140114/1ae3b9b6/attachment.html From matzew at apache.org Tue Jan 14 14:48:39 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 14 Jan 2014 20:48:39 +0100 Subject: [aerogear-dev] Getting Involved in AG? In-Reply-To: <1996257990.1309286.1389727315824.JavaMail.root@redhat.com> References: <200900014.1308856.1389727226644.JavaMail.root@redhat.com> <1996257990.1309286.1389727315824.JavaMail.root@redhat.com> Message-ID: Hi Lee, nice to meet you and thanks for the interest in our project! On Tue, Jan 14, 2014 at 8:21 PM, Lee Graham wrote: > Hi All, > > I was hoping to find a way to get plugged into the AeroGear project. I've > looked at the AG roadmaps, talked with Jay and Steve, and I'm really > excited about what you've been doing! > > I wanted to see how I could get plugged in. I was thinking of working on a > quickstart or two, and possibly even some blogging. To start topics like > "what if" scenarios for companies to see how they could potentially use AG > to extend current IT infrastructures to mobile. These are just my ideas. > I'm open to your thought on what are the needs of the community and how I > can help. > sure these all do sound good and I am sure more doc, blog or even quickstarts could help for growing the community. I think best is you pick a topic of your interest for that. If you are also interested in code related items, feel free to check out our JIRA instances to see if a ticket does sound interesting as a good starting point. > > Brief background... I've worked at Red Hat since March 2012, and have > been leading a small team to develop a RH mobile learning app. We are using > Cordova + OpenShift.com. Once we get our SAML auth working, we will > integrate push via AG. I'm most comfortable w/ PHP and JavaScript. > Ah, speaking about AG push integration; An article on that subject (e.g. how you integrated the AG UnifiedPush Server w/ your project) would be helpful for the project as well. Something else that comes up is a SDK for PHP-based backend - some code is already there, but I think it needs to be updated and polished: https://issues.jboss.org/browse/AGPUSH-183 Another idea might be some doc on the OpenShift cartridge: https://issues.jboss.org/browse/AGPUSH-475 Let us know what you think about these items ;-) > I have a few hobbies, but my most recent exploration has been brewing beer > (just finished a vanilla witbier, and before that a belgium tripel). > beer++ :-) Greetings, Matthias > > Happy Tuesday! > Lee > > > _______________________________________________ > 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/20140114/e7df5f7b/attachment.html From qmx at qmx.me Tue Jan 14 14:48:45 2014 From: qmx at qmx.me (Douglas Campos) Date: Tue, 14 Jan 2014 17:48:45 -0200 Subject: [aerogear-dev] Getting Involved in AG? In-Reply-To: <1996257990.1309286.1389727315824.JavaMail.root@redhat.com> References: <200900014.1308856.1389727226644.JavaMail.root@redhat.com> <1996257990.1309286.1389727315824.JavaMail.root@redhat.com> Message-ID: <20140114194845.GA12634@rohan.local> Hello Lee! On Tue, Jan 14, 2014 at 02:21:55PM -0500, Lee Graham wrote: > Hi All, > > I was hoping to find a way to get plugged into the AeroGear project. > I've looked at the AG roadmaps, talked with Jay and Steve, and I'm > really excited about what you've been doing! > > I wanted to see how I could get plugged in. I was thinking of working > on a quickstart or two, and possibly even some blogging. To start > topics like "what if" scenarios for companies to see how they could > potentially use AG to extend current IT infrastructures to mobile. > These are just my ideas. I'm open to your thought on what are the > needs of the community and how I can help. Right now the best way you can help is trying to use AeroGear on your apps and providing feedback on our getting started experience. We hang on #aerogear at irc.freenode.net if you're feeling like some irc chatter ;) > > Brief background... I've worked at Red Hat since March 2012 , and have > been leading a small team to develop a RH mobile learning app. We are > using Cordova + OpenShift.com. Once we get our SAML auth working, we > will integrate push via AG. I'm most comfortable w/ PHP and > JavaScript. Great! Keep us posted! > I have a few hobbies, but my most recent exploration has been brewing > beer (just finished a vanilla witbier, and before that a belgium > tripel). I wish I've had space at home for doing this...someday :) Cheers! -- qmx From matzew at apache.org Wed Jan 15 03:28:06 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 15 Jan 2014 09:28:06 +0100 Subject: [aerogear-dev] UnifiedPush Server - 0.10.0 release Message-ID: Hi, originally we scheduled a release for today/this week. There will be a 0.10.0 release of the UnifiedPush Server, but not today/this week. By the end of January we will release it; currently focus is on getting the User Management done right and fixing minor issues. If you have any questions / concerns, let us know! Cheers! 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/20140115/e497ebec/attachment.html From corinnekrych at gmail.com Wed Jan 15 05:38:59 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 15 Jan 2014 11:38:59 +0100 Subject: [aerogear-dev] Auth Authz and OAuth In-Reply-To: <52CAE4FD.1030802@redhat.com> References: <52CACA06.1000508@redhat.com> <2E21E3DB-DD8C-44B3-9132-7D1588334B07@redhat.com> <1645A48F-12E4-451C-A1DF-562556D53F13@gmail.com> <52CACE33.6070807@redhat.com> <52CAD3FB.6060408@redhat.com> <5835F3DC-6BF9-4FD7-9188-26E755C97407@gmail.com> <52CAE4FD.1030802@redhat.com> Message-ID: <762CBC47-AE29-48EC-B741-270D72A39DD1@gmail.com> Hello Guys, Bringing back the subject of refactoring Auth and Authz I've actually refactor applyToken into on emethod which fits both authentication token and Oauth2 tokens See code in OAuth2 PR: https://github.com/corinnekrych/aerogear-ios/blob/e6d4a15daf172706199aa8f09b00cd31cce7712c/AeroGear-iOS/AeroGear-iOS/pipeline/AGRESTPipe.m#L307 and when setting accessToken in exchange code for access token https://github.com/corinnekrych/aerogear-ios/blob/e6d4a15daf172706199aa8f09b00cd31cce7712c/AeroGear-iOS/AeroGear-iOS/security/Authorizer/AGRestAuthzModule.m#L128 This way is less intrusive for AGRestPipe. wdyt? ++ Corinne On Jan 6, 2014, at 6:16 PM, Summers Pittman wrote: > On Mon 06 Jan 2014 12:04:16 PM EST, Corinne Krych wrote: >> login/logoff/enroll is not part of authz already > > Oh, I misread your files this morning and this makes a lot more sense now. Note to self, don't review ObjC until I have had at least 3 cups of coffee. > > > >> ++ >> Corinne >> On Jan 6, 2014, at 5:04 PM, Summers Pittman wrote: >> >>> On 01/06/2014 10:48 AM, Corinne Krych wrote: >>>> Agreed. We could find a common way to treat both tokens and apply them. >>>> Make a proposal for android and I'll create a JIRA for iOS. >>>> this is at implementation level though and should not affect interfaces. >>>> Different interfaces still needed for auth and authz though. >>> True. But it may simplify both interfaces (like removing login/logoff/enroll from authz) >>>> >>>> ++ >>>> Corinne >>>> On Jan 6, 2014, at 4:39 PM, Summers Pittman wrote: >>>> >>>>> On Mon 06 Jan 2014 10:36:32 AM EST, Corinne Krych wrote: >>>>>> Summers, >>>>>> >>>>>> Do you mean, should we refactor and treat authToken and accessTokens in a similar way for the implementation of OAuth2? >>>>> Yes. That is what I am proposing. >>>>> >>>>>> ++ >>>>>> Corinne >>>>>> On Jan 6, 2014, at 4:33 PM, Lucas Holmquist wrote: >>>>>> >>>>>>> On Jan 6, 2014, at 10:21 AM, Summers Pittman wrote: >>>>>>> >>>>>>>> So in JS land and iOS land we have or will soon have OAuth2 handling. >>>>>>>> To handle OAuth2 a new API was created, AGAuthorizationModule. I >>>>>>>> understand and agree with the separation of concerns between >>>>>>>> Authentication and Authorization, but I am worried that this introduces >>>>>>>> two APIs now. >>>>>>>> >>>>>>>> Before Authz was added Authentication (login, logout, etc) and >>>>>>>> Authorization(here are my keys and permissions) were both handled by >>>>>>>> AGAuthenticationModules. With Authz now being a thing we should >>>>>>>> probably remove and deprecate the authz parts of the old >>>>>>>> AuthenticationModules. >>>>>>>> >>>>>>>> see iOS >>>>>>>> https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/AeroGear-iOS/pipeline/AGRESTPipe.m#L307 >>>>>>>> >>>>>>>> see Android >>>>>>>> https://github.com/aerogear/aerogear-android/blob/master/src/org/jboss/aerogear/android/impl/pipeline/RestRunner.java#L319 >>>>>>>> >>>>>>>> see Javascript: I couldn't actually find this in javascript? >>>>>>> We didn't have authz in our auth stuff, so it made sense to create a separate thing. >>>>>>> >>>>>>>> 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 cvasilak at gmail.com Wed Jan 15 08:21:26 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Wed, 15 Jan 2014 15:21:26 +0200 Subject: [aerogear-dev] Auth Authz and OAuth In-Reply-To: <762CBC47-AE29-48EC-B741-270D72A39DD1@gmail.com> References: <52CACA06.1000508@redhat.com> <2E21E3DB-DD8C-44B3-9132-7D1588334B07@redhat.com> <1645A48F-12E4-451C-A1DF-562556D53F13@gmail.com> <52CACE33.6070807@redhat.com> <52CAD3FB.6060408@redhat.com> <5835F3DC-6BF9-4FD7-9188-26E755C97407@gmail.com> <52CAE4FD.1030802@redhat.com> <762CBC47-AE29-48EC-B741-270D72A39DD1@gmail.com> Message-ID: On Jan 15, 2014, at 12:38 PM, Corinne Krych wrote: > Hello Guys, > > Bringing back the subject of refactoring Auth and Authz > I've actually refactor applyToken into on emethod which fits both authentication token and Oauth2 tokens > See code in OAuth2 PR: > > https://github.com/corinnekrych/aerogear-ios/blob/e6d4a15daf172706199aa8f09b00cd31cce7712c/AeroGear-iOS/AeroGear-iOS/pipeline/AGRESTPipe.m#L307 > > and when setting accessToken in exchange code for access token > https://github.com/corinnekrych/aerogear-ios/blob/e6d4a15daf172706199aa8f09b00cd31cce7712c/AeroGear-iOS/AeroGear-iOS/security/Authorizer/AGRestAuthzModule.m#L128 > > This way is less intrusive for AGRestPipe. wdyt? makes perfectly sense +1 > > ++ > Corinne > On Jan 6, 2014, at 6:16 PM, Summers Pittman wrote: > >> On Mon 06 Jan 2014 12:04:16 PM EST, Corinne Krych wrote: >>> login/logoff/enroll is not part of authz already >> >> Oh, I misread your files this morning and this makes a lot more sense now. Note to self, don't review ObjC until I have had at least 3 cups of coffee. >> >> >> >>> ++ >>> Corinne >>> On Jan 6, 2014, at 5:04 PM, Summers Pittman wrote: >>> >>>> On 01/06/2014 10:48 AM, Corinne Krych wrote: >>>>> Agreed. We could find a common way to treat both tokens and apply them. >>>>> Make a proposal for android and I'll create a JIRA for iOS. >>>>> this is at implementation level though and should not affect interfaces. >>>>> Different interfaces still needed for auth and authz though. >>>> True. But it may simplify both interfaces (like removing login/logoff/enroll from authz) >>>>> >>>>> ++ >>>>> Corinne >>>>> On Jan 6, 2014, at 4:39 PM, Summers Pittman wrote: >>>>> >>>>>> On Mon 06 Jan 2014 10:36:32 AM EST, Corinne Krych wrote: >>>>>>> Summers, >>>>>>> >>>>>>> Do you mean, should we refactor and treat authToken and accessTokens in a similar way for the implementation of OAuth2? >>>>>> Yes. That is what I am proposing. >>>>>> >>>>>>> ++ >>>>>>> Corinne >>>>>>> On Jan 6, 2014, at 4:33 PM, Lucas Holmquist wrote: >>>>>>> >>>>>>>> On Jan 6, 2014, at 10:21 AM, Summers Pittman wrote: >>>>>>>> >>>>>>>>> So in JS land and iOS land we have or will soon have OAuth2 handling. >>>>>>>>> To handle OAuth2 a new API was created, AGAuthorizationModule. I >>>>>>>>> understand and agree with the separation of concerns between >>>>>>>>> Authentication and Authorization, but I am worried that this introduces >>>>>>>>> two APIs now. >>>>>>>>> >>>>>>>>> Before Authz was added Authentication (login, logout, etc) and >>>>>>>>> Authorization(here are my keys and permissions) were both handled by >>>>>>>>> AGAuthenticationModules. With Authz now being a thing we should >>>>>>>>> probably remove and deprecate the authz parts of the old >>>>>>>>> AuthenticationModules. >>>>>>>>> >>>>>>>>> see iOS >>>>>>>>> https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/AeroGear-iOS/pipeline/AGRESTPipe.m#L307 >>>>>>>>> >>>>>>>>> see Android >>>>>>>>> https://github.com/aerogear/aerogear-android/blob/master/src/org/jboss/aerogear/android/impl/pipeline/RestRunner.java#L319 >>>>>>>>> >>>>>>>>> see Javascript: I couldn't actually find this in javascript? >>>>>>>> We didn't have authz in our auth stuff, so it made sense to create a separate thing. >>>>>>>> >>>>>>>>> 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 From lgraham at redhat.com Wed Jan 15 08:36:47 2014 From: lgraham at redhat.com (Lee Graham) Date: Wed, 15 Jan 2014 08:36:47 -0500 (EST) Subject: [aerogear-dev] Getting Involved in AG? In-Reply-To: References: <200900014.1308856.1389727226644.JavaMail.root@redhat.com> <1996257990.1309286.1389727315824.JavaMail.root@redhat.com> Message-ID: <1178596502.1707955.1389793007966.JavaMail.root@redhat.com> Hi Matthias and qmx, Thanks for the advice! Push integration sounds like a great place to start. I'll start integration and document my process/finding. If anyone is ever in Raleigh let me know. I'll bring you a beer! Lee ----- Original Message ----- From: "Matthias Wessendorf" To: "AeroGear Developer Mailing List" Sent: Tuesday, January 14, 2014 2:48:39 PM Subject: Re: [aerogear-dev] Getting Involved in AG? Hi Lee, nice to meet you and thanks for the interest in our project! On Tue, Jan 14, 2014 at 8:21 PM, Lee Graham < lgraham at redhat.com > wrote: Hi All, I was hoping to find a way to get plugged into the AeroGear project. I've looked at the AG roadmaps, talked with Jay and Steve, and I'm really excited about what you've been doing! I wanted to see how I could get plugged in. I was thinking of working on a quickstart or two, and possibly even some blogging. To start topics like "what if" scenarios for companies to see how they could potentially use AG to extend current IT infrastructures to mobile. These are just my ideas. I'm open to your thought on what are the needs of the community and how I can help. sure these all do sound good and I am sure more doc, blog or even quickstarts could help for growing the community. I think best is you pick a topic of your interest for that. If you are also interested in code related items, feel free to check out our JIRA instances to see if a ticket does sound interesting as a good starting point.
Brief background... I've worked at Red Hat since March 2012 , and have been leading a small team to develop a RH mobile learning app. We are using Cordova + OpenShift.com. Once we get our SAML auth working, we will integrate push via AG. I'm most comfortable w/ PHP and JavaScript.
Ah, speaking about AG push integration; An article on that subject (e.g. how you integrated the AG UnifiedPush Server w/ your project) would be helpful for the project as well. Something else that comes up is a SDK for PHP-based backend - some code is already there, but I think it needs to be updated and polished: https://issues.jboss.org/browse/AGPUSH-183 Another idea might be some doc on the OpenShift cartridge: https://issues.jboss.org/browse/AGPUSH-475 Let us know what you think about these items ;-)
I have a few hobbies, but my most recent exploration has been brewing beer (just finished a vanilla witbier, and before that a belgium tripel).
beer++ :-) Greetings, Matthias
Happy Tuesday ! Lee _______________________________________________ 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140115/84c6a10c/attachment.html From matzew at apache.org Wed Jan 15 09:05:16 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 15 Jan 2014 15:05:16 +0100 Subject: [aerogear-dev] Getting Involved in AG? In-Reply-To: <1178596502.1707955.1389793007966.JavaMail.root@redhat.com> References: <200900014.1308856.1389727226644.JavaMail.root@redhat.com> <1996257990.1309286.1389727315824.JavaMail.root@redhat.com> <1178596502.1707955.1389793007966.JavaMail.root@redhat.com> Message-ID: On Wed, Jan 15, 2014 at 2:36 PM, Lee Graham wrote: > Hi Matthias and qmx, > > Thanks for the advice! Push integration sounds like a great place to > start. I'll start integration and document my process/finding. > awesome! If you need help, you know where to find us ;-) > > If anyone is ever in Raleigh let me know. I'll bring you a beer! > doubt it, but word ! :-) > > Lee > > > > ------------------------------ > *From: *"Matthias Wessendorf" > *To: *"AeroGear Developer Mailing List" > *Sent: *Tuesday, January 14, 2014 2:48:39 PM > *Subject: *Re: [aerogear-dev] Getting Involved in AG? > > > Hi Lee, > > nice to meet you and thanks for the interest in our project! > > > On Tue, Jan 14, 2014 at 8:21 PM, Lee Graham wrote: > >> Hi All, >> >> I was hoping to find a way to get plugged into the AeroGear project. I've >> looked at the AG roadmaps, talked with Jay and Steve, and I'm really >> excited about what you've been doing! >> >> I wanted to see how I could get plugged in. I was thinking of working on >> a quickstart or two, and possibly even some blogging. To start topics like >> "what if" scenarios for companies to see how they could potentially use AG >> to extend current IT infrastructures to mobile. These are just my ideas. >> I'm open to your thought on what are the needs of the community and how I >> can help. >> > > sure these all do sound good and I am sure more doc, blog or even > quickstarts could help for growing the community. > > I think best is you pick a topic of your interest for that. > > If you are also interested in code related items, feel free to check out > our JIRA instances to see if a ticket does sound interesting as a good > starting point. > > >> >> Brief background... I've worked at Red Hat since March 2012, and have >> been leading a small team to develop a RH mobile learning app. We are using >> Cordova + OpenShift.com. Once we get our SAML auth working, we will >> integrate push via AG. I'm most comfortable w/ PHP and JavaScript. >> > > Ah, speaking about AG push integration; An article on that subject (e.g. > how you integrated the AG UnifiedPush Server w/ your project) would be > helpful for the project as well. > > Something else that comes up is a SDK for PHP-based backend - some code is > already there, but I think it needs to be updated and polished: > https://issues.jboss.org/browse/AGPUSH-183 > > Another idea might be some doc on the OpenShift cartridge: > https://issues.jboss.org/browse/AGPUSH-475 > > > Let us know what you think about these items ;-) > > > >> I have a few hobbies, but my most recent exploration has been brewing >> beer (just finished a vanilla witbier, and before that a belgium tripel). >> > > beer++ :-) > > > Greetings, > Matthias > > >> >> Happy Tuesday! >> Lee >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140115/aded8a4d/attachment.html From lholmqui at redhat.com Wed Jan 15 09:49:07 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 15 Jan 2014 09:49:07 -0500 Subject: [aerogear-dev] java simple push / unified client In-Reply-To: <72F02973-9DAC-4CE3-A920-7AD2BB13119E@redhat.com> References: <72F02973-9DAC-4CE3-A920-7AD2BB13119E@redhat.com> Message-ID: <1B995F12-9CED-429A-B38F-E67B876000C1@redhat.com> this sounds a lot like the node client that i randomly created one day for simple push https://github.com/lholmquist/aerogear-simplepush-node-client On Jan 13, 2014, at 9:21 AM, Erik Jan de Wit wrote: > So it will be renamed but here is an initial version: > > https://github.com/edewit/aerogear-simplepush-java > > On 13 Jan,2014, at 10:47 , Sebastien Blanc wrote: > >> Since Aerogear also offers a SPS "server" maybe it will be more clear if we specify it's a client lib like : aerogear-simplepush-java-client . >> Concerning the UPS bits, let's keep it in the same module as long we document it. >> >> >> On Mon, Jan 13, 2014 at 10:36 AM, Erik Jan de Wit wrote: >> Hi, >> >> I just finished a quick POC to see how hard it would be to create a simple push java client. And guess what it wasn?t hard at all only 20 / 30 lines of code. Now to make this a proper lib I was struggling a bit with how to name this thing. So I?m keeping close to the JS version as this is the same functionality. So I also have a UnifiedPushClient, that enables you to register your simple push endpoint. This would be about one class so I don?t think we would need a separate module for this. But that does make the naming of this module harder :) >> >> I was thinking just calling it aerogear-simplepush-java so 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 >> >> _______________________________________________ >> 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/20140115/b895a4f9/attachment-0001.html From matzew at apache.org Wed Jan 15 10:14:29 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 15 Jan 2014 16:14:29 +0100 Subject: [aerogear-dev] java simple push / unified client In-Reply-To: <1B995F12-9CED-429A-B38F-E67B876000C1@redhat.com> References: <72F02973-9DAC-4CE3-A920-7AD2BB13119E@redhat.com> <1B995F12-9CED-429A-B38F-E67B876000C1@redhat.com> Message-ID: Isn't that more for sending (HTTP put) from a Node backend to any SimplePush Server? The lib from Erik is a _client_ (not a "sender"), that can receive the SimplePush payload in a JavaSE environment -M On Wed, Jan 15, 2014 at 3:49 PM, Lucas Holmquist wrote: > this sounds a lot like the node client that i randomly created one day for > simple push > https://github.com/lholmquist/aerogear-simplepush-node-client > > > On Jan 13, 2014, at 9:21 AM, Erik Jan de Wit wrote: > > So it will be renamed but here is an initial version: > > https://github.com/edewit/aerogear-simplepush-java > > On 13 Jan,2014, at 10:47 , Sebastien Blanc wrote: > > Since Aerogear also offers a SPS "server" maybe it will be more clear if > we specify it's a client lib like : aerogear-simplepush-java-client . > Concerning the UPS bits, let's keep it in the same module as long we > document it. > > > On Mon, Jan 13, 2014 at 10:36 AM, Erik Jan de Wit wrote: > >> Hi, >> >> I just finished a quick POC to see how hard it would be to create a >> simple push java client. And guess what it wasn?t hard at all only 20 / 30 >> lines of code. Now to make this a proper lib I was struggling a bit with >> how to name this thing. So I?m keeping close to the JS version as this is >> the same functionality. So I also have a UnifiedPushClient, that enables >> you to register your simple push endpoint. This would be about one class so >> I don?t think we would need a separate module for this. But that does make >> the naming of this module harder :) >> >> I was thinking just calling it aerogear-simplepush-java so 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 >> > > _______________________________________________ > 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 > -- 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/20140115/428104da/attachment.html From lholmqui at redhat.com Wed Jan 15 10:16:42 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 15 Jan 2014 10:16:42 -0500 Subject: [aerogear-dev] java simple push / unified client In-Reply-To: References: <72F02973-9DAC-4CE3-A920-7AD2BB13119E@redhat.com> <1B995F12-9CED-429A-B38F-E67B876000C1@redhat.com> Message-ID: <0CA53698-9D9B-4325-8ED7-51ACD1EAF93C@redhat.com> i didn't actually look at the code, just made some assumptions( bad ) from the title On Jan 15, 2014, at 10:14 AM, Matthias Wessendorf wrote: > Isn't that more for sending (HTTP put) from a Node backend to any SimplePush Server? > > The lib from Erik is a _client_ (not a "sender"), that can receive the SimplePush payload in a JavaSE environment > > -M > > > On Wed, Jan 15, 2014 at 3:49 PM, Lucas Holmquist wrote: > this sounds a lot like the node client that i randomly created one day for simple push > https://github.com/lholmquist/aerogear-simplepush-node-client > > > On Jan 13, 2014, at 9:21 AM, Erik Jan de Wit wrote: > >> So it will be renamed but here is an initial version: >> >> https://github.com/edewit/aerogear-simplepush-java >> >> On 13 Jan,2014, at 10:47 , Sebastien Blanc wrote: >> >>> Since Aerogear also offers a SPS "server" maybe it will be more clear if we specify it's a client lib like : aerogear-simplepush-java-client . >>> Concerning the UPS bits, let's keep it in the same module as long we document it. >>> >>> >>> On Mon, Jan 13, 2014 at 10:36 AM, Erik Jan de Wit wrote: >>> Hi, >>> >>> I just finished a quick POC to see how hard it would be to create a simple push java client. And guess what it wasn?t hard at all only 20 / 30 lines of code. Now to make this a proper lib I was struggling a bit with how to name this thing. So I?m keeping close to the JS version as this is the same functionality. So I also have a UnifiedPushClient, that enables you to register your simple push endpoint. This would be about one class so I don?t think we would need a separate module for this. But that does make the naming of this module harder :) >>> >>> I was thinking just calling it aerogear-simplepush-java so 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 >>> >>> _______________________________________________ >>> 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 > > > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140115/02586cb3/attachment.html From lholmqui at redhat.com Wed Jan 15 15:31:16 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 15 Jan 2014 15:31:16 -0500 Subject: [aerogear-dev] [iOS] Simple draft of HTTP API to talk to ag-sync server In-Reply-To: References: Message-ID: well, i've hacked something together for js here in this branch: https://github.com/lholmquist/aerogear-js/tree/AGJS-124 it is in no way complete, just some idea's. to run the tests here, you need to have dan's server running. i'm currently trying out https://github.com/benjamine/JsonDiffPatch to do the diff/patching during an update conflict, Here is a quick and dirty API that i was thinking could be a start, for JS at least // Create a New Data Sync Object var dataSync = AeroGear.DataSync( { syncServerUrl: "http://localhost:8080" } ); /* possibly more options here, like "auto-merge" options = { syncServerUrl: "link_to_sync_server", autoMerge: false, //optional, defaults to false? Not sure this is the right spot for this, maybe should be in the update call otheroptions: .... } */ // Probably have 3 Methods: read, save( Update ), remove // each one has 2 parameters, the "document" and the settings /* The document here is an object defined like in qmx's sync thought dump var document = { id: "123sjf2-i", content: { // Some Arbitrary JSON or an array or something serializable into JSON }, rev: "SOME_REVISION_ID" // or rev_id or revision or revision_id, we can argue over names later } */ dataSync.read( document, settings ); /* --READ-- var settings = { success: function( document ){}, // GET the document error: function( error ){} // an error happened GETting the document, like it can't be found or something } */ dataSync.save( document, settings ); /* --Save-- document can be either an array or an object if whatever is passed is in the form of the document specifed above, then save works as an "update" var settings: { autoMerge: // not sure if this should be here or in the constructor success: function( document ){} // successful PUT to create the document or update the document, conflict: function( error, current_model_from_server, delta_of_current_server_model_and_local_document ) // this delta thing should be nice and user friendly or something SOME_OTHER_SPECIFIC_CALLBACK: function(){}, // Maybe other callbacks for specific events error: function( error ){} // an error happened, catch-all ? } */ dataSync.remove( document, settings ); /* TBD */ On Jan 13, 2014, at 11:56 AM, Matthias Wessendorf wrote: > Hi, > > based on the ag.org "sync-branch" (see [1]), I created a SIMPLE first iOS hack of a "document" API with a HTTP client that talks to Dan's Server. > > The model ([2]) is quite easy/simple and the HTTP client supports CREATE/READ/REMOVE ([3]), based on the protocol defined on the README of the server. > > The usage is covered in a test (like [4]). > > Next: I guess next (if we continue using Dan's Server) is to see how this project can we weaved into the exisiting stores - but first I really wanted to get some client (like Luke's JS client) which executes against our current server draft/implementation. > > BTW. the lib is based on AFN2.x (not sure we should use AFN 2.x at THIS point - switching to 1.x should not be that hard) > > -Matthias > > [1] https://github.com/aerogear/aerogear.org/pull/230 > [2] https://github.com/matzew/AGSyncKit/blob/master/SyncKit/AGDocument.h > [3] https://github.com/matzew/AGSyncKit/blob/master/SyncKit/AGSyncClient.h > [4] https://github.com/matzew/AGSyncKit/blob/master/SyncKitTests/SyncKitTests.m#L37-L61 > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140115/97fcdb95/attachment-0001.html From matzew at apache.org Thu Jan 16 01:31:50 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 16 Jan 2014 07:31:50 +0100 Subject: [aerogear-dev] [iOS] Apple requires iOS 7 for new apps/updates by Feb 1st Message-ID: Hi, in December, while I was away, I missed an email from Apple Developer, telling that by Feb. 1st all app submissions to the store need to be 'optimized' for iOS 7. "Starting February 1, new apps and app updates submitted to the App Store must be built with the latest version of Xcode 5 and must be optimized for iOS 7. " That's an interesting statement; also for our iOS libraries... - So.... looks like we can simply remove the 'support' / linkage of older SDKs, and straight update to iOS 7... Thoughts ? -Matthias [1] https://developer.apple.com/news/ [2] http://techcrunch.com/2013/12/17/apple-requiring-all-app-submissions-to-be-optimized-for-ios-7-by-feb-1st/ -- 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/20140116/2e40379f/attachment.html From cvasilak at gmail.com Thu Jan 16 03:21:11 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Thu, 16 Jan 2014 10:21:11 +0200 Subject: [aerogear-dev] [iOS] Apple requires iOS 7 for new apps/updates by Feb 1st In-Reply-To: References: Message-ID: <66BF1C73-3838-4CFD-936E-26FC5282E7E5@gmail.com> On Jan 16, 2014, at 8:31 AM, Matthias Wessendorf wrote: > Hi, > > in December, while I was away, I missed an email from Apple Developer, telling that by Feb. 1st all app submissions to the store need to be 'optimized' for iOS 7. > > "Starting February 1, new apps and app updates submitted to the App Store must be built with the latest version of Xcode 5 and must be optimized for iOS 7. " > > > That's an interesting statement; also for our iOS libraries... - So.... looks like we can simply remove the 'support' / linkage of older SDKs, and straight update to iOS 7... > > Thoughts ? IMHO it makes sense to move +1 - Christos > -Matthias > > [1] https://developer.apple.com/news/ > [2] http://techcrunch.com/2013/12/17/apple-requiring-all-app-submissions-to-be-optimized-for-ios-7-by-feb-1st/ > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140116/c047bedf/attachment.html From kpiwko at redhat.com Thu Jan 16 04:29:28 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Thu, 16 Jan 2014 10:29:28 +0100 Subject: [aerogear-dev] [iOS] Apple requires iOS 7 for new apps/updates by Feb 1st In-Reply-To: References: Message-ID: <20140116102928.4445497f@kapy-ntb-x220> Interesting. Do you think this will increase iOS7 adoption? Can this be translated as that AG web based stuff does not need to support Mobile Safari distributed in iOS 6 (or even previous versions) neither? On Thu, 16 Jan 2014 07:31:50 +0100 Matthias Wessendorf wrote: > Hi, > > in December, while I was away, I missed an email from Apple Developer, > telling that by Feb. 1st all app submissions to the store need to be > 'optimized' for iOS 7. > > "Starting February 1, new apps and app updates submitted to the App Store > must be built with the latest version of Xcode 5 and must be optimized for > iOS 7. " > > > That's an interesting statement; also for our iOS libraries... - So.... > looks like we can simply remove the 'support' / linkage of older SDKs, and > straight update to iOS 7... > > Thoughts ? > > -Matthias > > [1] https://developer.apple.com/news/ > [2] > http://techcrunch.com/2013/12/17/apple-requiring-all-app-submissions-to-be-optimized-for-ios-7-by-feb-1st/ > From matzew at apache.org Thu Jan 16 04:36:47 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 16 Jan 2014 10:36:47 +0100 Subject: [aerogear-dev] [iOS] Apple requires iOS 7 for new apps/updates by Feb 1st In-Reply-To: <20140116102928.4445497f@kapy-ntb-x220> References: <20140116102928.4445497f@kapy-ntb-x220> Message-ID: On Thu, Jan 16, 2014 at 10:29 AM, Karel Piwko wrote: > Interesting. Do you think this will increase iOS7 adoption? > well, from ~ 90% to 100? :-) > > Can this be translated as that AG web based stuff does not need > to support Mobile Safari distributed in iOS 6 (or even previous versions) > neither? > I'd say: Yes > > On Thu, 16 Jan 2014 07:31:50 +0100 > Matthias Wessendorf wrote: > > > Hi, > > > > in December, while I was away, I missed an email from Apple Developer, > > telling that by Feb. 1st all app submissions to the store need to be > > 'optimized' for iOS 7. > > > > "Starting February 1, new apps and app updates submitted to the App Store > > must be built with the latest version of Xcode 5 and must be optimized > for > > iOS 7. " > > > > > > That's an interesting statement; also for our iOS libraries... - So.... > > looks like we can simply remove the 'support' / linkage of older SDKs, > and > > straight update to iOS 7... > > > > Thoughts ? > > > > -Matthias > > > > [1] https://developer.apple.com/news/ > > [2] > > > http://techcrunch.com/2013/12/17/apple-requiring-all-app-submissions-to-be-optimized-for-ios-7-by-feb-1st/ > > > > _______________________________________________ > 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/20140116/0900b64e/attachment.html From matzew at apache.org Thu Jan 16 05:57:45 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 16 Jan 2014 11:57:45 +0100 Subject: [aerogear-dev] [iOS] Apple requires iOS 7 for new apps/updates by Feb 1st In-Reply-To: <66BF1C73-3838-4CFD-936E-26FC5282E7E5@gmail.com> References: <66BF1C73-3838-4CFD-936E-26FC5282E7E5@gmail.com> Message-ID: On Thu, Jan 16, 2014 at 9:21 AM, Christos Vasilakis wrote: > > On Jan 16, 2014, at 8:31 AM, Matthias Wessendorf > wrote: > > Hi, > > in December, while I was away, I missed an email from Apple Developer, > telling that by Feb. 1st all app submissions to the store need to be > 'optimized' for iOS 7. > > "Starting February 1, new apps and app updates submitted to the App Store > must be built with the latest version of Xcode 5 and must be optimized for > iOS 7. " > > > That's an interesting statement; also for our iOS libraries... - So.... > looks like we can simply remove the 'support' / linkage of older SDKs, and > straight update to iOS 7... > > Thoughts ? > > > IMHO it makes sense to move +1 > What do you think of creating a JIRA for 'optimizing iOS libraries for iOS7" ? After the 1.4.0 is released, we could do that task, release a 1.5.0 and move on with other items (e.g. like sync) -Matthias > > - > Christos > > > -Matthias > > [1] https://developer.apple.com/news/ > [2] > http://techcrunch.com/2013/12/17/apple-requiring-all-app-submissions-to-be-optimized-for-ios-7-by-feb-1st/ > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140116/734bbdb0/attachment.html From matzew at apache.org Thu Jan 16 06:36:23 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 16 Jan 2014 12:36:23 +0100 Subject: [aerogear-dev] [Documentation] AeroGear Newsstand App (for iOS?) Message-ID: Hi, today, on the IRC channel we chatted about the idea to create a newsstand app (for iOS), which contains the AeroGear documentation. A newsstand app is sort of a newspaper/magazine, optimized for browsing on an iOS device. It could contain not only our documentation, but also 'blog posts', tutorials etc - pretty much content from our website. The app would go in the real Apple App Store, since it is not a demo - it's a real app. In combination w/ UnifiedPush Server, the APNs could be used to ping users of the app that new content is available. The application itself would be a nice 'show-case' of the AeroGear-iOS library as well. Not sure about the priority of this atm, but just wondering about the idea itself. Any thoughts? -Matthias [1] https://developer.apple.com/library/ios/documentation/StoreKit/Reference/NewsstandKit_Framework/_index.html [2] http://www.viggiosoft.com/blog/blog/2011/10/17/ios-newsstand-tutorial/ -- 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/20140116/ffbeb6f6/attachment-0001.html From cvasilak at gmail.com Thu Jan 16 08:57:07 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Thu, 16 Jan 2014 15:57:07 +0200 Subject: [aerogear-dev] [iOS] Apple requires iOS 7 for new apps/updates by Feb 1st In-Reply-To: References: <66BF1C73-3838-4CFD-936E-26FC5282E7E5@gmail.com> Message-ID: <91578BA2-6549-489E-8335-F1FE8DF1CE4C@gmail.com> On Jan 16, 2014, at 12:57 PM, Matthias Wessendorf wrote: > > > > On Thu, Jan 16, 2014 at 9:21 AM, Christos Vasilakis wrote: > > On Jan 16, 2014, at 8:31 AM, Matthias Wessendorf wrote: > >> Hi, >> >> in December, while I was away, I missed an email from Apple Developer, telling that by Feb. 1st all app submissions to the store need to be 'optimized' for iOS 7. >> >> "Starting February 1, new apps and app updates submitted to the App Store must be built with the latest version of Xcode 5 and must be optimized for iOS 7. " >> >> >> That's an interesting statement; also for our iOS libraries... - So.... looks like we can simply remove the 'support' / linkage of older SDKs, and straight update to iOS 7... >> >> Thoughts ? > > IMHO it makes sense to move +1 > > What do you think of creating a JIRA for 'optimizing iOS libraries for iOS7" ? > After the 1.4.0 is released, we could do that task, release a 1.5.0 and move on with other items (e.g. like sync) sounds like a plan opened to track: https://issues.jboss.org/browse/AGIOS-152 - Christos > > > -Matthias > > > > > - > Christos > > >> -Matthias >> >> [1] https://developer.apple.com/news/ >> [2] http://techcrunch.com/2013/12/17/apple-requiring-all-app-submissions-to-be-optimized-for-ios-7-by-feb-1st/ >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140116/f11119ab/attachment.html From scm.blanc at gmail.com Thu Jan 16 11:47:04 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Thu, 16 Jan 2014 17:47:04 +0100 Subject: [aerogear-dev] [Documentation] AeroGear Newsstand App (for iOS?) In-Reply-To: References: Message-ID: This is really a cool idea ! +1 On Thu, Jan 16, 2014 at 12:36 PM, Matthias Wessendorf wrote: > Hi, > > today, on the IRC channel we chatted about the idea to create a newsstand > app (for iOS), which contains the AeroGear documentation. A newsstand app > is sort of a newspaper/magazine, optimized for browsing on an iOS device. > > It could contain not only our documentation, but also 'blog posts', > tutorials etc - pretty much content from our website. > > The app would go in the real Apple App Store, since it is not a demo - > it's a real app. > > In combination w/ UnifiedPush Server, the APNs could be used to ping users > of the app that new content is available. > > The application itself would be a nice 'show-case' of the AeroGear-iOS > library as well. > > Not sure about the priority of this atm, but just wondering about the idea > itself. > > Any thoughts? > -Matthias > > [1] > https://developer.apple.com/library/ios/documentation/StoreKit/Reference/NewsstandKit_Framework/_index.html > > [2] http://www.viggiosoft.com/blog/blog/2011/10/17/ios-newsstand-tutorial/ > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140116/967dc049/attachment.html From matzew at apache.org Thu Jan 16 17:13:57 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 16 Jan 2014 23:13:57 +0100 Subject: [aerogear-dev] [Documentation] AeroGear Newsstand App (for iOS?) In-Reply-To: References: Message-ID: For now I just created an 'umbrella' ticket, AEROGEAR-1393, for future tracking -Matthias https://issues.jboss.org/browse/AEROGEAR-1393 On Thu, Jan 16, 2014 at 5:47 PM, Sebastien Blanc wrote: > This is really a cool idea ! > +1 > > > > On Thu, Jan 16, 2014 at 12:36 PM, Matthias Wessendorf wrote: > >> Hi, >> >> today, on the IRC channel we chatted about the idea to create a newsstand >> app (for iOS), which contains the AeroGear documentation. A newsstand app >> is sort of a newspaper/magazine, optimized for browsing on an iOS device. >> >> It could contain not only our documentation, but also 'blog posts', >> tutorials etc - pretty much content from our website. >> >> The app would go in the real Apple App Store, since it is not a demo - >> it's a real app. >> >> In combination w/ UnifiedPush Server, the APNs could be used to ping >> users of the app that new content is available. >> >> The application itself would be a nice 'show-case' of the AeroGear-iOS >> library as well. >> >> Not sure about the priority of this atm, but just wondering about the >> idea itself. >> >> Any thoughts? >> -Matthias >> >> [1] >> https://developer.apple.com/library/ios/documentation/StoreKit/Reference/NewsstandKit_Framework/_index.html >> >> [2] >> http://www.viggiosoft.com/blog/blog/2011/10/17/ios-newsstand-tutorial/ >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140116/82567fd2/attachment.html From corinnekrych at gmail.com Fri Jan 17 04:27:31 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 17 Jan 2014 10:27:31 +0100 Subject: [aerogear-dev] [Documentation] AeroGear Newsstand App (for iOS?) In-Reply-To: References: Message-ID: <15BF2D2D-B21B-4CF3-A2DC-B92E6A3A12CE@gmail.com> Excellent! I might borrow the idea and kick start it in AeroGear hackengarten the 25th Januray [1] I was thinking to work on cookbook but this is good too. ++ Corinne [1] http://marsjug.org/#hackergarten2 On 16 Jan 2014, at 23:13, Matthias Wessendorf wrote: > For now I just created an 'umbrella' ticket, AEROGEAR-1393, for future tracking > > -Matthias > > https://issues.jboss.org/browse/AEROGEAR-1393 > > > On Thu, Jan 16, 2014 at 5:47 PM, Sebastien Blanc wrote: > This is really a cool idea ! > +1 > > > > On Thu, Jan 16, 2014 at 12:36 PM, Matthias Wessendorf wrote: > Hi, > > today, on the IRC channel we chatted about the idea to create a newsstand app (for iOS), which contains the AeroGear documentation. A newsstand app is sort of a newspaper/magazine, optimized for browsing on an iOS device. > > It could contain not only our documentation, but also 'blog posts', tutorials etc - pretty much content from our website. > > The app would go in the real Apple App Store, since it is not a demo - it's a real app. > > In combination w/ UnifiedPush Server, the APNs could be used to ping users of the app that new content is available. > > The application itself would be a nice 'show-case' of the AeroGear-iOS library as well. > > Not sure about the priority of this atm, but just wondering about the idea itself. > > Any thoughts? > -Matthias > > [1] https://developer.apple.com/library/ios/documentation/StoreKit/Reference/NewsstandKit_Framework/_index.html > [2] http://www.viggiosoft.com/blog/blog/2011/10/17/ios-newsstand-tutorial/ > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From cvasilak at gmail.com Fri Jan 17 04:39:33 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Fri, 17 Jan 2014 11:39:33 +0200 Subject: [aerogear-dev] [Documentation] AeroGear Newsstand App (for iOS?) In-Reply-To: References: Message-ID: sounds like a great idea++ ! - Christos On Jan 16, 2014, at 1:36 PM, Matthias Wessendorf wrote: > Hi, > > today, on the IRC channel we chatted about the idea to create a newsstand app (for iOS), which contains the AeroGear documentation. A newsstand app is sort of a newspaper/magazine, optimized for browsing on an iOS device. > > It could contain not only our documentation, but also 'blog posts', tutorials etc - pretty much content from our website. > > The app would go in the real Apple App Store, since it is not a demo - it's a real app. > > In combination w/ UnifiedPush Server, the APNs could be used to ping users of the app that new content is available. > > The application itself would be a nice 'show-case' of the AeroGear-iOS library as well. > > Not sure about the priority of this atm, but just wondering about the idea itself. > > Any thoughts? > -Matthias > > [1] https://developer.apple.com/library/ios/documentation/StoreKit/Reference/NewsstandKit_Framework/_index.html > [2] http://www.viggiosoft.com/blog/blog/2011/10/17/ios-newsstand-tutorial/ > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140117/7ad240ac/attachment-0001.html From matzew at apache.org Fri Jan 17 06:20:27 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 17 Jan 2014 12:20:27 +0100 Subject: [aerogear-dev] Team meeting agenda Message-ID: Proposed agenda for Mondays team meeting: http://oksoclap.com/p/aerogear-team-mgt-20140120 -- 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/20140117/24b30a08/attachment.html From daniel at passos.me Fri Jan 17 07:54:52 2014 From: daniel at passos.me (Daniel Passos) Date: Fri, 17 Jan 2014 10:54:52 -0200 Subject: [aerogear-dev] OpenShift profile in AeroGear (backend) projects Message-ID: Hi folks, What do you think about add Openshift profile in our backend projects? openshift project-name maven-war-plugin 2.1.1 deployments ROOT -- Daniel Passos -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140117/6f83bda8/attachment.html From cvasilak at gmail.com Fri Jan 17 08:06:44 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Fri, 17 Jan 2014 15:06:44 +0200 Subject: [aerogear-dev] OpenShift profile in AeroGear (backend) projects In-Reply-To: References: Message-ID: +1 for OpenShift hosted ones - Christos On Jan 17, 2014, at 2:54 PM, Daniel Passos wrote: > Hi folks, > > What do you think about add Openshift profile in our backend projects? > > > > > > > openshift > > project-name > > > maven-war-plugin > 2.1.1 > > deployments > ROOT > > > > > > -- Daniel Passos > > _______________________________________________ > 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/20140117/4523c267/attachment.html From lholmqui at redhat.com Fri Jan 17 08:13:51 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 17 Jan 2014 08:13:51 -0500 Subject: [aerogear-dev] Sync data model comparison In-Reply-To: <52CDBE15.1040902@redhat.com> References: <52CDBE15.1040902@redhat.com> Message-ID: <94189F85-39D2-4095-B09A-1CB4AF8A94E9@redhat.com> so i briefly looked at the spread sheet, i'm concerned about having to keep 2 models on the client, especially on the mobile web, since there is limited space( storage ) to work with as well as memory. i wonder what the performance impact of this is? it sounds cool though On Jan 8, 2014, at 4:07 PM, Summers Pittman wrote: > So I'm not sure I see how the data model in the current sync spec helps > with syncing data. Also the current spec draft is lacking a transport > format as well. > > I propose using the dual shadow data model described here: > https://neil.fraser.name/writing/sync/ > > ## Data Model: and Transport: > > Client side each piece of data which is currently in active > synchronization (ie the client is sending AND receiving updates at the > same time) has a copy of her data which represents the current assumed > good synchronized state. She also has the copy of the data she is > editing. When she has finished her edit (for an use case specific > defined by the developer definition of finish) the system will generate > a diff based on the JSON representations of her shadow and her model. > The model will replace the shadow and a diff of her data as well as a > checksum of her data will be sent to the server for processing. > > Server side the server will maintain its own model of the shared data, > as well as shadows for each session currently sync the data. When it > receives a sync, the diff will be applied to the server's shadow of the > session which sent the diff. If the diff merges cleanly and the > checksum of the server shadow matches the checksum in the transport, > then the server will update the canonical model of the data against what > was in the session's updated shadow. The server will then diff all of > its sessions' shadows against its model and send out diff messages to > the clients. > > I've made a spreadsheet* where I follow one of QMX's sample applications > and step through a few workflows with my proposed data model. (This is > the data model I use in the DevNexus sync demo and the real time text > demo). I would welcome someone to implement the use case with QMX's > proposed data model. > > * > https://docs.google.com/spreadsheet/ccc?key=0AjSy-Z4v4qE-dGhESFU5R1BSWTF3RnliMjVic3JnbXc#gid=1 > > wdyt? Who would mind doing the data flow for the other model? > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From supittma at redhat.com Fri Jan 17 09:51:21 2014 From: supittma at redhat.com (Summers Pittman) Date: Fri, 17 Jan 2014 09:51:21 -0500 Subject: [aerogear-dev] Sync data model comparison In-Reply-To: <94189F85-39D2-4095-B09A-1CB4AF8A94E9@redhat.com> References: <52CDBE15.1040902@redhat.com> <94189F85-39D2-4095-B09A-1CB4AF8A94E9@redhat.com> Message-ID: <52D94369.40707@redhat.com> On Fri 17 Jan 2014 08:13:51 AM EST, Lucas Holmquist wrote: > so i briefly looked at the spread sheet, i'm concerned about having to keep 2 models on the client, especially on the mobile web, since there is limited space( storage ) to work with as well as memory. i wonder what the performance impact of this is? Sounds like a good time for implement and measure :-p. On a less snarky tone the answer is it depends. At most you just double your storage, but part of the idea is also you have to be smart about what is being synced. If the user isn't editing a document then you don't need to be maintaining your local shadow. > > it sounds cool though > On Jan 8, 2014, at 4:07 PM, Summers Pittman wrote: > >> So I'm not sure I see how the data model in the current sync spec helps >> with syncing data. Also the current spec draft is lacking a transport >> format as well. >> >> I propose using the dual shadow data model described here: >> https://neil.fraser.name/writing/sync/ >> >> ## Data Model: and Transport: >> >> Client side each piece of data which is currently in active >> synchronization (ie the client is sending AND receiving updates at the >> same time) has a copy of her data which represents the current assumed >> good synchronized state. She also has the copy of the data she is >> editing. When she has finished her edit (for an use case specific >> defined by the developer definition of finish) the system will generate >> a diff based on the JSON representations of her shadow and her model. >> The model will replace the shadow and a diff of her data as well as a >> checksum of her data will be sent to the server for processing. >> >> Server side the server will maintain its own model of the shared data, >> as well as shadows for each session currently sync the data. When it >> receives a sync, the diff will be applied to the server's shadow of the >> session which sent the diff. If the diff merges cleanly and the >> checksum of the server shadow matches the checksum in the transport, >> then the server will update the canonical model of the data against what >> was in the session's updated shadow. The server will then diff all of >> its sessions' shadows against its model and send out diff messages to >> the clients. >> >> I've made a spreadsheet* where I follow one of QMX's sample applications >> and step through a few workflows with my proposed data model. (This is >> the data model I use in the DevNexus sync demo and the real time text >> demo). I would welcome someone to implement the use case with QMX's >> proposed data model. >> >> * >> https://docs.google.com/spreadsheet/ccc?key=0AjSy-Z4v4qE-dGhESFU5R1BSWTF3RnliMjVic3JnbXc#gid=1 >> >> wdyt? Who would mind doing the data flow for the other model? >> _______________________________________________ >> 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 Jan 17 11:31:09 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 17 Jan 2014 17:31:09 +0100 Subject: [aerogear-dev] [UnifiedPush] Refactorings Message-ID: Hi, over the next weeks, after we get the 0.10.0 out, there will be some refactorings on different parts of the server: - make the 'core' the sending logic a little more isolated - look into a better 'abstraction' for the data storage I think this might lead to new (sub)projects and JAR files. I was wondering, do folks like a - pom.xml - sender-component/ - data/ - api - some impl projects - pushee/ (the server as is today, but including above 'components') - database-scripts (the CLI files for WildFly/AS) 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/20140117/d3c88f22/attachment-0001.html From jbalunas at redhat.com Fri Jan 17 14:53:06 2014 From: jbalunas at redhat.com (Jay Balunas) Date: Fri, 17 Jan 2014 14:53:06 -0500 Subject: [aerogear-dev] AeroGear January sync release postponed Message-ID: <6CC5A734-4EE1-4BC9-93B4-37633836B217@redhat.com> Hi All, We've been making a lot of progress on sync, but as many of you likely already know it is not ready for a full focused release. Much like encryption, sync is a significant feature and is still in active R&D and likely needs multiple iterations given its complexity. Its much better to let this mature organically that force it out the door before its out of diapers :-) So with that said, I propose postponing the planned January umbrella release. I think we should revisit our roadmaps and plans during this time, before trying to set new release dates. While we do this we should make sure to add in time for updates to docs, examples, getting started items, site, cookbooks, etc... Thoughts? Jay From jbalunas at redhat.com Fri Jan 17 16:04:49 2014 From: jbalunas at redhat.com (Jay Balunas) Date: Fri, 17 Jan 2014 16:04:49 -0500 Subject: [aerogear-dev] Keycloak integration ideas Message-ID: Hi All, Sorry all - book mode ;-) We've had a couple of threads around keycloak integration (thanks Abstractj) and working together with them (both in our dev list and theirs). I had a meeting (dinner really) with Bill and talked about some possibilities and we're both excited to see what can happen. I wanted to capture some of those thoughts here (as well as some that already started before), have some discussions, and more importantly talk about next steps (jira's) to get some of this in the pipeline. I'm sure this is not exhaustive either, so please add your own thoughts, brainstorming etc... (for example Cordova plugin perhaps?) *In no particular order A) AeroGear security integration ** Abstractj already posted and implemented some of these changes ** http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Keycloak-on-AeroGear-td5663.html ** What's left here? Is it plug-able? Does it need to be? B) Crypto key management ** Server-side encryption key management for client crypto ** Abstractj had some discussions here *** http://lists.jboss.org/pipermail/keycloak-dev/2013-December/000915.html *** Where does that stand? ** Do we need our own impl as well? C) UnifiedPush server integration ** User management, Auth* ** Do we have our own basic impl for quickstart experience? ** See below for possible combined cartridge options D) Cross-project examples, tutorials, docs, etc... ** TBD KeyCloak has some things they need as well, that we could work together on. I'm sure the KeyCloak team could add more here :-) Z) Device support ** We need it, they need, and others need it ** Bill would like us to help them (and us at the same time) with this. Y) OpenShift Cartridge for KeyCloak ** I know this is already on their roadmap ** The work Farah and others has already done, could be very helpful to them ** We should also discuss the possibility of a joint cartridge *** Could be really compelling, especially if you add in device, client key, and push support with native SDKs & examples *** Would also want separate cartridges as well imo X) Client SDK support ** We have client SDKs & could help with their dev (either as part of AeroGear or KeyCloak perhaps) ** Primarily for iOS & Android, but would also want see where JS & Cordova fit. You start putting all of this together and there is a great set of functionality that really compliments each other well. After we discuss for a while, I'd like to find owners for the various items to help make progress on these. Abstractj is awesome, but not sure he can do it all ;-) -Jay PS: I'll post an email to the keycloak-dev list as well pointing to this thread on our list. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140117/a2969527/attachment.html From lholmqui at redhat.com Sat Jan 18 13:31:49 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Sat, 18 Jan 2014 13:31:49 -0500 Subject: [aerogear-dev] JS Future Roadmap Message-ID: I was having some thoughts on the future of AeroGear.js that i needed to share. Experimental Branch I think i want to create a branch that is very experimental, that targets new and upcoming API's, like Object.Observe, and Promises, etc? I feel this is the only way to drive innovation I was thinking this is sort of our "Canary" branch, and when things start to become less pollyfilly, then we can start to move these features in. I still however want the code in this branch to be complete, not just random crap 2.0 I would like to see that in 2.0 we start to remove our jQuery requirement, and focus more on Modern Browsers and have our 1.X branch be our less than modern browser( IE9 ) supported branch. much like how jQuery has a 1.X and 2.X branch, obviously the difference between our branches won't be as extreme. The major thing we use jQuery for atm is jQuery.ajax and Promises. this is nice for cross broswer compatibility and for transpoting other things other than json, which brings me to my next point I would also like in 2.0 to make our library( pipeline ) only speak json. I think this will make it really simple to have our own AeroGear.Ajax() method and be able to keep it small in size 1.X Branch Once we hit all our 1.X milestones( sync, offline ) then what is the current master branch would become a 1.X branch, and we recieve bug fixes, but no new features. If something in the future could be back ported, then maybe, but it wouldn't be a priority This branch would still have a jQuery requirement and would be for legacy stuff( IE9 ) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140118/b17d463e/attachment.html From sportsnewsblog318 at gmail.com Sat Jan 18 13:51:40 2014 From: sportsnewsblog318 at gmail.com (jack123) Date: Sat, 18 Jan 2014 10:51:40 -0800 (PST) Subject: [aerogear-dev] {{{ FuLL HD tV }}}LivE EnJOY Indiana State vs (5) Wichita State live online Watch HD TV Message-ID: <1390071100013-5824.post@n5.nabble.com> Welcome NCAA Men Basketball Fan?s !!! I think, your are surfing internet for get your favorite teams Live Online Watch match Indiana State vs (5) Wichita State live streaming TV link directly on your desktop, laptop or net-pad. Don?t worry, we are here for your help. Here you can get your all sporting event easy. So don?t be hesitated just follow our instruction and recommended streaming link assure that you are 100% satisfied in our service NCAA Men Basketball Match. It?s 100% Safe your money and Live Stream HD Quality. So Don?t miss Your favorite team Indiana State vs (5) Wichita State live sports. : Match schedules : Indiana State vs (5) Wichita State Live Competition: NCAA Men Basketball Date: Saturday, January 18, 2014 Time : 04:00 PM ET Live/Repeat: Live You can Watch easily live online Your favorite NCAA Men Basketball Match Live HD TV Link. And Totally HDQ. You can Watch all Sports also live Here & get instant 100% money back garanty. So click this TV link & watch Online HD TV. You can Watch all your favorite sports live here.?Get instant access to the widest sports coverage on the net directly on your PC,Laptop, Mobile,I phone,I pad and other devices anywhere in the world. So don?t be hesitated just follow our instruction and recommended streaming link assure that you are 100% satisfied in our service. clice here : http://sportsnewsgrup.blogspot.com/2014/01/full-hd-tv-live-enjoy-indiana-state-vs.html http://sportsnewsgrup.blogspot.com/2014/01/full-hd-tv-live-enjoy-indiana-state-vs.html http://sportsnewsgrup.blogspot.com/2014/01/full-hd-tv-live-enjoy-indiana-state-vs.html http://sportsnewsgrup.blogspot.com/2014/01/full-hd-tv-live-enjoy-indiana-state-vs.html http://sportsnewsgrup.blogspot.com/2014/01/full-hd-tv-live-enjoy-indiana-state-vs.html http://sportsnewsgrup.blogspot.com/2014/01/full-hd-tv-live-enjoy-indiana-state-vs.html http://sportsnewsgrup.blogspot.com/2014/01/full-hd-tv-live-enjoy-indiana-state-vs.html http://sportsnewsgrup.blogspot.com/2014/01/full-hd-tv-live-enjoy-indiana-state-vs.html http://sportsnewsgrup.blogspot.com/2014/01/full-hd-tv-live-enjoy-indiana-state-vs.html -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/FuLL-HD-tV-LivE-EnJOY-Indiana-State-vs-5-Wichita-State-live-online-Watch-HD-TV-tp5824.html Sent from the aerogear-dev mailing list archive at Nabble.com. From scm.blanc at gmail.com Sat Jan 18 14:31:24 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Sat, 18 Jan 2014 20:31:24 +0100 Subject: [aerogear-dev] JS Future Roadmap In-Reply-To: References: Message-ID: This sounds good. For 2.0, you speak about having our own AeroGear.Ajax(), do we also plan to rethink the concept of our pipeline ? There are some good stuff I really like , i.e the conventions for naming the endpoint, the save dealing with POST/PUT. But in the same time I see all the frameworks like Ember or Angular having their own solution and when integrating AeroGear I wonder which one to use or why using one rather than the other. I know that with sync, nice integrations are to come between pipes/datastore , maybe thinking on how we could integrate almost "transparently" with this "uber cool" frameworks would help people adopting it. On Sat, Jan 18, 2014 at 7:31 PM, Lucas Holmquist wrote: > I was having some thoughts on the future of AeroGear.js that i needed to > share. > > Experimental > Branch > > I think i want to create a branch that is very experimental, that targets > new and upcoming API's, like Object.Observe, and Promises, etc? > > I feel this is the only way to drive innovation > > I was thinking this is sort of our "Canary" branch, and when things start > to become less pollyfilly, then we can start to move these features in. > > I still however want the code in this branch to be complete, not just > random crap > > 2.0 > > I would like to see that in 2.0 we start to remove our jQuery requirement, > and focus more on Modern Browsers and have our 1.X branch be our less than > modern browser( IE9 ) supported branch. much like how jQuery has a 1.X and > 2.X branch, obviously the difference between our branches won't be as > extreme. > > The major thing we use jQuery for atm is jQuery.ajax and Promises. this is > nice for cross broswer compatibility and for transpoting other things other > than json, which brings me to my next point > > I would also like in 2.0 to make our library( pipeline ) only speak json. > I think this will make it really simple to have our own AeroGear.Ajax() > method and be able to keep it small in size > 1.X > Branch > > Once we hit all our 1.X milestones( sync, offline ) then what is the > current master branch would become a 1.X branch, and we recieve bug fixes, > but no new features. If something in the future could be back ported, then > maybe, but it wouldn't be a priority > > This branch would still have a jQuery requirement and would be for legacy > stuff( IE9 ) > > _______________________________________________ > 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/20140118/73cd6420/attachment-0001.html From sportsnewsblog318 at gmail.com Sat Jan 18 14:37:13 2014 From: sportsnewsblog318 at gmail.com (jack123) Date: Sat, 18 Jan 2014 11:37:13 -0800 (PST) Subject: [aerogear-dev] {{{ FuLL HD tV }}}LivE EnJOY Indiana State vs (5) Wichita State live online Watch HD TV Message-ID: <1390073833562-5826.post@n5.nabble.com> Welcome NCAA Men Basketball Fan?s !!! I think, your are surfing internet for get your favorite teams Live Online Watch match Indiana State vs (5) Wichita State live streaming TV link directly on your desktop, laptop or net-pad. Don?t worry, we are here for your help. Here you can get your all sporting event easy. So don?t be hesitated just follow our instruction and recommended streaming link assure that you are 100% satisfied in our service NCAA Men Basketball Match. It?s 100% Safe your money and Live Stream HD Quality. So Don?t miss Your favorite team Indiana State vs (5) Wichita State live sports. : Match schedules : Indiana State vs (5) Wichita State Live Competition: NCAA Men Basketball Date: Saturday, January 18, 2014 Time : 04:00 PM ET Live/Repeat: Live You can Watch easily live online Your favorite NCAA Men Basketball Match Live HD TV Link. And Totally HDQ. You can Watch all Sports also live Here & get instant 100% money back garanty. So click this TV link & watch Online HD TV. You can Watch all your favorite sports live here.?Get instant access to the widest sports coverage on the net directly on your PC,Laptop, Mobile,I phone,I pad and other devices anywhere in the world. So don?t be hesitated just follow our instruction and recommended streaming link assure that you are 100% satisfied in our service. clice here : http://sportsnewsgrup.blogspot.com/2014/01/full-hd-tv-live-enjoy-indiana-state-vs.html http://sportsnewsgrup.blogspot.com/2014/01/full-hd-tv-live-enjoy-indiana-state-vs.html http://sportsnewsgrup.blogspot.com/2014/01/full-hd-tv-live-enjoy-indiana-state-vs.html http://sportsnewsgrup.blogspot.com/2014/01/full-hd-tv-live-enjoy-indiana-state-vs.html http://sportsnewsgrup.blogspot.com/2014/01/full-hd-tv-live-enjoy-indiana-state-vs.html http://sportsnewsgrup.blogspot.com/2014/01/full-hd-tv-live-enjoy-indiana-state-vs.html http://sportsnewsgrup.blogspot.com/2014/01/full-hd-tv-live-enjoy-indiana-state-vs.html http://sportsnewsgrup.blogspot.com/2014/01/full-hd-tv-live-enjoy-indiana-state-vs.html http://sportsnewsgrup.blogspot.com/2014/01/full-hd-tv-live-enjoy-indiana-state-vs.html Remove Ads -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/FuLL-HD-tV-LivE-EnJOY-Indiana-State-vs-5-Wichita-State-live-online-Watch-HD-TV-tp5826.html Sent from the aerogear-dev mailing list archive at Nabble.com. From lholmqui at redhat.com Sat Jan 18 15:03:06 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Sat, 18 Jan 2014 15:03:06 -0500 Subject: [aerogear-dev] JS Future Roadmap In-Reply-To: References: Message-ID: On Jan 18, 2014, at 2:31 PM, Sebastien Blanc wrote: > This sounds good. > > For 2.0, you speak about having our own AeroGear.Ajax(), Well AeroGear.Ajax would only be an internal thing which pipeline and anything else that needed to talk to a server, like simplePush would use. > do we also plan to rethink the concept of our pipeline ? There are some good stuff I really like , i.e the conventions for naming the endpoint, the save dealing with POST/PUT. > > But in the same time I see all the frameworks like Ember or Angular having their own solution and when integrating AeroGear I wonder which one to use or why using one rather than the other. > > I know that with sync, nice integrations are to come between pipes/datastore , maybe thinking on how we could integrate almost "transparently" with this "uber cool" frameworks would help people adopting it. > > > > > > On Sat, Jan 18, 2014 at 7:31 PM, Lucas Holmquist wrote: > I was having some thoughts on the future of AeroGear.js that i needed to share. > > Experimental Branch > > I think i want to create a branch that is very experimental, that targets new and upcoming API's, like Object.Observe, and Promises, etc? > > I feel this is the only way to drive innovation > > I was thinking this is sort of our "Canary" branch, and when things start to become less pollyfilly, then we can start to move these features in. > > I still however want the code in this branch to be complete, not just random crap > > 2.0 > > I would like to see that in 2.0 we start to remove our jQuery requirement, and focus more on Modern Browsers and have our 1.X branch be our less than modern browser( IE9 ) supported branch. much like how jQuery has a 1.X and 2.X branch, obviously the difference between our branches won't be as extreme. > > The major thing we use jQuery for atm is jQuery.ajax and Promises. this is nice for cross broswer compatibility and for transpoting other things other than json, which brings me to my next point > > I would also like in 2.0 to make our library( pipeline ) only speak json. I think this will make it really simple to have our own AeroGear.Ajax() method and be able to keep it small in size > > 1.X Branch > > Once we hit all our 1.X milestones( sync, offline ) then what is the current master branch would become a 1.X branch, and we recieve bug fixes, but no new features. If something in the future could be back ported, then maybe, but it wouldn't be a priority > > This branch would still have a jQuery requirement and would be for legacy stuff( IE9 ) > > > _______________________________________________ > 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/20140118/07c5d258/attachment.html From mailnaveenraj at gmail.com Mon Jan 6 22:19:04 2014 From: mailnaveenraj at gmail.com (Naveenraj) Date: Mon, 6 Jan 2014 19:19:04 -0800 (PST) Subject: [aerogear-dev] does aerogear supported by mobile firefox Message-ID: <1389064744777-5703.post@n5.nabble.com> I just wantbto know if mozilla Firefox mobile is supported or not. In the tbd of mobile browser I am not able to find Firefox mobile. . -- View this message in context: http://aerogear-dev.1069024.n5.nabble.com/does-aerogear-supported-by-mobile-firefox-tp5703.html Sent from the aerogear-dev mailing list archive at Nabble.com. From bruno at abstractj.org Sun Jan 19 03:44:00 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Sun, 19 Jan 2014 03:44:00 -0500 Subject: [aerogear-dev] AeroGear January sync release postponed In-Reply-To: <6CC5A734-4EE1-4BC9-93B4-37633836B217@redhat.com> References: <6CC5A734-4EE1-4BC9-93B4-37633836B217@redhat.com> Message-ID: IMO we should postpone it to March to get something more stable, meanwhile I would vote to release small features (but unstable) on snapshots for testing. -- abstractj On January 17, 2014 at 2:53:13 PM, Jay Balunas (jbalunas at redhat.com) wrote: > > So with that said, I propose postponing the planned January > umbrella release. From bruno at abstractj.org Sun Jan 19 03:49:29 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Sun, 19 Jan 2014 03:49:29 -0500 Subject: [aerogear-dev] does aerogear supported by mobile firefox In-Reply-To: <1389064744777-5703.post@n5.nabble.com> References: <1389064744777-5703.post@n5.nabble.com> Message-ID: Good morning my friend, not yet. But if you want to start with something, Daniel Passos wrote an application using AeroGear JS (https://github.com/danielpassos/call4paperz4FirefoxOS) -- abstractj On January 18, 2014 at 5:22:42 PM, Naveenraj (mailnaveenraj at gmail.com) wrote: > > I just wantbto know if mozilla Firefox mobile is supported or > not. > In the tbd of mobile browser I am not able to find Firefox mobile. > . From bruno at abstractj.org Sun Jan 19 03:52:15 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Sun, 19 Jan 2014 03:52:15 -0500 Subject: [aerogear-dev] JS Future Roadmap In-Reply-To: References: Message-ID: +1000 -- abstractj On January 18, 2014 at 1:31:53 PM, Lucas Holmquist (lholmqui at redhat.com) wrote: > > I was having some thoughts on the future of AeroGear.js that i > needed to share. > > Experimental Branch > > I think i want to create a branch that is very experimental, that > targets new and upcoming API's, like Object.Observe, and Promises, > etc? > > I feel this is the only way to drive innovation > > I was thinking this is sort of our "Canary" branch, and when things > start to become less pollyfilly, then we can start to move these > features in. > > I still however want the code in this branch to be complete, not > just random crap > > 2.0 > > I would like to see that in 2.0 we start to remove our jQuery requirement, > and focus more on Modern Browsers and have our 1.X branch be our > less than modern browser( IE9 ) supported branch. much like how > jQuery has a 1.X and 2.X branch, obviously the difference between > our branches won't be as extreme. > > The major thing we use jQuery for atm is jQuery.ajax and Promises. > this is nice for cross broswer compatibility and for transpoting > other things other than json, which brings me to my next point > > I would also like in 2.0 to make our library( pipeline ) only speak > json. I think this will make it really simple to have our own AeroGear.Ajax() > method and be able to keep it small in size > > 1.X Branch > > Once we hit all our 1.X milestones( sync, offline ) then what is > the current master branch would become a 1.X branch, and we recieve > bug fixes, but no new features. If something in the future could > be back ported, then maybe, but it wouldn't be a priority > > This branch would still have a jQuery requirement and would be > for legacy stuff( IE9 )_______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Sun Jan 19 04:06:28 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sun, 19 Jan 2014 10:06:28 +0100 Subject: [aerogear-dev] does aerogear supported by mobile firefox In-Reply-To: References: <1389064744777-5703.post@n5.nabble.com> Message-ID: Hello Naveenraj, Besides the mentioned app, last week Erik Jan also did create an new app, for FirefoxOS: https://github.com/edewit/aerogear-aerodoc-firefoxos It is basically a port of our 'push show case'. I think these two different apps should give you a good starting point, how to use AeroGear APIs on a FirefoxOS device Greetings, Matthias On Sun, Jan 19, 2014 at 9:49 AM, Bruno Oliveira wrote: > Good morning my friend, not yet. But if you want to start with something, > Daniel Passos wrote an application using AeroGear JS ( > https://github.com/danielpassos/call4paperz4FirefoxOS) > > > > -- > abstractj > > On January 18, 2014 at 5:22:42 PM, Naveenraj (mailnaveenraj at gmail.com) > wrote: > > > I just wantbto know if mozilla Firefox mobile is supported or > > not. > > In the tbd of mobile browser I am not able to find Firefox mobile. > > . > > _______________________________________________ > 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/20140119/1755a24a/attachment-0001.html From matzew at apache.org Sun Jan 19 10:18:10 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sun, 19 Jan 2014 16:18:10 +0100 Subject: [aerogear-dev] Keycloak integration ideas In-Reply-To: References: Message-ID: On Fri, Jan 17, 2014 at 10:04 PM, Jay Balunas wrote: > Hi All, > > Sorry all - book mode ;-) > > We've had a couple of threads around keycloak integration (thanks > Abstractj) and working together with them (both in our dev list and > theirs). I had a meeting (dinner really) with Bill and talked about some > possibilities and we're both excited to see what can happen. > > I wanted to capture some of those thoughts here (as well as some that > already started before), have some discussions, and more importantly talk > about next steps (jira's) to get some of this in the pipeline. I'm sure > this is not exhaustive either, so please add your own thoughts, > brainstorming etc... (for example Cordova plugin perhaps?) > > *In no particular order > > A) AeroGear security integration > ** Abstractj already posted and implemented some of these changes > ** > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Keycloak-on-AeroGear-td5663.html > ** What's left here? Is it plug-able? Does it need to be? > The work started by Bruno looks promising. I like that for the login to the UPS Admin UI is being forwarded to the Keycloak server. As mentioned on the referenced thread, there is a bit of more work needed for the "protection" of the SEND (and likely device registration) URLs. > B) Crypto key management > ** Server-side encryption key management for client crypto > ** Abstractj had some discussions here > *** > http://lists.jboss.org/pipermail/keycloak-dev/2013-December/000915.html > *** Where does that stand? > ** Do we need our own impl as well? > > C) UnifiedPush server integration > ** User management, Auth* > ** Do we have our own basic impl for quickstart experience? > ** See below for possible combined cartridge options > yep, the UPS come in mind and as mentioned in A) Bruno was already actively starting this shortly before XMAS. > > D) Cross-project examples, tutorials, docs, etc... > ** TBD > Sure, combined docs/tutorials/examples are a good item once we do have a bit more :-) Not sure it makes much sense now, but I can be wrong > > KeyCloak has some things they need as well, that we could work together > on. I'm sure the KeyCloak team could add more here :-) > > Z) Device support > ** We need it, they need, and others need it > ** Bill would like us to help them (and us at the same time) with this. > yeah - that would be an extremely good fit for our Push efforts. > > Y) OpenShift Cartridge for KeyCloak > ** I know this is already on their roadmap > ** The work Farah and others has already done, could be very helpful to > them > ** We should also discuss the possibility of a joint cartridge > *** Could be really compelling, especially if you add in device, client > key, and push support with native SDKs & examples > *** Would also want separate cartridges as well imo > yeah, I see various options here: * 'standalone' Keycloak cartridge (on their roadmap already); Would be nice to get Farah involved here as well * combined cartridge (E.g. Push + Keycloak). If we do actually fully integrate Keycloak into the Push work, IMO this is a required option, to simply include the Keycloak offerings into our Push Cartridge > > X) Client SDK support > ** We have client SDKs & could help with their dev (either as part of > AeroGear or KeyCloak perhaps) > ** Primarily for iOS & Android, but would also want see where JS & Cordova > fit. > Yes, another good integration item, would be interesting to know their 'requirements'. I think our OAuth2 related work, would be something that's interesting for them as well > > You start putting all of this together and there is a great set of > functionality that really compliments each other well. After we discuss > for a while, I'd like to find owners for the various items to help make > progress on these. Abstractj is awesome, but not sure he can do it all ;-) > yes, great work by Bruno w/ getting actively started on this > > -Jay > > PS: I'll post an email to the keycloak-dev list as well pointing to this > thread on our list. > > _______________________________________________ > 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/20140119/11c02d38/attachment.html From matzew at apache.org Mon Jan 20 02:51:07 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 20 Jan 2014 08:51:07 +0100 Subject: [aerogear-dev] AeroGear January sync release postponed In-Reply-To: <6CC5A734-4EE1-4BC9-93B4-37633836B217@redhat.com> References: <6CC5A734-4EE1-4BC9-93B4-37633836B217@redhat.com> Message-ID: On Fri, Jan 17, 2014 at 8:53 PM, Jay Balunas wrote: > Hi All, > > We've been making a lot of progress on sync, but as many of you likely > already know it is not ready for a full focused release. Much like > encryption, sync is a significant feature and is still in active R&D and > likely needs multiple iterations given its complexity. Its much better to > let this mature organically that force it out the door before its out of > diapers :-) > yeah, makes sense; Let's not rush on a specific release date, while R&D is actively going on. > > So with that said, I propose postponing the planned January umbrella > release. +1 on postponing to a later point. If ready by April, should be fine as well (my opinion). Bruno had a good point, that the postponed release should not stop us from releasing (unstable) snapshots for testing reasons. I like that: Release often, release early. > I think we should revisit our roadmaps and plans during this time, before > trying to set new release dates. While we do this we should make sure to > add in time for updates to docs, examples, getting started items, site, > cookbooks, etc... > good point as well, it needs to have a 'good' user experience and should be easy to get started with -Matthias > > Thoughts? > > Jay > _______________________________________________ > 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/20140120/715c63ef/attachment.html From matzew at apache.org Mon Jan 20 03:51:37 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 20 Jan 2014 09:51:37 +0100 Subject: [aerogear-dev] JS Future Roadmap In-Reply-To: References: Message-ID: On Sat, Jan 18, 2014 at 7:31 PM, Lucas Holmquist wrote: > I was having some thoughts on the future of AeroGear.js that i needed to > share. > > Experimental > Branch > > I think i want to create a branch that is very experimental, that targets > new and upcoming API's, like Object.Observe, and Promises, etc? > > I feel this is the only way to drive innovation > > I was thinking this is sort of our "Canary" branch, and when things start > to become less pollyfilly, then we can start to move these features in. > > I still however want the code in this branch to be complete, not just > random crap > +1 - also liking the name :-) > > 2.0 > > I would like to see that in 2.0 we start to remove our jQuery requirement, > and focus more on Modern Browsers and have our 1.X branch be our less than > modern browser( IE9 ) supported branch. much like how jQuery has a 1.X and > 2.X branch, obviously the difference between our branches won't be as > extreme. > > The major thing we use jQuery for atm is jQuery.ajax and Promises. this is > nice for cross broswer compatibility and for transpoting other things other > than json, which brings me to my next point > > I would also like in 2.0 to make our library( pipeline ) only speak json. > I think this will make it really simple to have our own AeroGear.Ajax() > method and be able to keep it small in size > +1; like the idea; for our iOS 2.x bits I'd imagine we do similar: iOS7/8 only and using AFN 2.x > 1.X > Branch > > Once we hit all our 1.X milestones( sync, offline ) then what is the > current master branch would become a 1.X branch, and we recieve bug fixes, > but no new features. If something in the future could be back ported, then > maybe, but it wouldn't be a priority > > This branch would still have a jQuery requirement and would be for legacy > stuff( IE9 ) > makes perfectly sense! Great ideas! -Matthias > > _______________________________________________ > 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/20140120/bb43f77e/attachment-0001.html From corinnekrych at gmail.com Mon Jan 20 04:49:52 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 20 Jan 2014 10:49:52 +0100 Subject: [aerogear-dev] JS Future Roadmap In-Reply-To: References: Message-ID: On 20 Jan 2014, at 09:51, Matthias Wessendorf wrote: > > > > On Sat, Jan 18, 2014 at 7:31 PM, Lucas Holmquist wrote: > I was having some thoughts on the future of AeroGear.js that i needed to share. > > Experimental Branch early adoptor branch or really experiemental ? > > I think i want to create a branch that is very experimental, that targets new and upcoming API's, like Object.Observe, and Promises, etc? > > I feel this is the only way to drive innovation > > I was thinking this is sort of our "Canary" branch, and when things start to become less pollyfilly, then we can start to move these features in. > > I still however want the code in this branch to be complete, not just random crap > > > +1 - also liking the name :-) got the history for the name hew: http://readwrite.com/2010/08/02/google_releases_canary_build_of_chrome_for_the_ear#awesm=~ottCjppZ0Ra6HL "The name of the build refers to the old practice of miners to bring a canary into a coal mine. If poisonous gasses were present, the canary would die before it would kill the miners, acting as an alarm system." > > > 2.0 > > I would like to see that in 2.0 we start to remove our jQuery requirement, and focus more on Modern Browsers and have our 1.X branch be our less than modern browser( IE9 ) supported branch. much like how jQuery has a 1.X and 2.X branch, obviously the difference between our branches won't be as extreme. > > The major thing we use jQuery for atm is jQuery.ajax and Promises. this is nice for cross broswer compatibility and for transpoting other things other than json, which brings me to my next point > > I would also like in 2.0 to make our library( pipeline ) only speak json. I think this will make it really simple to have our own AeroGear.Ajax() method and be able to keep it small in size > > > > +1; like the idea; for our iOS 2.x bits I'd imagine we do similar: iOS7/8 only and using AFN 2.x > > > 1.X Branch > > Once we hit all our 1.X milestones( sync, offline ) then what is the current master branch would become a 1.X branch, and we recieve bug fixes, but no new features. If something in the future could be back ported, then maybe, but it wouldn't be a priority > > This branch would still have a jQuery requirement and would be for legacy stuff( IE9 ) > > > makes perfectly sense! > > Great ideas! > > -Matthias > > > > _______________________________________________ > 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 From matzew at apache.org Mon Jan 20 04:56:45 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 20 Jan 2014 10:56:45 +0100 Subject: [aerogear-dev] JS Future Roadmap In-Reply-To: References: Message-ID: On Mon, Jan 20, 2014 at 10:49 AM, Corinne Krych wrote: > > On 20 Jan 2014, at 09:51, Matthias Wessendorf wrote: > > > > > > > > > On Sat, Jan 18, 2014 at 7:31 PM, Lucas Holmquist > wrote: > > I was having some thoughts on the future of AeroGear.js that i needed to > share. > > > > Experimental Branch > > early adoptor branch or really experiemental ? > > > > > I think i want to create a branch that is very experimental, that > targets new and upcoming API's, like Object.Observe, and Promises, etc? > > > > I feel this is the only way to drive innovation > > > > I was thinking this is sort of our "Canary" branch, and when things > start to become less pollyfilly, then we can start to move these features > in. > > > > I still however want the code in this branch to be complete, not just > random crap > > > > > > +1 - also liking the name :-) > > got the history for the name hew: > > http://readwrite.com/2010/08/02/google_releases_canary_build_of_chrome_for_the_ear#awesm=~ottCjppZ0Ra6HL > > "The name of the build refers to the old practice of miners to bring a > canary into a coal mine. If poisonous gasses were present, the canary would > die before it would kill the miners, acting as an alarm system." > awesome :-) > > > > > > > 2.0 > > > > I would like to see that in 2.0 we start to remove our jQuery > requirement, and focus more on Modern Browsers and have our 1.X branch be > our less than modern browser( IE9 ) supported branch. much like how jQuery > has a 1.X and 2.X branch, obviously the difference between our branches > won't be as extreme. > > > > The major thing we use jQuery for atm is jQuery.ajax and Promises. this > is nice for cross broswer compatibility and for transpoting other things > other than json, which brings me to my next point > > > > I would also like in 2.0 to make our library( pipeline ) only speak > json. I think this will make it really simple to have our own > AeroGear.Ajax() method and be able to keep it small in size > > > > > > > > +1; like the idea; for our iOS 2.x bits I'd imagine we do similar: > iOS7/8 only and using AFN 2.x > > > > > > 1.X Branch > > > > Once we hit all our 1.X milestones( sync, offline ) then what is the > current master branch would become a 1.X branch, and we recieve bug fixes, > but no new features. If something in the future could be back ported, then > maybe, but it wouldn't be a priority > > > > This branch would still have a jQuery requirement and would be for > legacy stuff( IE9 ) > > > > > > makes perfectly sense! > > > > Great ideas! > > > > -Matthias > > > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140120/79f674d7/attachment.html From edewit at redhat.com Mon Jan 20 05:37:28 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 20 Jan 2014 11:37:28 +0100 Subject: [aerogear-dev] Fwd: Website restructure References: Message-ID: <2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com> Hi, What I get from this thread is that we like the colour section idea, but we don?t want to re structure the entire site. So what we need to discuss is how are we going to use these sections if we don?t restructure. What I like about them is that it emphasises that our API?s are similar for all platforms and that we only have one document explaining for instance what pipes are. But the menu, doesn?t fit into this new colour scheme, so we need some decisions about how we are going to move forward. Based on the work Corinne did with the introduction of sass I?ve had a go at implementing a bit what Hylke proposed, have a look at my sass branch https://github.com/edewit/aerogear.org/tree/saas and the page I?ve updated http://localhost:4000/docs/guides/aerogear-android/AerogearAndroidPipes101/ to be in section layout. Don?t look at the header and footer as I haven?t changed those. There are a couple of things that I don?t like about the current implementation, to enable the code blocks I?ve added some html into the asciidoc and some jquery magic in the layout. Maybe we could make this better by chaining the rendering/backend or by introducing some sort of plugin into asciidoc? Other then that, I?m sure Hylke sees a lot of things that are still off, but it?s a start. What do you think? Cheers, Erik Jan p.s example picture https://www.dropbox.com/s/qtc4g0xwnyi0p41/Example.tiff -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140120/b38d5bf3/attachment.html From matzew at apache.org Mon Jan 20 05:53:56 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 20 Jan 2014 11:53:56 +0100 Subject: [aerogear-dev] Fwd: Website restructure In-Reply-To: <2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com> References: <2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com> Message-ID: On Mon, Jan 20, 2014 at 11:37 AM, Erik Jan de Wit wrote: > Hi, > > What I get from this thread is that we like the colour section idea, but > we don?t want to re structure the entire site. So what we need to discuss > is how are we going to use these sections if we don?t restructure. What I > like about them is that it emphasises that our API?s are similar for all > platforms and that we only have one document explaining for instance what > pipes are. But the menu, doesn?t fit into this new colour scheme, so we > need some decisions about how we are going to move forward. > > Based on the work Corinne did with the introduction of sass I?ve had a go > at implementing a bit what Hylke proposed, have a look at my sass branch > https://github.com/edewit/aerogear.org/tree/saas and the page I?ve > updated > http://localhost:4000/docs/guides/aerogear-android/AerogearAndroidPipes101/ to > be in section layout. Don?t look at the header and footer as I haven?t > changed those. > > There are a couple of things that I don?t like about the current > implementation, to enable the code blocks I?ve added some html into the > asciidoc and some jquery magic in the layout. Maybe we could make this > better by chaining the rendering/backend or by introducing some sort of > plugin into asciidoc? Other then that, I?m sure Hylke sees a lot of things > that are still off, but it?s a start. > > What do you think? > > Cheers, > Erik Jan > > p.s > example picture https://www.dropbox.com/s/qtc4g0xwnyi0p41/Example.tiff > that example screenshot looks very nice > > > _______________________________________________ > 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/20140120/0dc3267f/attachment-0001.html From kpiwko at redhat.com Mon Jan 20 06:02:17 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Mon, 20 Jan 2014 12:02:17 +0100 Subject: [aerogear-dev] [UnifiedPush] Refactorings In-Reply-To: References: Message-ID: <20140120120217.78884e88@kapy-ntb-x220> Matthias, this looks like a great idea. It would be great if refactoring could be done in such way that our integration tests can on api-only artifacts, that are stable. That would help us to write tests in cleaner way (now we require ups to be cloned to specific location and use maven-resources-plugin), also it would avoid situation where we test internals which are often subject to change. Current list https://gist.github.com/kpiwko/8518205. We should work in order to let tests use as less "impl" stuff as possible. Something like: * message-api (cache, sender) * model-api (now, it is confusing to have Variant in .api package and AbstractVariant in .model package, for instance) * core-api ?(dunno) * service-api (service, sender) Some of the APIs that are supposed to be implemented by others (for instance SenderService is provided by SP)could also make a nice SPI module. Karel On Fri, 17 Jan 2014 17:31:09 +0100 Matthias Wessendorf wrote: > Hi, > > over the next weeks, after we get the 0.10.0 out, there will be some > refactorings on different parts of the server: > > - make the 'core' the sending logic a little more isolated > - look into a better 'abstraction' for the data storage > > I think this might lead to new (sub)projects and JAR files. I was > wondering, do folks like a > > - pom.xml > - sender-component/ > - data/ > - api > - some impl projects > - pushee/ (the server as is today, but including above 'components') > - database-scripts (the CLI files for WildFly/AS) > > Greetings, Matthias > From kpiwko at redhat.com Mon Jan 20 06:17:57 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Mon, 20 Jan 2014 12:17:57 +0100 Subject: [aerogear-dev] AeroGear January sync release postponed In-Reply-To: References: <6CC5A734-4EE1-4BC9-93B4-37633836B217@redhat.com> Message-ID: <20140120121757.574a1184@kapy-ntb-x220> > +1 on postponing to a later point. If ready by April, should be fine as > well (my opinion). Bruno had a good point, that the postponed release > should not stop us from releasing (unstable) snapshots for testing reasons. > I like that: Release often, release early. What is actually an (unstable) snapshot? Could you shed more light on that? Namely, is the "snapshot" a set of micro/minor releases of Aerogear projects? Or do you plan to release every Aerogear project as -SNAPSHOT? Or introducing -milestone/.Mx/alpha/beta/cr/timestamp/any-qualifier-you-like into version strings? I don't think 2/ option is a good idea, especially if SNAPSHOTs are released early & often. That would be a maintenance/testing nightmare, if various SNAPSHOTs of the same project cannot be distinguished from each other and used within other projects. Karel From matzew at apache.org Mon Jan 20 06:27:22 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 20 Jan 2014 12:27:22 +0100 Subject: [aerogear-dev] AeroGear January sync release postponed In-Reply-To: <20140120121757.574a1184@kapy-ntb-x220> References: <6CC5A734-4EE1-4BC9-93B4-37633836B217@redhat.com> <20140120121757.574a1184@kapy-ntb-x220> Message-ID: On Mon, Jan 20, 2014 at 12:17 PM, Karel Piwko wrote: > > +1 on postponing to a later point. If ready by April, should be fine as > > well (my opinion). Bruno had a good point, that the postponed release > > should not stop us from releasing (unstable) snapshots for testing > reasons. > > I like that: Release often, release early. > > What is actually an (unstable) snapshot? Could you shed more light on that? > I'd say a regular snapshot, from master branch, released to the snapshot repo > > Namely, is the "snapshot" a set of micro/minor releases of Aerogear > projects? > Or do you plan to release every Aerogear project as -SNAPSHOT? Or > introducing > -milestone/.Mx/alpha/beta/cr/timestamp/any-qualifier-you-like into version > strings? > > I don't think 2/ option is a good idea, especially if SNAPSHOTs are > released > early & often. That would be a maintenance/testing nightmare, if various > SNAPSHOTs of the same project cannot be distinguished from each other and > used > within other projects. > > Karel > _______________________________________________ > 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/20140120/4dc02860/attachment.html From kpiwko at redhat.com Mon Jan 20 06:35:59 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Mon, 20 Jan 2014 12:35:59 +0100 Subject: [aerogear-dev] Fwd: Website restructure In-Reply-To: <2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com> References: <2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com> Message-ID: <20140120123559.3a3aec13@kapy-ntb-x220> Looks good! Apart for platform related code (JavaScript, Objective-C, Java), are there any plans to support platform related text? E.g. pipes on Aerogear can be used within FragmentActivity, which is valid for Android only; Javadoc is not related to iOS, etc. That's basically a merge of our guides into a one per feature with information covering all the platforms. Which brings me to and idea of global platform switch. User/reader can switch platform once and all code snippets and platform related blocks are automatically selected. Can also be session based and affect all pages user visits. Karel On Mon, 20 Jan 2014 11:37:28 +0100 Erik Jan de Wit wrote: > Hi, > > What I get from this thread is that we like the colour section idea, but we > don?t want to re structure the entire site. So what we need to discuss is how > are we going to use these sections if we don?t restructure. What I like about > them is that it emphasises that our API?s are similar for all platforms and > that we only have one document explaining for instance what pipes are. But > the menu, doesn?t fit into this new colour scheme, so we need some decisions > about how we are going to move forward. > > Based on the work Corinne did with the introduction of sass I?ve had a go at > implementing a bit what Hylke proposed, have a look at my sass branch > https://github.com/edewit/aerogear.org/tree/saas and the page I?ve updated > http://localhost:4000/docs/guides/aerogear-android/AerogearAndroidPipes101/ > to be in section layout. Don?t look at the header and footer as I haven?t > changed those. > > There are a couple of things that I don?t like about the current > implementation, to enable the code blocks I?ve added some html into the > asciidoc and some jquery magic in the layout. Maybe we could make this better > by chaining the rendering/backend or by introducing some sort of plugin into > asciidoc? Other then that, I?m sure Hylke sees a lot of things that are still > off, but it?s a start. > > What do you think? > > Cheers, > Erik Jan > > p.s > example picture https://www.dropbox.com/s/qtc4g0xwnyi0p41/Example.tiff > From kpiwko at redhat.com Mon Jan 20 06:39:52 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Mon, 20 Jan 2014 12:39:52 +0100 Subject: [aerogear-dev] AeroGear January sync release postponed In-Reply-To: References: <6CC5A734-4EE1-4BC9-93B4-37633836B217@redhat.com> <20140120121757.574a1184@kapy-ntb-x220> Message-ID: <20140120123952.3b2df63f@kapy-ntb-x220> On Mon, 20 Jan 2014 12:27:22 +0100 Matthias Wessendorf wrote: > On Mon, Jan 20, 2014 at 12:17 PM, Karel Piwko wrote: > > > > +1 on postponing to a later point. If ready by April, should be fine as > > > well (my opinion). Bruno had a good point, that the postponed release > > > should not stop us from releasing (unstable) snapshots for testing > > reasons. > > > I like that: Release often, release early. > > > > What is actually an (unstable) snapshot? Could you shed more light on that? > > > > I'd say a regular snapshot, from master branch, released to the snapshot > repo That's good until another project(s) will rely on it. You update snaphot and other projects will get broken without any option to avoid that. It would be much better to make snapshots stable in time, as I described in previous email. > > > > > > Namely, is the "snapshot" a set of micro/minor releases of Aerogear > > projects? > > Or do you plan to release every Aerogear project as -SNAPSHOT? Or > > introducing > > -milestone/.Mx/alpha/beta/cr/timestamp/any-qualifier-you-like into version > > strings? > > > > I don't think 2/ option is a good idea, especially if SNAPSHOTs are > > released > > early & often. That would be a maintenance/testing nightmare, if various > > SNAPSHOTs of the same project cannot be distinguished from each other and > > used > > within other projects. > > > > Karel > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > From scm.blanc at gmail.com Mon Jan 20 06:44:21 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Mon, 20 Jan 2014 12:44:21 +0100 Subject: [aerogear-dev] Fwd: Website restructure In-Reply-To: <20140120123559.3a3aec13@kapy-ntb-x220> References: <2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com> <20140120123559.3a3aec13@kapy-ntb-x220> Message-ID: On Mon, Jan 20, 2014 at 12:35 PM, Karel Piwko wrote: > Looks good! > +1 I like the dracula theme ! > > Apart for platform related code (JavaScript, Objective-C, Java), are there > any > plans to support platform related text? > > E.g. pipes on Aerogear can be used within FragmentActivity, which is valid > for > Android only; Javadoc is not related to iOS, etc. That's basically a merge > of > our guides into a one per feature with information covering all the > platforms. > > Which brings me to and idea of global platform switch. User/reader can > switch > platform once and all code snippets and platform related blocks are > automatically selected. Can also be session based and affect all pages user > visits. > +1 , that would be really cool. I came accross such a layout on https://www.paymill.com/fr-fr/documentation/reference/api-reference/#document-authentication , check on the right, you have a tab where you can switch between different languages, the snippet is updated. There are also some online apps that does the job for you like apiary.ioand https://www.mashape.com > > Karel > > On Mon, 20 Jan 2014 11:37:28 +0100 > Erik Jan de Wit wrote: > > > Hi, > > > > What I get from this thread is that we like the colour section idea, but > we > > don?t want to re structure the entire site. So what we need to discuss > is how > > are we going to use these sections if we don?t restructure. What I like > about > > them is that it emphasises that our API?s are similar for all platforms > and > > that we only have one document explaining for instance what pipes are. > But > > the menu, doesn?t fit into this new colour scheme, so we need some > decisions > > about how we are going to move forward. > > > > Based on the work Corinne did with the introduction of sass I?ve had a > go at > > implementing a bit what Hylke proposed, have a look at my sass branch > > https://github.com/edewit/aerogear.org/tree/saas and the page I?ve > updated > > > http://localhost:4000/docs/guides/aerogear-android/AerogearAndroidPipes101/ > > to be in section layout. Don?t look at the header and footer as I haven?t > > changed those. > > > > There are a couple of things that I don?t like about the current > > implementation, to enable the code blocks I?ve added some html into the > > asciidoc and some jquery magic in the layout. Maybe we could make this > better > > by chaining the rendering/backend or by introducing some sort of plugin > into > > asciidoc? Other then that, I?m sure Hylke sees a lot of things that are > still > > off, but it?s a start. > > > > What do you think? > > > > Cheers, > > Erik Jan > > > > p.s > > example picture https://www.dropbox.com/s/qtc4g0xwnyi0p41/Example.tiff > > > > _______________________________________________ > 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/20140120/a424c77d/attachment-0001.html From matzew at apache.org Mon Jan 20 07:17:00 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 20 Jan 2014 13:17:00 +0100 Subject: [aerogear-dev] AeroGear January sync release postponed In-Reply-To: <20140120123952.3b2df63f@kapy-ntb-x220> References: <6CC5A734-4EE1-4BC9-93B4-37633836B217@redhat.com> <20140120121757.574a1184@kapy-ntb-x220> <20140120123952.3b2df63f@kapy-ntb-x220> Message-ID: On Monday, January 20, 2014, Karel Piwko wrote: > On Mon, 20 Jan 2014 12:27:22 +0100 > Matthias Wessendorf > wrote: > > > On Mon, Jan 20, 2014 at 12:17 PM, Karel Piwko > > wrote: > > > > > > +1 on postponing to a later point. If ready by April, should be fine > as > > > > well (my opinion). Bruno had a good point, that the postponed release > > > > should not stop us from releasing (unstable) snapshots for testing > > > reasons. > > > > I like that: Release often, release early. > > > > > > What is actually an (unstable) snapshot? Could you shed more light on > that? > > > > > > > I'd say a regular snapshot, from master branch, released to the snapshot > > repo > > That's good until another project(s) will rely on it. You update snaphot > and > other projects will get broken without any option to avoid that. It would > be > much better to make snapshots stable in time, as I described in previous > email. Well, this is all early and understood, not why thats a problem, when DEVELOPING something... > > > > > > > > > > > Namely, is the "snapshot" a set of micro/minor releases of Aerogear > > > projects? > > > Or do you plan to release every Aerogear project as -SNAPSHOT? Or > > > introducing > > > -milestone/.Mx/alpha/beta/cr/timestamp/any-qualifier-you-like into > version > > > strings? > > > > > > I don't think 2/ option is a good idea, especially if SNAPSHOTs are > > > released > > > early & often. That would be a maintenance/testing nightmare, if > various > > > SNAPSHOTs of the same project cannot be distinguished from each other > and > > > used > > > within other projects. > > > > > > Karel > > > _______________________________________________ > > > 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 > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140120/1dff7f7c/attachment.html From kpiwko at redhat.com Mon Jan 20 07:29:23 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Mon, 20 Jan 2014 13:29:23 +0100 Subject: [aerogear-dev] AeroGear January sync release postponed In-Reply-To: References: <6CC5A734-4EE1-4BC9-93B4-37633836B217@redhat.com> <20140120121757.574a1184@kapy-ntb-x220> <20140120123952.3b2df63f@kapy-ntb-x220> Message-ID: <20140120132923.51156c61@kapy-ntb-x220> On Mon, 20 Jan 2014 13:17:00 +0100 Matthias Wessendorf wrote: > On Monday, January 20, 2014, Karel Piwko wrote: > > > On Mon, 20 Jan 2014 12:27:22 +0100 > > Matthias Wessendorf > wrote: > > > > > On Mon, Jan 20, 2014 at 12:17 PM, Karel Piwko > > > > > > wrote: > > > > > > > > +1 on postponing to a later point. If ready by April, should be fine > > as > > > > > well (my opinion). Bruno had a good point, that the postponed release > > > > > should not stop us from releasing (unstable) snapshots for testing > > > > reasons. > > > > > I like that: Release often, release early. > > > > > > > > What is actually an (unstable) snapshot? Could you shed more light on > > that? > > > > > > > > > > I'd say a regular snapshot, from master branch, released to the snapshot > > > repo > > > > That's good until another project(s) will rely on it. You update snaphot > > and > > other projects will get broken without any option to avoid that. It would > > be > > much better to make snapshots stable in time, as I described in previous > > email. > > > Well, this is all early and understood, not why thats a problem, when > DEVELOPING something... > That's right. But when testing something it is a problem. We don't have a bandwidth to update tests every time something get's broken due to new SNAPSHOT being released to repository. OTOH, updating tests after all projects are released as Final is too late. I'm looking for some model in between to let us keep pace with devs. > > > > > > > > > > > > > > > > > > > Namely, is the "snapshot" a set of micro/minor releases of Aerogear > > > > projects? > > > > Or do you plan to release every Aerogear project as -SNAPSHOT? Or > > > > introducing > > > > -milestone/.Mx/alpha/beta/cr/timestamp/any-qualifier-you-like into > > version > > > > strings? > > > > > > > > I don't think 2/ option is a good idea, especially if SNAPSHOTs are > > > > released > > > > early & often. That would be a maintenance/testing nightmare, if > > various > > > > SNAPSHOTs of the same project cannot be distinguished from each other > > and > > > > used > > > > within other projects. > > > > > > > > Karel > > > > _______________________________________________ > > > > 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 Mon Jan 20 07:41:23 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 20 Jan 2014 13:41:23 +0100 Subject: [aerogear-dev] AeroGear January sync release postponed In-Reply-To: <20140120132923.51156c61@kapy-ntb-x220> References: <6CC5A734-4EE1-4BC9-93B4-37633836B217@redhat.com> <20140120121757.574a1184@kapy-ntb-x220> <20140120123952.3b2df63f@kapy-ntb-x220> <20140120132923.51156c61@kapy-ntb-x220> Message-ID: On Monday, January 20, 2014, Karel Piwko wrote: > On Mon, 20 Jan 2014 13:17:00 +0100 > Matthias Wessendorf > wrote: > > > On Monday, January 20, 2014, Karel Piwko > > wrote: > > > > > On Mon, 20 Jan 2014 12:27:22 +0100 > > > Matthias Wessendorf > > wrote: > > > > > > > On Mon, Jan 20, 2014 at 12:17 PM, Karel Piwko > > > > > > > > wrote: > > > > > > > > > > +1 on postponing to a later point. If ready by April, should be > fine > > > as > > > > > > well (my opinion). Bruno had a good point, that the postponed > release > > > > > > should not stop us from releasing (unstable) snapshots for > testing > > > > > reasons. > > > > > > I like that: Release often, release early. > > > > > > > > > > What is actually an (unstable) snapshot? Could you shed more light > on > > > that? > > > > > > > > > > > > > I'd say a regular snapshot, from master branch, released to the > snapshot > > > > repo > > > > > > That's good until another project(s) will rely on it. You update > snaphot > > > and > > > other projects will get broken without any option to avoid that. It > would > > > be > > > much better to make snapshots stable in time, as I described in > previous > > > email. > > > > > > Well, this is all early and understood, not why thats a problem, when > > DEVELOPING something... > > > > That's right. But when testing something it is a problem. We don't have a > bandwidth to update tests every time something get's broken due to new > SNAPSHOT being released to repository. OTOH, updating tests after all > projects > are released as Final is too late. I'm looking for some model in between > to let > us keep pace with devs. Well, when something is under heavy development, like ALL the sync things, it makes sense to do snapshots; when things(e.g protocol, server etc) changes, sure we will update our unit tests and adjust the clients; thats basically the development of sync; You talking about integration tests or what? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Namely, is the "snapshot" a set of micro/minor releases of Aerogear > > > > > projects? > > > > > Or do you plan to release every Aerogear project as -SNAPSHOT? Or > > > > > introducing > > > > > -milestone/.Mx/alpha/beta/cr/timestamp/any-qualifier-you-like into > > > version > > > > > strings? > > > > > > > > > > I don't think 2/ option is a good idea, especially if SNAPSHOTs are > > > > > released > > > > > early & often. That would be a maintenance/testing nightmare, if > > > various > > > > > SNAPSHOTs of the same project cannot be distinguished from each > other > > > and > > > > > used > > > > > within other projects. > > > > > > > > > > Karel > > > > > _______________________________________________ > > > > > 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 > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140120/dd8989f7/attachment.html From kpiwko at redhat.com Mon Jan 20 08:06:32 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Mon, 20 Jan 2014 14:06:32 +0100 Subject: [aerogear-dev] AeroGear January sync release postponed In-Reply-To: References: <6CC5A734-4EE1-4BC9-93B4-37633836B217@redhat.com> <20140120121757.574a1184@kapy-ntb-x220> <20140120123952.3b2df63f@kapy-ntb-x220> <20140120132923.51156c61@kapy-ntb-x220> Message-ID: <20140120140632.1e241805@kapy-ntb-x220> On Mon, 20 Jan 2014 13:41:23 +0100 Matthias Wessendorf wrote: > On Monday, January 20, 2014, Karel Piwko wrote: > > > On Mon, 20 Jan 2014 13:17:00 +0100 > > Matthias Wessendorf > wrote: > > > > > On Monday, January 20, 2014, Karel Piwko > > > wrote: > > > > > > > On Mon, 20 Jan 2014 12:27:22 +0100 > > > > Matthias Wessendorf > > > wrote: > > > > > > > > > On Mon, Jan 20, 2014 at 12:17 PM, Karel Piwko > > > > > > > > > > wrote: > > > > > > > > > > > > +1 on postponing to a later point. If ready by April, should be > > fine > > > > as > > > > > > > well (my opinion). Bruno had a good point, that the postponed > > release > > > > > > > should not stop us from releasing (unstable) snapshots for > > testing > > > > > > reasons. > > > > > > > I like that: Release often, release early. > > > > > > > > > > > > What is actually an (unstable) snapshot? Could you shed more light > > on > > > > that? > > > > > > > > > > > > > > > > I'd say a regular snapshot, from master branch, released to the > > snapshot > > > > > repo > > > > > > > > That's good until another project(s) will rely on it. You update > > snaphot > > > > and > > > > other projects will get broken without any option to avoid that. It > > would > > > > be > > > > much better to make snapshots stable in time, as I described in > > previous > > > > email. > > > > > > > > > Well, this is all early and understood, not why thats a problem, when > > > DEVELOPING something... > > > > > > > That's right. But when testing something it is a problem. We don't have a > > bandwidth to update tests every time something get's broken due to new > > SNAPSHOT being released to repository. OTOH, updating tests after all > > projects > > are released as Final is too late. I'm looking for some model in between > > to let > > us keep pace with devs. > > > Well, when something is under heavy development, like ALL the sync things, > it makes sense to do snapshots; when things(e.g protocol, server etc) > changes, sure we will update our unit tests and adjust the clients; thats > basically the development of sync; > > You talking about integration tests or what? Exactly. Integration tests, especially that ones that test more Aerogear projects combined together. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Namely, is the "snapshot" a set of micro/minor releases of Aerogear > > > > > > projects? > > > > > > Or do you plan to release every Aerogear project as -SNAPSHOT? Or > > > > > > introducing > > > > > > -milestone/.Mx/alpha/beta/cr/timestamp/any-qualifier-you-like into > > > > version > > > > > > strings? > > > > > > > > > > > > I don't think 2/ option is a good idea, especially if SNAPSHOTs are > > > > > > released > > > > > > early & often. That would be a maintenance/testing nightmare, if > > > > various > > > > > > SNAPSHOTs of the same project cannot be distinguished from each > > other > > > > and > > > > > > used > > > > > > within other projects. > > > > > > > > > > > > Karel > > > > > > _______________________________________________ > > > > > > 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 matzew at apache.org Mon Jan 20 08:09:12 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 20 Jan 2014 14:09:12 +0100 Subject: [aerogear-dev] AeroGear January sync release postponed In-Reply-To: <20140120140632.1e241805@kapy-ntb-x220> References: <6CC5A734-4EE1-4BC9-93B4-37633836B217@redhat.com> <20140120121757.574a1184@kapy-ntb-x220> <20140120123952.3b2df63f@kapy-ntb-x220> <20140120132923.51156c61@kapy-ntb-x220> <20140120140632.1e241805@kapy-ntb-x220> Message-ID: On Mon, Jan 20, 2014 at 2:06 PM, Karel Piwko wrote: > On Mon, 20 Jan 2014 13:41:23 +0100 > Matthias Wessendorf wrote: > > > On Monday, January 20, 2014, Karel Piwko wrote: > > > > > On Mon, 20 Jan 2014 13:17:00 +0100 > > > Matthias Wessendorf > wrote: > > > > > > > On Monday, January 20, 2014, Karel Piwko > > > > wrote: > > > > > > > > > On Mon, 20 Jan 2014 12:27:22 +0100 > > > > > Matthias Wessendorf > > > > > wrote: > > > > > > > > > > > On Mon, Jan 20, 2014 at 12:17 PM, Karel Piwko > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > +1 on postponing to a later point. If ready by April, should > be > > > fine > > > > > as > > > > > > > > well (my opinion). Bruno had a good point, that the postponed > > > release > > > > > > > > should not stop us from releasing (unstable) snapshots for > > > testing > > > > > > > reasons. > > > > > > > > I like that: Release often, release early. > > > > > > > > > > > > > > What is actually an (unstable) snapshot? Could you shed more > light > > > on > > > > > that? > > > > > > > > > > > > > > > > > > > I'd say a regular snapshot, from master branch, released to the > > > snapshot > > > > > > repo > > > > > > > > > > That's good until another project(s) will rely on it. You update > > > snaphot > > > > > and > > > > > other projects will get broken without any option to avoid that. It > > > would > > > > > be > > > > > much better to make snapshots stable in time, as I described in > > > previous > > > > > email. > > > > > > > > > > > > Well, this is all early and understood, not why thats a problem, when > > > > DEVELOPING something... > > > > > > > > > > That's right. But when testing something it is a problem. We don't > have a > > > bandwidth to update tests every time something get's broken due to new > > > SNAPSHOT being released to repository. OTOH, updating tests after all > > > projects > > > are released as Final is too late. I'm looking for some model in > between > > > to let > > > us keep pace with devs. > > > > > > Well, when something is under heavy development, like ALL the sync > things, > > it makes sense to do snapshots; when things(e.g protocol, server etc) > > changes, sure we will update our unit tests and adjust the clients; thats > > basically the development of sync; > > > > You talking about integration tests or what? > > Exactly. Integration tests, especially that ones that test more Aerogear > projects combined together. > well, to be honest, as long as we don't really know what the server is, how the client APIs look like (e.g 0.0.1-SNAPSHOT, 0.0.2-SNAPSHOT) it's pointless to actually do that. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Namely, is the "snapshot" a set of micro/minor releases of > Aerogear > > > > > > > projects? > > > > > > > Or do you plan to release every Aerogear project as -SNAPSHOT? > Or > > > > > > > introducing > > > > > > > -milestone/.Mx/alpha/beta/cr/timestamp/any-qualifier-you-like > into > > > > > version > > > > > > > strings? > > > > > > > > > > > > > > I don't think 2/ option is a good idea, especially if > SNAPSHOTs are > > > > > > > released > > > > > > > early & often. That would be a maintenance/testing nightmare, > if > > > > > various > > > > > > > SNAPSHOTs of the same project cannot be distinguished from each > > > other > > > > > and > > > > > > > used > > > > > > > within other projects. > > > > > > > > > > > > > > Karel > > > > > > > _______________________________________________ > > > > > > > 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 > -- 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/20140120/57e3aded/attachment.html From kpiwko at redhat.com Mon Jan 20 08:54:27 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Mon, 20 Jan 2014 14:54:27 +0100 Subject: [aerogear-dev] AeroGear January sync release postponed In-Reply-To: References: <6CC5A734-4EE1-4BC9-93B4-37633836B217@redhat.com> <20140120121757.574a1184@kapy-ntb-x220> <20140120123952.3b2df63f@kapy-ntb-x220> <20140120132923.51156c61@kapy-ntb-x220> <20140120140632.1e241805@kapy-ntb-x220> Message-ID: <20140120145427.7f07a68b@kapy-ntb-x220> > > well, to be honest, as long as we don't really know what the server is, how > the client APIs look like (e.g 0.0.1-SNAPSHOT, 0.0.2-SNAPSHOT) it's > pointless to actually do that. In such case, how do you want us to proceed with updating integration tests? How do you guys feel about releasing a few (1 or 2) SNAPSHOT sets marked as non-snapshots (beta) till you reach finals? If the dev is going to take 2+ months or so, I would hate to be stale in test dev and catch all later on. Yet, I don't want to rewrite tests back and forth more times then twice. From lholmqui at redhat.com Mon Jan 20 08:55:02 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 20 Jan 2014 08:55:02 -0500 Subject: [aerogear-dev] does aerogear supported by mobile firefox In-Reply-To: References: <1389064744777-5703.post@n5.nabble.com> Message-ID: <83AA33C9-AD9E-477A-96FE-9D59F14AC0C7@redhat.com> Hi, are you talking about FireFox OS or the firefox Mobile Browser on Android? On Jan 19, 2014, at 4:06 AM, Matthias Wessendorf wrote: > Hello Naveenraj, > > Besides the mentioned app, last week Erik Jan also did create an new app, for FirefoxOS: > > https://github.com/edewit/aerogear-aerodoc-firefoxos > > It is basically a port of our 'push show case'. > > I think these two different apps should give you a good starting point, how to use AeroGear APIs on a FirefoxOS device > > Greetings, > Matthias > > > On Sun, Jan 19, 2014 at 9:49 AM, Bruno Oliveira wrote: > Good morning my friend, not yet. But if you want to start with something, Daniel Passos wrote an application using AeroGear JS (https://github.com/danielpassos/call4paperz4FirefoxOS) > > > > -- > abstractj > > On January 18, 2014 at 5:22:42 PM, Naveenraj (mailnaveenraj at gmail.com) wrote: > > > I just wantbto know if mozilla Firefox mobile is supported or > > not. > > In the tbd of mobile browser I am not able to find Firefox mobile. > > . > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140120/04997330/attachment.html From qmx at qmx.me Mon Jan 20 09:01:44 2014 From: qmx at qmx.me (Douglas Campos) Date: Mon, 20 Jan 2014 12:01:44 -0200 Subject: [aerogear-dev] AeroGear January sync release postponed In-Reply-To: <20140120123952.3b2df63f@kapy-ntb-x220> References: <6CC5A734-4EE1-4BC9-93B4-37633836B217@redhat.com> <20140120121757.574a1184@kapy-ntb-x220> <20140120123952.3b2df63f@kapy-ntb-x220> Message-ID: <20140120140144.GE26872@rohan.local> On Mon, Jan 20, 2014 at 12:39:52PM +0100, Karel Piwko wrote: > On Mon, 20 Jan 2014 12:27:22 +0100 > Matthias Wessendorf wrote: > > > On Mon, Jan 20, 2014 at 12:17 PM, Karel Piwko wrote: > > > > > > +1 on postponing to a later point. If ready by April, should be fine as > > > > well (my opinion). Bruno had a good point, that the postponed release > > > > should not stop us from releasing (unstable) snapshots for testing > > > reasons. > > > > I like that: Release often, release early. > > > > > > What is actually an (unstable) snapshot? Could you shed more light on that? > > > > > > > I'd say a regular snapshot, from master branch, released to the snapshot > > repo > > That's good until another project(s) will rely on it. You update snaphot and > other projects will get broken without any option to avoid that. It would be > much better to make snapshots stable in time, as I described in previous email. Well, that's how snapshots work. We can't fix people not getting it, unfortunately :( -- qmx From supittma at redhat.com Mon Jan 20 09:03:18 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 20 Jan 2014 09:03:18 -0500 Subject: [aerogear-dev] iOS Factory Classes Message-ID: <52DD2CA6.30907@redhat.com> One of the things I brought up in the review of the iOS OAUTH2 PR was that the Authz factory class, AGAuthorizer, does not allow injection of custom Authorizors. Corrine mentioned that this wasn't done for any of the other classes (Pipeline, Authentication, etc). I know Android does this (via an add method and also allows you to supply a custom builder) and I am pretty sure JavaScript has an add method as well. Just wanted to bring up this place where the platforms diverged and get community input. Back to coffee, Summers From supittma at redhat.com Mon Jan 20 09:07:40 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 20 Jan 2014 09:07:40 -0500 Subject: [aerogear-dev] AeroGear January sync release postponed In-Reply-To: <20140120123952.3b2df63f@kapy-ntb-x220> References: <6CC5A734-4EE1-4BC9-93B4-37633836B217@redhat.com> <20140120121757.574a1184@kapy-ntb-x220> <20140120123952.3b2df63f@kapy-ntb-x220> Message-ID: <52DD2DAC.3080805@redhat.com> On 01/20/2014 06:39 AM, Karel Piwko wrote: > On Mon, 20 Jan 2014 12:27:22 +0100 > Matthias Wessendorf wrote: > >> On Mon, Jan 20, 2014 at 12:17 PM, Karel Piwko wrote: >> >>>> +1 on postponing to a later point. If ready by April, should be fine as >>>> well (my opinion). Bruno had a good point, that the postponed release >>>> should not stop us from releasing (unstable) snapshots for testing >>> reasons. >>>> I like that: Release often, release early. >>> What is actually an (unstable) snapshot? Could you shed more light on that? >>> >> I'd say a regular snapshot, from master branch, released to the snapshot >> repo > That's good until another project(s) will rely on it. You update snaphot and > other projects will get broken without any option to avoid that. It would be > much better to make snapshots stable in time, as I described in previous email. So from my POV I don't mind code SNAPSHOTS always breaking. One of the problems with having several machines and locations to work from is keeping the code up to date. Because the Android project is in flux based on upstream AND downstream projects (IE demos I'm writing to exercise the APIs) it is very very nice to have something I can look at and play with. I understand a side effect of this is I will have to rewrite code, but in my instance I'm usually rewriting code based on code changes I made. Maybe we can do the Google thing and we have to rewrite tests we break? (/me Waits for the flood of -1's) > >> >>> Namely, is the "snapshot" a set of micro/minor releases of Aerogear >>> projects? >>> Or do you plan to release every Aerogear project as -SNAPSHOT? Or >>> introducing >>> -milestone/.Mx/alpha/beta/cr/timestamp/any-qualifier-you-like into version >>> strings? >>> >>> I don't think 2/ option is a good idea, especially if SNAPSHOTs are >>> released >>> early & often. That would be a maintenance/testing nightmare, if various >>> SNAPSHOTs of the same project cannot be distinguished from each other and >>> used >>> within other projects. >>> >>> Karel >>> _______________________________________________ >>> 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 bruno at abstractj.org Mon Jan 20 10:00:37 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 20 Jan 2014 13:00:37 -0200 Subject: [aerogear-dev] AeroGear January sync release postponed In-Reply-To: <52DD2DAC.3080805@redhat.com> References: <6CC5A734-4EE1-4BC9-93B4-37633836B217@redhat.com> <20140120121757.574a1184@kapy-ntb-x220> <20140120123952.3b2df63f@kapy-ntb-x220> <52DD2DAC.3080805@redhat.com> Message-ID: Snapshots are unstable by definition, period. If necessary release anything for testing will be necessary, well this was supposed to be done after we reach a consensus at whatever feature. -- abstractj On January 20, 2014 at 12:07:44 PM, Summers Pittman (supittma at redhat.com) wrote: > > On 01/20/2014 06:39 AM, Karel Piwko wrote: > > On Mon, 20 Jan 2014 12:27:22 +0100 > > Matthias Wessendorf wrote: > > > >> On Mon, Jan 20, 2014 at 12:17 PM, Karel Piwko > wrote: > >> > >>>> +1 on postponing to a later point. If ready by April, should > be fine as > >>>> well (my opinion). Bruno had a good point, that the postponed > release > >>>> should not stop us from releasing (unstable) snapshots > for testing > >>> reasons. > >>>> I like that: Release often, release early. > >>> What is actually an (unstable) snapshot? Could you shed more > light on that? > >>> > >> I'd say a regular snapshot, from master branch, released to > the snapshot > >> repo > > That's good until another project(s) will rely on it. You update > snaphot and > > other projects will get broken without any option to avoid that. > It would be > > much better to make snapshots stable in time, as I described > in previous email. > So from my POV I don't mind code SNAPSHOTS always breaking. One > of the > problems with having several machines and locations to work > from is > keeping the code up to date. Because the Android project is in > flux > based on upstream AND downstream projects (IE demos I'm writing > to > exercise the APIs) it is very very nice to have something I can > look at > and play with. > > I understand a side effect of this is I will have to rewrite code, > but > in my instance I'm usually rewriting code based on code changes > I made. > > Maybe we can do the Google thing and we have to rewrite tests we > break? > (/me Waits for the flood of -1's) > > > >> > >>> Namely, is the "snapshot" a set of micro/minor releases of > Aerogear > >>> projects? > >>> Or do you plan to release every Aerogear project as -SNAPSHOT? > Or > >>> introducing > >>> -milestone/.Mx/alpha/beta/cr/timestamp/any-qualifier-you-like > into version > >>> strings? > >>> > >>> I don't think 2/ option is a good idea, especially if SNAPSHOTs > are > >>> released > >>> early & often. That would be a maintenance/testing nightmare, > if various > >>> SNAPSHOTs of the same project cannot be distinguished from > each other and > >>> used > >>> within other projects. > >>> > >>> Karel > >>> _______________________________________________ > >>> 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 Mon Jan 20 10:40:29 2014 From: supittma at redhat.com (Summers Pittman) Date: Mon, 20 Jan 2014 10:40:29 -0500 Subject: [aerogear-dev] Encrypted Store Message-ID: <52DD436D.80809@redhat.com> Hi. On Android and iOS you CAN mix data keys in the datastore, but this will cause the readAll method to fail. On Android we are planning on fixing this (there is a JIRA somewhere) to make it so that we will do simple key checks. How does JavaScript do encrypted stores and how does it work when you begin mixing/matching keys. From lholmqui at redhat.com Mon Jan 20 11:29:07 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 20 Jan 2014 11:29:07 -0500 Subject: [aerogear-dev] cleaning old JS repo branches Message-ID: hello hello, Either later today or tomorrow, i'll be cleaning up the old branches of the Aerogear-js git repo, https://github.com/aerogear/aerogear-js/branches?merged=1 i doubt there is going to be any issues since it was me or Kris who created them -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140120/4e83bf4e/attachment.html From lholmqui at redhat.com Mon Jan 20 11:39:02 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 20 Jan 2014 11:39:02 -0500 Subject: [aerogear-dev] Browser Targets In-Reply-To: <9682E781-175D-4BD7-A193-1593509416D8@redhat.com> References: <79E19B64-A584-4821-A1BA-EA3B49E08344@redhat.com> <9682E781-175D-4BD7-A193-1593509416D8@redhat.com> Message-ID: <92FEC0F0-7359-4B49-8AC9-3BCD18D8D3B5@redhat.com> following up from the team meeting, here is the current link to our Browser targets http://aerogear.org/docs/guides/AeroGearBrowserTargets/ when this was created, i think it was very early on in the project. the desktop browsers are probably ok at this point, ( i would like to remove IE9, though ). Mobile Browsers i think can be revamped a little, Mobile Safari should probably be 6 and 7 we can probably add in Chrome for Android and FireFox for Android WRT the other platforms, i think there is a JIRA to create a Matrix On Jan 8, 2014, at 5:28 AM, Erik Jan de Wit wrote: >> >> on this same topic, what % should we be looking at when thinking about dropping support for other platforms, like android and iOS > > Don?t think we should have a hard (written in stone) rule, but try and to be pragmatic about what we support. > > Because if 10% would be the limit for browsers we could drop IE support all together ;) > _______________________________________________ > 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/20140120/cb1ba85a/attachment.html From tkriz at redhat.com Mon Jan 20 12:00:54 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Mon, 20 Jan 2014 18:00:54 +0100 Subject: [aerogear-dev] Should encrypted store fail to open when passphrase is wrong? Message-ID: <0F40D30B-3EF2-4531-A1BA-E302CBDC0166@redhat.com> Hey, I know we?ve been discussing this before, but with no solution. I myself think, that the store should fail to open when the passphrase is wrong, because that?s where you?d like to have your ?try .. catch ..? to handle the problem, not elsewhere, when you want to actually read/write/delete from the store, that?s just not very user friendly. If the answer to that is YES, then the next question is, how to decide when the passphrase is right and when it isn?t. Again I?ll write more ways I?ve got on mind, that?d solve this. Important is, that none of them actually stores the passphrase! On each call of ?open()?: 1. do ?readAll()? to ensure the passphrase is right. Basically, that?s what user has to do now to find out if the passphrase is right. 2. read the first row and if the read is successful, then the passphrase is right. In this case, we?d have to be 100% sure that there is no way to put data into the store with different key and thus all the rows are encrypted with the same passphrase. 3. Save some metadata for each data model, that would be encrypted with the same passphrase and we?d read them and if successful, the passphrase is right. This has two possible implementations. a. The first row in the data model table would be reserved for the metadata, so the verification would work similarly to the option 2. b. There would be separate table, in which we?d add a row for each data model table. Again, very similar to a. but without the pain of having different data in the same table. Also, if the implementation of SQLStore will become multi-table (instead of multi-database which is now), there would be only one table for all the metadata. So, what do you think? PS: For abstractj, I?ve been trying to find any library that would do the encryption on high-level, as AeroGear does, but couldn?t find any. There are many ways to encrypt SQLite database though they work on different approach of encrypting the whole database file, not just rows themselves. ? Tadeas Kriz tkriz at redhat.com From corinnekrych at gmail.com Mon Jan 20 12:31:41 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 20 Jan 2014 18:31:41 +0100 Subject: [aerogear-dev] Website restructure In-Reply-To: References: <2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com> <20140120123559.3a3aec13@kapy-ntb-x220> Message-ID: Hello All I think the original idea was to have a common text. I think we could have common part for exemple: http://aerogear.org/docs/guides/aerogear-android/AerogearAndroidPipes101/ http://aerogear.org/docs/guides/iOSCookbook/ (section on pipe) http://aerogear.org/docs/guides/GetStartedAeroGearJS.html (section Pipeline & Pipes) all defined Pipe and pipeline, they could have a common part but of course this will involve some serious documentation refactoring. => first task make common smaller pages However, we still need platform specific text. In all the previous exemple we give code snippet + code explantion. We could extend the tab to include text + sample. What will be nice to have as a POC is also: - the main documentation page with the 3 features section: Core/Push/Security - when we pick core, the display of the list of features: Pipe, Store etc?. which is actually missing from Hylke draft. - where do we put documentation like: http://aerogear.org/docs/guides/GetStartedAndroid/ which is not features oriented but goes into the category setup I?ll fork your branch and try to see how we can refactor documentation and give you more concrete feedbacks shortly. For the menu color I guess the best person to help is Hylke. ++ Corinne On 20 Jan 2014, at 12:44, Sebastien Blanc wrote: > > > > On Mon, Jan 20, 2014 at 12:35 PM, Karel Piwko wrote: > Looks good! > +1 I like the dracula theme ! > > Apart for platform related code (JavaScript, Objective-C, Java), are there any > plans to support platform related text? > > E.g. pipes on Aerogear can be used within FragmentActivity, which is valid for > Android only; Javadoc is not related to iOS, etc. That's basically a merge of > our guides into a one per feature with information covering all the platforms. > > Which brings me to and idea of global platform switch. User/reader can switch > platform once and all code snippets and platform related blocks are > automatically selected. Can also be session based and affect all pages user > visits. > > +1 , that would be really cool. I came accross such a layout on https://www.paymill.com/fr-fr/documentation/reference/api-reference/#document-authentication , check on the right, you have a tab where you can switch between different languages, the snippet is updated. > > There are also some online apps that does the job for you like apiary.io and https://www.mashape.com > > Karel > > On Mon, 20 Jan 2014 11:37:28 +0100 > Erik Jan de Wit wrote: > > > Hi, > > > > What I get from this thread is that we like the colour section idea, but we > > don?t want to re structure the entire site. So what we need to discuss is how > > are we going to use these sections if we don?t restructure. What I like about > > them is that it emphasises that our API?s are similar for all platforms and > > that we only have one document explaining for instance what pipes are. But > > the menu, doesn?t fit into this new colour scheme, so we need some decisions > > about how we are going to move forward. > > > > Based on the work Corinne did with the introduction of sass I?ve had a go at > > implementing a bit what Hylke proposed, have a look at my sass branch > > https://github.com/edewit/aerogear.org/tree/saas and the page I?ve updated > > http://localhost:4000/docs/guides/aerogear-android/AerogearAndroidPipes101/ > > to be in section layout. Don?t look at the header and footer as I haven?t > > changed those. > > > > There are a couple of things that I don?t like about the current > > implementation, to enable the code blocks I?ve added some html into the > > asciidoc and some jquery magic in the layout. Maybe we could make this better > > by chaining the rendering/backend or by introducing some sort of plugin into > > asciidoc? Other then that, I?m sure Hylke sees a lot of things that are still > > off, but it?s a start. > > > > What do you think? > > > > Cheers, > > Erik Jan > > > > p.s > > example picture https://www.dropbox.com/s/qtc4g0xwnyi0p41/Example.tiff > > > > _______________________________________________ > 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 Mon Jan 20 12:50:33 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 20 Jan 2014 12:50:33 -0500 Subject: [aerogear-dev] does aerogear supported by mobile firefox In-Reply-To: References: <1389064744777-5703.post@n5.nabble.com> <83AA33C9-AD9E-477A-96FE-9D59F14AC0C7@redhat.com> Message-ID: <017930D6-6BC9-4E60-B02B-F89915246D59@redhat.com> On Jan 20, 2014, at 12:04 PM, naveenraj bala wrote: > I would be glad if i also knew about both . You made me courious. Do you have road map for FireFox OS . I never saw any like that. we don't have anything currently on the Road Map for FFoS, but the the "apps" you create for it are all html/javascript/css based, so our JS libs should work fine with it. as for Firefox Mobile on Android, we are in the process of revamping our supported browser targets, but there is no reason that it, aerogear.js, shouldn't work fine since we currently use jQuery behind the scenes to do ajax > > Thanks, > Naveen Raj Balasubramaniam > > > On Mon, Jan 20, 2014 at 7:25 PM, Lucas Holmquist wrote: > Hi, are you talking about FireFox OS or the firefox Mobile Browser on Android? > > On Jan 19, 2014, at 4:06 AM, Matthias Wessendorf wrote: > >> Hello Naveenraj, >> >> Besides the mentioned app, last week Erik Jan also did create an new app, for FirefoxOS: >> >> https://github.com/edewit/aerogear-aerodoc-firefoxos >> >> It is basically a port of our 'push show case'. >> >> I think these two different apps should give you a good starting point, how to use AeroGear APIs on a FirefoxOS device >> >> Greetings, >> Matthias >> >> >> On Sun, Jan 19, 2014 at 9:49 AM, Bruno Oliveira wrote: >> Good morning my friend, not yet. But if you want to start with something, Daniel Passos wrote an application using AeroGear JS (https://github.com/danielpassos/call4paperz4FirefoxOS) >> >> >> >> -- >> abstractj >> >> On January 18, 2014 at 5:22:42 PM, Naveenraj (mailnaveenraj at gmail.com) wrote: >> > > I just wantbto know if mozilla Firefox mobile is supported or >> > not. >> > In the tbd of mobile browser I am not able to find Firefox mobile. >> > . >> >> _______________________________________________ >> 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140120/33ddae8c/attachment.html From cvasilak at gmail.com Mon Jan 20 12:55:32 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 20 Jan 2014 19:55:32 +0200 Subject: [aerogear-dev] iOS Factory Classes In-Reply-To: <52DD2CA6.30907@redhat.com> References: <52DD2CA6.30907@redhat.com> Message-ID: <3FAF6120-3FD2-49EE-999A-7832EC0D060D@gmail.com> thanks Summers for bringing this up you are correct, currently dynamically plugging custom user modules is not supported apart from serving the build-ones. Although a user can somehow plug in ?custom? modules directly [see RedditAuthModule [1] it feels ?awkward?. Since JS, Android has support for it, opened Jira[2] to align on this in iOS Regards - Christos [1] https://github.com/aerogear/aerogear-ios-integration/blob/master/AeroGear-iOS-Integration/AeroGear-iOS-IntegrationTests/AGPagingBody_RedditSpec.m#L30 [2] https://issues.jboss.org/browse/AGIOS-154 On Jan 20, 2014, at 4:03 PM, Summers Pittman wrote: > One of the things I brought up in the review of the iOS OAUTH2 PR was > that the Authz factory class, AGAuthorizer, does not allow injection of > custom Authorizors. > Corrine mentioned that this wasn't done for any of the other classes > (Pipeline, Authentication, etc). I know Android does this (via an add > method and also allows you to supply a custom builder) and I am pretty > sure JavaScript has an add method as well. > > Just wanted to bring up this place where the platforms diverged and get > community input. > > Back to coffee, > > Summers > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From lholmqui at redhat.com Mon Jan 20 12:57:22 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 20 Jan 2014 12:57:22 -0500 Subject: [aerogear-dev] JS Future Roadmap In-Reply-To: References: Message-ID: On Jan 20, 2014, at 4:49 AM, Corinne Krych wrote: > > On 20 Jan 2014, at 09:51, Matthias Wessendorf wrote: > >> >> >> >> On Sat, Jan 18, 2014 at 7:31 PM, Lucas Holmquist wrote: >> I was having some thoughts on the future of AeroGear.js that i needed to share. >> >> Experimental Branch > > early adoptor branch or really experimental ? I imagine that to use this branch, you would might need to turn on features in your browser, like enabling experimental javascript in chrome for example. > >> >> I think i want to create a branch that is very experimental, that targets new and upcoming API's, like Object.Observe, and Promises, etc? >> >> I feel this is the only way to drive innovation >> >> I was thinking this is sort of our "Canary" branch, and when things start to become less pollyfilly, then we can start to move these features in. >> >> I still however want the code in this branch to be complete, not just random crap >> >> >> +1 - also liking the name :-) > > got the history for the name hew: > http://readwrite.com/2010/08/02/google_releases_canary_build_of_chrome_for_the_ear#awesm=~ottCjppZ0Ra6HL > > "The name of the build refers to the old practice of miners to bring a canary into a coal mine. If poisonous gasses were present, the canary would die before it would kill the miners, acting as an alarm system." > >> >> >> 2.0 >> >> I would like to see that in 2.0 we start to remove our jQuery requirement, and focus more on Modern Browsers and have our 1.X branch be our less than modern browser( IE9 ) supported branch. much like how jQuery has a 1.X and 2.X branch, obviously the difference between our branches won't be as extreme. >> >> The major thing we use jQuery for atm is jQuery.ajax and Promises. this is nice for cross broswer compatibility and for transpoting other things other than json, which brings me to my next point >> >> I would also like in 2.0 to make our library( pipeline ) only speak json. I think this will make it really simple to have our own AeroGear.Ajax() method and be able to keep it small in size >> >> >> >> +1; like the idea; for our iOS 2.x bits I'd imagine we do similar: iOS7/8 only and using AFN 2.x >> >> >> 1.X Branch >> >> Once we hit all our 1.X milestones( sync, offline ) then what is the current master branch would become a 1.X branch, and we recieve bug fixes, but no new features. If something in the future could be back ported, then maybe, but it wouldn't be a priority >> >> This branch would still have a jQuery requirement and would be for legacy stuff( IE9 ) >> >> >> makes perfectly sense! >> >> Great ideas! >> >> -Matthias >> >> >> >> _______________________________________________ >> 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 From lholmqui at redhat.com Mon Jan 20 13:14:24 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 20 Jan 2014 13:14:24 -0500 Subject: [aerogear-dev] JS Future Roadmap In-Reply-To: References: Message-ID: On Jan 20, 2014, at 3:51 AM, Matthias Wessendorf wrote: > > > > On Sat, Jan 18, 2014 at 7:31 PM, Lucas Holmquist wrote: > I was having some thoughts on the future of AeroGear.js that i needed to share. > > Experimental Branch > > I think i want to create a branch that is very experimental, that targets new and upcoming API's, like Object.Observe, and Promises, etc? > > I feel this is the only way to drive innovation > > I was thinking this is sort of our "Canary" branch, and when things start to become less pollyfilly, then we can start to move these features in. > > I still however want the code in this branch to be complete, not just random crap > > > +1 - also liking the name :-) > > > 2.0 > > I would like to see that in 2.0 we start to remove our jQuery requirement, and focus more on Modern Browsers and have our 1.X branch be our less than modern browser( IE9 ) supported branch. much like how jQuery has a 1.X and 2.X branch, obviously the difference between our branches won't be as extreme. > > The major thing we use jQuery for atm is jQuery.ajax and Promises. this is nice for cross broswer compatibility and for transpoting other things other than json, which brings me to my next point > > I would also like in 2.0 to make our library( pipeline ) only speak json. I think this will make it really simple to have our own AeroGear.Ajax() method and be able to keep it small in size > > I'm also tempted to remove "jsonp" support since there are risks with this > > > +1; like the idea; for our iOS 2.x bits I'd imagine we do similar: iOS7/8 only and using AFN 2.x > > > 1.X Branch > > Once we hit all our 1.X milestones( sync, offline ) then what is the current master branch would become a 1.X branch, and we recieve bug fixes, but no new features. If something in the future could be back ported, then maybe, but it wouldn't be a priority > > This branch would still have a jQuery requirement and would be for legacy stuff( IE9 ) > > > makes perfectly sense! > > Great ideas! > > -Matthias > > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140120/bfe9621c/attachment-0001.html From edewit at redhat.com Mon Jan 20 13:36:10 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Mon, 20 Jan 2014 19:36:10 +0100 Subject: [aerogear-dev] Website restructure In-Reply-To: References: <2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com> <20140120123559.3a3aec13@kapy-ntb-x220> Message-ID: <2D17D895-D2E4-4167-A686-71F962D658DF@redhat.com> > I think the original idea was to have a common text. I think we could have common part for exemple: > http://aerogear.org/docs/guides/aerogear-android/AerogearAndroidPipes101/ > http://aerogear.org/docs/guides/iOSCookbook/ (section on pipe) > http://aerogear.org/docs/guides/GetStartedAeroGearJS.html (section Pipeline & Pipes) > all defined Pipe and pipeline, they could have a common part but of course this will involve some serious documentation refactoring. Yeah, that was my take on it as well, and because we explain how to use these things in only one document with some platform specific parts it will also be a place to verify that our api?s are close to one another. > > => first task make common smaller pages > > However, we still need platform specific text. In all the previous exemple we give code snippet + code explantion. We could extend the tab to include text + sample. +1 if there is a need for that that is very do-able > > What will be nice to have as a POC is also: > - the main documentation page with the 3 features section: Core/Push/Security Okay that is one thing I wasn?t certain on, that will mean restructure of the site to create these sections based on ?functionality? instead of platform. Does that mean you want to move away from the per platform split, or does it mean that you want to keep both? > I?ll fork your branch and try to see how we can refactor documentation and give you more concrete feedbacks shortly. > For the menu color I guess the best person to help is Hylke. > K, have a closer look and I?ll wait in the mean time Hylke do you have some ideas for keeping the menu or maybe integrating it differently? > ++ > Corinne > > > On 20 Jan 2014, at 12:44, Sebastien Blanc wrote: > >> >> >> >> On Mon, Jan 20, 2014 at 12:35 PM, Karel Piwko wrote: >> Looks good! >> +1 I like the dracula theme ! >> >> Apart for platform related code (JavaScript, Objective-C, Java), are there any >> plans to support platform related text? >> >> E.g. pipes on Aerogear can be used within FragmentActivity, which is valid for >> Android only; Javadoc is not related to iOS, etc. That's basically a merge of >> our guides into a one per feature with information covering all the platforms. >> >> Which brings me to and idea of global platform switch. User/reader can switch >> platform once and all code snippets and platform related blocks are >> automatically selected. Can also be session based and affect all pages user >> visits. >> >> +1 , that would be really cool. I came accross such a layout on https://www.paymill.com/fr-fr/documentation/reference/api-reference/#document-authentication , check on the right, you have a tab where you can switch between different languages, the snippet is updated. >> >> There are also some online apps that does the job for you like apiary.io and https://www.mashape.com >> >> Karel >> >> On Mon, 20 Jan 2014 11:37:28 +0100 >> Erik Jan de Wit wrote: >> >>> Hi, >>> >>> What I get from this thread is that we like the colour section idea, but we >>> don?t want to re structure the entire site. So what we need to discuss is how >>> are we going to use these sections if we don?t restructure. What I like about >>> them is that it emphasises that our API?s are similar for all platforms and >>> that we only have one document explaining for instance what pipes are. But >>> the menu, doesn?t fit into this new colour scheme, so we need some decisions >>> about how we are going to move forward. >>> >>> Based on the work Corinne did with the introduction of sass I?ve had a go at >>> implementing a bit what Hylke proposed, have a look at my sass branch >>> https://github.com/edewit/aerogear.org/tree/saas and the page I?ve updated >>> http://localhost:4000/docs/guides/aerogear-android/AerogearAndroidPipes101/ >>> to be in section layout. Don?t look at the header and footer as I haven?t >>> changed those. >>> >>> There are a couple of things that I don?t like about the current >>> implementation, to enable the code blocks I?ve added some html into the >>> asciidoc and some jquery magic in the layout. Maybe we could make this better >>> by chaining the rendering/backend or by introducing some sort of plugin into >>> asciidoc? Other then that, I?m sure Hylke sees a lot of things that are still >>> off, but it?s a start. >>> >>> What do you think? >>> >>> Cheers, >>> Erik Jan >>> >>> p.s >>> example picture https://www.dropbox.com/s/qtc4g0xwnyi0p41/Example.tiff >>> >> >> _______________________________________________ >> 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 cvasilak at gmail.com Mon Jan 20 13:48:09 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 20 Jan 2014 20:48:09 +0200 Subject: [aerogear-dev] Auth Authz and OAuth In-Reply-To: References: <52CACA06.1000508@redhat.com> <2E21E3DB-DD8C-44B3-9132-7D1588334B07@redhat.com> <1645A48F-12E4-451C-A1DF-562556D53F13@gmail.com> <52CACE33.6070807@redhat.com> Message-ID: On Jan 6, 2014, at 5:48 PM, Corinne Krych wrote: > Agreed. We could find a common way to treat both tokens and apply them. @summers continue on the discussion we had on our meeting, per OAuthz workflow req. a separate AGAuthzModule has been created [1] since the original AuthenticationModule[2] interface couldn?t accommodate it. Since the end-result for both is ?modifying? the request (currently headers but possible in the future body) prior on performing the operation would be interesting if we can somehow encapsulate this common ?behaviour? and have those separate AuthModule and AuthzModule inherit from. would be interesting to know your idea on this Regards, - Christos [1] https://github.com/corinnekrych/aerogear-ios/blob/bd579a8f0ef407cfe7fd50e4ed741d0041e3810f/AeroGear-iOS/AeroGear-iOS/security/Authorizer/AGAuthzModule.h [2] https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/security/AGAuthenticationModule.h > Make a proposal for android and I'll create a JIRA for iOS. > this is at implementation level though and should not affect interfaces. > Different interfaces still needed for auth and authz though. > > ++ > Corinne > On Jan 6, 2014, at 4:39 PM, Summers Pittman wrote: > >> On Mon 06 Jan 2014 10:36:32 AM EST, Corinne Krych wrote: >>> Summers, >>> >>> Do you mean, should we refactor and treat authToken and accessTokens in a similar way for the implementation of OAuth2? >> >> Yes. That is what I am proposing. >> >>> >>> ++ >>> Corinne >>> On Jan 6, 2014, at 4:33 PM, Lucas Holmquist wrote: >>> >>>> >>>> On Jan 6, 2014, at 10:21 AM, Summers Pittman wrote: >>>> >>>>> So in JS land and iOS land we have or will soon have OAuth2 handling. >>>>> To handle OAuth2 a new API was created, AGAuthorizationModule. I >>>>> understand and agree with the separation of concerns between >>>>> Authentication and Authorization, but I am worried that this introduces >>>>> two APIs now. >>>>> >>>>> Before Authz was added Authentication (login, logout, etc) and >>>>> Authorization(here are my keys and permissions) were both handled by >>>>> AGAuthenticationModules. With Authz now being a thing we should >>>>> probably remove and deprecate the authz parts of the old >>>>> AuthenticationModules. >>>>> >>>>> see iOS >>>>> https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/AeroGear-iOS/pipeline/AGRESTPipe.m#L307 >>>>> >>>>> see Android >>>>> https://github.com/aerogear/aerogear-android/blob/master/src/org/jboss/aerogear/android/impl/pipeline/RestRunner.java#L319 >>>>> >>>>> see Javascript: I couldn't actually find this in javascript? >>>> >>>> We didn't have authz in our auth stuff, so it made sense to create a separate thing. >>>> >>>>> >>>>> 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 From qmx at qmx.me Mon Jan 20 13:53:38 2014 From: qmx at qmx.me (Douglas Campos) Date: Mon, 20 Jan 2014 16:53:38 -0200 Subject: [aerogear-dev] JS Future Roadmap In-Reply-To: References: Message-ID: <20140120185338.GG26872@rohan.local> On Mon, Jan 20, 2014 at 01:14:24PM -0500, Lucas Holmquist wrote: > I'm also tempted to remove "jsonp" support since there are risks with this +9001, nowadays the right answer is setup CORS properly, right? -- qmx From cvasilak at gmail.com Mon Jan 20 13:53:44 2014 From: cvasilak at gmail.com (Christos Vasilakis) Date: Mon, 20 Jan 2014 20:53:44 +0200 Subject: [aerogear-dev] Backend (jax-rs) Project In-Reply-To: References: Message-ID: <996ACE2C-F429-4224-9E3D-E9836DFEB0DD@gmail.com> fyi have added multipart upload support endpoint that simply echo backs(json) the request and in the case of ?file? parts just the file file size of each. I am Planning to use on our ig-tests and cookbook [1] https://github.com/danielpassos/aerogear-integration-tests-server/pull/1 Regards - Christos On Jan 14, 2014, at 3:20 PM, Daniel Passos wrote: > Hi folks, > > I started a new backend project[1] using jax-rs. The idea of this project is provide some endpoints to use in the demos, integration tests and cookbooks. > > I have tried to fix and add new features to the old project[2], but the legacy is big and hard to fix > > I created a jira for it[3]. Feel free to add (and take) new sub tasks and send PRs > > [1] https://github.com/danielpassos/aerogear-integration-tests-server > [2] https://github.com/aerogear/aerogear-jaxrs-demo > [3] https://issues.jboss.org/browse/AEROGEAR-1388 > > -- > Daniel Passos > > _______________________________________________ > 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/20140120/8b2df273/attachment.html From lholmqui at redhat.com Mon Jan 20 13:54:59 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Mon, 20 Jan 2014 13:54:59 -0500 Subject: [aerogear-dev] JS Future Roadmap In-Reply-To: <20140120185338.GG26872@rohan.local> References: <20140120185338.GG26872@rohan.local> Message-ID: <3D034EF7-A7FC-495C-839F-EA8CAF0483DF@redhat.com> On Jan 20, 2014, at 1:53 PM, Douglas Campos wrote: > On Mon, Jan 20, 2014 at 01:14:24PM -0500, Lucas Holmquist wrote: >> I'm also tempted to remove "jsonp" support since there are risks with this > > +9001, nowadays the right answer is setup CORS properly, right? thats my thinking > > -- > qmx > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Tue Jan 21 03:08:45 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 21 Jan 2014 09:08:45 +0100 Subject: [aerogear-dev] JS Future Roadmap In-Reply-To: <20140120185338.GG26872@rohan.local> References: <20140120185338.GG26872@rohan.local> Message-ID: On Mon, Jan 20, 2014 at 7:53 PM, Douglas Campos wrote: > On Mon, Jan 20, 2014 at 01:14:24PM -0500, Lucas Holmquist wrote: > > I'm also tempted to remove "jsonp" support since there are risks with > this > > +9001, nowadays the right answer is setup CORS properly, right? > +1 > > -- > qmx > _______________________________________________ > 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/20140121/1347ea4d/attachment.html From scm.blanc at gmail.com Tue Jan 21 03:27:02 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Tue, 21 Jan 2014 09:27:02 +0100 Subject: [aerogear-dev] Team meeting agenda In-Reply-To: References: Message-ID: Et voila ! http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-01-20-14.50.html On Fri, Jan 17, 2014 at 12:20 PM, Matthias Wessendorf wrote: > Proposed agenda for Mondays team meeting: > > http://oksoclap.com/p/aerogear-team-mgt-20140120 > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140121/ab660bfb/attachment-0001.html From matzew at apache.org Tue Jan 21 03:34:32 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 21 Jan 2014 09:34:32 +0100 Subject: [aerogear-dev] Team meeting agenda In-Reply-To: References: Message-ID: jbottMeeting ended Mon Jan 20 15:36:06 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)15:40 jbottMinutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-01-20-14.50.html 15:40 jbottMinutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-01-20-14.50.txt 15:40 jbottLog: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-01-20-14.50.log.html 15:40 On Tue, Jan 21, 2014 at 9:27 AM, Sebastien Blanc wrote: > Et voila ! > > http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-01-20-14.50.html > > > On Fri, Jan 17, 2014 at 12:20 PM, Matthias Wessendorf wrote: > >> Proposed agenda for Mondays team meeting: >> >> http://oksoclap.com/p/aerogear-team-mgt-20140120 >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140121/1a60864a/attachment.html From edewit at redhat.com Tue Jan 21 04:43:07 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 21 Jan 2014 10:43:07 +0100 Subject: [aerogear-dev] simple Java sync server Message-ID: <3CA6121A-60F0-4C8A-9B4A-CD208D594782@redhat.com> Hi, Made a very simple Java version (based on hibernate) of the sync server. It doesn?t merge so any change in a entity that is old will give a merge conflict. It uses the same ?protocol? as couch so WDYT? Cheers, Erik Jan https://github.com/edewit/sync-server -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140121/69cd5547/attachment.html From bruno at abstractj.org Tue Jan 21 07:32:32 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 21 Jan 2014 10:32:32 -0200 Subject: [aerogear-dev] Encrypted Store In-Reply-To: <52DD436D.80809@redhat.com> References: <52DD436D.80809@redhat.com> Message-ID: Hi Summers, could you please elaborate more or give to me some pointers? ?mix data keys in the datastore? doesn?t help too much. Which kind of simple key checks? Define mixing/matching keys, please point me to jiras or some code. Is hard to guess exactly what you are talking. -- abstractj On January 20, 2014 at 1:40:33 PM, Summers Pittman (supittma at redhat.com) wrote: > > Hi. > > On Android and iOS you CAN mix data keys in the datastore, but this > will > cause the readAll method to fail. > > On Android we are planning on fixing this (there is a JIRA somewhere) > to > make it so that we will do simple key checks. > > How does JavaScript do encrypted stores and how does it work when > you > begin mixing/matching keys. From hbons at redhat.com Tue Jan 21 07:39:59 2014 From: hbons at redhat.com (Hylke Bons) Date: Tue, 21 Jan 2014 12:39:59 +0000 Subject: [aerogear-dev] Website restructure In-Reply-To: <2D17D895-D2E4-4167-A686-71F962D658DF@redhat.com> References: <2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com> <20140120123559.3a3aec13@kapy-ntb-x220> <2D17D895-D2E4-4167-A686-71F962D658DF@redhat.com> Message-ID: <52DE6A9F.6090906@redhat.com> On 20/01/2014 18:36, Erik Jan de Wit wrote: >> I think the original idea was to have a common text. I think we could have common part for exemple: >> http://aerogear.org/docs/guides/aerogear-android/AerogearAndroidPipes101/ >> http://aerogear.org/docs/guides/iOSCookbook/ (section on pipe) >> http://aerogear.org/docs/guides/GetStartedAeroGearJS.html (section Pipeline & Pipes) >> all defined Pipe and pipeline, they could have a common part but of course this will involve some serious documentation refactoring. > Yeah, that was my take on it as well, and because we explain how to use these things in only one document with some platform specific parts it will also be a place to verify that our api?s are close to one another. Hey Erik, This is great work! :) >> => first task make common smaller pages >> >> However, we still need platform specific text. In all the previous exemple we give code snippet + code explantion. We could extend the tab to include text + sample. > +1 if there is a need for that that is very do-able It would be nice if the body text is as generic as possible so that it always works with the code in every language, but there may be some situations where this isn't possible. So yes, your suggestion of a small comment section in the code snippet would be a good solution for that. >> What will be nice to have as a POC is also: >> - the main documentation page with the 3 features section: Core/Push/Security > Okay that is one thing I wasn?t certain on, that will mean restructure of the site to create these sections based on ?functionality? instead of platform. Does that mean you want to move away from the per platform split, or does it mean that you want to keep both? This is probably the biggest change and the main point of the restructure to keep everything understandable and easy to navigate. I'd say yes, but am not sure if everybody agrees with me (but I hope to convince them :). > >> I?ll fork your branch and try to see how we can refactor documentation and give you more concrete feedbacks shortly. >> For the menu color I guess the best person to help is Hylke. >> > K, have a closer look and I?ll wait in the mean time Hylke do you have some ideas for keeping the menu or maybe integrating it differently? We may not need the menu anymore. What we do need is some kind of side bar in the documentation to quickly jump between the submodules (Core/Sync/Push/etc.). I'll have a look at that and post some mockups here. Anyway, it's great to see progress in this area. Good job and I will have a look at the branch. :) Hylke >> ++ >> Corinne >> >> >> On 20 Jan 2014, at 12:44, Sebastien Blanc wrote: >> >>> >>> >>> On Mon, Jan 20, 2014 at 12:35 PM, Karel Piwko wrote: >>> Looks good! >>> +1 I like the dracula theme ! >>> >>> Apart for platform related code (JavaScript, Objective-C, Java), are there any >>> plans to support platform related text? >>> >>> E.g. pipes on Aerogear can be used within FragmentActivity, which is valid for >>> Android only; Javadoc is not related to iOS, etc. That's basically a merge of >>> our guides into a one per feature with information covering all the platforms. >>> >>> Which brings me to and idea of global platform switch. User/reader can switch >>> platform once and all code snippets and platform related blocks are >>> automatically selected. Can also be session based and affect all pages user >>> visits. >>> >>> +1 , that would be really cool. I came accross such a layout on https://www.paymill.com/fr-fr/documentation/reference/api-reference/#document-authentication , check on the right, you have a tab where you can switch between different languages, the snippet is updated. >>> >>> There are also some online apps that does the job for you like apiary.io and https://www.mashape.com >>> >>> Karel >>> >>> On Mon, 20 Jan 2014 11:37:28 +0100 >>> Erik Jan de Wit wrote: >>> >>>> Hi, >>>> >>>> What I get from this thread is that we like the colour section idea, but we >>>> don?t want to re structure the entire site. So what we need to discuss is how >>>> are we going to use these sections if we don?t restructure. What I like about >>>> them is that it emphasises that our API?s are similar for all platforms and >>>> that we only have one document explaining for instance what pipes are. But >>>> the menu, doesn?t fit into this new colour scheme, so we need some decisions >>>> about how we are going to move forward. >>>> >>>> Based on the work Corinne did with the introduction of sass I?ve had a go at >>>> implementing a bit what Hylke proposed, have a look at my sass branch >>>> https://github.com/edewit/aerogear.org/tree/saas and the page I?ve updated >>>> http://localhost:4000/docs/guides/aerogear-android/AerogearAndroidPipes101/ >>>> to be in section layout. Don?t look at the header and footer as I haven?t >>>> changed those. >>>> >>>> There are a couple of things that I don?t like about the current >>>> implementation, to enable the code blocks I?ve added some html into the >>>> asciidoc and some jquery magic in the layout. Maybe we could make this better >>>> by chaining the rendering/backend or by introducing some sort of plugin into >>>> asciidoc? Other then that, I?m sure Hylke sees a lot of things that are still >>>> off, but it?s a start. >>>> >>>> What do you think? >>>> >>>> Cheers, >>>> Erik Jan >>>> >>>> p.s >>>> example picture https://www.dropbox.com/s/qtc4g0xwnyi0p41/Example.tiff >>>> >>> _______________________________________________ >>> 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 hbons at redhat.com Tue Jan 21 07:43:39 2014 From: hbons at redhat.com (Hylke Bons) Date: Tue, 21 Jan 2014 12:43:39 +0000 Subject: [aerogear-dev] Website restructure In-Reply-To: References: <2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com> <20140120123559.3a3aec13@kapy-ntb-x220> Message-ID: <52DE6B7B.6050202@redhat.com> On 20/01/2014 17:31, Corinne Krych wrote: >> On Mon, Jan 20, 2014 at 12:35 PM, Karel Piwko wrote: >> Looks good! >> +1 I like the dracula theme ! >> >> Apart for platform related code (JavaScript, Objective-C, Java), are there any >> plans to support platform related text? >> >> E.g. pipes on Aerogear can be used within FragmentActivity, which is valid for >> Android only; Javadoc is not related to iOS, etc. That's basically a merge of >> our guides into a one per feature with information covering all the platforms. Is there a list of the most important features/classes/objects that I can use in the mockup? >> Which brings me to and idea of global platform switch. User/reader can switch >> platform once and all code snippets and platform related blocks are >> automatically selected. Can also be session based and affect all pages user >> visits. Interesting idea. :) Hylke From bruno at abstractj.org Tue Jan 21 07:54:51 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 21 Jan 2014 10:54:51 -0200 Subject: [aerogear-dev] Should encrypted store fail to open when passphrase is wrong? In-Reply-To: <0F40D30B-3EF2-4531-A1BA-E302CBDC0166@redhat.com> References: <0F40D30B-3EF2-4531-A1BA-E302CBDC0166@redhat.com> Message-ID: -- abstractj On January 20, 2014 at 3:00:54 PM, Tadeas Kriz (tkriz at redhat.com) wrote: > > Hey, > > I know we?ve been discussing this before, but with no solution. > I myself think, that the store should fail to open when the passphrase > is wrong, because that?s where you?d like to have your ?try .. > catch ..? to handle the problem, not elsewhere, when you want > to actually read/write/delete from the store, that?s just not > very user friendly. >? > If the answer to that is YES, then the next question is, how to decide? > when the passphrase is right and when it isn?t. Again I?ll write? Like I mentioned here (https://issues.jboss.org/browse/AGDROID-173), our goal to the very initial release was not to make anything perfect, but lay down the groundwork for encryption. So if you where you read ?Experimental?, by that means, not perfect. Offline authentication didn?t start yet, so that might happen. The API will be user friendly when become stable. > more ways I?ve got on mind, that?d solve this. Important is, that > none of them actually stores the passphrase! >? > On each call of ?open()?: > 1. do ?readAll()? to ensure the passphrase is right. Basically, > that?s what user has to do now to find out if the passphrase is right. > > 2. read the first row and if the read is successful, then the passphrase > is right. In this case, we?d have to be 100% sure that there is no > way to put data into the store with different key and thus all the > rows are encrypted with the same passphrase. We are aware of it, at the same time we didn?t add support for querying into the database. That?s planned, but not atm. Our focus was data encryption, optimizations will come with the next releases, for this reason a jiras like this exist https://issues.jboss.org/browse/AGSEC-137? > > 3. Save some metadata for each data model, that would be encrypted > with the same passphrase and we?d read them and if successful, > the passphrase is right. This has two possible implementations. > > a. The first row in the data model table would be reserved for the > metadata, so the verification would work similarly to the option? > 2. > > b. There would be separate table, in which we?d add a row for each > data model table. Again, very similar to a. but without the pain > of having different data in the same table. Also, if the implementation > of SQLStore will become multi-table (instead of multi-database > which is now), there would be only one table for all the metadata. > > So, what do you think? Repeating what I said on that Jira, it seems too much. APIs like SQLCipher don?t do that. > > PS: For abstractj, I?ve been trying to find any library that would > do the encryption on high-level, as AeroGear does, but couldn?t > find any. There are many ways to encrypt SQLite database though > they work on different approach of encrypting the whole database > file, not just rows themselves. That?s the reason why we?ve been working on it. > > ? > Tadeas Kriz > tkriz at redhat.com > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > From lholmqui at redhat.com Tue Jan 21 08:45:19 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 21 Jan 2014 08:45:19 -0500 Subject: [aerogear-dev] [iOS] Simple draft of HTTP API to talk to ag-sync server In-Reply-To: References: Message-ID: <23CE682F-AAE2-4F30-99C0-22731DFD2396@redhat.com> anyone have any thoughts on this? On Jan 15, 2014, at 3:31 PM, Lucas Holmquist wrote: > well, i've hacked something together for js here in this branch: https://github.com/lholmquist/aerogear-js/tree/AGJS-124 > > it is in no way complete, just some idea's. > > to run the tests here, you need to have dan's server running. > > i'm currently trying out https://github.com/benjamine/JsonDiffPatch to do the diff/patching during an update conflict, > > Here is a quick and dirty API that i was thinking could be a start, for JS at least > > // Create a New Data Sync Object > > var dataSync = AeroGear.DataSync( { syncServerUrl: "http://localhost:8080" } ); > > /* possibly more options here, like "auto-merge" > options = { > syncServerUrl: "link_to_sync_server", > autoMerge: false, //optional, defaults to false? Not sure this is the right spot for this, maybe should be in the update call > otheroptions: .... > } > */ > > // Probably have 3 Methods: read, save( Update ), remove > // each one has 2 parameters, the "document" and the settings > > /* > The document here is an object defined like in qmx's sync thought dump > var document = { > id: "123sjf2-i", > content: { > // Some Arbitrary JSON or an array or something serializable into JSON > }, > rev: "SOME_REVISION_ID" // or rev_id or revision or revision_id, we can argue over names later > } > */ > > dataSync.read( document, settings ); > > /* > --READ-- > > var settings = { > success: function( document ){}, // GET the document > error: function( error ){} // an error happened GETting the document, like it can't be found or something > } > */ > > dataSync.save( document, settings ); > > /* > --Save-- > document can be either an array or an object > if whatever is passed is in the form of the document specifed above, then save works as an "update" > var settings: { > autoMerge: // not sure if this should be here or in the constructor > success: function( document ){} // successful PUT to create the document or update the document, > conflict: function( error, current_model_from_server, delta_of_current_server_model_and_local_document ) // this delta thing should be nice and user friendly or something > SOME_OTHER_SPECIFIC_CALLBACK: function(){}, // Maybe other callbacks for specific events > error: function( error ){} // an error happened, catch-all ? > } > */ > > dataSync.remove( document, settings ); > > /* > TBD > */ > > > > On Jan 13, 2014, at 11:56 AM, Matthias Wessendorf wrote: > >> Hi, >> >> based on the ag.org "sync-branch" (see [1]), I created a SIMPLE first iOS hack of a "document" API with a HTTP client that talks to Dan's Server. >> >> The model ([2]) is quite easy/simple and the HTTP client supports CREATE/READ/REMOVE ([3]), based on the protocol defined on the README of the server. >> >> The usage is covered in a test (like [4]). >> >> Next: I guess next (if we continue using Dan's Server) is to see how this project can we weaved into the exisiting stores - but first I really wanted to get some client (like Luke's JS client) which executes against our current server draft/implementation. >> >> BTW. the lib is based on AFN2.x (not sure we should use AFN 2.x at THIS point - switching to 1.x should not be that hard) >> >> -Matthias >> >> [1] https://github.com/aerogear/aerogear.org/pull/230 >> [2] https://github.com/matzew/AGSyncKit/blob/master/SyncKit/AGDocument.h >> [3] https://github.com/matzew/AGSyncKit/blob/master/SyncKit/AGSyncClient.h >> [4] https://github.com/matzew/AGSyncKit/blob/master/SyncKitTests/SyncKitTests.m#L37-L61 >> >> -- >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140121/f453a77d/attachment.html From bruno at abstractj.org Tue Jan 21 08:56:10 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 21 Jan 2014 11:56:10 -0200 Subject: [aerogear-dev] simple Java sync server In-Reply-To: <3CA6121A-60F0-4C8A-9B4A-CD208D594782@redhat.com> References: <3CA6121A-60F0-4C8A-9B4A-CD208D594782@redhat.com> Message-ID: Why not contribute to?https://github.com/aerogear/aerogear-sync-server, instead of create a new server implementation? -- abstractj On January 21, 2014 at 7:43:31 AM, Erik Jan de Wit (edewit at redhat.com) wrote: > > Hi, > > Made a very simple Java version (based on hibernate) of the sync > server. It doesn?t merge so any change in a entity that is old will > give a merge conflict. It uses the same ?protocol? as couch so > WDYT? > > Cheers, > Erik Jan > > https://github.com/edewit/sync-server From matzew at apache.org Tue Jan 21 08:57:39 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 21 Jan 2014 14:57:39 +0100 Subject: [aerogear-dev] [iOS] Simple draft of HTTP API to talk to ag-sync server In-Reply-To: <23CE682F-AAE2-4F30-99C0-22731DFD2396@redhat.com> References: <23CE682F-AAE2-4F30-99C0-22731DFD2396@redhat.com> Message-ID: On Tue, Jan 21, 2014 at 2:45 PM, Lucas Holmquist wrote: > anyone have any thoughts on this? > yes, sorry for the delay; pretty much aligned w/ the 'primitive' iOS API that we currently have (which was 'inspired' by your initial JS tests, on Dan's Server). Currently we are pretty much all (almost all) on the CouchDB design (including Erik Jan's server (not yet tested)). I guess so far this all makes sense. Next interesting item would be a 'pushed' sync, using something like WebSocket/SockJS (not only on the JS side of things) @JsonDiffPatch: pretty interesting library, looks like does what we need on the (JS) client side -Matthias > > On Jan 15, 2014, at 3:31 PM, Lucas Holmquist wrote: > > well, i've hacked something together for js here in this branch: > https://github.com/lholmquist/aerogear-js/tree/AGJS-124 > > it is in no way complete, just some idea's. > > to run the tests here, you need to have dan's server running. > > i'm currently trying out https://github.com/benjamine/JsonDiffPatch to do > the diff/patching during an update conflict, > > Here is a quick and dirty API that i was thinking could be a start, for > JS at least > > // Create a New Data Sync Object > > var dataSync = AeroGear.DataSync( { syncServerUrl: "http://localhost:8080" } ); > > /* possibly more options here, like "auto-merge" > options = { > syncServerUrl: "link_to_sync_server", > autoMerge: false, //optional, defaults to false? Not sure this is the right spot for this, maybe should be in the update call > otheroptions: .... > } > */ > > // Probably have 3 Methods: read, save( Update ), remove > // each one has 2 parameters, the "document" and the settings > > /* > The document here is an object defined like in qmx's sync thought dump > var document = { > id: "123sjf2-i", > content: { > // Some Arbitrary JSON or an array or something serializable into JSON > }, > rev: "SOME_REVISION_ID" // or rev_id or revision or revision_id, we can argue over names later > } > */ > > dataSync.read( document, settings ); > > /* > --READ-- > var settings = { > success: function( document ){}, // GET the document > error: function( error ){} // an error happened GETting the document, like it can't be found or something > } > */ > > dataSync.save( document, settings ); > > /* > --Save-- > document can be either an array or an object > if whatever is passed is in the form of the document specifed above, then save works as an "update" > var settings: { > autoMerge: // not sure if this should be here or in the constructor > success: function( document ){} // successful PUT to create the document or update the document, > conflict: function( error, current_model_from_server, delta_of_current_server_model_and_local_document ) // this delta thing should be nice and user friendly or something > SOME_OTHER_SPECIFIC_CALLBACK: function(){}, // Maybe other callbacks for specific events > error: function( error ){} // an error happened, catch-all ? > } > */ > > dataSync.remove( document, settings ); > > /* > TBD > */ > > > > > On Jan 13, 2014, at 11:56 AM, Matthias Wessendorf > wrote: > > Hi, > > based on the ag.org "sync-branch" (see [1]), I created a SIMPLE first iOS > hack of a "document" API with a HTTP client that talks to Dan's Server. > > The model ([2]) is quite easy/simple and the HTTP client supports > CREATE/READ/REMOVE ([3]), based on the protocol defined on the README of > the server. > > The usage is covered in a test (like [4]). > > Next: I guess next (if we continue using Dan's Server) is to see how this > project can we weaved into the exisiting stores - but first I really wanted > to get some client (like Luke's JS client) which executes against our > current server draft/implementation. > > BTW. the lib is based on AFN2.x (not sure we should use AFN 2.x at THIS > point - switching to 1.x should not be that hard) > > -Matthias > > [1] https://github.com/aerogear/aerogear.org/pull/230 > [2] https://github.com/matzew/AGSyncKit/blob/master/SyncKit/AGDocument.h > [3] https://github.com/matzew/AGSyncKit/blob/master/SyncKit/AGSyncClient.h > [4] > https://github.com/matzew/AGSyncKit/blob/master/SyncKitTests/SyncKitTests.m#L37-L61 > > -- > 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 > -- 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/20140121/84df41ca/attachment-0001.html From lholmqui at redhat.com Tue Jan 21 09:02:13 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 21 Jan 2014 09:02:13 -0500 Subject: [aerogear-dev] [iOS] Simple draft of HTTP API to talk to ag-sync server In-Reply-To: References: <23CE682F-AAE2-4F30-99C0-22731DFD2396@redhat.com> Message-ID: On Jan 21, 2014, at 8:57 AM, Matthias Wessendorf wrote: > > > > On Tue, Jan 21, 2014 at 2:45 PM, Lucas Holmquist wrote: > anyone have any thoughts on this? > > yes, sorry for the delay; pretty much aligned w/ the 'primitive' iOS API that we currently have (which was 'inspired' by your initial JS tests, on Dan's Server). > > Currently we are pretty much all (almost all) on the CouchDB design (including Erik Jan's server (not yet tested)). I guess so far this all makes sense. > Next interesting item would be a 'pushed' sync, using something like WebSocket/SockJS (not only on the JS side of things) > > @JsonDiffPatch: pretty interesting library, looks like does what we need on the (JS) client side yea, it is pretty nice when comparing/diffing objects and arrays > > -Matthias > > > > On Jan 15, 2014, at 3:31 PM, Lucas Holmquist wrote: > >> well, i've hacked something together for js here in this branch: https://github.com/lholmquist/aerogear-js/tree/AGJS-124 >> >> it is in no way complete, just some idea's. >> >> to run the tests here, you need to have dan's server running. >> >> i'm currently trying out https://github.com/benjamine/JsonDiffPatch to do the diff/patching during an update conflict, >> >> Here is a quick and dirty API that i was thinking could be a start, for JS at least >> >> // Create a New Data Sync Object >> >> var dataSync = AeroGear.DataSync( { syncServerUrl: "http://localhost:8080" } ); >> >> >> /* possibly more options here, like "auto-merge" >> options = { >> >> syncServerUrl: "link_to_sync_server", >> autoMerge: false, //optional, defaults to false? Not sure this is the right spot for this, maybe should be in the update call >> >> otheroptions: .... >> } >> */ >> >> >> // Probably have 3 Methods: read, save( Update ), remove >> // each one has 2 parameters, the "document" and the settings >> >> >> /* >> The document here is an object defined like in qmx's sync thought dump >> >> var document = { >> id: "123sjf2-i", >> content: { >> >> // Some Arbitrary JSON or an array or something serializable into JSON >> }, >> >> rev: "SOME_REVISION_ID" // or rev_id or revision or revision_id, we can argue over names later >> } >> >> */ >> >> dataSync.read( document, settings ); >> >> >> /* >> --READ-- >> >> >> var settings = { >> success: function( document ){}, // GET the document >> >> error: function( error ){} // an error happened GETting the document, like it can't be found or something >> } >> >> */ >> >> dataSync.save( document, settings ); >> >> >> /* >> --Save-- >> document can be either an array or an object >> >> if whatever is passed is in the form of the document specifed above, then save works as an "update" >> var settings: { >> >> autoMerge: // not sure if this should be here or in the constructor >> success: function( document ){} // successful PUT to create the document or update the document, >> >> conflict: function( error, current_model_from_server, delta_of_current_server_model_and_local_document ) // this delta thing should be nice and user friendly or something >> >> SOME_OTHER_SPECIFIC_CALLBACK: function(){}, // Maybe other callbacks for specific events >> error: function( error ){} // an error happened, catch-all ? >> >> } >> */ >> >> dataSync.remove( document, settings ); >> >> >> /* >> TBD >> */ >> >> >> >> >> On Jan 13, 2014, at 11:56 AM, Matthias Wessendorf wrote: >> >>> Hi, >>> >>> based on the ag.org "sync-branch" (see [1]), I created a SIMPLE first iOS hack of a "document" API with a HTTP client that talks to Dan's Server. >>> >>> The model ([2]) is quite easy/simple and the HTTP client supports CREATE/READ/REMOVE ([3]), based on the protocol defined on the README of the server. >>> >>> The usage is covered in a test (like [4]). >>> >>> Next: I guess next (if we continue using Dan's Server) is to see how this project can we weaved into the exisiting stores - but first I really wanted to get some client (like Luke's JS client) which executes against our current server draft/implementation. >>> >>> BTW. the lib is based on AFN2.x (not sure we should use AFN 2.x at THIS point - switching to 1.x should not be that hard) >>> >>> -Matthias >>> >>> [1] https://github.com/aerogear/aerogear.org/pull/230 >>> [2] https://github.com/matzew/AGSyncKit/blob/master/SyncKit/AGDocument.h >>> [3] https://github.com/matzew/AGSyncKit/blob/master/SyncKit/AGSyncClient.h >>> [4] https://github.com/matzew/AGSyncKit/blob/master/SyncKitTests/SyncKitTests.m#L37-L61 >>> >>> -- >>> 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 > > > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140121/83ec9a41/attachment.html From matzew at apache.org Tue Jan 21 09:07:10 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 21 Jan 2014 15:07:10 +0100 Subject: [aerogear-dev] [iOS] Simple draft of HTTP API to talk to ag-sync server In-Reply-To: References: Message-ID: Any thoughts on the iOS side of things ? -Matthias On Mon, Jan 13, 2014 at 5:56 PM, Matthias Wessendorf wrote: > Hi, > > based on the ag.org "sync-branch" (see [1]), I created a SIMPLE first iOS > hack of a "document" API with a HTTP client that talks to Dan's Server. > > The model ([2]) is quite easy/simple and the HTTP client supports > CREATE/READ/REMOVE ([3]), based on the protocol defined on the README of > the server. > > The usage is covered in a test (like [4]). > > Next: I guess next (if we continue using Dan's Server) is to see how this > project can we weaved into the exisiting stores - but first I really wanted > to get some client (like Luke's JS client) which executes against our > current server draft/implementation. > > BTW. the lib is based on AFN2.x (not sure we should use AFN 2.x at THIS > point - switching to 1.x should not be that hard) > > -Matthias > > [1] https://github.com/aerogear/aerogear.org/pull/230 > [2] https://github.com/matzew/AGSyncKit/blob/master/SyncKit/AGDocument.h > [3] https://github.com/matzew/AGSyncKit/blob/master/SyncKit/AGSyncClient.h > [4] > https://github.com/matzew/AGSyncKit/blob/master/SyncKitTests/SyncKitTests.m#L37-L61 > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- 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/20140121/36db1c09/attachment.html From tkriz at redhat.com Tue Jan 21 09:18:29 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Tue, 21 Jan 2014 15:18:29 +0100 Subject: [aerogear-dev] Should encrypted store fail to open when passphrase is wrong? In-Reply-To: References: <0F40D30B-3EF2-4531-A1BA-E302CBDC0166@redhat.com> Message-ID: <43C214A7-522F-4194-9975-DBA1390A6193@redhat.com> On 21 Jan 2014, at 13:54, Bruno Oliveira wrote: > > -- > abstractj > > On January 20, 2014 at 3:00:54 PM, Tadeas Kriz (tkriz at redhat.com) wrote: >> >> Hey, >> >> I know we?ve been discussing this before, but with no solution. >> I myself think, that the store should fail to open when the passphrase >> is wrong, because that?s where you?d like to have your ?try .. >> catch ..? to handle the problem, not elsewhere, when you want >> to actually read/write/delete from the store, that?s just not >> very user friendly. >> >> If the answer to that is YES, then the next question is, how to decide >> when the passphrase is right and when it isn?t. Again I?ll write > > Like I mentioned here (https://issues.jboss.org/browse/AGDROID-173), our goal to the very initial release was not to make anything perfect, but lay down the groundwork for encryption. So if you where you read ?Experimental?, by that means, not perfect. > > Offline authentication didn?t start yet, so that might happen. The API will be user friendly when become stable. On one side, the API for DataManager is considered stable, because changing it is postponed for version 2.0.0, but on the other hand it?s not stable? I?m a bit confused right now. I completely agree with the decision to not change the DataManager API before 2.0.0, but that means the API should be almost perfect and the implementation might not be as good, because the implementation can be improved overtime. >> more ways I?ve got on mind, that?d solve this. Important is, that >> none of them actually stores the passphrase! >> >> On each call of ?open()?: >> 1. do ?readAll()? to ensure the passphrase is right. Basically, >> that?s what user has to do now to find out if the passphrase is right. >> >> 2. read the first row and if the read is successful, then the passphrase >> is right. In this case, we?d have to be 100% sure that there is no >> way to put data into the store with different key and thus all the >> rows are encrypted with the same passphrase. > > We are aware of it, at the same time we didn?t add support for querying into the database. That?s planned, but not atm. Our focus was data encryption, optimizations will come with the next releases, for this reason a jiras like this existhttps://issues.jboss.org/browse/AGSEC-137 > I?m not talking about optimisations there. The whole problem is about developer?s experience. Like I wouldn?t like to have to add try .. catch .. everywhere I?d like to read/save/delete from encrypted database, that?s just not cool. >> >> 3. Save some metadata for each data model, that would be encrypted >> with the same passphrase and we?d read them and if successful, >> the passphrase is right. This has two possible implementations. >> >> a. The first row in the data model table would be reserved for the >> metadata, so the verification would work similarly to the option >> 2. >> >> b. There would be separate table, in which we?d add a row for each >> data model table. Again, very similar to a. but without the pain >> of having different data in the same table. Also, if the implementation >> of SQLStore will become multi-table (instead of multi-database >> which is now), there would be only one table for all the metadata. >> >> So, what do you think? > > Repeating what I said on that Jira, it seems too much. APIs like SQLCipher don?t do that. You can?t compare EncryptedSQLStore with SQLCipher. Completely different way of encryption. SQLCipher encrypts the database page by page (mostly chunks of 1024 bytes), but EncryptedSQLStore encrypts only the data row by row individually (check [1] for very simple comparsion). That?s completely different approach. This way you can find out if the passphrase is right by calling basically any SQL command and an exception will be thrown if it won?t succeed. That?s something that cannot be achieved with current EncryptedSQLStore implementation. The EncryptedSQLStore already saves IV and Salt in separate table. It wouldn?t be a problem, performance issue or space issue to add one more row, which the EncryptedSQLStore would try to decrypt and if successful, that?d mean the passphrase is correct. The value of that row might be just an encrypted JSON with random key and value. That way, you?d check if the decrypted is valid JSON. There should be no security issue with that, or is there? >> >> PS: For abstractj, I?ve been trying to find any library that would >> do the encryption on high-level, as AeroGear does, but couldn?t >> find any. There are many ways to encrypt SQLite database though >> they work on different approach of encrypting the whole database >> file, not just rows themselves. > > That?s the reason why we?ve been working on it. > I?m not saying ?don?t work on it?. I?m just trying to help, so it'll have added value for the user. >> >> ? >> Tadeas Kriz >> tkriz at redhat.com >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev 1 - http://i.imgur.com/u7WFNPJ.png -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140121/065f08a3/attachment-0001.html From bruno at abstractj.org Tue Jan 21 09:26:41 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 21 Jan 2014 12:26:41 -0200 Subject: [aerogear-dev] Should encrypted store fail to open when passphrase is wrong? In-Reply-To: <43C214A7-522F-4194-9975-DBA1390A6193@redhat.com> References: <0F40D30B-3EF2-4531-A1BA-E302CBDC0166@redhat.com> <43C214A7-522F-4194-9975-DBA1390A6193@redhat.com> Message-ID: -- abstractj On January 21, 2014 at 12:18:34 PM, Tadeas Kriz (tkriz at redhat.com) wrote: > > You can?t compare EncryptedSQLStore with SQLCipher. Completely Keep in mind that I never did that ;) ? > different way of encryption. SQLCipher encrypts the database > page by page (mostly chunks of 1024 bytes), but EncryptedSQLStore > encrypts only the data row by row individually (check [1] for > very simple comparsion). That?s completely different approach. > This way you can find out if the passphrase is right by calling > basically any SQL command and an exception will be thrown if it > won?t succeed. That?s something that cannot be achieved with > current EncryptedSQLStore implementation. The EncryptedSQLStore > already saves IV and Salt in separate table. It wouldn?t be a problem, > performance issue or space issue to add one more row, which the > EncryptedSQLStore would try to decrypt and if successful, that?d > mean the passphrase is correct. The value of that row might be > just an encrypted JSON with random key and value. That way, you?d > check if the decrypted is valid JSON. There should be no security > issue with that, or is there? I never mentioned ?security issue? in any kind of e-mail or Jira. From tkriz at redhat.com Tue Jan 21 09:29:20 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Tue, 21 Jan 2014 15:29:20 +0100 Subject: [aerogear-dev] Should encrypted store fail to open when passphrase is wrong? In-Reply-To: References: <0F40D30B-3EF2-4531-A1BA-E302CBDC0166@redhat.com> <43C214A7-522F-4194-9975-DBA1390A6193@redhat.com> Message-ID: <452813ED-BFDB-4AC6-9888-4AC726175D9F@redhat.com> ? Tadeas Kriz tkriz at redhat.com On 21 Jan 2014, at 15:26, Bruno Oliveira wrote: > > > -- > abstractj > > On January 21, 2014 at 12:18:34 PM, Tadeas Kriz (tkriz at redhat.com) wrote: >>> You can?t compare EncryptedSQLStore with SQLCipher. Completely > > Keep in mind that I never did that ;) Then I had to misunderstood the "APIs like SQLCipher don?t do that.?, sorry about that. >> different way of encryption. SQLCipher encrypts the database >> page by page (mostly chunks of 1024 bytes), but EncryptedSQLStore >> encrypts only the data row by row individually (check [1] for >> very simple comparsion). That?s completely different approach. >> This way you can find out if the passphrase is right by calling >> basically any SQL command and an exception will be thrown if it >> won?t succeed. That?s something that cannot be achieved with >> current EncryptedSQLStore implementation. The EncryptedSQLStore >> already saves IV and Salt in separate table. It wouldn?t be a problem, >> performance issue or space issue to add one more row, which the >> EncryptedSQLStore would try to decrypt and if successful, that?d >> mean the passphrase is correct. The value of that row might be >> just an encrypted JSON with random key and value. That way, you?d >> check if the decrypted is valid JSON. There should be no security >> issue with that, or is there? > > I never mentioned ?security issue? in any kind of e-mail or Jira. Then why would it be a problem? From matzew at apache.org Tue Jan 21 09:30:39 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 21 Jan 2014 15:30:39 +0100 Subject: [aerogear-dev] simple Java sync server In-Reply-To: <3CA6121A-60F0-4C8A-9B4A-CD208D594782@redhat.com> References: <3CA6121A-60F0-4C8A-9B4A-CD208D594782@redhat.com> Message-ID: Hello Erik, On Tue, Jan 21, 2014 at 10:43 AM, Erik Jan de Wit wrote: > Hi, > > Made a very simple Java version (based on hibernate) of the sync server. > I think JAX-RS is a good choice for (existing) Java EE applications. Grizzly/Jersey was just used as an example? Or was it meant to be 'embedded' ? In that case my choice would have been undertow-resteasy: ``` UndertowJaxrsServer undertow = new UndertowJaxrsServer(); undertow.deploy(my_JAX_RS_application); undertow.start(...); ``` Regarding the 'Car' entity: I am wondering if, on the server, something more like the API discussed in here would be possible: https://github.com/aerogear/aerogear.org/blob/data-sync/docs/specs/aerogear-data-sync/index.md#java So, we would have a @Entity for the 'Document', where the content field could be an 'embedded' entity/object; > It doesn?t merge so any change in a entity that is old will give a merge > conflict. It uses the same ?protocol? as couch so WDYT? > Regarding the 'couch-based protocol': In theory that means our current clients (e.g. iOS/JS) would work here too, assuming the JAX-RS server would be following the 'document' model, right? > > Cheers, > Erik Jan > > https://github.com/edewit/sync-server > > _______________________________________________ > 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/20140121/63f6f0e4/attachment.html From matzew at apache.org Tue Jan 21 09:31:30 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 21 Jan 2014 15:31:30 +0100 Subject: [aerogear-dev] simple Java sync server In-Reply-To: References: <3CA6121A-60F0-4C8A-9B4A-CD208D594782@redhat.com> Message-ID: On Tue, Jan 21, 2014 at 2:56 PM, Bruno Oliveira wrote: > Why not contribute to https://github.com/aerogear/aerogear-sync-server, > instead of create a new server implementation? > That's a good idea; similar to what already exists on the SimplePush Server, having an 'Hibernate' adapter on the Netty-Server would be a nice to test against as well; -Matthias > > > -- > abstractj > > On January 21, 2014 at 7:43:31 AM, Erik Jan de Wit (edewit at redhat.com) > wrote: > > > Hi, > > > > Made a very simple Java version (based on hibernate) of the sync > > server. It doesn?t merge so any change in a entity that is old will > > give a merge conflict. It uses the same ?protocol? as couch so > > WDYT? > > > > Cheers, > > Erik Jan > > > > https://github.com/edewit/sync-server > > > _______________________________________________ > 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/20140121/9675f4d5/attachment.html From bruno at abstractj.org Tue Jan 21 09:34:08 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 21 Jan 2014 12:34:08 -0200 Subject: [aerogear-dev] Should encrypted store fail to open when passphrase is wrong? In-Reply-To: <452813ED-BFDB-4AC6-9888-4AC726175D9F@redhat.com> References: <0F40D30B-3EF2-4531-A1BA-E302CBDC0166@redhat.com> <43C214A7-522F-4194-9975-DBA1390A6193@redhat.com> <452813ED-BFDB-4AC6-9888-4AC726175D9F@redhat.com> Message-ID: Because password validation and data encryption are completely different things, both features were planned and I don?t want to workaround it only because some feature still doesn?t exist.? -- abstractj On January 21, 2014 at 12:29:23 PM, Tadeas Kriz (tkriz at redhat.com) wrote: > > Then why would it be a problem? From tkriz at redhat.com Tue Jan 21 09:36:21 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Tue, 21 Jan 2014 15:36:21 +0100 Subject: [aerogear-dev] Should encrypted store fail to open when passphrase is wrong? In-Reply-To: References: <0F40D30B-3EF2-4531-A1BA-E302CBDC0166@redhat.com> <43C214A7-522F-4194-9975-DBA1390A6193@redhat.com> <452813ED-BFDB-4AC6-9888-4AC726175D9F@redhat.com> Message-ID: <3033CF95-DC60-496C-92CD-7E0DF3233398@redhat.com> ? Tadeas Kriz tkriz at redhat.com On 21 Jan 2014, at 15:34, Bruno Oliveira wrote: > Because password validation and data encryption are completely different things, both features were planned and I don?t want to workaround it only because some feature still doesn?t exist. > So, does that mean that when user calls ?open? on EncryptedSQLStore, he?ll get an exception if he used wrong passphrase (or for example keystore) ? > -- > abstractj > > On January 21, 2014 at 12:29:23 PM, Tadeas Kriz (tkriz at redhat.com) wrote: >>> Then why would it be a problem? > From bruno at abstractj.org Tue Jan 21 09:39:27 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 21 Jan 2014 12:39:27 -0200 Subject: [aerogear-dev] Should encrypted store fail to open when passphrase is wrong? In-Reply-To: <3033CF95-DC60-496C-92CD-7E0DF3233398@redhat.com> References: <0F40D30B-3EF2-4531-A1BA-E302CBDC0166@redhat.com> <43C214A7-522F-4194-9975-DBA1390A6193@redhat.com> <452813ED-BFDB-4AC6-9888-4AC726175D9F@redhat.com> <3033CF95-DC60-496C-92CD-7E0DF3233398@redhat.com> Message-ID: Yes, we are under the data encryption domain right? Either way you are free to suggest whatever you think is ideal for you, if the team agree on that, I would respect their decision. Even if it doesn?t sound right for me. -- abstractj On January 21, 2014 at 12:36:24 PM, Tadeas Kriz (tkriz at redhat.com) wrote: > > So, does that mean that when user calls ?open? on EncryptedSQLStore, > he?ll get an exception if he used wrong passphrase (or for example > keystore) ? From edewit at redhat.com Tue Jan 21 09:44:57 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Tue, 21 Jan 2014 15:44:57 +0100 Subject: [aerogear-dev] simple Java sync server In-Reply-To: References: <3CA6121A-60F0-4C8A-9B4A-CD208D594782@redhat.com> Message-ID: <36FC464E-2B97-41F9-B0EE-7C7B3AFA0BF9@redhat.com> On 21 Jan,2014, at 15:30 , Matthias Wessendorf wrote: > Hello Erik, > > > On Tue, Jan 21, 2014 at 10:43 AM, Erik Jan de Wit wrote: > Hi, > > Made a very simple Java version (based on hibernate) of the sync server. > > I think JAX-RS is a good choice for (existing) Java EE applications. > > Grizzly/Jersey was just used as an example? Or was it meant to be 'embedded' ? In that case my choice would have been undertow-resteasy: > It was just meant for testing > ``` > UndertowJaxrsServer undertow = new UndertowJaxrsServer(); > undertow.deploy(my_JAX_RS_application); > undertow.start(...); > ``` > > > Regarding the 'Car' entity: I am wondering if, on the server, something more like the API discussed in here would be possible: > https://github.com/aerogear/aerogear.org/blob/data-sync/docs/specs/aerogear-data-sync/index.md#java > > > So, we would have a @Entity for the 'Document', where the content field could be an 'embedded' entity/object; right, I now just use version number instead of revision, let?s see fi I can get the more align > > > > It doesn?t merge so any change in a entity that is old will give a merge conflict. It uses the same ?protocol? as couch so WDYT? > > Regarding the 'couch-based protocol': In theory that means our current clients (e.g. iOS/JS) would work here too, assuming the JAX-RS server would be following the 'document' model, right? > > > Cheers, > Erik Jan > > https://github.com/edewit/sync-server > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140121/34ec40e8/attachment.html From tkriz at redhat.com Tue Jan 21 09:46:50 2014 From: tkriz at redhat.com (Tadeas Kriz) Date: Tue, 21 Jan 2014 15:46:50 +0100 Subject: [aerogear-dev] Should encrypted store fail to open when passphrase is wrong? In-Reply-To: References: <0F40D30B-3EF2-4531-A1BA-E302CBDC0166@redhat.com> <43C214A7-522F-4194-9975-DBA1390A6193@redhat.com> <452813ED-BFDB-4AC6-9888-4AC726175D9F@redhat.com> <3033CF95-DC60-496C-92CD-7E0DF3233398@redhat.com> Message-ID: <678FFB23-3B38-4685-9761-E37368BD7523@redhat.com> Right, the whole time all I was trying to agree on is that the user should know that the EncryptedSQLStore can?t decrypt the data inside it with the passphrase (or any other authentication method) when trying to open the store and not on ?read? like it?s now. All my suggestions were how that could be done and it seems that you have just another solution for that. As I see it, we?ve just misunderstood each other (or it might be just on my side). To wrap it up, if there are plans that EncryptedSQLStore#open would be the method to throw InvalidKeyException and not other methods (well, of course other methods might be throwing this too, but that?d be just in some corner cases in which the database was tampered after it was already opened), I?m all good with that. ? Tadeas Kriz tkriz at redhat.com On 21 Jan 2014, at 15:39, Bruno Oliveira wrote: > Yes, we are under the data encryption domain right? > > Either way you are free to suggest whatever you think is ideal for you, if the team agree on that, I would respect their decision. Even if it doesn?t sound right for me. > > -- > abstractj > > On January 21, 2014 at 12:36:24 PM, Tadeas Kriz (tkriz at redhat.com) wrote: >>> So, does that mean that when user calls ?open? on EncryptedSQLStore, >> he?ll get an exception if he used wrong passphrase (or for example >> keystore) ? > From matzew at apache.org Tue Jan 21 10:22:17 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 21 Jan 2014 16:22:17 +0100 Subject: [aerogear-dev] simple Java sync server In-Reply-To: <36FC464E-2B97-41F9-B0EE-7C7B3AFA0BF9@redhat.com> References: <3CA6121A-60F0-4C8A-9B4A-CD208D594782@redhat.com> <36FC464E-2B97-41F9-B0EE-7C7B3AFA0BF9@redhat.com> Message-ID: On Tue, Jan 21, 2014 at 3:44 PM, Erik Jan de Wit wrote: > > On 21 Jan,2014, at 15:30 , Matthias Wessendorf wrote: > > Hello Erik, > > > On Tue, Jan 21, 2014 at 10:43 AM, Erik Jan de Wit wrote: > >> Hi, >> >> Made a very simple Java version (based on hibernate) of the sync server. >> > > I think JAX-RS is a good choice for (existing) Java EE applications. > > Grizzly/Jersey was just used as an example? Or was it meant to be > 'embedded' ? In that case my choice would have been undertow-resteasy: > > > It was just meant for testing > > ``` > UndertowJaxrsServer undertow = new UndertowJaxrsServer(); > undertow.deploy(my_JAX_RS_application); > undertow.start(...); > ``` > > > Regarding the 'Car' entity: I am wondering if, on the server, something > more like the API discussed in here would be possible: > > https://github.com/aerogear/aerogear.org/blob/data-sync/docs/specs/aerogear-data-sync/index.md#java > > > > So, we would have a @Entity for the 'Document', where the content field > could be an 'embedded' entity/object; > > > right, I now just use version number instead of revision, let?s see fi I > can get the more align > A hibernate adapter for the Netty-Server would be nice as well, especially since all the HTTP part has been already there, would be just a matter of plugin in a different store > > > > > >> It doesn?t merge so any change in a entity that is old will give a merge >> conflict. It uses the same ?protocol? as couch so WDYT? >> > > Regarding the 'couch-based protocol': In theory that means our current > clients (e.g. iOS/JS) would work here too, assuming the JAX-RS server would > be following the 'document' model, right? > > >> >> Cheers, >> Erik Jan >> >> https://github.com/edewit/sync-server >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140121/241199cf/attachment.html From hbons at redhat.com Tue Jan 21 10:57:03 2014 From: hbons at redhat.com (Hylke Bons) Date: Tue, 21 Jan 2014 15:57:03 +0000 Subject: [aerogear-dev] Website restructure In-Reply-To: <79689455-DBA9-430A-BB2F-68D02F706E09@redhat.com> References: <5277BC35.5070300@redhat.com> <79689455-DBA9-430A-BB2F-68D02F706E09@redhat.com> Message-ID: <52DE98CF.9000209@redhat.com> Hi Jay, On 25/11/2013 14:41, Jay Balunas wrote: > Hi All, > > I'm just going to reply to the original email. There has been some good discussions in the thread though and for the most part I agree with other emails. > > Most of my comments will be inline, but in general: > > I like the idea of using colors and lots of your ideas around APIs, doc areas, etc... My main concern is about drastically changing the current site as we've had several redesigns ( a couple before you came, and then you last one, and this proposed on). I'd like to make sure we explore integrating some of your ideas, but keeping core aerogear.org site mostly intact. So lets work on color scheme's, content updates, API/coding presentations, etc... within the context of the current site if at all possible. What do you mean exactly by "core aerogear.org"? I'm not really sure if you're talking about the graphical design or the structure here. I'm assuming the latter, just making sure. > As I mention I really do like the color coding, and especially being use-case driven. I also agree with corrine that on the home page I'd like to make sure we keep the platform icons (I like those a lot as well), but perhaps work in use-cases (below, above, etc...), or use case drive in the sub-pages? > >> I've done a lot of research on the project, but some things may be >> wrong. So your feedback on that would be greatly appreciated. Even after >> spending many months with the project, I still don't fully grasp >> everything (which shows part of the problem). >> >> 1. Naming >> I've split up the project into three main subprojects: "AeroGear Core", >> "AeroGear Push", and "AeroGear Security". These three are the main focus >> and use different icons and colour codings throughout the website to >> guide people. Each subproject has "client" and "server" components. >> Server pieces being appended by "Server Component" and may be standalone >> or an addin to something. Client (API) pieces follow "Project.Namespace" >> format. This way, there's never any confusion about what we're talking >> about in the documentation and marketing materials. >> > +1 on color scheme - and agree with server/client aspects of each. We really have 2 matrixes here; platform (iOS, Android, etc..) & feature (use-case) perhaps there is a paradigm or structure to showing both somehow? If all libraries work on all platforms then I don't we don't think we need something like this (we just need to mention which platforms are available). If not, then yes, we need to somehow present that in a way that doesn't conflict with the bigger picture. This is what I meant with the library-platform mapping. As said, I' not really at home with all the libraries. >> 2. Documentation >> Splitting up documentation. "documentation" can be a broad term. I >> suggest splitting it up in three parts to easily find what you're >> looking for: "Setting up" (downloading and boatstrapping a dev >> environment), "Examples" (how to use the API in your environment to get >> started), "API Documentation" (speaks for itself), and "Tutorials" >> (setting up more complex environments and API usage). This covers most >> of the documentation that is currently on aerogear.org and will make it >> a lot easier to browse. > +100 our doc sections needs a good cleaning, organizing, and a better way to navigate and view. I'm so glad you agree with this! Apart from the subprojects presentation I think this is the point on which we can benefit the most. I already saw Erik has made some great headway this. Also, it's probably the biggest task ahead of us site-wise... >> 3. Coding languages >> Where the API is unified across all platforms (hopefully most of it), we >> can generalise example docs, and show a switcher for code blocks that >> shows how to do a certain thing in a particular language using the >> AeroGear API. > +1 I like the idea of common docs, with some context switch ability to shift platform. This will not always be possible but I think it could be on many of our features. It might also help point out issues or mis-matches between libraries. > >> 4. 1:1 mappings >> I'd like to see the iOS, Android and Javscript APIs be self-contained >> things that you can just drop in and use, with 1:1 mappings (what you >> get on Android for a (sub)project, is what you get on iOS). There could >> be technical reasons why these things are split up the way they are now, >> let me know if so. I could be totally wrong on this too. > As above there is not always a 1:1 mapping. Can we figure out a list which these are? This way I can figure out how we can present the exception without distracting from the bigger picture. >> Missing pieces: >> - Where do we fit in Cordova? > As Erik said - Cordova is a another core platform and should be featured. I'll be on that. >> - AeroGear Auth, Controller? >> >> These are things I'm not sure yet how they would fit in the proposed scheme. >> >> I think this is a step in the right direction, and I really hope it is >> helpful. Let's iterate on this. Let me know what you think and how we >> can improve. Looking forward to hear your opinions on this. > Good stuff Hylke, and sorry for the delay getting back to you! Sorry for the delay as well. ;) Thanks, Hylke > >> Thanks, >> >> Hylke >> _______________________________________________ >> 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 jbalunas at redhat.com Tue Jan 21 17:10:31 2014 From: jbalunas at redhat.com (Jay Balunas) Date: Tue, 21 Jan 2014 17:10:31 -0500 Subject: [aerogear-dev] Keycloak integration ideas In-Reply-To: References: Message-ID: On Jan 19, 2014, at 10:18 AM, Matthias Wessendorf wrote: > > > > On Fri, Jan 17, 2014 at 10:04 PM, Jay Balunas wrote: > Hi All, > > Sorry all - book mode ;-) > > We've had a couple of threads around keycloak integration (thanks Abstractj) and working together with them (both in our dev list and theirs). I had a meeting (dinner really) with Bill and talked about some possibilities and we're both excited to see what can happen. > > I wanted to capture some of those thoughts here (as well as some that already started before), have some discussions, and more importantly talk about next steps (jira's) to get some of this in the pipeline. I'm sure this is not exhaustive either, so please add your own thoughts, brainstorming etc... (for example Cordova plugin perhaps?) > > *In no particular order > > A) AeroGear security integration > ** Abstractj already posted and implemented some of these changes > ** http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Keycloak-on-AeroGear-td5663.html > ** What's left here? Is it plug-able? Does it need to be? > > The work started by Bruno looks promising. I like that for the login to the UPS Admin UI is being forwarded to the Keycloak server. > As mentioned on the referenced thread, there is a bit of more work needed for the "protection" of the SEND (and likely device registration) URLs. > > > B) Crypto key management > ** Server-side encryption key management for client crypto > ** Abstractj had some discussions here > *** http://lists.jboss.org/pipermail/keycloak-dev/2013-December/000915.html > *** Where does that stand? > ** Do we need our own impl as well? > > C) UnifiedPush server integration > ** User management, Auth* > ** Do we have our own basic impl for quickstart experience? > ** See below for possible combined cartridge options > > yep, the UPS come in mind and as mentioned in A) Bruno was already actively starting this shortly before XMAS. > > > > D) Cross-project examples, tutorials, docs, etc... > ** TBD > > Sure, combined docs/tutorials/examples are a good item once we do have a bit more :-) Not sure it makes much sense now, but I can be wrong Completely agree now is not the time. Just wanted to bring it up for discussion. > > > KeyCloak has some things they need as well, that we could work together on. I'm sure the KeyCloak team could add more here :-) > > Z) Device support > ** We need it, they need, and others need it > ** Bill would like us to help them (and us at the same time) with this. > > yeah - that would be an extremely good fit for our Push efforts. We'll need someone to setup a mtg, or discuss on the topic. Any takers? > > > Y) OpenShift Cartridge for KeyCloak > ** I know this is already on their roadmap > ** The work Farah and others has already done, could be very helpful to them > ** We should also discuss the possibility of a joint cartridge > *** Could be really compelling, especially if you add in device, client key, and push support with native SDKs & examples > *** Would also want separate cartridges as well imo > > yeah, I see various options here: > * 'standalone' Keycloak cartridge (on their roadmap already); Would be nice to get Farah involved here as well > * combined cartridge (E.g. Push + Keycloak). If we do actually fully integrate Keycloak into the Push work, IMO this is a required option, to simply include the Keycloak offerings into our Push Cartridge Agreed, and I'd like to hear from the keycloak team on this as well. If they have plans for pairing their cartridge with others. > > > X) Client SDK support > ** We have client SDKs & could help with their dev (either as part of AeroGear or KeyCloak perhaps) > ** Primarily for iOS & Android, but would also want see where JS & Cordova fit. > > Yes, another good integration item, would be interesting to know their 'requirements'. I think our OAuth2 related work, would be something that's interesting for them as well +1 > > > You start putting all of this together and there is a great set of functionality that really compliments each other well. After we discuss for a while, I'd like to find owners for the various items to help make progress on these. Abstractj is awesome, but not sure he can do it all ;-) > > yes, great work by Bruno w/ getting actively started on this +1 > > > > -Jay > > PS: I'll post an email to the keycloak-dev list as well pointing to this thread on our list. > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140121/f94f53f7/attachment.html From matzew at apache.org Wed Jan 22 02:41:10 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 22 Jan 2014 08:41:10 +0100 Subject: [aerogear-dev] Keycloak integration ideas In-Reply-To: References: Message-ID: On Tue, Jan 21, 2014 at 11:10 PM, Jay Balunas wrote: > > On Jan 19, 2014, at 10:18 AM, Matthias Wessendorf > wrote: > > > > > On Fri, Jan 17, 2014 at 10:04 PM, Jay Balunas wrote: > >> Hi All, >> >> Sorry all - book mode ;-) >> >> We've had a couple of threads around keycloak integration (thanks >> Abstractj) and working together with them (both in our dev list and >> theirs). I had a meeting (dinner really) with Bill and talked about some >> possibilities and we're both excited to see what can happen. >> >> I wanted to capture some of those thoughts here (as well as some that >> already started before), have some discussions, and more importantly talk >> about next steps (jira's) to get some of this in the pipeline. I'm sure >> this is not exhaustive either, so please add your own thoughts, >> brainstorming etc... (for example Cordova plugin perhaps?) >> >> *In no particular order >> >> A) AeroGear security integration >> ** Abstractj already posted and implemented some of these changes >> ** >> http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Keycloak-on-AeroGear-td5663.html >> ** What's left here? Is it plug-able? Does it need to be? >> > > The work started by Bruno looks promising. I like that for the login to > the UPS Admin UI is being forwarded to the Keycloak server. > As mentioned on the referenced thread, there is a bit of more work needed > for the "protection" of the SEND (and likely device registration) URLs. > > >> B) Crypto key management >> ** Server-side encryption key management for client crypto >> ** Abstractj had some discussions here >> *** >> http://lists.jboss.org/pipermail/keycloak-dev/2013-December/000915.html >> *** Where does that stand? >> ** Do we need our own impl as well? >> >> C) UnifiedPush server integration >> ** User management, Auth* >> ** Do we have our own basic impl for quickstart experience? >> ** See below for possible combined cartridge options >> > > yep, the UPS come in mind and as mentioned in A) Bruno was already > actively starting this shortly before XMAS. > > > >> >> D) Cross-project examples, tutorials, docs, etc... >> ** TBD >> > > Sure, combined docs/tutorials/examples are a good item once we do have a > bit more :-) Not sure it makes much sense now, but I can be wrong > > > Completely agree now is not the time. Just wanted to bring it up for > discussion. > > > >> >> KeyCloak has some things they need as well, that we could work together >> on. I'm sure the KeyCloak team could add more here :-) >> >> Z) Device support >> ** We need it, they need, and others need it >> ** Bill would like us to help them (and us at the same time) with this. >> > > yeah - that would be an extremely good fit for our Push efforts. > > > We'll need someone to setup a mtg, or discuss on the topic. Any takers? > I can reach out to them, via mailing list, to see what they are up to, regarding "Device support". Not 100% sure which email list is the 'right' choice (cross-postings are IMO a PITA :)) > > > >> >> Y) OpenShift Cartridge for KeyCloak >> ** I know this is already on their roadmap >> ** The work Farah and others has already done, could be very helpful to >> them >> ** We should also discuss the possibility of a joint cartridge >> *** Could be really compelling, especially if you add in device, client >> key, and push support with native SDKs & examples >> *** Would also want separate cartridges as well imo >> > > yeah, I see various options here: > * 'standalone' Keycloak cartridge (on their roadmap already); Would be > nice to get Farah involved here as well > * combined cartridge (E.g. Push + Keycloak). If we do actually fully > integrate Keycloak into the Push work, IMO this is a required option, to > simply include the Keycloak offerings into our Push Cartridge > > > Agreed, and I'd like to hear from the keycloak team on this as well. If > they have plans for pairing their cartridge with others. > On their list they are currently talking about standalone ones, but later, we might be able to integrate w/ their server piece. > > > >> >> X) Client SDK support >> ** We have client SDKs & could help with their dev (either as part of >> AeroGear or KeyCloak perhaps) >> ** Primarily for iOS & Android, but would also want see where JS & >> Cordova fit. >> > > Yes, another good integration item, would be interesting to know their > 'requirements'. I think our OAuth2 related work, would be something that's > interesting for them as well > > > +1 > > > >> >> You start putting all of this together and there is a great set of >> functionality that really compliments each other well. After we discuss >> for a while, I'd like to find owners for the various items to help make >> progress on these. Abstractj is awesome, but not sure he can do it all ;-) >> > > yes, great work by Bruno w/ getting actively started on this > > > +1 > > > > >> >> -Jay >> >> PS: I'll post an email to the keycloak-dev list as well pointing to this >> thread on our list. >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140122/9d700129/attachment-0001.html From matzew at apache.org Wed Jan 22 03:57:47 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 22 Jan 2014 09:57:47 +0100 Subject: [aerogear-dev] [UnifiedPush] Query component issues with 'deviceType' for simplepush clients Message-ID: Howdy! Going over the code I recalled that right now we somewhat nail the device-type for SimplePush clients down to just 'web' (see [1] and [2]). However w/ the new Java-Client, [3], (e.g. for desktop environments) it would be pretty stupid to 'require' the 'web' there as well. Instead of coming up w/ something else, I'd propose handle it like we do Android/iOS. Basically: Feel free to register your device with a device-type what ever you are up to; Use the same for the sending/querying part, if it fits your backend/model. Any thoughts? Greetings, Matthias [1] https://github.com/aerogear/aerogear.org/blob/master/docs/specs/aerogear-push-messages/index.markdown#query-component [2] https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/main/java/org/jboss/aerogear/unifiedpush/service/sender/impl/SenderServiceImpl.java#L157 [3] https://github.com/aerogear/aerogear-simplepush-java-client -- 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/20140122/f6002327/attachment.html From scm.blanc at gmail.com Wed Jan 22 04:11:07 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 22 Jan 2014 10:11:07 +0100 Subject: [aerogear-dev] [UnifiedPush] Query component issues with 'deviceType' for simplepush clients In-Reply-To: References: Message-ID: +1 Make totally sense On Wed, Jan 22, 2014 at 9:57 AM, Matthias Wessendorf wrote: > Howdy! > > Going over the code I recalled that right now we somewhat nail the > device-type for SimplePush clients down to just 'web' (see [1] and [2]). > > However w/ the new Java-Client, [3], (e.g. for desktop environments) it > would be pretty stupid to 'require' the 'web' there as well. > > Instead of coming up w/ something else, I'd propose handle it like we do > Android/iOS. > Basically: Feel free to register your device with a device-type what ever > you are up to; Use the same for the sending/querying part, if it fits your > backend/model. > > Any thoughts? > > Greetings, > Matthias > > > [1] > https://github.com/aerogear/aerogear.org/blob/master/docs/specs/aerogear-push-messages/index.markdown#query-component > [2] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/main/java/org/jboss/aerogear/unifiedpush/service/sender/impl/SenderServiceImpl.java#L157 > [3] https://github.com/aerogear/aerogear-simplepush-java-client > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140122/d6dc2ef0/attachment.html From aemmanou at redhat.com Wed Jan 22 04:41:05 2014 From: aemmanou at redhat.com (Apostolos Emmanouilidis) Date: Wed, 22 Jan 2014 04:41:05 -0500 (EST) Subject: [aerogear-dev] aerogear-js Mozilla's Persona authentication adapter In-Reply-To: <734665923.4117587.1390383478992.JavaMail.root@redhat.com> References: <734665923.4117587.1390383478992.JavaMail.root@redhat.com> Message-ID: <1126554180.4118114.1390383665653.JavaMail.root@redhat.com> hello, while looking at AGJS-122 and the possibility to add an authentication adapter which is based on Mozilla's Persona sign-in system, I was thinking of the following API: // Construct an AeroGear.Authentication.adapters.Persona var persona = AeroGear.Auth({ name: 'persona', type: 'Persona', settings: { verificationEndpoint: "http://127.0.0.1:3000/verify" } }).modules.persona; // use login to initiate the Mozilla's Persona authentication procedure. login enables the BrowserID and generates a signed assertion which contains the user's email address // on assertion generation call the verification service persona.login({ onAssertion: function ( assertion ) { // the verification API receives the assertion and the audience (our website URL) as parameters // for security reasons there must be an intermediate service between the client and the verification API. the reason for which we want the intermediate service // is that we want to ensure that the audience parameter is not hacked. I was thinking that it is better to avoid adding the persona.verify call inside our adapter // since this way we would force the user to create the intermediate service according our implementation. That's why the following line exists: persona.verify( { assertion: assertion }, { success: onSuccessVerification, error: onFailedVerification } ); }, error: onLoginError }); // logout persona.logout( onLogout ); I have added a working example in: https://github.com/tolis-e/aerogear-js-persona-authentication-poc and a first implementation sample: https://github.com/aerogear/aerogear-js/pull/100 In order you'd like to try the working example on Android emulator, change lines: https://github.com/tolis-e/aerogear-js-persona-authentication-poc/blob/master/static/persona-test.html#L16 and https://github.com/tolis-e/aerogear-js-persona-authentication-poc/blob/master/server.js#L29 to use host 10.0.2.2 and open the http://10.0.2.2:3000/persona-test.html page on the Android browser any thoughts, suggestions? From scm.blanc at gmail.com Wed Jan 22 05:26:16 2014 From: scm.blanc at gmail.com (Sebastien Blanc) Date: Wed, 22 Jan 2014 11:26:16 +0100 Subject: [aerogear-dev] [UPS] User Management - open items / following up Message-ID: Hi, Since the User Management PR has been submitted [1] there has been of a lot of useful and interesting feedback, thanks Matzew and Abstractj for that. Some valid concerns has been raised, in particular 2 of them that I would like to expose here and to discuss to see how we can deal witth them for the 0.10.0 release : 1. Currently the password register/reset link that is generated is persisted. This is a point of concern[2]. The fact is that with the current flow, we can not go against that: - An admin create an user, a link is generated. - The admin send this link to the new user. - The user browse to link -> at this moment we need to be able to retrieve the stored link to check for its validity. Some points : - The token/register link is presisted without any relation with the newly created user, so an hacker could not make a connection between the 2. - The new created user, as long he has not registered through the link, can not log into the system as he has no password, as Bruno suggested me to do on the ML. How shall we deal with that for 0.10.0 ? We can improve in 0.11.0 and also keeping in mind that keycloak could come into the party quite soon. 2. Currently, to generate the register link, we use a private key. This key is located in the project[3]. This should not be in the github project as pointed by Bruno [4] which make totally sense. I will remove the private key from the repo and add instructions to tell how and where to put your private key. But I don't know how to deal for the UPS cartdridge, since we ship a war, the private key will be missing. Any ideas input on that is welcome. For 0.10.0, we could just ship a war containing a private key and add a warning and maybe add instruction on how to clone the app locally, change the key and push again (which is not really user friendly when you expect to have a cartdridge that "just work"). Notice that there is ticket to be able to manage your private key from the Admin console[5] Again, in the future, keycloak could be used also to manage the keys. Besides that, the current PR, in terms of functionnalities works : you can create and manage users like specified in the specs. So for the (very soon) 0.10.0 release how shall we deal with these concerns ? Sebi [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/118 [2] https://github.com/aerogear/aerogear-unifiedpush-server/pull/118#discussion_r8996725 [3] https://github.com/aerogear/aerogear-unifiedpush-server/blob/register_link/src/main/resources/META-INF/config.properties [4] https://github.com/aerogear/aerogear-unifiedpush-server/pull/118#discussion_r8996712 [5] https://issues.jboss.org/browse/AGPUSH-518 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140122/70396f3b/attachment.html From edewit at redhat.com Wed Jan 22 05:38:49 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Wed, 22 Jan 2014 11:38:49 +0100 Subject: [aerogear-dev] simple Java sync server In-Reply-To: References: <3CA6121A-60F0-4C8A-9B4A-CD208D594782@redhat.com> Message-ID: Right good point, at the time of writing Dan?s server didn?t exist, but now I could submit it as an alternative implementation. I?ll do that now. On 21 Jan,2014, at 14:56 , Bruno Oliveira wrote: > Why not contribute to https://github.com/aerogear/aerogear-sync-server, instead of create a new server implementation? > > > -- > abstractj > > On January 21, 2014 at 7:43:31 AM, Erik Jan de Wit (edewit at redhat.com) wrote: >>> Hi, >> >> Made a very simple Java version (based on hibernate) of the sync >> server. It doesn?t merge so any change in a entity that is old will >> give a merge conflict. It uses the same ?protocol? as couch so >> WDYT? >> >> Cheers, >> Erik Jan >> >> https://github.com/edewit/sync-server > From matzew at apache.org Wed Jan 22 05:50:49 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 22 Jan 2014 11:50:49 +0100 Subject: [aerogear-dev] [UnifiedPush] Query component issues with 'deviceType' for simplepush clients In-Reply-To: References: Message-ID: On Wed, Jan 22, 2014 at 10:11 AM, Sebastien Blanc wrote: > +1 Make totally sense > Thanks for the feedback; Created a JIRA (w/ an attached PR), based on this thread: https://issues.jboss.org/browse/AGPUSH-522 -M > > On Wed, Jan 22, 2014 at 9:57 AM, Matthias Wessendorf wrote: > >> Howdy! >> >> Going over the code I recalled that right now we somewhat nail the >> device-type for SimplePush clients down to just 'web' (see [1] and [2]). >> >> However w/ the new Java-Client, [3], (e.g. for desktop environments) it >> would be pretty stupid to 'require' the 'web' there as well. >> >> Instead of coming up w/ something else, I'd propose handle it like we do >> Android/iOS. >> Basically: Feel free to register your device with a device-type what ever >> you are up to; Use the same for the sending/querying part, if it fits your >> backend/model. >> >> Any thoughts? >> >> Greetings, >> Matthias >> >> >> [1] >> https://github.com/aerogear/aerogear.org/blob/master/docs/specs/aerogear-push-messages/index.markdown#query-component >> [2] >> https://github.com/aerogear/aerogear-unifiedpush-server/blob/master/src/main/java/org/jboss/aerogear/unifiedpush/service/sender/impl/SenderServiceImpl.java#L157 >> [3] https://github.com/aerogear/aerogear-simplepush-java-client >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140122/584c936a/attachment-0001.html From stian at redhat.com Wed Jan 22 06:40:21 2014 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 22 Jan 2014 06:40:21 -0500 (EST) Subject: [aerogear-dev] Keycloak integration ideas In-Reply-To: References: Message-ID: <1879733740.8801251.1390390821039.JavaMail.root@redhat.com> It's great to see interest in the Keycloak project :) We've been quite busy with getting the alpha out the door (hopefully it'll be released tomorrow) hence the lack of response. Also, I don't think Bill follows aerogear-dev. Would be good to start discussions on these items, maybe as separate posts to keycloak-dev? A few thoughts from me: * We've got a quick and dirty OpenShift cartridge (https://github.com/keycloak/openshift-keycloak-cartridge) - it's based on the WildFly cartridge by Corey Daley. Seems to work pretty well and took me about an hour to do the mods. I was considering if it was possible to do the Keycloak and UPS cartridges as add-ons to the WildFly cartridge (same as postgresql and mysql cartridges). That way you can mix and match whatever combo you want. A specific cartridge may provide a better integrated experience though. Maybe we can ping someone in the OpenShift team to find out the correct approach? * Mobile SDKs - There's not much effort yet on supporting mobiles. Maybe you could help us with creating Keycloak SDKs, with most of the code reusable in AeroGear and LiveOak? * JS - None in Keycloak, but I've started one in LiveOak. Again, could we do a Keycloak JS lib that could be reused by AeroGear and LiveOak? If you have any issues/questions at all post to keycloak-dev and I'm sure me and Bill will fight to see how gets to answer first ;) ----- Original Message ----- > From: "Matthias Wessendorf" > To: "AeroGear Developer Mailing List" > Sent: Wednesday, 22 January, 2014 7:41:10 AM > Subject: Re: [aerogear-dev] Keycloak integration ideas > > > > > On Tue, Jan 21, 2014 at 11:10 PM, Jay Balunas < jbalunas at redhat.com > wrote: > > > > > On Jan 19, 2014, at 10:18 AM, Matthias Wessendorf < matzew at apache.org > > wrote: > > > > > > > > On Fri, Jan 17, 2014 at 10:04 PM, Jay Balunas < jbalunas at redhat.com > wrote: > > > > Hi All, > > Sorry all - book mode ;-) > > We've had a couple of threads around keycloak integration (thanks Abstractj) > and working together with them (both in our dev list and theirs). I had a > meeting (dinner really) with Bill and talked about some possibilities and > we're both excited to see what can happen. > > I wanted to capture some of those thoughts here (as well as some that already > started before), have some discussions, and more importantly talk about next > steps (jira's) to get some of this in the pipeline. I'm sure this is not > exhaustive either, so please add your own thoughts, brainstorming etc... > (for example Cordova plugin perhaps?) > > *In no particular order > > A) AeroGear security integration > ** Abstractj already posted and implemented some of these changes > ** > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Keycloak-on-AeroGear-td5663.html > ** What's left here? Is it plug-able? Does it need to be? > > The work started by Bruno looks promising. I like that for the login to the > UPS Admin UI is being forwarded to the Keycloak server. > As mentioned on the referenced thread, there is a bit of more work needed for > the "protection" of the SEND (and likely device registration) URLs. > > > > > > B) Crypto key management > ** Server-side encryption key management for client crypto > ** Abstractj had some discussions here > *** http://lists.jboss.org/pipermail/keycloak-dev/2013-December/000915.html > *** Where does that stand? > ** Do we need our own impl as well? > > C) UnifiedPush server integration > ** User management, Auth* > ** Do we have our own basic impl for quickstart experience? > ** See below for possible combined cartridge options > > yep, the UPS come in mind and as mentioned in A) Bruno was already actively > starting this shortly before XMAS. > > > > > > D) Cross-project examples, tutorials, docs, etc... > ** TBD > > Sure, combined docs/tutorials/examples are a good item once we do have a bit > more :-) Not sure it makes much sense now, but I can be wrong > > Completely agree now is not the time. Just wanted to bring it up for > discussion. > > > > > > > > > KeyCloak has some things they need as well, that we could work together on. > I'm sure the KeyCloak team could add more here :-) > > Z) Device support > ** We need it, they need, and others need it > ** Bill would like us to help them (and us at the same time) with this. > > yeah - that would be an extremely good fit for our Push efforts. > > We'll need someone to setup a mtg, or discuss on the topic. Any takers? > > I can reach out to them, via mailing list, to see what they are up to, > regarding "Device support". Not 100% sure which email list is the 'right' > choice (cross-postings are IMO a PITA :)) > > > > > > > > > > > > > Y) OpenShift Cartridge for KeyCloak > ** I know this is already on their roadmap > ** The work Farah and others has already done, could be very helpful to them > ** We should also discuss the possibility of a joint cartridge > *** Could be really compelling, especially if you add in device, client key, > and push support with native SDKs & examples > *** Would also want separate cartridges as well imo > > yeah, I see various options here: > * 'standalone' Keycloak cartridge (on their roadmap already); Would be nice > to get Farah involved here as well > * combined cartridge (E.g. Push + Keycloak). If we do actually fully > integrate Keycloak into the Push work, IMO this is a required option, to > simply include the Keycloak offerings into our Push Cartridge > > Agreed, and I'd like to hear from the keycloak team on this as well. If they > have plans for pairing their cartridge with others. > > On their list they are currently talking about standalone ones, but later, we > might be able to integrate w/ their server piece. > > > > > > > > > > > > X) Client SDK support > ** We have client SDKs & could help with their dev (either as part of > AeroGear or KeyCloak perhaps) > ** Primarily for iOS & Android, but would also want see where JS & Cordova > fit. > > Yes, another good integration item, would be interesting to know their > 'requirements'. I think our OAuth2 related work, would be something that's > interesting for them as well > > +1 > > > > > > > > > You start putting all of this together and there is a great set of > functionality that really compliments each other well. After we discuss for > a while, I'd like to find owners for the various items to help make progress > on these. Abstractj is awesome, but not sure he can do it all ;-) > > yes, great work by Bruno w/ getting actively started on this > > +1 > > > > > > > > > > -Jay > > PS: I'll post an email to the keycloak-dev list as well pointing to this > thread on our list. > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Wed Jan 22 06:53:24 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 22 Jan 2014 12:53:24 +0100 Subject: [aerogear-dev] Keycloak integration ideas In-Reply-To: <1879733740.8801251.1390390821039.JavaMail.root@redhat.com> References: <1879733740.8801251.1390390821039.JavaMail.root@redhat.com> Message-ID: Hello Stian, On Wed, Jan 22, 2014 at 12:40 PM, Stian Thorgersen wrote: > It's great to see interest in the Keycloak project :) > > We've been quite busy with getting the alpha out the door (hopefully it'll > be released tomorrow) hence the lack of response. Also, I don't think Bill > follows aerogear-dev. > > Would be good to start discussions on these items, maybe as separate posts > to keycloak-dev? > sure, that would work for me > > A few thoughts from me: > > * We've got a quick and dirty OpenShift cartridge ( > https://github.com/keycloak/openshift-keycloak-cartridge) - it's based on > the WildFly cartridge by Corey Daley. Seems to work pretty well and took me > about an hour to do the mods. I was considering if it was possible to do > the Keycloak and UPS cartridges as add-ons to the WildFly cartridge (same > as postgresql and mysql cartridges). That way you can mix and match > whatever combo you want. A specific cartridge may provide a better > integrated experience though. Maybe we can ping someone in the OpenShift > team to find out the correct approach? > sounds reasonable. Farah was kindly helping us w/ our Push Cartridge (containing Unified- and SimplePush Servers + MySQL). There are thoughts on integrating the UPS (e.g. the user management) w/ Keycloak. Something like that makes a perfect 'mix' for adding the Keycloak bits into our cartridge. Sure we could 're-lable' it. Is that something that sounds good ? > * Mobile SDKs - There's not much effort yet on supporting mobiles. Maybe > you could help us with creating Keycloak SDKs, with most of the code > reusable in AeroGear and LiveOak? > Absolutely, for that I think it would be good to start a thread on keycloak-dev regarding 'requirements' / desired functionality. Ideally these SDKs are leveraging AeroGear's mobile client SDKs. > * JS - None in Keycloak, but I've started one in LiveOak. Again, could we > do a Keycloak JS lib that could be reused by AeroGear and LiveOak? > +1 and that would be needed pretty much once the UnifiedPushServer is integrating w/ Keycloak :-) > > If you have any issues/questions at all post to keycloak-dev and I'm sure > me and Bill will fight to see how gets to answer first ;) > yay! Cheers! Matthias > > ----- Original Message ----- > > From: "Matthias Wessendorf" > > To: "AeroGear Developer Mailing List" > > Sent: Wednesday, 22 January, 2014 7:41:10 AM > > Subject: Re: [aerogear-dev] Keycloak integration ideas > > > > > > > > > > On Tue, Jan 21, 2014 at 11:10 PM, Jay Balunas < jbalunas at redhat.com > > wrote: > > > > > > > > > > On Jan 19, 2014, at 10:18 AM, Matthias Wessendorf < matzew at apache.org > > > wrote: > > > > > > > > > > > > > > > > On Fri, Jan 17, 2014 at 10:04 PM, Jay Balunas < jbalunas at redhat.com > > wrote: > > > > > > > > Hi All, > > > > Sorry all - book mode ;-) > > > > We've had a couple of threads around keycloak integration (thanks > Abstractj) > > and working together with them (both in our dev list and theirs). I had a > > meeting (dinner really) with Bill and talked about some possibilities and > > we're both excited to see what can happen. > > > > I wanted to capture some of those thoughts here (as well as some that > already > > started before), have some discussions, and more importantly talk about > next > > steps (jira's) to get some of this in the pipeline. I'm sure this is not > > exhaustive either, so please add your own thoughts, brainstorming etc... > > (for example Cordova plugin perhaps?) > > > > *In no particular order > > > > A) AeroGear security integration > > ** Abstractj already posted and implemented some of these changes > > ** > > > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Keycloak-on-AeroGear-td5663.html > > ** What's left here? Is it plug-able? Does it need to be? > > > > The work started by Bruno looks promising. I like that for the login to > the > > UPS Admin UI is being forwarded to the Keycloak server. > > As mentioned on the referenced thread, there is a bit of more work > needed for > > the "protection" of the SEND (and likely device registration) URLs. > > > > > > > > > > > > B) Crypto key management > > ** Server-side encryption key management for client crypto > > ** Abstractj had some discussions here > > *** > http://lists.jboss.org/pipermail/keycloak-dev/2013-December/000915.html > > *** Where does that stand? > > ** Do we need our own impl as well? > > > > C) UnifiedPush server integration > > ** User management, Auth* > > ** Do we have our own basic impl for quickstart experience? > > ** See below for possible combined cartridge options > > > > yep, the UPS come in mind and as mentioned in A) Bruno was already > actively > > starting this shortly before XMAS. > > > > > > > > > > > > D) Cross-project examples, tutorials, docs, etc... > > ** TBD > > > > Sure, combined docs/tutorials/examples are a good item once we do have a > bit > > more :-) Not sure it makes much sense now, but I can be wrong > > > > Completely agree now is not the time. Just wanted to bring it up for > > discussion. > > > > > > > > > > > > > > > > > > KeyCloak has some things they need as well, that we could work together > on. > > I'm sure the KeyCloak team could add more here :-) > > > > Z) Device support > > ** We need it, they need, and others need it > > ** Bill would like us to help them (and us at the same time) with this. > > > > yeah - that would be an extremely good fit for our Push efforts. > > > > We'll need someone to setup a mtg, or discuss on the topic. Any takers? > > > > I can reach out to them, via mailing list, to see what they are up to, > > regarding "Device support". Not 100% sure which email list is the 'right' > > choice (cross-postings are IMO a PITA :)) > > > > > > > > > > > > > > > > > > > > > > > > > > Y) OpenShift Cartridge for KeyCloak > > ** I know this is already on their roadmap > > ** The work Farah and others has already done, could be very helpful to > them > > ** We should also discuss the possibility of a joint cartridge > > *** Could be really compelling, especially if you add in device, client > key, > > and push support with native SDKs & examples > > *** Would also want separate cartridges as well imo > > > > yeah, I see various options here: > > * 'standalone' Keycloak cartridge (on their roadmap already); Would be > nice > > to get Farah involved here as well > > * combined cartridge (E.g. Push + Keycloak). If we do actually fully > > integrate Keycloak into the Push work, IMO this is a required option, to > > simply include the Keycloak offerings into our Push Cartridge > > > > Agreed, and I'd like to hear from the keycloak team on this as well. If > they > > have plans for pairing their cartridge with others. > > > > On their list they are currently talking about standalone ones, but > later, we > > might be able to integrate w/ their server piece. > > > > > > > > > > > > > > > > > > > > > > > > X) Client SDK support > > ** We have client SDKs & could help with their dev (either as part of > > AeroGear or KeyCloak perhaps) > > ** Primarily for iOS & Android, but would also want see where JS & > Cordova > > fit. > > > > Yes, another good integration item, would be interesting to know their > > 'requirements'. I think our OAuth2 related work, would be something > that's > > interesting for them as well > > > > +1 > > > > > > > > > > > > > > > > > > You start putting all of this together and there is a great set of > > functionality that really compliments each other well. After we discuss > for > > a while, I'd like to find owners for the various items to help make > progress > > on these. Abstractj is awesome, but not sure he can do it all ;-) > > > > yes, great work by Bruno w/ getting actively started on this > > > > +1 > > > > > > > > > > > > > > > > > > > > -Jay > > > > PS: I'll post an email to the keycloak-dev list as well pointing to this > > thread on our list. > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- 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/20140122/4cb19c54/attachment-0001.html From kpiwko at redhat.com Wed Jan 22 07:03:02 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Wed, 22 Jan 2014 13:03:02 +0100 Subject: [aerogear-dev] Website restructure In-Reply-To: <52DE6B7B.6050202@redhat.com> References: <2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com> <20140120123559.3a3aec13@kapy-ntb-x220> <52DE6B7B.6050202@redhat.com> Message-ID: <20140122130302.233deb81@kapy-ntb-x220> On Tue, 21 Jan 2014 12:43:39 +0000 Hylke Bons wrote: > On 20/01/2014 17:31, Corinne Krych wrote: > >> On Mon, Jan 20, 2014 at 12:35 PM, Karel Piwko wrote: > >> Looks good! > >> +1 I like the dracula theme ! > >> > >> Apart for platform related code (JavaScript, Objective-C, Java), are there > >> any plans to support platform related text? > >> > >> E.g. pipes on Aerogear can be used within FragmentActivity, which is valid > >> for Android only; Javadoc is not related to iOS, etc. That's basically a > >> merge of our guides into a one per feature with information covering all > >> the platforms. > > Is there a list of the most important features/classes/objects that I > can use in the mockup? I'm not aware of any. Trying to compose list of features, I'd go for: * Push Messages * Pipes * Authentication ** OTP * Crypto > > >> Which brings me to and idea of global platform switch. User/reader can > >> switch platform once and all code snippets and platform related blocks are > >> automatically selected. Can also be session based and affect all pages user > >> visits. > > Interesting idea. :) > > Hylke > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From corinnekrych at gmail.com Wed Jan 22 08:00:57 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 22 Jan 2014 14:00:57 +0100 Subject: [aerogear-dev] Website restructure In-Reply-To: <20140122130302.233deb81@kapy-ntb-x220> References: <2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com> <20140120123559.3a3aec13@kapy-ntb-x220> <52DE6B7B.6050202@redhat.com> <20140122130302.233deb81@kapy-ntb-x220> Message-ID: I like the original idea in the mockup (core/Security/Push), maybe we can introduce sub-section like: - Core (pipe - paging / store) - Security(authentication - OTP - OAuth2 / encryption / - Push (push registration / sender api / UPS - Simple Push) - Sync wdyt? ++ Corinne On 22 Jan 2014, at 13:03, Karel Piwko wrote: > On Tue, 21 Jan 2014 12:43:39 +0000 > Hylke Bons wrote: > >> On 20/01/2014 17:31, Corinne Krych wrote: >>>> On Mon, Jan 20, 2014 at 12:35 PM, Karel Piwko wrote: >>>> Looks good! >>>> +1 I like the dracula theme ! >>>> >>>> Apart for platform related code (JavaScript, Objective-C, Java), are there >>>> any plans to support platform related text? >>>> >>>> E.g. pipes on Aerogear can be used within FragmentActivity, which is valid >>>> for Android only; Javadoc is not related to iOS, etc. That's basically a >>>> merge of our guides into a one per feature with information covering all >>>> the platforms. >> >> Is there a list of the most important features/classes/objects that I >> can use in the mockup? > > I'm not aware of any. Trying to compose list of features, I'd go for: > > * Push Messages > * Pipes > * Authentication > ** OTP > * Crypto > > >> >>>> Which brings me to and idea of global platform switch. User/reader can >>>> switch platform once and all code snippets and platform related blocks are >>>> automatically selected. Can also be session based and affect all pages user >>>> visits. >> >> Interesting idea. :) >> >> Hylke >> >> _______________________________________________ >> 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 hbons at redhat.com Wed Jan 22 08:13:17 2014 From: hbons at redhat.com (Hylke Bons) Date: Wed, 22 Jan 2014 13:13:17 +0000 Subject: [aerogear-dev] Website restructure In-Reply-To: References: <2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com> <20140120123559.3a3aec13@kapy-ntb-x220> <52DE6B7B.6050202@redhat.com> <20140122130302.233deb81@kapy-ntb-x220> Message-ID: <52DFC3ED.2060405@redhat.com> On 22/01/2014 13:00, Corinne Krych wrote: > I like the original idea in the mockup (core/Security/Push), maybe we can introduce sub-section like: > - Core (pipe - paging / store) > - Security(authentication - OTP - OAuth2 / encryption / > - Push (push registration / sender api / UPS - Simple Push) > - Sync > > wdyt? > ++ > Corinne Yes, exactly that! :) I'm doing that as we speak, but I'm not sure what all the (useful) classes are. Hylke > On 22 Jan 2014, at 13:03, Karel Piwko wrote: > >> On Tue, 21 Jan 2014 12:43:39 +0000 >> Hylke Bons wrote: >> >>> On 20/01/2014 17:31, Corinne Krych wrote: >>>>> On Mon, Jan 20, 2014 at 12:35 PM, Karel Piwko wrote: >>>>> Looks good! >>>>> +1 I like the dracula theme ! >>>>> >>>>> Apart for platform related code (JavaScript, Objective-C, Java), are there >>>>> any plans to support platform related text? >>>>> >>>>> E.g. pipes on Aerogear can be used within FragmentActivity, which is valid >>>>> for Android only; Javadoc is not related to iOS, etc. That's basically a >>>>> merge of our guides into a one per feature with information covering all >>>>> the platforms. >>> Is there a list of the most important features/classes/objects that I >>> can use in the mockup? >> I'm not aware of any. Trying to compose list of features, I'd go for: >> >> * Push Messages >> * Pipes >> * Authentication >> ** OTP >> * Crypto >> >> >>>>> Which brings me to and idea of global platform switch. User/reader can >>>>> switch platform once and all code snippets and platform related blocks are >>>>> automatically selected. Can also be session based and affect all pages user >>>>> visits. >>> Interesting idea. :) >>> >>> Hylke >>> >>> _______________________________________________ >>> 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 bruno at abstractj.org Wed Jan 22 08:16:50 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 22 Jan 2014 11:16:50 -0200 Subject: [aerogear-dev] [UPS] User Management - open items / following up In-Reply-To: References: Message-ID: Morning, answers inline. -- abstractj On January 22, 2014 at 8:26:25 AM, Sebastien Blanc (scm.blanc at gmail.com) wrote: > > Hi, > Since the User Management PR has been submitted [1] there has > been of a lot > of useful and interesting feedback, thanks Matzew and Abstractj > for that. > > Some valid concerns has been raised, in particular 2 of them that > I would > like to expose here and to discuss to see how we can deal witth them > for > the 0.10.0 release : > > 1. > Currently the password register/reset link that is generated > is persisted. > This is a point of concern[2]. The fact is that with the current > flow, we > can not go against that: > > - An admin create an user, a link is generated. > - The admin send this link to the new user. > - The user browse to link -> at this moment we need to be able to retrieve > the stored link to check for its validity. I completely understand that you guys need to release it by the end of this month and I?m not against it. The goal was just to alert about the risks and maybe create new Jiras for it (only to people know that we are aware of it). > > Some points : > - The token/register link is presisted without any relation > with the newly > created user, so an hacker could not make a connection between > the 2. Maybe is my misunderstanding about the big picture, but the token has no relation with the newly created user, why do we have something like this??https://github.com/aerogear/aerogear-unifiedpush-server/pull/118#discussion-diff-8996740R29 > - The new created user, as long he has not registered through the > link, > can not log into the system as he has no password, as Bruno suggested > me to > do on the ML. > > How shall we deal with that for 0.10.0 ? We can improve in 0.11.0? If we are aware of the improvements to the next release, why not? Just make sure to remove any relation between users and tokens (at least for password reseting) and also make it clear to the ?admin? that with "great power comes with great responsibility?. I would suggest to point them to Jiras at our docs, we can always improve.? > and also > keeping in mind that keycloak could come into the party quite > soon. We need to keep our eyes in Keycloak, but they are still under development, the best approach is to make clear our needs, ideas and send some code to the project, IMO. > > 2. > Currently, to generate the register link, we use a private key. > This key is > located in the project[3]. This should not be in the github project > as > pointed by Bruno [4] which make totally sense. I will remove the > private > key from the repo and add instructions to tell how and where to > put your > private key. > > But I don't know how to deal for the UPS cartdridge, since we ship > a war, > the private key will be missing. Any ideas input on that is welcome.? I can help on it and change my priorities if necessary, just not sure about the timing for you guys (I can do it today and make it available tomorrow for testing). Some ideas: - Automagically generate the property file with the secret key, into this way that would be per application. - If we don?t have too much time, provide a script with the steps to upload the keys on OpenShift (maybe the first step is less confuse) > For 0.10.0, we could just ship a war containing a private key and > add a > warning and maybe add instruction on how to clone the app locally, > change > the key and push again (which is not really user friendly when > you expect > to have a cartdridge that "just work?). +1 in the worst case scenario > > Notice that there is ticket to be able to manage your private key > from the > Admin console[5] That would be nice > > Again, in the future, keycloak could be used also to manage the > keys. > > Besides that, the current PR, in terms of functionnalities works > : you can > create and manage users like specified in the specs. > > So for the (very soon) 0.10.0 release how shall we deal with these > concerns > ? Looking at UPS roadmap (https://issues.jboss.org/browse/AGPUSH) the date for 0.10.0 is Wed, right? I think independent of our decision now, the timing is too tight to merge your PR and release it tomorrow, maybe we should release it on the next week? Or do not merge that PR? > > Sebi > > > > [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/118 > [2] > https://github.com/aerogear/aerogear-unifiedpush-server/pull/118#discussion_r8996725 > [3] > https://github.com/aerogear/aerogear-unifiedpush-server/blob/register_link/src/main/resources/META-INF/config.properties > [4] > https://github.com/aerogear/aerogear-unifiedpush-server/pull/118#discussion_r8996712 > [5] https://issues.jboss.org/browse/AGPUSH-518 > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From bruno at abstractj.org Wed Jan 22 08:20:14 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 22 Jan 2014 11:20:14 -0200 Subject: [aerogear-dev] simple Java sync server In-Reply-To: References: <3CA6121A-60F0-4C8A-9B4A-CD208D594782@redhat.com> Message-ID: +10000 awesome! -- abstractj On January 22, 2014 at 8:39:08 AM, Erik Jan de Wit (edewit at redhat.com) wrote: > > Right good point, at the time of writing Dan?s server didn?t > exist, but now I could submit it as an alternative implementation. > I?ll do that now. From matzew at apache.org Wed Jan 22 08:31:12 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 22 Jan 2014 14:31:12 +0100 Subject: [aerogear-dev] [UPS] User Management - open items / following up In-Reply-To: References: Message-ID: On Wed, Jan 22, 2014 at 2:16 PM, Bruno Oliveira wrote: > Morning, answers inline. > > -- > abstractj > > On January 22, 2014 at 8:26:25 AM, Sebastien Blanc (scm.blanc at gmail.com) > wrote: > > > > Hi, > > Since the User Management PR has been submitted [1] there has > > been of a lot > > of useful and interesting feedback, thanks Matzew and Abstractj > > for that. > > > > Some valid concerns has been raised, in particular 2 of them that > > I would > > like to expose here and to discuss to see how we can deal witth them > > for > > the 0.10.0 release : > > > > 1. > > Currently the password register/reset link that is generated > > is persisted. > > This is a point of concern[2]. The fact is that with the current > > flow, we > > can not go against that: > > > > - An admin create an user, a link is generated. > > - The admin send this link to the new user. > > - The user browse to link -> at this moment we need to be able to > retrieve > > the stored link to check for its validity. > > I completely understand that you guys need to release it by the end of > this month and I?m not against it. The goal was just to alert about the > risks and maybe create new Jiras for it (only to people know that we are > aware of it). > Well, even if it takes a bit longer (e.g. early Feb.), I think that is fine to have a few more days/weeks to get the 'User Management' in. Was supposed to be the 'big' item for 0.10 :) Other than that there were a few fixes and UI polish things. So IMO waiting a bit is perfectly valid - my personal opinion. I am glad we are following up on these items, and eventually we create JIRAs :-) Thanks for the heads-up, Bruno! > > > > > Some points : > > - The token/register link is presisted without any relation > > with the newly > > created user, so an hacker could not make a connection between > > the 2. > > Maybe is my misunderstanding about the big picture, but the token has no > relation with the newly created user, why do we have something like this? > https://github.com/aerogear/aerogear-unifiedpush-server/pull/118#discussion-diff-8996740R29 > > > - The new created user, as long he has not registered through the > > link, > > can not log into the system as he has no password, as Bruno suggested > > me to > > do on the ML. > > > > How shall we deal with that for 0.10.0 ? We can improve in 0.11.0 > > If we are aware of the improvements to the next release, why not? that would be fine w/ me as well > Just make sure to remove any relation between users and tokens (at least > for password reseting) and also make it clear to the ?admin? that with > "great power comes with great responsibility?. > +1 > > I would suggest to point them to Jiras at our docs, we can always improve. > > > and also > > keeping in mind that keycloak could come into the party quite > > soon. > > We need to keep our eyes in Keycloak, but they are still under > development, the best approach is to make clear our needs, ideas and send > some code to the project, IMO. > yep, I agree! > > > > > 2. > > Currently, to generate the register link, we use a private key. > > This key is > > located in the project[3]. This should not be in the github project > > as > > pointed by Bruno [4] which make totally sense. I will remove the > > private > > key from the repo and add instructions to tell how and where to > > put your > > private key. > > > > But I don't know how to deal for the UPS cartdridge, since we ship > > a war, > > the private key will be missing. Any ideas input on that is welcome. > > I can help on it and change my priorities if necessary, just not sure > about the timing for you guys (I can do it today and make it available > tomorrow for testing). IMO not worth rushing for today/tomorrow, as said above; If you can help that would be extremely awesome, but let's not change all of your priorities because of this :-) -Matthias > Some ideas: > > - Automagically generate the property file with the secret key, into this > way that would be per application. > - If we don?t have too much time, provide a script with the steps to > upload the keys on OpenShift (maybe the first step is less confuse) > > > > For 0.10.0, we could just ship a war containing a private key and > > add a > > warning and maybe add instruction on how to clone the app locally, > > change > > the key and push again (which is not really user friendly when > > you expect > > to have a cartdridge that "just work?). > > +1 in the worst case scenario > > > > > Notice that there is ticket to be able to manage your private key > > from the > > Admin console[5] > > That would be nice > > > > > Again, in the future, keycloak could be used also to manage the > > keys. > > > > Besides that, the current PR, in terms of functionnalities works > > : you can > > create and manage users like specified in the specs. > > > > So for the (very soon) 0.10.0 release how shall we deal with these > > concerns > > ? > > Looking at UPS roadmap (https://issues.jboss.org/browse/AGPUSH) the date > for 0.10.0 is Wed, right? I think independent of our decision now, the > timing is too tight to merge your PR and release it tomorrow, maybe we > should release it on the next week? Or do not merge that PR? > > > > > Sebi > > > > > > > > [1] https://github.com/aerogear/aerogear-unifiedpush-server/pull/118 > > [2] > > > https://github.com/aerogear/aerogear-unifiedpush-server/pull/118#discussion_r8996725 > > [3] > > > https://github.com/aerogear/aerogear-unifiedpush-server/blob/register_link/src/main/resources/META-INF/config.properties > > [4] > > > https://github.com/aerogear/aerogear-unifiedpush-server/pull/118#discussion_r8996712 > > [5] https://issues.jboss.org/browse/AGPUSH-518 > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140122/ff434166/attachment-0001.html From lholmqui at redhat.com Wed Jan 22 08:32:31 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 22 Jan 2014 08:32:31 -0500 Subject: [aerogear-dev] aerogear-js Mozilla's Persona authentication adapter In-Reply-To: <1126554180.4118114.1390383665653.JavaMail.root@redhat.com> References: <734665923.4117587.1390383478992.JavaMail.root@redhat.com> <1126554180.4118114.1390383665653.JavaMail.root@redhat.com> Message-ID: <3D1DA411-328B-4605-A00B-ED6AACDD58BD@redhat.com> sounds cool, i'll take a look On Jan 22, 2014, at 4:41 AM, Apostolos Emmanouilidis wrote: > hello, > > while looking at AGJS-122 and the possibility to add an authentication adapter which is based on Mozilla's Persona sign-in system, I was thinking of the following API: > > // Construct an AeroGear.Authentication.adapters.Persona > var persona = AeroGear.Auth({ > name: 'persona', > type: 'Persona', > settings: { > verificationEndpoint: "http://127.0.0.1:3000/verify" > } > }).modules.persona; > > // use login to initiate the Mozilla's Persona authentication procedure. login enables the BrowserID and generates a signed assertion which contains the user's email address > // on assertion generation call the verification service > persona.login({ > onAssertion: function ( assertion ) { for consistency, i would probably call this callback 'success' > // the verification API receives the assertion and the audience (our website URL) as parameters > // for security reasons there must be an intermediate service between the client and the verification API. the reason for which we want the intermediate service > // is that we want to ensure that the audience parameter is not hacked. I was thinking that it is better to avoid adding the persona.verify call inside our adapter > // since this way we would force the user to create the intermediate service according our implementation. That's why the following line exists: > persona.verify( { assertion: assertion }, { success: onSuccessVerification, error: onFailedVerification } ); > }, > error: onLoginError > }); > > // logout > persona.logout( onLogout ); i know for the REST adapter we also have an "enroll" method, not sure if that makes sense for this one. I haven't really looked at the Persona thing to much, just a shiny object that i saw and created a JIRA > > I have added a working example in: https://github.com/tolis-e/aerogear-js-persona-authentication-poc > and a first implementation sample: https://github.com/aerogear/aerogear-js/pull/100 > > In order you'd like to try the working example on Android emulator, change lines: > https://github.com/tolis-e/aerogear-js-persona-authentication-poc/blob/master/static/persona-test.html#L16 > and > https://github.com/tolis-e/aerogear-js-persona-authentication-poc/blob/master/server.js#L29 > to use host 10.0.2.2 > and open the http://10.0.2.2:3000/persona-test.html page on the Android browser > > > any thoughts, suggestions? > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From lholmqui at redhat.com Wed Jan 22 08:38:30 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 22 Jan 2014 08:38:30 -0500 Subject: [aerogear-dev] Keycloak integration ideas In-Reply-To: References: <1879733740.8801251.1390390821039.JavaMail.root@redhat.com> Message-ID: <7E46A996-D9DB-4430-AD3F-8779044FFF5C@redhat.com> On Jan 22, 2014, at 6:53 AM, Matthias Wessendorf wrote: > Hello Stian, > > > On Wed, Jan 22, 2014 at 12:40 PM, Stian Thorgersen wrote: > It's great to see interest in the Keycloak project :) > > We've been quite busy with getting the alpha out the door (hopefully it'll be released tomorrow) hence the lack of response. Also, I don't think Bill follows aerogear-dev. > > Would be good to start discussions on these items, maybe as separate posts to keycloak-dev? > > sure, that would work for me > > > A few thoughts from me: > > * We've got a quick and dirty OpenShift cartridge (https://github.com/keycloak/openshift-keycloak-cartridge) - it's based on the WildFly cartridge by Corey Daley. Seems to work pretty well and took me about an hour to do the mods. I was considering if it was possible to do the Keycloak and UPS cartridges as add-ons to the WildFly cartridge (same as postgresql and mysql cartridges). That way you can mix and match whatever combo you want. A specific cartridge may provide a better integrated experience though. Maybe we can ping someone in the OpenShift team to find out the correct approach? > > sounds reasonable. Farah was kindly helping us w/ our Push Cartridge (containing Unified- and SimplePush Servers + MySQL). > There are thoughts on integrating the UPS (e.g. the user management) w/ Keycloak. Something like that makes a perfect 'mix' for adding the Keycloak bits into our cartridge. Sure we could 're-lable' it. Is that something that sounds good ? > > > * Mobile SDKs - There's not much effort yet on supporting mobiles. Maybe you could help us with creating Keycloak SDKs, with most of the code reusable in AeroGear and LiveOak? > > Absolutely, for that I think it would be good to start a thread on keycloak-dev regarding 'requirements' / desired functionality. Ideally these SDKs are leveraging AeroGear's mobile client SDKs. > > * JS - None in Keycloak, but I've started one in LiveOak. Again, could we do a Keycloak JS lib that could be reused by AeroGear and LiveOak? > > +1 and that would be needed pretty much once the UnifiedPushServer is integrating w/ Keycloak :-) what is the target for having the "implicit" auth flow, since this is needed for JS clients. I have a OAuth2 client in aerogear.js, currently tested against googles OAuth2 stuff, but it is written to spec > > > If you have any issues/questions at all post to keycloak-dev and I'm sure me and Bill will fight to see how gets to answer first ;) > > yay! > > Cheers! > Matthias > > > ----- Original Message ----- > > From: "Matthias Wessendorf" > > To: "AeroGear Developer Mailing List" > > Sent: Wednesday, 22 January, 2014 7:41:10 AM > > Subject: Re: [aerogear-dev] Keycloak integration ideas > > > > > > > > > > On Tue, Jan 21, 2014 at 11:10 PM, Jay Balunas < jbalunas at redhat.com > wrote: > > > > > > > > > > On Jan 19, 2014, at 10:18 AM, Matthias Wessendorf < matzew at apache.org > > > wrote: > > > > > > > > > > > > > > > > On Fri, Jan 17, 2014 at 10:04 PM, Jay Balunas < jbalunas at redhat.com > wrote: > > > > > > > > Hi All, > > > > Sorry all - book mode ;-) > > > > We've had a couple of threads around keycloak integration (thanks Abstractj) > > and working together with them (both in our dev list and theirs). I had a > > meeting (dinner really) with Bill and talked about some possibilities and > > we're both excited to see what can happen. > > > > I wanted to capture some of those thoughts here (as well as some that already > > started before), have some discussions, and more importantly talk about next > > steps (jira's) to get some of this in the pipeline. I'm sure this is not > > exhaustive either, so please add your own thoughts, brainstorming etc... > > (for example Cordova plugin perhaps?) > > > > *In no particular order > > > > A) AeroGear security integration > > ** Abstractj already posted and implemented some of these changes > > ** > > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Keycloak-on-AeroGear-td5663.html > > ** What's left here? Is it plug-able? Does it need to be? > > > > The work started by Bruno looks promising. I like that for the login to the > > UPS Admin UI is being forwarded to the Keycloak server. > > As mentioned on the referenced thread, there is a bit of more work needed for > > the "protection" of the SEND (and likely device registration) URLs. > > > > > > > > > > > > B) Crypto key management > > ** Server-side encryption key management for client crypto > > ** Abstractj had some discussions here > > *** http://lists.jboss.org/pipermail/keycloak-dev/2013-December/000915.html > > *** Where does that stand? > > ** Do we need our own impl as well? > > > > C) UnifiedPush server integration > > ** User management, Auth* > > ** Do we have our own basic impl for quickstart experience? > > ** See below for possible combined cartridge options > > > > yep, the UPS come in mind and as mentioned in A) Bruno was already actively > > starting this shortly before XMAS. > > > > > > > > > > > > D) Cross-project examples, tutorials, docs, etc... > > ** TBD > > > > Sure, combined docs/tutorials/examples are a good item once we do have a bit > > more :-) Not sure it makes much sense now, but I can be wrong > > > > Completely agree now is not the time. Just wanted to bring it up for > > discussion. > > > > > > > > > > > > > > > > > > KeyCloak has some things they need as well, that we could work together on. > > I'm sure the KeyCloak team could add more here :-) > > > > Z) Device support > > ** We need it, they need, and others need it > > ** Bill would like us to help them (and us at the same time) with this. > > > > yeah - that would be an extremely good fit for our Push efforts. > > > > We'll need someone to setup a mtg, or discuss on the topic. Any takers? > > > > I can reach out to them, via mailing list, to see what they are up to, > > regarding "Device support". Not 100% sure which email list is the 'right' > > choice (cross-postings are IMO a PITA :)) > > > > > > > > > > > > > > > > > > > > > > > > > > Y) OpenShift Cartridge for KeyCloak > > ** I know this is already on their roadmap > > ** The work Farah and others has already done, could be very helpful to them > > ** We should also discuss the possibility of a joint cartridge > > *** Could be really compelling, especially if you add in device, client key, > > and push support with native SDKs & examples > > *** Would also want separate cartridges as well imo > > > > yeah, I see various options here: > > * 'standalone' Keycloak cartridge (on their roadmap already); Would be nice > > to get Farah involved here as well > > * combined cartridge (E.g. Push + Keycloak). If we do actually fully > > integrate Keycloak into the Push work, IMO this is a required option, to > > simply include the Keycloak offerings into our Push Cartridge > > > > Agreed, and I'd like to hear from the keycloak team on this as well. If they > > have plans for pairing their cartridge with others. > > > > On their list they are currently talking about standalone ones, but later, we > > might be able to integrate w/ their server piece. > > > > > > > > > > > > > > > > > > > > > > > > X) Client SDK support > > ** We have client SDKs & could help with their dev (either as part of > > AeroGear or KeyCloak perhaps) > > ** Primarily for iOS & Android, but would also want see where JS & Cordova > > fit. > > > > Yes, another good integration item, would be interesting to know their > > 'requirements'. I think our OAuth2 related work, would be something that's > > interesting for them as well > > > > +1 > > > > > > > > > > > > > > > > > > You start putting all of this together and there is a great set of > > functionality that really compliments each other well. After we discuss for > > a while, I'd like to find owners for the various items to help make progress > > on these. Abstractj is awesome, but not sure he can do it all ;-) > > > > yes, great work by Bruno w/ getting actively started on this > > > > +1 > > > > > > > > > > > > > > > > > > > > -Jay > > > > PS: I'll post an email to the keycloak-dev list as well pointing to this > > thread on our list. > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140122/9a82eb4c/attachment-0001.html From stian at redhat.com Wed Jan 22 09:14:14 2014 From: stian at redhat.com (Stian Thorgersen) Date: Wed, 22 Jan 2014 09:14:14 -0500 (EST) Subject: [aerogear-dev] Keycloak integration ideas In-Reply-To: <7E46A996-D9DB-4430-AD3F-8779044FFF5C@redhat.com> References: <1879733740.8801251.1390390821039.JavaMail.root@redhat.com> <7E46A996-D9DB-4430-AD3F-8779044FFF5C@redhat.com> Message-ID: <406179885.8919462.1390400054349.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Lucas Holmquist" > To: "AeroGear Developer Mailing List" > Sent: Wednesday, 22 January, 2014 1:38:30 PM > Subject: Re: [aerogear-dev] Keycloak integration ideas > > > On Jan 22, 2014, at 6:53 AM, Matthias Wessendorf < matzew at apache.org > wrote: > > > > > Hello Stian, > > > On Wed, Jan 22, 2014 at 12:40 PM, Stian Thorgersen < stian at redhat.com > > wrote: > > > It's great to see interest in the Keycloak project :) > > We've been quite busy with getting the alpha out the door (hopefully it'll be > released tomorrow) hence the lack of response. Also, I don't think Bill > follows aerogear-dev. > > Would be good to start discussions on these items, maybe as separate posts to > keycloak-dev? > > sure, that would work for me > > > > A few thoughts from me: > > * We've got a quick and dirty OpenShift cartridge ( > https://github.com/keycloak/openshift-keycloak-cartridge ) - it's based on > the WildFly cartridge by Corey Daley. Seems to work pretty well and took me > about an hour to do the mods. I was considering if it was possible to do the > Keycloak and UPS cartridges as add-ons to the WildFly cartridge (same as > postgresql and mysql cartridges). That way you can mix and match whatever > combo you want. A specific cartridge may provide a better integrated > experience though. Maybe we can ping someone in the OpenShift team to find > out the correct approach? > > sounds reasonable. Farah was kindly helping us w/ our Push Cartridge > (containing Unified- and SimplePush Servers + MySQL). > There are thoughts on integrating the UPS (e.g. the user management) w/ > Keycloak. Something like that makes a perfect 'mix' for adding the Keycloak > bits into our cartridge. Sure we could 're-lable' it. Is that something that > sounds good ? > > > > * Mobile SDKs - There's not much effort yet on supporting mobiles. Maybe you > could help us with creating Keycloak SDKs, with most of the code reusable in > AeroGear and LiveOak? > > Absolutely, for that I think it would be good to start a thread on > keycloak-dev regarding 'requirements' / desired functionality. Ideally these > SDKs are leveraging AeroGear's mobile client SDKs. > > > * JS - None in Keycloak, but I've started one in LiveOak. Again, could we do > a Keycloak JS lib that could be reused by AeroGear and LiveOak? > > +1 and that would be needed pretty much once the UnifiedPushServer is > integrating w/ Keycloak :-) > > what is the target for having the "implicit" auth flow, since this is needed > for JS clients. > > I have a OAuth2 client in aerogear.js, currently tested against googles > OAuth2 stuff, but it is written to spec JS clients can use authorization code flow as well. Currently Keycloak requires a client id and secret to exchange the code for a token, but I think for public clients it should allow these to not have a password. As it's pointless having a password in a public client. To my understanding the authorization code flow is safer even without a confidential password. I think a JS client should support both flows, and Keycloak should probably also support both flows. I have loads of unanswered questions with regards how to best support JS clients. At the moment there's no JS lib for Keycloak, but I've done one for LiveOak (https://github.com/liveoak-io/liveoak/blob/master/clients/javascript/src/main/javascript/auth/client.js), the plan was to re-spin that for Keycloak for the next release. > > > > > > > > If you have any issues/questions at all post to keycloak-dev and I'm sure me > and Bill will fight to see how gets to answer first ;) > > yay! > > Cheers! > Matthias > > > > > ----- Original Message ----- > > From: "Matthias Wessendorf" < matzew at apache.org > > > To: "AeroGear Developer Mailing List" < aerogear-dev at lists.jboss.org > > > Sent: Wednesday, 22 January, 2014 7:41:10 AM > > Subject: Re: [aerogear-dev] Keycloak integration ideas > > > > > > > > > > On Tue, Jan 21, 2014 at 11:10 PM, Jay Balunas < jbalunas at redhat.com > > > wrote: > > > > > > > > > > On Jan 19, 2014, at 10:18 AM, Matthias Wessendorf < matzew at apache.org > > > wrote: > > > > > > > > > > > > > > > > On Fri, Jan 17, 2014 at 10:04 PM, Jay Balunas < jbalunas at redhat.com > > > wrote: > > > > > > > > Hi All, > > > > Sorry all - book mode ;-) > > > > We've had a couple of threads around keycloak integration (thanks > > Abstractj) > > and working together with them (both in our dev list and theirs). I had a > > meeting (dinner really) with Bill and talked about some possibilities and > > we're both excited to see what can happen. > > > > I wanted to capture some of those thoughts here (as well as some that > > already > > started before), have some discussions, and more importantly talk about > > next > > steps (jira's) to get some of this in the pipeline. I'm sure this is not > > exhaustive either, so please add your own thoughts, brainstorming etc... > > (for example Cordova plugin perhaps?) > > > > *In no particular order > > > > A) AeroGear security integration > > ** Abstractj already posted and implemented some of these changes > > ** > > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Keycloak-on-AeroGear-td5663.html > > ** What's left here? Is it plug-able? Does it need to be? > > > > The work started by Bruno looks promising. I like that for the login to the > > UPS Admin UI is being forwarded to the Keycloak server. > > As mentioned on the referenced thread, there is a bit of more work needed > > for > > the "protection" of the SEND (and likely device registration) URLs. > > > > > > > > > > > > B) Crypto key management > > ** Server-side encryption key management for client crypto > > ** Abstractj had some discussions here > > *** http://lists.jboss.org/pipermail/keycloak-dev/2013-December/000915.html > > *** Where does that stand? > > ** Do we need our own impl as well? > > > > C) UnifiedPush server integration > > ** User management, Auth* > > ** Do we have our own basic impl for quickstart experience? > > ** See below for possible combined cartridge options > > > > yep, the UPS come in mind and as mentioned in A) Bruno was already actively > > starting this shortly before XMAS. > > > > > > > > > > > > D) Cross-project examples, tutorials, docs, etc... > > ** TBD > > > > Sure, combined docs/tutorials/examples are a good item once we do have a > > bit > > more :-) Not sure it makes much sense now, but I can be wrong > > > > Completely agree now is not the time. Just wanted to bring it up for > > discussion. > > > > > > > > > > > > > > > > > > KeyCloak has some things they need as well, that we could work together on. > > I'm sure the KeyCloak team could add more here :-) > > > > Z) Device support > > ** We need it, they need, and others need it > > ** Bill would like us to help them (and us at the same time) with this. > > > > yeah - that would be an extremely good fit for our Push efforts. > > > > We'll need someone to setup a mtg, or discuss on the topic. Any takers? > > > > I can reach out to them, via mailing list, to see what they are up to, > > regarding "Device support". Not 100% sure which email list is the 'right' > > choice (cross-postings are IMO a PITA :)) > > > > > > > > > > > > > > > > > > > > > > > > > > Y) OpenShift Cartridge for KeyCloak > > ** I know this is already on their roadmap > > ** The work Farah and others has already done, could be very helpful to > > them > > ** We should also discuss the possibility of a joint cartridge > > *** Could be really compelling, especially if you add in device, client > > key, > > and push support with native SDKs & examples > > *** Would also want separate cartridges as well imo > > > > yeah, I see various options here: > > * 'standalone' Keycloak cartridge (on their roadmap already); Would be nice > > to get Farah involved here as well > > * combined cartridge (E.g. Push + Keycloak). If we do actually fully > > integrate Keycloak into the Push work, IMO this is a required option, to > > simply include the Keycloak offerings into our Push Cartridge > > > > Agreed, and I'd like to hear from the keycloak team on this as well. If > > they > > have plans for pairing their cartridge with others. > > > > On their list they are currently talking about standalone ones, but later, > > we > > might be able to integrate w/ their server piece. > > > > > > > > > > > > > > > > > > > > > > > > X) Client SDK support > > ** We have client SDKs & could help with their dev (either as part of > > AeroGear or KeyCloak perhaps) > > ** Primarily for iOS & Android, but would also want see where JS & Cordova > > fit. > > > > Yes, another good integration item, would be interesting to know their > > 'requirements'. I think our OAuth2 related work, would be something that's > > interesting for them as well > > > > +1 > > > > > > > > > > > > > > > > > > You start putting all of this together and there is a great set of > > functionality that really compliments each other well. After we discuss for > > a while, I'd like to find owners for the various items to help make > > progress > > on these. Abstractj is awesome, but not sure he can do it all ;-) > > > > yes, great work by Bruno w/ getting actively started on this > > > > +1 > > > > > > > > > > > > > > > > > > > > -Jay > > > > PS: I'll post an email to the keycloak-dev list as well pointing to this > > thread on our list. > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > 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 From jbalunas at redhat.com Wed Jan 22 09:31:26 2014 From: jbalunas at redhat.com (Jay Balunas) Date: Wed, 22 Jan 2014 09:31:26 -0500 Subject: [aerogear-dev] AeroGear & Ceylon Android support Message-ID: <04D260EC-6086-4892-81B6-B12ED88EC6D9@redhat.com> Hi Y'All, Saw the other day that the Ceylon[1] team has been working on some Android support, especially around their tooling. Here are some links: ceylon-dev list posts: https://groups.google.com/d/msg/ceylon-dev/BNqosBRDuSI/WuqUWfxraQcJ https://groups.google.com/d/msg/ceylon-dev/n2ZfmaW-I2M/GhZVEa_uV44J I had a quick chat with Gavin about this, and we think it could be neat if we look into how we might be able to collaborate and/or provide some feedback on their Android support and tooling. There could be some interesting ways to integrate between the projects :-) Thoughts? - Jay [1] http://ceylon-lang.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140122/15fcfc41/attachment.html From matzew at apache.org Wed Jan 22 10:46:11 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 22 Jan 2014 16:46:11 +0100 Subject: [aerogear-dev] AeroGear & Ceylon Android support In-Reply-To: <04D260EC-6086-4892-81B6-B12ED88EC6D9@redhat.com> References: <04D260EC-6086-4892-81B6-B12ED88EC6D9@redhat.com> Message-ID: On Wed, Jan 22, 2014 at 3:31 PM, Jay Balunas wrote: > Hi Y'All, > > Saw the other day that the Ceylon[1] team has been working on some Android > support, especially around their tooling. Here are some links: > > ceylon-dev list posts: > > https://groups.google.com/d/msg/ceylon-dev/BNqosBRDuSI/WuqUWfxraQcJ > https://groups.google.com/d/msg/ceylon-dev/n2ZfmaW-I2M/GhZVEa_uV44J > > I had a quick chat with Gavin about this, and we think it could be neat if > we look into how we might be able to collaborate and/or provide some > feedback on their Android support and tooling. > sounds interesting, and taking a look does not hurt > > There could be some interesting ways to integrate between the projects :-) > sure, however, I think if we are now taking a (deeper) look at Keycloak, perhaps thats something to focus on for now. However, as said, doing some sort of evaluation for a few days, and see if ours works there etc, would be a nice task. > > Thoughts? > > - Jay > > [1] http://ceylon-lang.org/ > > > > > > > > _______________________________________________ > 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/20140122/eafe1d39/attachment.html From jbalunas at redhat.com Wed Jan 22 13:48:43 2014 From: jbalunas at redhat.com (Jay Balunas) Date: Wed, 22 Jan 2014 13:48:43 -0500 Subject: [aerogear-dev] AeroGear & Ceylon Android support In-Reply-To: References: <04D260EC-6086-4892-81B6-B12ED88EC6D9@redhat.com> Message-ID: <6BD55059-38BC-483B-8990-BB4614711478@redhat.com> On Jan 22, 2014, at 10:46 AM, Matthias Wessendorf wrote: > > > > On Wed, Jan 22, 2014 at 3:31 PM, Jay Balunas wrote: > Hi Y'All, > > Saw the other day that the Ceylon[1] team has been working on some Android support, especially around their tooling. Here are some links: > > ceylon-dev list posts: > > https://groups.google.com/d/msg/ceylon-dev/BNqosBRDuSI/WuqUWfxraQcJ > https://groups.google.com/d/msg/ceylon-dev/n2ZfmaW-I2M/GhZVEa_uV44J > > I had a quick chat with Gavin about this, and we think it could be neat if we look into how we might be able to collaborate and/or provide some feedback on their Android support and tooling. > > sounds interesting, and taking a look does not hurt > > > There could be some interesting ways to integrate between the projects :-) > > sure, however, I think if we are now taking a (deeper) look at Keycloak, perhaps thats something to focus on for now. > > However, as said, doing some sort of evaluation for a few days, and see if ours works there etc, would be a nice task. I agree, the keycloak integration is a higher priority. I just wanted to raise this as a interesting opportunity not a "drop everything" and look :-) > > > Thoughts? > > - Jay > > [1] http://ceylon-lang.org/ > > > > > > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140122/ad2fc739/attachment-0001.html From bsutter at redhat.com Wed Jan 22 14:18:15 2014 From: bsutter at redhat.com (Burr Sutter) Date: Wed, 22 Jan 2014 14:18:15 -0500 Subject: [aerogear-dev] AeroGear & Ceylon Android support In-Reply-To: <6BD55059-38BC-483B-8990-BB4614711478@redhat.com> References: <04D260EC-6086-4892-81B6-B12ED88EC6D9@redhat.com> <6BD55059-38BC-483B-8990-BB4614711478@redhat.com> Message-ID: Does the overall team have a list of priorities? Things like: Investigate Keycloak integration Investigate Vert.x runtime vs Java EE runtime Investigate LiveOak integration Create and/or Improve Unified Push Server + Cordova + JBoss Tools Getting Started Docs/Videos etc It is easy for me to "lose sight of the forest for the trees" in Jira :-) On Jan 22, 2014, at 1:48 PM, Jay Balunas wrote: > > On Jan 22, 2014, at 10:46 AM, Matthias Wessendorf wrote: > >> >> >> >> On Wed, Jan 22, 2014 at 3:31 PM, Jay Balunas wrote: >> Hi Y'All, >> >> Saw the other day that the Ceylon[1] team has been working on some Android support, especially around their tooling. Here are some links: >> >> ceylon-dev list posts: >> >> https://groups.google.com/d/msg/ceylon-dev/BNqosBRDuSI/WuqUWfxraQcJ >> https://groups.google.com/d/msg/ceylon-dev/n2ZfmaW-I2M/GhZVEa_uV44J >> >> I had a quick chat with Gavin about this, and we think it could be neat if we look into how we might be able to collaborate and/or provide some feedback on their Android support and tooling. >> >> sounds interesting, and taking a look does not hurt >> >> >> There could be some interesting ways to integrate between the projects :-) >> >> sure, however, I think if we are now taking a (deeper) look at Keycloak, perhaps thats something to focus on for now. >> >> However, as said, doing some sort of evaluation for a few days, and see if ours works there etc, would be a nice task. > > I agree, the keycloak integration is a higher priority. I just wanted to raise this as a interesting opportunity not a "drop everything" and look :-) > >> >> >> Thoughts? >> >> - Jay >> >> [1] http://ceylon-lang.org/ >> >> >> >> >> >> >> >> _______________________________________________ >> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140122/7088b3f4/attachment.html From bruno at abstractj.org Wed Jan 22 15:53:21 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 22 Jan 2014 12:53:21 -0800 (PST) Subject: [aerogear-dev] AeroGear & Ceylon Android support In-Reply-To: References: Message-ID: <1390424000677.779a4d98@Nodemailer> That's what roadmaps stand for, no?? abstractj On Wed, Jan 22, 2014 at 5:18 PM, Burr Sutter wrote: > Does the overall team have a list of priorities? Things like: > Investigate Keycloak integration > Investigate Vert.x runtime vs Java EE runtime > Investigate LiveOak integration > Create and/or Improve Unified Push Server + Cordova + JBoss Tools Getting Started Docs/Videos > etc > It is easy for me to "lose sight of the forest for the trees" in Jira :-) > On Jan 22, 2014, at 1:48 PM, Jay Balunas wrote: >> >> On Jan 22, 2014, at 10:46 AM, Matthias Wessendorf wrote: >> >>> >>> >>> >>> On Wed, Jan 22, 2014 at 3:31 PM, Jay Balunas wrote: >>> Hi Y'All, >>> >>> Saw the other day that the Ceylon[1] team has been working on some Android support, especially around their tooling. Here are some links: >>> >>> ceylon-dev list posts: >>> >>> https://groups.google.com/d/msg/ceylon-dev/BNqosBRDuSI/WuqUWfxraQcJ >>> https://groups.google.com/d/msg/ceylon-dev/n2ZfmaW-I2M/GhZVEa_uV44J >>> >>> I had a quick chat with Gavin about this, and we think it could be neat if we look into how we might be able to collaborate and/or provide some feedback on their Android support and tooling. >>> >>> sounds interesting, and taking a look does not hurt >>> >>> >>> There could be some interesting ways to integrate between the projects :-) >>> >>> sure, however, I think if we are now taking a (deeper) look at Keycloak, perhaps thats something to focus on for now. >>> >>> However, as said, doing some sort of evaluation for a few days, and see if ours works there etc, would be a nice task. >> >> I agree, the keycloak integration is a higher priority. I just wanted to raise this as a interesting opportunity not a "drop everything" and look :-) >> >>> >>> >>> Thoughts? >>> >>> - Jay >>> >>> [1] http://ceylon-lang.org/ >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140122/2999970e/attachment.html From matzew at apache.org Wed Jan 22 15:58:14 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 22 Jan 2014 21:58:14 +0100 Subject: [aerogear-dev] AeroGear & Ceylon Android support In-Reply-To: <1390424000677.779a4d98@Nodemailer> References: <1390424000677.779a4d98@Nodemailer> Message-ID: On Wednesday, January 22, 2014, Bruno Oliveira wrote: > That's what roadmaps stand for, no? Yeah > ? > abstractj > > > On Wed, Jan 22, 2014 at 5:18 PM, Burr Sutter wrote: > > Does the overall team have a list of priorities? Things like: > Investigate Keycloak integration > Investigate Vert.x runtime vs Java EE runtime > Investigate LiveOak integration > Create and/or Improve Unified Push Server + Cordova + JBoss Tools Getting > Started Docs/Videos > etc > > It is easy for me to "lose sight of the forest for the trees" in Jira :-) > > > > On Jan 22, 2014, at 1:48 PM, Jay Balunas wrote: > > > On Jan 22, 2014, at 10:46 AM, Matthias Wessendorf > wrote: > > > > > On Wed, Jan 22, 2014 at 3:31 PM, Jay Balunas wrote: > > Hi Y'All, > > Saw the other day that the Ceylon[1] team has been working on some Android > support, especially around their tooling. Here are some links: > > ceylon-dev list posts: > > https://groups.google.com/d/msg/ceylon-dev/BNqosBRDuSI/WuqUWfxraQcJ > https://groups.google.com/d/msg/ceylon-dev/n2ZfmaW-I2M/GhZVEa_uV44J > > I had a quick chat with Gavin about this, and we think it could be neat if > we look into how we might be able to collaborate and/or provide some > feedback on their Android support and tooling. > > > sounds interesting, and taking a look does not hurt > > > > There could be some interesting ways to integrate between the projects :-) > > > sure, however, I think if we are now taking a (deeper) look at Keycloak, > perhaps thats something to focus on for now. > > However, as said, doing some sort of evaluation for a few days, and see if > ours works there etc, would be a nice task. > > > I agree, the keycloak integration is a higher priority. I just wanted to > raise this as a interesting opportunity not a "drop everything" and look :-) > > > > > Thoughts? > > - Jay > > [1] http://ceylon-lang.org/ > > > > > > > > _______________________________________________ > 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://w > > -- Sent from Gmail Mobile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140122/d3968761/attachment-0001.html From jbalunas at redhat.com Thu Jan 23 08:29:00 2014 From: jbalunas at redhat.com (Jay Balunas) Date: Thu, 23 Jan 2014 08:29:00 -0500 Subject: [aerogear-dev] Glass Dev + Firefighter == interesting idea Message-ID: <87F8CA81-5D92-470F-98A9-5490AE26F544@redhat.com> http://www.youtube.com/watch?v=QPbZy2wrTGk Just the start imo... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140123/77ffba9d/attachment.html From matzew at apache.org Thu Jan 23 11:11:33 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 23 Jan 2014 17:11:33 +0100 Subject: [aerogear-dev] UnifiedPush Server - 0.10.0 release In-Reply-To: References: Message-ID: Hi, there are a few items left, for User Management (see [1]). I have a very strong opinion in _not_ rushing these fixes in. Instead I'd vote for releasing the 0.10.0, AFTER these have been addressed, regardless if it is Feb 5th, 10th or 15th; Any thoughts ? -Matthias [1] http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-UPS-User-Management-open-items-following-up-td5900.html On Wed, Jan 15, 2014 at 9:28 AM, Matthias Wessendorf wrote: > Hi, > > originally we scheduled a release for today/this week. There will be a > 0.10.0 release of the UnifiedPush Server, but not today/this week. > > By the end of January we will release it; currently focus is on getting > the User Management done right and fixing minor issues. > > If you have any questions / concerns, let us know! > > Cheers! > Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- 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/20140123/26df2890/attachment.html From bruno at abstractj.org Thu Jan 23 11:17:53 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 23 Jan 2014 14:17:53 -0200 Subject: [aerogear-dev] UnifiedPush Server - 0.10.0 release In-Reply-To: References: Message-ID: +1 for?Feb 5th -- abstractj On January 23, 2014 at 2:11:40 PM, Matthias Wessendorf (matzew at apache.org) wrote: > > Hi, > > there are a few items left, for User Management (see [1]). I have > a very > strong opinion in _not_ rushing these fixes in. Instead I'd vote > for > releasing the 0.10.0, AFTER these have been addressed, regardless > if it is > Feb 5th, 10th or 15th; > > Any thoughts ? > > -Matthias > > > [1] > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-UPS-User-Management-open-items-following-up-td5900.html > > > On Wed, Jan 15, 2014 at 9:28 AM, Matthias Wessendorf wrote: > > > Hi, > > > > originally we scheduled a release for today/this week. There > will be a > > 0.10.0 release of the UnifiedPush Server, but not today/this > week. > > > > By the end of January we will release it; currently focus is on > getting > > the User Management done right and fixing minor issues. > > > > If you have any questions / concerns, let us know! > > > > Cheers! > > Matthias > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > > > -- > 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 From hbons at redhat.com Thu Jan 23 12:15:00 2014 From: hbons at redhat.com (Hylke Bons) Date: Thu, 23 Jan 2014 17:15:00 +0000 Subject: [aerogear-dev] Website suggestion: Team members page Message-ID: <52E14E14.9000204@redhat.com> Hey, What does everyone think about having a team members page on the website? I think it would be good for community engagement. It would have profile pictures, and maybe 2-3 lines about who you are and what you are doing on the project. It doesn't have to go in-depth. Maybe links to blogs and Twitter accounts would be nice too. Something like: http://openstack.redhat.com/People Let me know what you think. Hylke From corinnekrych at gmail.com Thu Jan 23 12:22:04 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 23 Jan 2014 18:22:04 +0100 Subject: [aerogear-dev] Website suggestion: Team members page In-Reply-To: <52E14E14.9000204@redhat.com> References: <52E14E14.9000204@redhat.com> Message-ID: <7192BD55-96F3-49C4-89AC-CB6B380709E8@gmail.com> +1 On 23 Jan 2014, at 18:15, Hylke Bons wrote: > Hey, > > What does everyone think about having a team members page on the website? > I think it would be good for community engagement. > > It would have profile pictures, and maybe 2-3 lines about who you are > and what you are doing on the project. It doesn't have to go in-depth. > Maybe links to blogs and Twitter accounts would be nice too. > > Something like: http://openstack.redhat.com/People > > Let me know what you think. > > Hylke > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Thu Jan 23 12:28:10 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 23 Jan 2014 18:28:10 +0100 Subject: [aerogear-dev] Website suggestion: Team members page In-Reply-To: <7192BD55-96F3-49C4-89AC-CB6B380709E8@gmail.com> References: <52E14E14.9000204@redhat.com> <7192BD55-96F3-49C4-89AC-CB6B380709E8@gmail.com> Message-ID: +1 like the idea. Gives faces to the website! Sure you can find these faces, by checking on GH ;-) but yeah... +1 on something like that -M On Thu, Jan 23, 2014 at 6:22 PM, Corinne Krych wrote: > +1 > On 23 Jan 2014, at 18:15, Hylke Bons wrote: > > > Hey, > > > > What does everyone think about having a team members page on the website? > > I think it would be good for community engagement. > > > > It would have profile pictures, and maybe 2-3 lines about who you are > > and what you are doing on the project. It doesn't have to go in-depth. > > Maybe links to blogs and Twitter accounts would be nice too. > > > > Something like: http://openstack.redhat.com/People > > > > Let me know what you think. > > > > Hylke > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140123/3f06edb6/attachment.html From bruno at abstractj.org Thu Jan 23 21:23:54 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 24 Jan 2014 00:23:54 -0200 Subject: [aerogear-dev] Website suggestion: Team members page In-Reply-To: References: <52E14E14.9000204@redhat.com> <7192BD55-96F3-49C4-89AC-CB6B380709E8@gmail.com> Message-ID: I'm not against it, but we have the same thing on GH https://github.com/orgs/aerogear/members On Thu, Jan 23, 2014 at 3:28 PM, Matthias Wessendorf wrote: > +1 like the idea. Gives faces to the website! Sure you can find these > faces, by checking on GH ;-) but yeah... +1 on something like that > > -M > > > On Thu, Jan 23, 2014 at 6:22 PM, Corinne Krych wrote: > >> +1 >> On 23 Jan 2014, at 18:15, Hylke Bons wrote: >> >> > Hey, >> > >> > What does everyone think about having a team members page on the >> website? >> > I think it would be good for community engagement. >> > >> > It would have profile pictures, and maybe 2-3 lines about who you are >> > and what you are doing on the project. It doesn't have to go in-depth. >> > Maybe links to blogs and Twitter accounts would be nice too. >> > >> > Something like: http://openstack.redhat.com/People >> > >> > Let me know what you think. >> > >> > Hylke >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140124/1283c3e4/attachment-0001.html From aemmanou at redhat.com Fri Jan 24 04:20:42 2014 From: aemmanou at redhat.com (Apostolos Emmanouilidis) Date: Fri, 24 Jan 2014 10:20:42 +0100 Subject: [aerogear-dev] Website suggestion: Team members page In-Reply-To: References: <52E14E14.9000204@redhat.com> <7192BD55-96F3-49C4-89AC-CB6B380709E8@gmail.com> Message-ID: <1390555242.2538.5.camel@dhcp129-205.brq.redhat.com> it would be nice to create a contributors page instead of a team members page. something similar to JBoss Arquillian contributors page [1]. This would motivate people outside the team members to contribute to the project and get involved. [1]: http://arquillian.org/community/contributors/ On Fri, 2014-01-24 at 00:23 -0200, Bruno Oliveira wrote: > I'm not against it, but we have the same thing on > GH https://github.com/orgs/aerogear/members > > > > On Thu, Jan 23, 2014 at 3:28 PM, Matthias Wessendorf > wrote: > > +1 like the idea. Gives faces to the website! Sure you can > find these faces, by checking on GH ;-) but yeah... +1 on > something like that > > > > -M > > > > On Thu, Jan 23, 2014 at 6:22 PM, Corinne Krych > wrote: > > +1 > > On 23 Jan 2014, at 18:15, Hylke Bons > wrote: > > > Hey, > > > > What does everyone think about having a team members > page on the website? > > I think it would be good for community engagement. > > > > It would have profile pictures, and maybe 2-3 lines > about who you are > > and what you are doing on the project. It doesn't > have to go in-depth. > > Maybe links to blogs and Twitter accounts would be > nice too. > > > > Something like: http://openstack.redhat.com/People > > > > Let me know what you think. > > > > Hylke > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > -- > > > > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > > _______________________________________________ > 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/20140124/25839616/attachment.html From qmx at qmx.me Fri Jan 24 07:02:52 2014 From: qmx at qmx.me (Douglas Campos) Date: Fri, 24 Jan 2014 10:02:52 -0200 Subject: [aerogear-dev] Website suggestion: Team members page In-Reply-To: <1390555242.2538.5.camel@dhcp129-205.brq.redhat.com> References: <52E14E14.9000204@redhat.com> <7192BD55-96F3-49C4-89AC-CB6B380709E8@gmail.com> <1390555242.2538.5.camel@dhcp129-205.brq.redhat.com> Message-ID: <20140124120252.GC7065@rohan.local> On Fri, Jan 24, 2014 at 10:20:42AM +0100, Apostolos Emmanouilidis wrote: > it would be nice to create a contributors page instead of a team members > page. something similar to JBoss Arquillian contributors page [1]. > This would motivate people outside the team members to contribute to the > project and get involved. > > [1]: http://arquillian.org/community/contributors/ +9001 -- qmx From edewit at redhat.com Fri Jan 24 07:10:25 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Fri, 24 Jan 2014 13:10:25 +0100 Subject: [aerogear-dev] Website suggestion: Team members page In-Reply-To: <1390555242.2538.5.camel@dhcp129-205.brq.redhat.com> References: <52E14E14.9000204@redhat.com> <7192BD55-96F3-49C4-89AC-CB6B380709E8@gmail.com> <1390555242.2538.5.camel@dhcp129-205.brq.redhat.com> Message-ID: <615B01B7-8BB1-48E2-9589-3BF2F7B5D00D@redhat.com> Great idea, what would also be good to motivate contributions is something like brackets does http://brackets.io/contribute.html Where they have selected issue people can fix to get started On 24 Jan,2014, at 10:20 , Apostolos Emmanouilidis wrote: > it would be nice to create a contributors page instead of a team members page. something similar to JBoss Arquillian contributors page [1]. > This would motivate people outside the team members to contribute to the project and get involved. > > [1]: http://arquillian.org/community/contributors/ > > > On Fri, 2014-01-24 at 00:23 -0200, Bruno Oliveira wrote: >> >> I'm not against it, but we have the same thing on GH https://github.com/orgs/aerogear/members >> >> >> On Thu, Jan 23, 2014 at 3:28 PM, Matthias Wessendorf wrote: >> +1 like the idea. Gives faces to the website! Sure you can find these faces, by checking on GH ;-) but yeah... +1 on something like that >> >> >> -M >> >> >> On Thu, Jan 23, 2014 at 6:22 PM, Corinne Krych wrote: >> +1 >> On 23 Jan 2014, at 18:15, Hylke Bons wrote: >> >> > Hey, >> > >> > What does everyone think about having a team members page on the website? >> > I think it would be good for community engagement. >> > >> > It would have profile pictures, and maybe 2-3 lines about who you are >> > and what you are doing on the project. It doesn't have to go in-depth. >> > Maybe links to blogs and Twitter accounts would be nice too. >> > >> > Something like: http://openstack.redhat.com/People >> > >> > Let me know what you think. >> > >> > Hylke >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> -- >> >> >> -- >> "The measure of a man is what he does with power" - Plato >> - >> @abstractj >> - >> Volenti Nihil Difficile >> _______________________________________________ >> 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/20140124/df036099/attachment.html From qmx at qmx.me Fri Jan 24 07:42:08 2014 From: qmx at qmx.me (Douglas Campos) Date: Fri, 24 Jan 2014 10:42:08 -0200 Subject: [aerogear-dev] [aerogear.org] monster sass branch Message-ID: <20140124124208.GE7065@rohan.local> Howdy! The sass branch is becoming a monster[1]! Could we please land this on master soon or start splitting unrelated changes? I don't even want to see what will happen on merge time :P Also, it looks like there are unrelated changes on this branch - am I crazy? Thanks! [1]:https://github.com/aerogear/aerogear.org/compare/sass -- qmx From lholmqui at redhat.com Fri Jan 24 07:45:14 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 24 Jan 2014 07:45:14 -0500 Subject: [aerogear-dev] [aerogear.org] monster sass branch In-Reply-To: <20140124124208.GE7065@rohan.local> References: <20140124124208.GE7065@rohan.local> Message-ID: On Jan 24, 2014, at 7:42 AM, Douglas Campos wrote: > Howdy! > > The sass branch is becoming a monster[1]! > > Could we please land this on master soon or start splitting unrelated > changes? I don't even want to see what will happen on merge time :P > > Also, it looks like there are unrelated changes on this branch - am I > crazy? yes, but not about this, bad rebase? or other git buzzword > > Thanks! > > [1]:https://github.com/aerogear/aerogear.org/compare/sass > > -- > qmx > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From corinnekrych at gmail.com Fri Jan 24 07:45:47 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 24 Jan 2014 13:45:47 +0100 Subject: [aerogear-dev] [aerogear.org] monster sass branch In-Reply-To: <20140124124208.GE7065@rohan.local> References: <20140124124208.GE7065@rohan.local> Message-ID: <47529285-1B7A-4920-884F-6817A6D5D687@gmail.com> Jan 17th seems to come from a rebase, no? It?s not related indeed On 24 Jan 2014, at 13:42, Douglas Campos wrote: > Howdy! > > The sass branch is becoming a monster[1]! > > Could we please land this on master soon or start splitting unrelated > changes? I don't even want to see what will happen on merge time :P > > Also, it looks like there are unrelated changes on this branch - am I > crazy? > > Thanks! > > [1]:https://github.com/aerogear/aerogear.org/compare/sass > > -- > qmx > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From bruno at abstractj.org Fri Jan 24 07:51:30 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 24 Jan 2014 10:51:30 -0200 Subject: [aerogear-dev] Website suggestion: Team members page In-Reply-To: <1390555242.2538.5.camel@dhcp129-205.brq.redhat.com> References: <52E14E14.9000204@redhat.com> <7192BD55-96F3-49C4-89AC-CB6B380709E8@gmail.com> <1390555242.2538.5.camel@dhcp129-205.brq.redhat.com> Message-ID: Gotcha +1 -- abstractj On January 24, 2014 at 7:20:46 AM, Apostolos Emmanouilidis (aemmanou at redhat.com) wrote: > > it would be nice to create a contributors page instead of a team > members page. something similar to JBoss Arquillian contributors > page [1]. > This would motivate people outside the team members to contribute > to the project and get involved. > > [1]: http://arquillian.org/community/contributors/ From lholmqui at redhat.com Fri Jan 24 07:58:40 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Fri, 24 Jan 2014 07:58:40 -0500 Subject: [aerogear-dev] Website suggestion: Team members page In-Reply-To: <1390555242.2538.5.camel@dhcp129-205.brq.redhat.com> References: <52E14E14.9000204@redhat.com> <7192BD55-96F3-49C4-89AC-CB6B380709E8@gmail.com> <1390555242.2538.5.camel@dhcp129-205.brq.redhat.com> Message-ID: <182429E7-C9C0-477E-824D-D3A429C3C43E@redhat.com> On Jan 24, 2014, at 4:20 AM, Apostolos Emmanouilidis wrote: > it would be nice to create a contributors page instead of a team members page. something similar to JBoss Arquillian contributors page [1]. > This would motivate people outside the team members to contribute to the project and get involved. > > [1]: http://arquillian.org/community/contributors/ oh snap, i'm on that list > > > On Fri, 2014-01-24 at 00:23 -0200, Bruno Oliveira wrote: >> >> I'm not against it, but we have the same thing on GH https://github.com/orgs/aerogear/members >> >> >> On Thu, Jan 23, 2014 at 3:28 PM, Matthias Wessendorf wrote: >> +1 like the idea. Gives faces to the website! Sure you can find these faces, by checking on GH ;-) but yeah... +1 on something like that >> >> >> -M >> >> >> On Thu, Jan 23, 2014 at 6:22 PM, Corinne Krych wrote: >> +1 >> On 23 Jan 2014, at 18:15, Hylke Bons wrote: >> >> > Hey, >> > >> > What does everyone think about having a team members page on the website? >> > I think it would be good for community engagement. >> > >> > It would have profile pictures, and maybe 2-3 lines about who you are >> > and what you are doing on the project. It doesn't have to go in-depth. >> > Maybe links to blogs and Twitter accounts would be nice too. >> > >> > Something like: http://openstack.redhat.com/People >> > >> > Let me know what you think. >> > >> > Hylke >> > _______________________________________________ >> > aerogear-dev mailing list >> > aerogear-dev at lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> -- >> >> >> -- >> "The measure of a man is what he does with power" - Plato >> - >> @abstractj >> - >> Volenti Nihil Difficile >> _______________________________________________ >> 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/20140124/15b8abdf/attachment.html From bsutter at redhat.com Fri Jan 24 08:18:45 2014 From: bsutter at redhat.com (Burr Sutter) Date: Fri, 24 Jan 2014 08:18:45 -0500 Subject: [aerogear-dev] AeroGear & Ceylon Android support In-Reply-To: References: <1390424000677.779a4d98@Nodemailer> Message-ID: <98B72CCC-482F-45F7-A5C0-D4ADD8BE9A08@redhat.com> This document? http://aerogear.org/docs/planning/roadmaps/AeroGearRoadMap/ I notice there are no years, just months, allows for flexibility :-) On Jan 22, 2014, at 3:58 PM, Matthias Wessendorf wrote: > > > On Wednesday, January 22, 2014, Bruno Oliveira wrote: > That's what roadmaps stand for, no? > > Yeah > > > > ? > abstractj > > > On Wed, Jan 22, 2014 at 5:18 PM, Burr Sutter wrote: > > Does the overall team have a list of priorities? Things like: > > Investigate Keycloak integration > Investigate Vert.x runtime vs Java EE runtime > Investigate LiveOak integration > Create and/or Improve Unified Push Server + Cordova + JBoss Tools Getting Started Docs/Videos > etc > > It is easy for me to "lose sight of the forest for the trees" in Jira :-) > > > > On Jan 22, 2014, at 1:48 PM, Jay Balunas wrote: > >> >> On Jan 22, 2014, at 10:46 AM, Matthias Wessendorf wrote: >> >>> >>> >>> >>> On Wed, Jan 22, 2014 at 3:31 PM, Jay Balunas wrote: >>> Hi Y'All, >>> >>> Saw the other day that the Ceylon[1] team has been working on some Android support, especially around their tooling. Here are some links: >>> >>> ceylon-dev list posts: >>> >>> https://groups.google.com/d/msg/ceylon-dev/BNqosBRDuSI/WuqUWfxraQcJ >>> https://groups.google.com/d/msg/ceylon-dev/n2ZfmaW-I2M/GhZVEa_uV44J >>> >>> I had a quick chat with Gavin about this, and we think it could be neat if we look into how we might be able to collaborate and/or provide some feedback on their Android support and tooling. >>> >>> sounds interesting, and taking a look does not hurt >>> >>> >>> There could be some interesting ways to integrate between the projects :-) >>> >>> sure, however, I think if we are now taking a (deeper) look at Keycloak, perhaps thats something to focus on for now. >>> >>> However, as said, doing some sort of evaluation for a few days, and see if ours works there etc, would be a nice task. >> >> I agree, the keycloak integration is a higher priority. I just wanted to raise this as a interesting opportunity not a "drop everything" and look :-) >> >>> >>> >>> Thoughts? >>> >>> - Jay >>> >>> [1] http://ceylon-lang.org/ >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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://w > > > -- > 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/20140124/d3aed421/attachment-0001.html From matzew at apache.org Fri Jan 24 08:26:55 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 24 Jan 2014 14:26:55 +0100 Subject: [aerogear-dev] AeroGear & Ceylon Android support In-Reply-To: <98B72CCC-482F-45F7-A5C0-D4ADD8BE9A08@redhat.com> References: <1390424000677.779a4d98@Nodemailer> <98B72CCC-482F-45F7-A5C0-D4ADD8BE9A08@redhat.com> Message-ID: On Fri, Jan 24, 2014 at 2:18 PM, Burr Sutter wrote: > This document? > http://aerogear.org/docs/planning/roadmaps/AeroGearRoadMap/ > > I notice there are no years, just months, allows for flexibility :-) > +1 > > > On Jan 22, 2014, at 3:58 PM, Matthias Wessendorf > wrote: > > > > On Wednesday, January 22, 2014, Bruno Oliveira > wrote: > >> That's what roadmaps stand for, no? > > > Yeah > > > > >> ? >> abstractj >> >> >> On Wed, Jan 22, 2014 at 5:18 PM, Burr Sutter wrote: >> >> Does the overall team have a list of priorities? Things like: >> Investigate Keycloak integration >> Investigate Vert.x runtime vs Java EE runtime >> Investigate LiveOak integration >> Create and/or Improve Unified Push Server + Cordova + JBoss Tools Getting >> Started Docs/Videos >> etc >> >> It is easy for me to "lose sight of the forest for the trees" in Jira :-) >> >> >> >> On Jan 22, 2014, at 1:48 PM, Jay Balunas wrote: >> >> >> On Jan 22, 2014, at 10:46 AM, Matthias Wessendorf >> wrote: >> >> >> >> >> On Wed, Jan 22, 2014 at 3:31 PM, Jay Balunas wrote: >> >> Hi Y'All, >> >> Saw the other day that the Ceylon[1] team has been working on some >> Android support, especially around their tooling. Here are some links: >> >> ceylon-dev list posts: >> >> https://groups.google.com/d/msg/ceylon-dev/BNqosBRDuSI/WuqUWfxraQcJ >> https://groups.google.com/d/msg/ceylon-dev/n2ZfmaW-I2M/GhZVEa_uV44J >> >> I had a quick chat with Gavin about this, and we think it could be neat >> if we look into how we might be able to collaborate and/or provide some >> feedback on their Android support and tooling. >> >> >> sounds interesting, and taking a look does not hurt >> >> >> >> There could be some interesting ways to integrate between the projects :-) >> >> >> sure, however, I think if we are now taking a (deeper) look at Keycloak, >> perhaps thats something to focus on for now. >> >> However, as said, doing some sort of evaluation for a few days, and see >> if ours works there etc, would be a nice task. >> >> >> I agree, the keycloak integration is a higher priority. I just wanted to >> raise this as a interesting opportunity not a "drop everything" and look :-) >> >> >> >> >> Thoughts? >> >> - Jay >> >> [1] http://ceylon-lang.org/ >> >> >> >> >> >> >> >> _______________________________________________ >> 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://w >> >> > > -- > 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 > -- 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/20140124/1df1ce65/attachment.html From edewit at redhat.com Fri Jan 24 08:32:09 2014 From: edewit at redhat.com (Erik Jan de Wit) Date: Fri, 24 Jan 2014 14:32:09 +0100 Subject: [aerogear-dev] Website suggestion: Team members page In-Reply-To: <182429E7-C9C0-477E-824D-D3A429C3C43E@redhat.com> References: <52E14E14.9000204@redhat.com> <7192BD55-96F3-49C4-89AC-CB6B380709E8@gmail.com> <1390555242.2538.5.camel@dhcp129-205.brq.redhat.com> <182429E7-C9C0-477E-824D-D3A429C3C43E@redhat.com> Message-ID: On 24 Jan,2014, at 13:58 , Lucas Holmquist wrote: > > On Jan 24, 2014, at 4:20 AM, Apostolos Emmanouilidis wrote: > >> it would be nice to create a contributors page instead of a team members page. something similar to JBoss Arquillian contributors page [1]. >> This would motivate people outside the team members to contribute to the project and get involved. >> >> [1]: http://arquillian.org/community/contributors/ > > oh snap, i'm on that list > so am I -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140124/f64d28ac/attachment.html From bruno at abstractj.org Fri Jan 24 09:10:47 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Fri, 24 Jan 2014 12:10:47 -0200 Subject: [aerogear-dev] AeroGear & Ceylon Android support In-Reply-To: References: <1390424000677.779a4d98@Nodemailer> <98B72CCC-482F-45F7-A5C0-D4ADD8BE9A08@redhat.com> Message-ID: Nope http://aerogear.org/docs/planning/ for dates, please refer to the sub projects. -- abstractj On January 24, 2014 at 11:27:03 AM, Matthias Wessendorf (matzew at apache.org) wrote: > > This document? > http://aerogear.org/docs/planning/roadmaps/AeroGearRoadMap/ > > I notice there are no years, just months, allows for flexibility > :-) From corinnekrych at gmail.com Fri Jan 24 09:58:27 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Fri, 24 Jan 2014 15:58:27 +0100 Subject: [aerogear-dev] Website restructure In-Reply-To: <52DFC3ED.2060405@redhat.com> References: <2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com> <20140120123559.3a3aec13@kapy-ntb-x220> <52DE6B7B.6050202@redhat.com> <20140122130302.233deb81@kapy-ntb-x220> <52DFC3ED.2060405@redhat.com> Message-ID: Hello All, I?ve being working on sass branch [1], the same branch Erik-Jan did its initial work. Here is more feedback on our site redesign 1. Example page with each language code snippet It?s a good idea, to show the unified aspect of our libs. Having a short snippet code is great, however it?s not possible to fit the detailed example we alreday have in our documentation. Rather than simplifying and not going into details, I think we could have a main page like [2] which give the definition + each snippet. Below the code snipet I?ve added a link: Read more on Pipes on Android / Pipes on iOS / Paging on Web which points to detailled page. I think we should keep this documetation. It goes deeper in the sample code as opposed to snippet which is not necessarly complete code. One think that we could do is use code sample extracted from our cookbook recipe. So we can point to the repository for the full app code. @Hylke Do you have a better idea than just a simple link? I think it?s not visual enough. And what should be the layout of the detailled example page? 2. New structure As hylke asked for it, here a proposal, wdyt? _ Core __ Pipe __ Paging __ Store _ Security __ Authentication __ Encryption _ Push __ Registration __ Sender 3. Refactoring of each documentaiton is needed to fit this structure: How do we want to proceed? One guy is doing the full refactor of doc (poor guy) or we split it into a bunch of JIRAs? Maybe as @qmx suggested once we?ve go the structure we could merge the PR and find a way to progressively refactor. 4. markdown or asciidoc ? It?s a great opportunity to unify our doc. asciidoc offers great plugins. For example page, we use tab plugin. 5. Dracula theme vs White theme If you uncomment [3] you can have a white theme. A shame that with Dracula theme we loose the AeroGear blue and orange logo... @Hylke for the dracula theme we need AG logo in each of the 3 colors. 5. Menu @Hylke you said you want to remove the actual menu, but what do you propose to navigate between topic: Core/Security/Push/Sync 6. Mobile site New design need to be responsive. Actual CSS are not any more. But we can fix them ;) ++ Corinne [1] https://github.com/aerogear/aerogear.org/tree/sass [2] http://localhost:4000/docs/guides/new/index/ [3] https://github.com/aerogear/aerogear.org/blob/sass/sass/main.sass#L117 On 22 Jan 2014, at 14:13, Hylke Bons wrote: > On 22/01/2014 13:00, Corinne Krych wrote: >> I like the original idea in the mockup (core/Security/Push), maybe we can introduce sub-section like: >> - Core (pipe - paging / store) >> - Security(authentication - OTP - OAuth2 / encryption / >> - Push (push registration / sender api / UPS - Simple Push) >> - Sync >> >> wdyt? >> ++ >> Corinne > > Yes, exactly that! :) > I'm doing that as we speak, but I'm not sure what all the (useful) > classes are. > > Hylke > > > > >> On 22 Jan 2014, at 13:03, Karel Piwko wrote: >> >>> On Tue, 21 Jan 2014 12:43:39 +0000 >>> Hylke Bons wrote: >>> >>>> On 20/01/2014 17:31, Corinne Krych wrote: >>>>>> On Mon, Jan 20, 2014 at 12:35 PM, Karel Piwko wrote: >>>>>> Looks good! >>>>>> +1 I like the dracula theme ! >>>>>> >>>>>> Apart for platform related code (JavaScript, Objective-C, Java), are there >>>>>> any plans to support platform related text? >>>>>> >>>>>> E.g. pipes on Aerogear can be used within FragmentActivity, which is valid >>>>>> for Android only; Javadoc is not related to iOS, etc. That's basically a >>>>>> merge of our guides into a one per feature with information covering all >>>>>> the platforms. >>>> Is there a list of the most important features/classes/objects that I >>>> can use in the mockup? >>> I'm not aware of any. Trying to compose list of features, I'd go for: >>> >>> * Push Messages >>> * Pipes >>> * Authentication >>> ** OTP >>> * Crypto >>> >>> >>>>>> Which brings me to and idea of global platform switch. User/reader can >>>>>> switch platform once and all code snippets and platform related blocks are >>>>>> automatically selected. Can also be session based and affect all pages user >>>>>> visits. >>>> Interesting idea. :) >>>> >>>> Hylke >>>> >>>> _______________________________________________ >>>> 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 aemmanou at redhat.com Fri Jan 24 10:30:11 2014 From: aemmanou at redhat.com (Apostolos Emmanouilidis) Date: Fri, 24 Jan 2014 16:30:11 +0100 Subject: [aerogear-dev] aerogear-js Mozilla's Persona authentication adapter In-Reply-To: <3D1DA411-328B-4605-A00B-ED6AACDD58BD@redhat.com> References: <734665923.4117587.1390383478992.JavaMail.root@redhat.com> <1126554180.4118114.1390383665653.JavaMail.root@redhat.com> <3D1DA411-328B-4605-A00B-ED6AACDD58BD@redhat.com> Message-ID: <1390577411.2538.14.camel@dhcp129-205.brq.redhat.com> I have created a new branch which contains an example using the navigator.id watch-request methods instead of the get method which is used in the master branch and added session support to the server [1]. The AeroGear persona adapter API still needs many improvements and redesign :) What worries me about Mozilla's Persona sign-in system is that even if you sign out with Persona, you should remember to explicitly sign out of your personal email account as well. Otherwise the next person who will sit over a shared computer, will be able to to sign in to the Persona service without entering a password [2]. I don't know if the lesson is, to never share your computer :) [1]: https://github.com/tolis-e/aerogear-js-persona-authentication-poc/tree/persona_watch-request [2]: https://support.mozilla.org/el/kb/signing-out-using-persona On Wed, 2014-01-22 at 08:32 -0500, Lucas Holmquist wrote: > sounds cool, i'll take a look > On Jan 22, 2014, at 4:41 AM, Apostolos Emmanouilidis wrote: > > > hello, > > > > while looking at AGJS-122 and the possibility to add an authentication adapter which is based on Mozilla's Persona sign-in system, I was thinking of the following API: > > > > // Construct an AeroGear.Authentication.adapters.Persona > > var persona = AeroGear.Auth({ > > name: 'persona', > > type: 'Persona', > > settings: { > > verificationEndpoint: "http://127.0.0.1:3000/verify" > > } > > }).modules.persona; > > > > // use login to initiate the Mozilla's Persona authentication procedure. login enables the BrowserID and generates a signed assertion which contains the user's email address > > // on assertion generation call the verification service > > persona.login({ > > onAssertion: function ( assertion ) { > for consistency, i would probably call this callback 'success' > > // the verification API receives the assertion and the audience (our website URL) as parameters > > // for security reasons there must be an intermediate service between the client and the verification API. the reason for which we want the intermediate service > > // is that we want to ensure that the audience parameter is not hacked. I was thinking that it is better to avoid adding the persona.verify call inside our adapter > > // since this way we would force the user to create the intermediate service according our implementation. That's why the following line exists: > > persona.verify( { assertion: assertion }, { success: onSuccessVerification, error: onFailedVerification } ); > > }, > > error: onLoginError > > }); > > > > // logout > > persona.logout( onLogout ); > > i know for the REST adapter we also have an "enroll" method, not sure if that makes sense for this one. I haven't really looked at the Persona thing to much, just a shiny object that i saw and created a JIRA > > > > > I have added a working example in: https://github.com/tolis-e/aerogear-js-persona-authentication-poc > > and a first implementation sample: https://github.com/aerogear/aerogear-js/pull/100 > > > > In order you'd like to try the working example on Android emulator, change lines: > > https://github.com/tolis-e/aerogear-js-persona-authentication-poc/blob/master/static/persona-test.html#L16 > > and > > https://github.com/tolis-e/aerogear-js-persona-authentication-poc/blob/master/server.js#L29 > > to use host 10.0.2.2 > > and open the http://10.0.2.2:3000/persona-test.html page on the Android browser > > > > > > any thoughts, suggestions? > > _______________________________________________ > > 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/20140124/16ca2217/attachment-0001.html From matzew at apache.org Fri Jan 24 12:05:51 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Fri, 24 Jan 2014 18:05:51 +0100 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: References: Message-ID: I have updated the branch w/ their recent changes from this weeks alpha-1 release, and submitted a PR against abstractj's repo: https://github.com/abstractj/aerogear-unifiedpush-server/pull/1 More to come Greetings, Matthias On Fri, Dec 20, 2013 at 1:11 PM, Bruno Oliveira wrote: > Good morning peeps, yesterday I started to replace AeroGear Security on > Unified Push server by Keycloak and you might be asking: ?Why??. Keycloak > is a SSO with some handy features like TOTP, OAuth2, user management > support and I think we have too much to contribute, is the only way to have > some success with security, ?divide to conquer" (at least for authorization > and authentication). > > So will ag-security be discontinued? No! Keycloak is still on Alpha and we > have to test it against our projects before fully replace ag-security, but > the only way to upstream our needs, is to using it. > > This replacement only applies to authentication/authorization features, we > still have a ton of projects which Keycloak is not able to replace like: > TOTP, crypto and OAuth2 on mobile, our focus. > > - PoC > > So let?s talk about this replacement, any dependency on ag-security was > removed from the push server and replaced by Keycloak: > https://github.com/abstractj/aerogear-unifiedpush-server/tree/openshift > > Based on Keycloak examples, I just did copy & paste from one of the demos ( > https://github.com/abstractj/auth-server/tree/openshift) to create a > server. Keycloak requires Resteasy 3.0.4, for this reason I had to manually > replace some modules on JBoss. > > To test it go to: http://push-abstractj.rhcloud.com/ag-push/ you must be > redirected to Keycloak, enter: > > username: john at doe.com > password: password > > You must be redirected to agpush console, keep in mind that I took some > shortcuts to get this demo working, so for example the create will fail > because I removed everything related into the ember interface. > > Is also possible to enable TOTP, user?s registration and whatever you want. > > So what do you think? > > -- > abstractj > > _______________________________________________ > 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/20140124/e070e54a/attachment.html From hbons at redhat.com Fri Jan 24 12:14:23 2014 From: hbons at redhat.com (Hylke Bons) Date: Fri, 24 Jan 2014 17:14:23 +0000 Subject: [aerogear-dev] Website restructure In-Reply-To: References: <2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com> <20140120123559.3a3aec13@kapy-ntb-x220> Message-ID: <52E29F6F.7080300@redhat.com> Hi Corinne, I've updated the mockup with a sidebar to show the structure a bit better: https://raw2.github.com/hbons/aerogear-design/master/website-restructure/aerogear-project.png I think this is mostly like what you've described. Other changes are a simple menubar and the platform icons on the main page that we decided we wanted back. "where do we put documentation like: http://aerogear.org/docs/guides/GetStartedAndroid/ which is not features oriented but goes into the category setup " This should actually go right below the download options (see the second page in the mockup). There will also a link to it in the Docs sidebar. It's a bit hard to explain in an email, I think the mockup explains it better. :) Hylke On 20/01/2014 17:31, Corinne Krych wrote: > Hello All > > I think the original idea was to have a common text. I think we could have common part for exemple: > http://aerogear.org/docs/guides/aerogear-android/AerogearAndroidPipes101/ > http://aerogear.org/docs/guides/iOSCookbook/ (section on pipe) > http://aerogear.org/docs/guides/GetStartedAeroGearJS.html (section Pipeline & Pipes) > all defined Pipe and pipeline, they could have a common part but of course this will involve some serious documentation refactoring. > > => first task make common smaller pages > > However, we still need platform specific text. In all the previous exemple we give code snippet + code explantion. We could extend the tab to include text + sample. > > What will be nice to have as a POC is also: > - the main documentation page with the 3 features section: Core/Push/Security > - when we pick core, the display of the list of features: Pipe, Store etc?. which is actually missing from Hylke draft. > - where do we put documentation like: > http://aerogear.org/docs/guides/GetStartedAndroid/ > which is not features oriented but goes into the category setup > > I?ll fork your branch and try to see how we can refactor documentation and give you more concrete feedbacks shortly. > For the menu color I guess the best person to help is Hylke. > > ++ > Corinne > > > On 20 Jan 2014, at 12:44, Sebastien Blanc wrote: > >> >> >> On Mon, Jan 20, 2014 at 12:35 PM, Karel Piwko wrote: >> Looks good! >> +1 I like the dracula theme ! >> >> Apart for platform related code (JavaScript, Objective-C, Java), are there any >> plans to support platform related text? >> >> E.g. pipes on Aerogear can be used within FragmentActivity, which is valid for >> Android only; Javadoc is not related to iOS, etc. That's basically a merge of >> our guides into a one per feature with information covering all the platforms. >> >> Which brings me to and idea of global platform switch. User/reader can switch >> platform once and all code snippets and platform related blocks are >> automatically selected. Can also be session based and affect all pages user >> visits. >> >> +1 , that would be really cool. I came accross such a layout on https://www.paymill.com/fr-fr/documentation/reference/api-reference/#document-authentication , check on the right, you have a tab where you can switch between different languages, the snippet is updated. >> >> There are also some online apps that does the job for you like apiary.io and https://www.mashape.com >> >> Karel >> >> On Mon, 20 Jan 2014 11:37:28 +0100 >> Erik Jan de Wit wrote: >> >>> Hi, >>> >>> What I get from this thread is that we like the colour section idea, but we >>> don?t want to re structure the entire site. So what we need to discuss is how >>> are we going to use these sections if we don?t restructure. What I like about >>> them is that it emphasises that our API?s are similar for all platforms and >>> that we only have one document explaining for instance what pipes are. But >>> the menu, doesn?t fit into this new colour scheme, so we need some decisions >>> about how we are going to move forward. >>> >>> Based on the work Corinne did with the introduction of sass I?ve had a go at >>> implementing a bit what Hylke proposed, have a look at my sass branch >>> https://github.com/edewit/aerogear.org/tree/saas and the page I?ve updated >>> http://localhost:4000/docs/guides/aerogear-android/AerogearAndroidPipes101/ >>> to be in section layout. Don?t look at the header and footer as I haven?t >>> changed those. >>> >>> There are a couple of things that I don?t like about the current >>> implementation, to enable the code blocks I?ve added some html into the >>> asciidoc and some jquery magic in the layout. Maybe we could make this better >>> by chaining the rendering/backend or by introducing some sort of plugin into >>> asciidoc? Other then that, I?m sure Hylke sees a lot of things that are still >>> off, but it?s a start. >>> >>> What do you think? >>> >>> Cheers, >>> Erik Jan >>> >>> p.s >>> example picture https://www.dropbox.com/s/qtc4g0xwnyi0p41/Example.tiff >>> >> _______________________________________________ >> 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 hbons at redhat.com Fri Jan 24 13:08:04 2014 From: hbons at redhat.com (Hylke Bons) Date: Fri, 24 Jan 2014 18:08:04 +0000 Subject: [aerogear-dev] Website restructure In-Reply-To: References: <2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com> <20140120123559.3a3aec13@kapy-ntb-x220> <52DE6B7B.6050202@redhat.com> <20140122130302.233deb81@kapy-ntb-x220> <52DFC3ED.2060405@redhat.com> Message-ID: <52E2AC04.1010306@redhat.com> Hey, On 24/01/2014 14:58, Corinne Krych wrote: > Hello All, > > I?ve being working on sass branch [1], the same branch Erik-Jan did its initial work. > Here is more feedback on our site redesign > > 1. Example page with each language code snippet > It?s a good idea, to show the unified aspect of our libs. Having a short snippet code is great, however it?s not possible to fit the detailed example we alreday have in our documentation. Rather than simplifying and not going into details, I think we could have a main page like [2] which give the definition + each snippet. Below the code snipet I?ve added a link: > Read more on Pipes on Android / Pipes on iOS / Paging on Web > which points to detailled page. > > I think we should keep this documetation. It goes deeper in the sample code as opposed to snippet which is not necessarly complete code. One think that we could do is use code sample extracted from our cookbook recipe. So we can point to the repository for the full app code. > > @Hylke Do you have a better idea than just a simple link? I think it?s not visual enough. And what should be the layout of the detailled example page? The [2] link is on localhost. :) How about we try it out for Pipes and see how it goes? Yes, we probably would need to move some stuff out to other sections, but that's ok. We'll have a better ideas what to do with the "excess" docs once we try any simplify the multiple documents into one. Here's the idea for the scopes I had: - Examples => High level overview of AeroGear concepts and code snippets about how they're used. Not neccesarily big programmes. - Documentation - Getting started => Download and setup - API Browser => just a link to the full API overview - Guides: We can go more all out here. Tutorials, example projects, more complex configurations, etc. Basically everything else that doesn't fall into the above categories. :) I know it's a lot of work... I do think it's the best way to go. I'd be happy to help out on this too, though I've absolutely no clue on the topic, but that may actually be a good thing for explaining stuff to people new to the concepts. :) > > > 5. Dracula theme vs White theme > If you uncomment [3] you can have a white theme. A shame that with Dracula theme we loose the AeroGear blue and orange logo... > @Hylke for the dracula theme we need AG logo in each of the 3 colors. Yes, I'll send you those. Don't worry about the theming too much, as we haven't really discussed that yet. The "Dracula" theme was more of an example of how we can use colours to mark different sections of the project/site. So if you'd like to see things different, let me know! :) > 5. Menu > @Hylke you said you want to remove the actual menu, but what do you propose to navigate between topic: Core/Security/Push/Sync I've actually added it back in the mockup (see the other email on the thread). It was more of a time thing that I hadn't added it yet. It's back now. Hylke From matzew at apache.org Sun Jan 26 06:11:49 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sun, 26 Jan 2014 12:11:49 +0100 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: References: Message-ID: Hello! I have a few more updates: On my branch (a fork from Bruno's branch), the URLs for the actual sending and the device-registration (both 'protected' via HTTP-Basic), now work again. I have 'limited' the scope of the Keycloak 'protection' to the AdminUI. Greetings, Matthias On Fri, Jan 24, 2014 at 6:05 PM, Matthias Wessendorf wrote: > I have updated the branch w/ their recent changes from this weeks alpha-1 > release, and submitted a PR against abstractj's repo: > https://github.com/abstractj/aerogear-unifiedpush-server/pull/1 > > More to come > > Greetings, > Matthias > > > > On Fri, Dec 20, 2013 at 1:11 PM, Bruno Oliveira wrote: > >> Good morning peeps, yesterday I started to replace AeroGear Security on >> Unified Push server by Keycloak and you might be asking: ?Why??. Keycloak >> is a SSO with some handy features like TOTP, OAuth2, user management >> support and I think we have too much to contribute, is the only way to have >> some success with security, ?divide to conquer" (at least for authorization >> and authentication). >> >> So will ag-security be discontinued? No! Keycloak is still on Alpha and >> we have to test it against our projects before fully replace ag-security, >> but the only way to upstream our needs, is to using it. >> >> This replacement only applies to authentication/authorization features, >> we still have a ton of projects which Keycloak is not able to replace like: >> TOTP, crypto and OAuth2 on mobile, our focus. >> >> - PoC >> >> So let?s talk about this replacement, any dependency on ag-security was >> removed from the push server and replaced by Keycloak: >> https://github.com/abstractj/aerogear-unifiedpush-server/tree/openshift >> >> Based on Keycloak examples, I just did copy & paste from one of the demos >> (https://github.com/abstractj/auth-server/tree/openshift) to create a >> server. Keycloak requires Resteasy 3.0.4, for this reason I had to manually >> replace some modules on JBoss. >> >> To test it go to: http://push-abstractj.rhcloud.com/ag-push/ you must be >> redirected to Keycloak, enter: >> >> username: john at doe.com >> password: password >> >> You must be redirected to agpush console, keep in mind that I took some >> shortcuts to get this demo working, so for example the create will fail >> because I removed everything related into the ember interface. >> >> Is also possible to enable TOTP, user?s registration and whatever you >> want. >> >> So what do you think? >> >> -- >> abstractj >> >> _______________________________________________ >> 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 > -- 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/20140126/f9be3796/attachment-0001.html From bruno at abstractj.org Sun Jan 26 07:20:35 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Sun, 26 Jan 2014 04:20:35 -0800 (PST) Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: References: Message-ID: <1390738834902.6b58437e@Nodemailer> Any specific reason to limit the scope to admin page only? I'm thinking about login for regular users? abstractj On Sun, Jan 26, 2014 at 9:11 AM, Matthias Wessendorf wrote: > Hello! > I have a few more updates: > On my branch (a fork from Bruno's branch), the URLs for the actual sending > and the device-registration (both 'protected' via HTTP-Basic), now work > again. I have 'limited' the scope of the Keycloak 'protection' to the > AdminUI. > Greetings, > Matthias > On Fri, Jan 24, 2014 at 6:05 PM, Matthias Wessendorf wrote: >> I have updated the branch w/ their recent changes from this weeks alpha-1 >> release, and submitted a PR against abstractj's repo: >> https://github.com/abstractj/aerogear-unifiedpush-server/pull/1 >> >> More to come >> >> Greetings, >> Matthias >> >> >> >> On Fri, Dec 20, 2013 at 1:11 PM, Bruno Oliveira wrote: >> >>> Good morning peeps, yesterday I started to replace AeroGear Security on >>> Unified Push server by Keycloak and you might be asking: ?Why??. Keycloak >>> is a SSO with some handy features like TOTP, OAuth2, user management >>> support and I think we have too much to contribute, is the only way to have >>> some success with security, ?divide to conquer" (at least for authorization >>> and authentication). >>> >>> So will ag-security be discontinued? No! Keycloak is still on Alpha and >>> we have to test it against our projects before fully replace ag-security, >>> but the only way to upstream our needs, is to using it. >>> >>> This replacement only applies to authentication/authorization features, >>> we still have a ton of projects which Keycloak is not able to replace like: >>> TOTP, crypto and OAuth2 on mobile, our focus. >>> >>> - PoC >>> >>> So let?s talk about this replacement, any dependency on ag-security was >>> removed from the push server and replaced by Keycloak: >>> https://github.com/abstractj/aerogear-unifiedpush-server/tree/openshift >>> >>> Based on Keycloak examples, I just did copy & paste from one of the demos >>> (https://github.com/abstractj/auth-server/tree/openshift) to create a >>> server. Keycloak requires Resteasy 3.0.4, for this reason I had to manually >>> replace some modules on JBoss. >>> >>> To test it go to: http://push-abstractj.rhcloud.com/ag-push/ you must be >>> redirected to Keycloak, enter: >>> >>> username: john at doe.com >>> password: password >>> >>> You must be redirected to agpush console, keep in mind that I took some >>> shortcuts to get this demo working, so for example the create will fail >>> because I removed everything related into the ember interface. >>> >>> Is also possible to enable TOTP, user?s registration and whatever you >>> want. >>> >>> So what do you think? >>> >>> -- >>> abstractj >>> >>> _______________________________________________ >>> 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 >> > -- > 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/20140126/8e444a88/attachment.html From matzew at apache.org Sun Jan 26 07:41:04 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Sun, 26 Jan 2014 13:41:04 +0100 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: <1390738834902.6b58437e@Nodemailer> References: <1390738834902.6b58437e@Nodemailer> Message-ID: Hello Bruno, On Sun, Jan 26, 2014 at 1:20 PM, Bruno Oliveira wrote: > Any specific reason to limit the scope to admin page only? I'm thinking > about login for regular users Not sure I follow. What do you mean w/ "regular users"? Before my change very thing was restricted by Keycloak (/*). I did not really change there a lot, however I just removed the URLs for 'device-registration' and 'sending': https://github.com/matzew/aerogear-unifiedpush-server/blob/keycloak/src/main/webapp/WEB-INF/web.xml#L42-L50 So, currently the following is protected by Keycloak: * Admin UI (not speaking about a specific admin user) * REST APIs that are accessed by the Admin UI, like: - http://aerogear.org/docs/specs/aerogear-push-rest/PushApplication/ - http://aerogear.org/docs/specs/aerogear-push-rest/Variants/ Perviously the 'device-registration' and 'sending' URL were protected as well. Removing them from the 'keycloak protection' is really the only change Greetings, Matthias > ? > abstractj > > > On Sun, Jan 26, 2014 at 9:11 AM, Matthias Wessendorf wrote: > >> Hello! >> >> I have a few more updates: >> >> On my branch (a fork from Bruno's branch), the URLs for the actual >> sending and the device-registration (both 'protected' via HTTP-Basic), now >> work again. I have 'limited' the scope of the Keycloak 'protection' to the >> AdminUI. >> >> Greetings, >> Matthias >> >> >> >> On Fri, Jan 24, 2014 at 6:05 PM, Matthias Wessendorf wrote: >> >>> I have updated the branch w/ their recent changes from this weeks >>> alpha-1 release, and submitted a PR against abstractj's repo: >>> https://github.com/abstractj/aerogear-unifiedpush-server/pull/1 >>> >>> More to come >>> >>> Greetings, >>> Matthias >>> >>> >>> >>> On Fri, Dec 20, 2013 at 1:11 PM, Bruno Oliveira wrote: >>> >>>> Good morning peeps, yesterday I started to replace AeroGear Security on >>>> Unified Push server by Keycloak and you might be asking: ?Why??. Keycloak >>>> is a SSO with some handy features like TOTP, OAuth2, user management >>>> support and I think we have too much to contribute, is the only way to have >>>> some success with security, ?divide to conquer" (at least for authorization >>>> and authentication). >>>> >>>> So will ag-security be discontinued? No! Keycloak is still on Alpha and >>>> we have to test it against our projects before fully replace ag-security, >>>> but the only way to upstream our needs, is to using it. >>>> >>>> This replacement only applies to authentication/authorization features, >>>> we still have a ton of projects which Keycloak is not able to replace like: >>>> TOTP, crypto and OAuth2 on mobile, our focus. >>>> >>>> - PoC >>>> >>>> So let?s talk about this replacement, any dependency on ag-security was >>>> removed from the push server and replaced by Keycloak: >>>> https://github.com/abstractj/aerogear-unifiedpush-server/tree/openshift >>>> >>>> Based on Keycloak examples, I just did copy & paste from one of the >>>> demos (https://github.com/abstractj/auth-server/tree/openshift) to >>>> create a server. Keycloak requires Resteasy 3.0.4, for this reason I had to >>>> manually replace some modules on JBoss. >>>> >>>> To test it go to: http://push-abstractj.rhcloud.com/ag-push/ you must >>>> be redirected to Keycloak, enter: >>>> >>>> username: john at doe.com >>>> password: password >>>> >>>> You must be redirected to agpush console, keep in mind that I took some >>>> shortcuts to get this demo working, so for example the create will fail >>>> because I removed everything related into the ember interface. >>>> >>>> Is also possible to enable TOTP, user?s registration and whatever you >>>> want. >>>> >>>> So what do you think? >>>> >>>> -- >>>> abstractj >>>> >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> 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 > -- 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/20140126/59a573a1/attachment.html From matzew at apache.org Mon Jan 27 01:44:25 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 27 Jan 2014 07:44:25 +0100 Subject: [aerogear-dev] team meeting agenda Message-ID: Proposed agenda for today's meeting http://oksoclap.com/p/aerogear-team-mgt-20140127 -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/20140127/fbbda7e3/attachment-0001.html From kpiwko at redhat.com Mon Jan 27 07:25:25 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Mon, 27 Jan 2014 13:25:25 +0100 Subject: [aerogear-dev] Website restructure In-Reply-To: References: <2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com> <20140120123559.3a3aec13@kapy-ntb-x220> <52DE6B7B.6050202@redhat.com> <20140122130302.233deb81@kapy-ntb-x220> <52DFC3ED.2060405@redhat.com> Message-ID: <20140127132525.3c3751ef@kapy-ntb-x220> On Fri, 24 Jan 2014 15:58:27 +0100 Corinne Krych wrote: > Hello All, > > I?ve being working on sass branch [1], the same branch Erik-Jan did its > initial work. Here is more feedback on our site redesign > > 1. Example page with each language code snippet > It?s a good idea, to show the unified aspect of our libs. Having a short > snippet code is great, however it?s not possible to fit the detailed example > we alreday have in our documentation. Rather than simplifying and not going > into details, I think we could have a main page like [2] which give the > definition + each snippet. Below the code snipet I?ve added a link: Read more > on Pipes on Android / Pipes on iOS / Paging on Web which points to detailled > page. > > I think we should keep this documetation. It goes deeper in the sample code > as opposed to snippet which is not necessarly complete code. One think that > we could do is use code sample extracted from our cookbook recipe. So we can > point to the repository for the full app code. > > @Hylke Do you have a better idea than just a simple link? I think it?s not > visual enough. And what should be the layout of the detailled example page? > Asciidoc allows to directly source a snipet from a file. Keeping code snippet on a single place in repo and automatically propagated to the documentation during page build. We were at least planning to use it on arquillian.org but it's imho not at the place atm. More details here: http://codeextactor.berlios.de/codeextractor.html https://groups.google.com/forum/#!topic/asciidoc/v0bofNfTGs4 > 2. New structure > As hylke asked for it, here a proposal, wdyt? > _ Core > __ Pipe > __ Paging > __ Store > > _ Security > __ Authentication > __ Encryption > > _ Push > __ Registration > __ Sender > > 3. Refactoring of each documentaiton is needed to fit this structure: > How do we want to proceed? One guy is doing the full refactor of doc (poor > guy) or we split it into a bunch of JIRAs? Maybe as @qmx suggested once we?ve > go the structure we could merge the PR and find a way to progressively > refactor. > > 4. markdown or asciidoc ? > It?s a great opportunity to unify our doc. asciidoc offers great plugins. For > example page, we use tab plugin. > > 5. Dracula theme vs White theme > If you uncomment [3] you can have a white theme. A shame that with Dracula > theme we loose the AeroGear blue and orange logo... @Hylke for the dracula > theme we need AG logo in each of the 3 colors. > > 5. Menu > @Hylke you said you want to remove the actual menu, but what do you propose > to navigate between topic: Core/Security/Push/Sync > > 6. Mobile site > New design need to be responsive. Actual CSS are not any more. But we can fix > them ;) > > ++ > Corinne > [1] https://github.com/aerogear/aerogear.org/tree/sass > [2] http://localhost:4000/docs/guides/new/index/ > [3] https://github.com/aerogear/aerogear.org/blob/sass/sass/main.sass#L117 > > On 22 Jan 2014, at 14:13, Hylke Bons wrote: > > > On 22/01/2014 13:00, Corinne Krych wrote: > >> I like the original idea in the mockup (core/Security/Push), maybe we can > >> introduce sub-section like: > >> - Core (pipe - paging / store) > >> - Security(authentication - OTP - OAuth2 / encryption / > >> - Push (push registration / sender api / UPS - Simple Push) > >> - Sync > >> > >> wdyt? > >> ++ > >> Corinne > > > > Yes, exactly that! :) > > I'm doing that as we speak, but I'm not sure what all the (useful) > > classes are. > > > > Hylke > > > > > > > > > >> On 22 Jan 2014, at 13:03, Karel Piwko wrote: > >> > >>> On Tue, 21 Jan 2014 12:43:39 +0000 > >>> Hylke Bons wrote: > >>> > >>>> On 20/01/2014 17:31, Corinne Krych wrote: > >>>>>> On Mon, Jan 20, 2014 at 12:35 PM, Karel Piwko > >>>>>> wrote: Looks good! > >>>>>> +1 I like the dracula theme ! > >>>>>> > >>>>>> Apart for platform related code (JavaScript, Objective-C, Java), are > >>>>>> there any plans to support platform related text? > >>>>>> > >>>>>> E.g. pipes on Aerogear can be used within FragmentActivity, which is > >>>>>> valid for Android only; Javadoc is not related to iOS, etc. That's > >>>>>> basically a merge of our guides into a one per feature with > >>>>>> information covering all the platforms. > >>>> Is there a list of the most important features/classes/objects that I > >>>> can use in the mockup? > >>> I'm not aware of any. Trying to compose list of features, I'd go for: > >>> > >>> * Push Messages > >>> * Pipes > >>> * Authentication > >>> ** OTP > >>> * Crypto > >>> > >>> > >>>>>> Which brings me to and idea of global platform switch. User/reader can > >>>>>> switch platform once and all code snippets and platform related blocks > >>>>>> are automatically selected. Can also be session based and affect all > >>>>>> pages user visits. > >>>> Interesting idea. :) > >>>> > >>>> Hylke > >>>> > >>>> _______________________________________________ > >>>> 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 From corinnekrych at gmail.com Mon Jan 27 07:30:26 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Mon, 27 Jan 2014 13:30:26 +0100 Subject: [aerogear-dev] Website restructure In-Reply-To: <20140127132525.3c3751ef@kapy-ntb-x220> References: <2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com> <20140120123559.3a3aec13@kapy-ntb-x220> <52DE6B7B.6050202@redhat.com> <20140122130302.233deb81@kapy-ntb-x220> <52DFC3ED.2060405@redhat.com> <20140127132525.3c3751ef@kapy-ntb-x220> Message-ID: Interesting link Karel, thanks for sharing. I?ll have a on look how to include cookbook spnippet in arg.org. ++ Corinne On 27 Jan 2014, at 13:25, Karel Piwko wrote: > On Fri, 24 Jan 2014 15:58:27 +0100 > Corinne Krych wrote: > >> Hello All, >> >> I?ve being working on sass branch [1], the same branch Erik-Jan did its >> initial work. Here is more feedback on our site redesign >> >> 1. Example page with each language code snippet >> It?s a good idea, to show the unified aspect of our libs. Having a short >> snippet code is great, however it?s not possible to fit the detailed example >> we alreday have in our documentation. Rather than simplifying and not going >> into details, I think we could have a main page like [2] which give the >> definition + each snippet. Below the code snipet I?ve added a link: Read more >> on Pipes on Android / Pipes on iOS / Paging on Web which points to detailled >> page. >> >> I think we should keep this documetation. It goes deeper in the sample code >> as opposed to snippet which is not necessarly complete code. One think that >> we could do is use code sample extracted from our cookbook recipe. So we can >> point to the repository for the full app code. >> >> @Hylke Do you have a better idea than just a simple link? I think it?s not >> visual enough. And what should be the layout of the detailled example page? >> > Asciidoc allows to directly source a snipet from a file. Keeping code snippet on > a single place in repo and automatically propagated to the documentation > during page build. We were at least planning to use it on arquillian.org but > it's imho not at the place atm. > > More details here: > http://codeextactor.berlios.de/codeextractor.html > https://groups.google.com/forum/#!topic/asciidoc/v0bofNfTGs4 > >> 2. New structure >> As hylke asked for it, here a proposal, wdyt? >> _ Core >> __ Pipe >> __ Paging >> __ Store >> >> _ Security >> __ Authentication >> __ Encryption >> >> _ Push >> __ Registration >> __ Sender >> >> 3. Refactoring of each documentaiton is needed to fit this structure: >> How do we want to proceed? One guy is doing the full refactor of doc (poor >> guy) or we split it into a bunch of JIRAs? Maybe as @qmx suggested once we?ve >> go the structure we could merge the PR and find a way to progressively >> refactor. >> >> 4. markdown or asciidoc ? >> It?s a great opportunity to unify our doc. asciidoc offers great plugins. For >> example page, we use tab plugin. >> >> 5. Dracula theme vs White theme >> If you uncomment [3] you can have a white theme. A shame that with Dracula >> theme we loose the AeroGear blue and orange logo... @Hylke for the dracula >> theme we need AG logo in each of the 3 colors. >> >> 5. Menu >> @Hylke you said you want to remove the actual menu, but what do you propose >> to navigate between topic: Core/Security/Push/Sync >> >> 6. Mobile site >> New design need to be responsive. Actual CSS are not any more. But we can fix >> them ;) >> >> ++ >> Corinne >> [1] https://github.com/aerogear/aerogear.org/tree/sass >> [2] http://localhost:4000/docs/guides/new/index/ >> [3] https://github.com/aerogear/aerogear.org/blob/sass/sass/main.sass#L117 >> >> On 22 Jan 2014, at 14:13, Hylke Bons wrote: >> >>> On 22/01/2014 13:00, Corinne Krych wrote: >>>> I like the original idea in the mockup (core/Security/Push), maybe we can >>>> introduce sub-section like: >>>> - Core (pipe - paging / store) >>>> - Security(authentication - OTP - OAuth2 / encryption / >>>> - Push (push registration / sender api / UPS - Simple Push) >>>> - Sync >>>> >>>> wdyt? >>>> ++ >>>> Corinne >>> >>> Yes, exactly that! :) >>> I'm doing that as we speak, but I'm not sure what all the (useful) >>> classes are. >>> >>> Hylke >>> >>> >>> >>> >>>> On 22 Jan 2014, at 13:03, Karel Piwko wrote: >>>> >>>>> On Tue, 21 Jan 2014 12:43:39 +0000 >>>>> Hylke Bons wrote: >>>>> >>>>>> On 20/01/2014 17:31, Corinne Krych wrote: >>>>>>>> On Mon, Jan 20, 2014 at 12:35 PM, Karel Piwko >>>>>>>> wrote: Looks good! >>>>>>>> +1 I like the dracula theme ! >>>>>>>> >>>>>>>> Apart for platform related code (JavaScript, Objective-C, Java), are >>>>>>>> there any plans to support platform related text? >>>>>>>> >>>>>>>> E.g. pipes on Aerogear can be used within FragmentActivity, which is >>>>>>>> valid for Android only; Javadoc is not related to iOS, etc. That's >>>>>>>> basically a merge of our guides into a one per feature with >>>>>>>> information covering all the platforms. >>>>>> Is there a list of the most important features/classes/objects that I >>>>>> can use in the mockup? >>>>> I'm not aware of any. Trying to compose list of features, I'd go for: >>>>> >>>>> * Push Messages >>>>> * Pipes >>>>> * Authentication >>>>> ** OTP >>>>> * Crypto >>>>> >>>>> >>>>>>>> Which brings me to and idea of global platform switch. User/reader can >>>>>>>> switch platform once and all code snippets and platform related blocks >>>>>>>> are automatically selected. Can also be session based and affect all >>>>>>>> pages user visits. >>>>>> Interesting idea. :) >>>>>> >>>>>> Hylke >>>>>> >>>>>> _______________________________________________ >>>>>> 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 From kpiwko at redhat.com Mon Jan 27 07:32:53 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Mon, 27 Jan 2014 13:32:53 +0100 Subject: [aerogear-dev] Website suggestion: Team members page In-Reply-To: <1390555242.2538.5.camel@dhcp129-205.brq.redhat.com> References: <52E14E14.9000204@redhat.com> <7192BD55-96F3-49C4-89AC-CB6B380709E8@gmail.com> <1390555242.2538.5.camel@dhcp129-205.brq.redhat.com> Message-ID: <20140127133253.483b3f41@kapy-ntb-x220> On Fri, 24 Jan 2014 10:20:42 +0100 Apostolos Emmanouilidis wrote: > it would be nice to create a contributors page instead of a team members > page. something similar to JBoss Arquillian contributors page [1]. > This would motivate people outside the team members to contribute to the > project and get involved. > > [1]: http://arquillian.org/community/contributors/ > The other great thing there is "contributor spotlight" - awarding an active community member with a few paragraphs on the main page > > On Fri, 2014-01-24 at 00:23 -0200, Bruno Oliveira wrote: > > I'm not against it, but we have the same thing on > > GH https://github.com/orgs/aerogear/members > > > > > > > > On Thu, Jan 23, 2014 at 3:28 PM, Matthias Wessendorf > > wrote: > > > > +1 like the idea. Gives faces to the website! Sure you can > > find these faces, by checking on GH ;-) but yeah... +1 on > > something like that > > > > > > > > -M > > > > > > > > On Thu, Jan 23, 2014 at 6:22 PM, Corinne Krych > > wrote: > > > > +1 > > > > On 23 Jan 2014, at 18:15, Hylke Bons > > wrote: > > > > > Hey, > > > > > > What does everyone think about having a team members > > page on the website? > > > I think it would be good for community engagement. > > > > > > It would have profile pictures, and maybe 2-3 lines > > about who you are > > > and what you are doing on the project. It doesn't > > have to go in-depth. > > > Maybe links to blogs and Twitter accounts would be > > nice too. > > > > > > Something like: http://openstack.redhat.com/People > > > > > > Let me know what you think. > > > > > > Hylke > > > _______________________________________________ > > > aerogear-dev mailing list > > > aerogear-dev at lists.jboss.org > > > > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > > > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > > > > > > > > > > > > -- > > > > > > > > > > -- > > "The measure of a man is what he does with power" - Plato > > - > > @abstractj > > - > > Volenti Nihil Difficile > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > From bruno at abstractj.org Mon Jan 27 10:15:28 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Mon, 27 Jan 2014 13:15:28 -0200 Subject: [aerogear-dev] team meeting agenda In-Reply-To: References: Message-ID: Meeting minutes: [13:14] jbott: Meeting ended Mon Jan 27 15:04:44 2014 UTC. ?Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [13:14] jbott: Minutes: ? ? ? ?http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-01-27-14.51.html [13:14] jbott: Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-01-27-14.51.txt [13:14] jbott: Log: ? ? ? ? ? ?http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-01-27-14.51.log.html -- abstractj On January 27, 2014 at 4:44:33 AM, Matthias Wessendorf (matzew at apache.org) wrote: > > Proposed agenda for today's meeting > > http://oksoclap.com/p/aerogear-team-mgt-20140127 > > -Matthias > > -- > 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 From matzew at apache.org Mon Jan 27 10:18:55 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Mon, 27 Jan 2014 16:18:55 +0100 Subject: [aerogear-dev] team meeting agenda In-Reply-To: References: Message-ID: short meeting was short: [16:14:44] ** Meeting ended Mon Jan 27 15:04:44 2014 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) [16:14:44] ** Minutes: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-01-27-14.51.html [16:14:44] ** Minutes (text): http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-01-27-14.51.txt [16:14:44] ** Log: http://transcripts.jboss.org/meeting/irc.freenode.org/aerogear/2014/aerogear.2014-01-27-14.51.log.html On Mon, Jan 27, 2014 at 7:44 AM, Matthias Wessendorf wrote: > Proposed agenda for today's meeting > > http://oksoclap.com/p/aerogear-team-mgt-20140127 > > -Matthias > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- 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/20140127/48c15489/attachment-0001.html From avibelli at redhat.com Mon Jan 27 12:27:04 2014 From: avibelli at redhat.com (Andrea Vibelli) Date: Mon, 27 Jan 2014 12:27:04 -0500 (EST) Subject: [aerogear-dev] Upgrading process for the OpenShift AeroGear UPS cartridge In-Reply-To: <104737512.5419827.1390842425965.JavaMail.root@redhat.com> Message-ID: <676075311.5431814.1390843624382.JavaMail.root@redhat.com> Hello all, I just wanted to let you know that Farah is working on AGPUSH-504, a snapshot/restore approach for upgrading the downloadable cartridge. The overall idea is to take a snapshot of the database (and other configuration) for an older existing cartridge instance, delete this old instance, and then create a new instance based on the latest cartridge version and restore the new instance's database (and other configuration) to the state in the snapshot. The new instance must have the same name as the old instance. The main thing that she needed to determine was what needed to be included in the snapshot that's not already part of the MySQL database. The SimplePush token key was one of these things (we generate this value when a cartridge instance is created and it is used by the server for encryption and decryption of endpoint URLs). The standalone.xml file also needed to be backed up just in case the user made any changes to it. (Creating a backup of this file allows users to manually merge back any changes they may have made.) The snapshot/restore action hooks she has created can be found in [1]. The steps she has been using to try upgrading from an 0.8.1 instance are listed below. It would be great if you could try out these steps as well. There's one important caveat though: because an 0.8.1 instance won't have the necessary snapshot hook, you'll need to manually perform some commands to save the necessary data (step 3 below). If we include these snapshot/restore action hooks in the 0.10.0 cartridge release, users will be able to make use of these hooks for future upgrades, e.g., for upgrading from 0.10.0 to 0.11.0. 1) Create an 0.8.1 cartridge instance rhc create-app mypush "https://cartreflect-claytondev.rhcloud.com/reflect?github=aerogear/openshift-origin-cartridge-aerogear-push&commit=8aada257de52157a837db23a9f7b1a8574fdffab" mysql-5.1 2) Log into the admin console, change password, create push applications, create variants, send push notifications, etc. 3) ssh into your instance and perform these commands (this step manually captures needed data) echo "$OPENSHIFT_AEROGEAR_PUSH_TOKEN_KEY" > $OPENSHIFT_DATA_DIR/aerogear_push_token_key cp $OPENSHIFT_AEROGEAR_PUSH_DIR/standalone/configuration/standalone.xml $OPENSHIFT_DATA_DIR/standalone.snapshot.xml 4) Create a snapshot of the 0.8.1 instance: rhc snapshot save mypush 5) Delete the 0.8.1 instance: rhc app delete mypush 6) Delete the local directory on the local machine (from step 1, you should have a directory named 'mypush') 7) Create a new cartridge instance (this uses her fork of the 0.9.0 cartridge repository that contains the snapshot/restore action hooks) rhc create-app mypush "https://cartreflect-claytondev.rhcloud.com/reflect?github=fjuma/openshift-origin-cartridge-aerogear-push&commit=956a4fc09edc93fe76394b86b265ceb1d238ccaf" mysql-5.1 8) Restore the instance: rhc snapshot restore mypush -f /PATH/TO/mypush.tar.gz 9) You should now be able to log into the admin console with the same password you previously set, see existing push applications, variants, send push notifications, etc. One disadvantage of this snapshot/restore approach is the extra work for the user. It would be nice to have a single command that can do the snapshot, delete, create, and restore all at once. She is going to start looking into this "wrappering" functionality. Why am I writing about this? I have made some test about the above steps. At a first glance, it seemed that something was broken between steps 6 and 7. Doing various tests, what I saw in the logs (server.log) were different errors: 2014/01/26 10:19:18,061 ERROR [org.jboss.as] (MSC service thread 1-3) JBAS015875: JBoss AS 7.1.1.Final "Brontes" started (with errors) in 296088ms - Started 349 of 524 services (52 services failed or missing dependencies, 119 services are passive or on-demand) 2014/01/26 10:19:18,344 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS015870: Deploy of deployment "ROOT.war" was rolled back with failure message {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]} 2014/01/26 10:19:19,390 INFO [org.jboss.as.server.deployment] (MSC service thread 1-2) JBAS015877: Stopped deployment ROOT.war in 1125ms 2014/01/26 10:19:19,393 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) JBAS014774: Service status report JBAS014775: New missing/unsatisfied dependencies: service jboss.naming.context.java.jboss.datasources.PushEEDS (missing) dependents: [service jboss.persistenceunit."ROOT.war#unifiedpush-default", service jboss.persistenceunit."ROOT.war#picketlink-default"] 2014/01/26 10:19:19,440 ERROR [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]}}} OR 2014/01/26 05:41:46,522 INFO [org.jboss.as.connector] (MSC service thread 1-1) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.9.Final) 2014/01/26 05:41:46,922 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 62) Operation ("enable") failed - address: ([ ("subsystem" => "datasources"), ("data-source" => "PostgreSQLDS") ]) - failure description: "JBAS014802: Cannot resolve expression 'expression \"jdbcostgresql://${env.OPENSHIFT_POSTGRESQL_DB_HOST}:${env.OPENSHIFT_POSTGRESQL_DB_PORT}/mypush13\"' -- java.lang.IllegalStateException: Failed to resolve expression: ${env.OPENSHIFT_POSTGRESQL_DB_HOST}" OR no errors in the logs, but in the deployments directory I found 'ROOT.war.dodeploy' and 'ROOT.war.isdeploying' files, but no 'ROOT.war.deployed' file. Those error seemed to me as random and too strange (by the way, the creation of the cartridge is always correct, I never had problems if I created a new instance with a never used before name). To investigate further, I then tried to do the same steps with a completely different application: 'Kitchensink on OpenShift', and I had the same error! After the deletion and the recreation of a cartridge with a same name, I encountered: 'The requested URL /app was not found on this server.' The steps I have done are: 1) rhc app create -a kitchensink -t jbossas-7 --from-code git://github.com/openshift/kitchensink-example.git 2) rhc snapshot save kitchensink 3) rhc app delete kitchensink 4) rm -rf kitchensinkhtml5/ 5) rhc app create -a kitchensink -t jbossas-7 --from-code git://github.com/openshift/kitchensink-example.git 6) Access to the application. So the good news is that the error I encountered is not related to this specific AeroGear cartridges, but the bad news is that is something more general about OpenShift. We need to investigate further and find out if there is a way to "flush" the deletion, it seems that there is something appended or cached that prevent the recreation of a cartridge with a same name. We are currently doing some more tests on these process. From fjuma at redhat.com Mon Jan 27 13:07:31 2014 From: fjuma at redhat.com (Farah Juma) Date: Mon, 27 Jan 2014 13:07:31 -0500 (EST) Subject: [aerogear-dev] Upgrading process for the OpenShift AeroGear UPS cartridge In-Reply-To: <676075311.5431814.1390843624382.JavaMail.root@redhat.com> References: <676075311.5431814.1390843624382.JavaMail.root@redhat.com> Message-ID: <2099059360.11646680.1390846051314.JavaMail.root@redhat.com> > From: "Andrea Vibelli" > To: aerogear-dev at lists.jboss.org > Sent: Monday, January 27, 2014 12:27:04 PM > Subject: [aerogear-dev] Upgrading process for the OpenShift AeroGear UPS cartridge > > Hello all, > > I just wanted to let you know that Farah is working on AGPUSH-504, a > snapshot/restore approach for upgrading the downloadable cartridge. > The overall idea is to take a snapshot of the database (and other > configuration) for an older existing cartridge instance, delete this old > instance, and then create a new instance based on the latest cartridge > version and restore the new instance's database (and other configuration) to > the state in the snapshot. The new instance must have the same name as the > old instance. The main thing that she needed to determine was what needed to > be included in the snapshot that's not already part of the MySQL database. > The SimplePush token key was one of these things (we generate this value > when a cartridge instance is created and it is used by the server for > encryption and decryption of endpoint URLs). The standalone.xml file also > needed to be backed up just in case the user made any changes to it. > (Creating a backup of this file allows users to manually merge back any > changes they may have made.) > > The snapshot/restore action hooks she has created can be found in [1]. > > The steps she has been using to try upgrading from an 0.8.1 instance are > listed below. It would be great if you could try out these steps as well. > There's one important caveat though: because an 0.8.1 instance won't have > the necessary snapshot hook, you'll need to manually perform some commands > to save the necessary data (step 3 below). If we include these > snapshot/restore action hooks in the 0.10.0 cartridge release, users will be > able to make use of these hooks for future upgrades, e.g., for upgrading > from 0.10.0 to 0.11.0. > > 1) Create an 0.8.1 cartridge instance > rhc create-app mypush > "https://cartreflect-claytondev.rhcloud.com/reflect?github=aerogear/openshift-origin-cartridge-aerogear-push&commit=8aada257de52157a837db23a9f7b1a8574fdffab" > mysql-5.1 > > 2) Log into the admin console, change password, create push applications, > create variants, send push notifications, etc. > > 3) ssh into your instance and perform these commands (this step manually > captures needed data) > echo "$OPENSHIFT_AEROGEAR_PUSH_TOKEN_KEY" > > $OPENSHIFT_DATA_DIR/aerogear_push_token_key > cp $OPENSHIFT_AEROGEAR_PUSH_DIR/standalone/configuration/standalone.xml > $OPENSHIFT_DATA_DIR/standalone.snapshot.xml > > 4) Create a snapshot of the 0.8.1 instance: rhc snapshot save mypush > > 5) Delete the 0.8.1 instance: rhc app delete mypush > > 6) Delete the local directory on the local machine (from step 1, you should > have a directory named 'mypush') > > 7) Create a new cartridge instance (this uses her fork of the 0.9.0 cartridge > repository that contains the snapshot/restore action hooks) > rhc create-app mypush > "https://cartreflect-claytondev.rhcloud.com/reflect?github=fjuma/openshift-origin-cartridge-aerogear-push&commit=956a4fc09edc93fe76394b86b265ceb1d238ccaf" > mysql-5.1 > > 8) Restore the instance: rhc snapshot restore mypush -f > /PATH/TO/mypush.tar.gz > > 9) You should now be able to log into the admin console with the same > password you previously set, see existing push applications, variants, send > push notifications, etc. > > One disadvantage of this snapshot/restore approach is the extra work for the > user. It would be nice to have a single command that can do the snapshot, > delete, create, and restore all at once. She is going to start looking into > this "wrappering" functionality. > > > Why am I writing about this? > > I have made some test about the above steps. At a first glance, it seemed > that something was broken between steps 6 and 7. > Doing various tests, what I saw in the logs (server.log) were different > errors: > > 2014/01/26 10:19:18,061 ERROR [org.jboss.as] (MSC service thread 1-3) > JBAS015875: JBoss AS 7.1.1.Final "Brontes" started (with errors) in 296088ms > - Started 349 of 524 services (52 services failed or missing dependencies, > 119 services are passive or on-demand) > 2014/01/26 10:19:18,344 INFO [org.jboss.as.server] > (DeploymentScanner-threads - 2) JBAS015870: Deploy of deployment "ROOT.war" > was rolled back with failure message {"JBAS014771: Services with > missing/unavailable dependencies" => > ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]} > 2014/01/26 10:19:19,390 INFO [org.jboss.as.server.deployment] (MSC service > thread 1-2) JBAS015877: Stopped deployment ROOT.war in 1125ms > 2014/01/26 10:19:19,393 INFO [org.jboss.as.controller] > (DeploymentScanner-threads - 2) JBAS014774: Service status report > JBAS014775: New missing/unsatisfied dependencies: > service jboss.naming.context.java.jboss.datasources.PushEEDS (missing) > dependents: [service > jboss.persistenceunit."ROOT.war#unifiedpush-default", service > jboss.persistenceunit."ROOT.war#picketlink-default"] > > > 2014/01/26 10:19:19,440 ERROR [org.jboss.as.server.deployment.scanner] > (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation failed and > was rolled back. Steps that failed:" => {"Operation step-2" => {"JBAS014771: > Services with missing/unavailable dependencies" => > ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]}}} It looks like the MySQL cartridge either wasn't added or wasn't able to start successfully. The following command can be used to check the status of the MySQL cartridge: rhc cartridge status -a APP -c mysql > OR > > > 2014/01/26 05:41:46,522 INFO [org.jboss.as.connector] (MSC service thread > 1-1) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.9.Final) > 2014/01/26 05:41:46,922 ERROR [org.jboss.as.controller.management-operation] > (ServerService Thread Pool -- 62) Operation ("enable") failed - address: ([ > ("subsystem" => "datasources"), > ("data-source" => "PostgreSQLDS") > ]) - failure description: "JBAS014802: Cannot resolve expression 'expression > \"jdbcostgresql://${env.OPENSHIFT_POSTGRESQL_DB_HOST}:${env.OPENSHIFT_POSTGRESQL_DB_PORT}/mypush13\"' > -- java.lang.IllegalStateException: Failed to resolve expression: > ${env.OPENSHIFT_POSTGRESQL_DB_HOST}" > > > OR > > > no errors in the logs, but in the deployments directory I found > 'ROOT.war.dodeploy' and 'ROOT.war.isdeploying' files, but no > 'ROOT.war.deployed' file. > > > Those error seemed to me as random and too strange (by the way, the creation > of the cartridge is always correct, I never had problems if I created a new > instance with a never used before name). > > To investigate further, I then tried to do the same steps with a completely > different application: 'Kitchensink on OpenShift', and I had the same error! > After the deletion and the recreation of a cartridge with a same name, I > encountered: 'The requested URL /app was not found on this server.' > The steps I have done are: > 1) rhc app create -a kitchensink -t jbossas-7 --from-code > git://github.com/openshift/kitchensink-example.git > 2) rhc snapshot save kitchensink > 3) rhc app delete kitchensink > 4) rm -rf kitchensinkhtml5/ > 5) rhc app create -a kitchensink -t jbossas-7 --from-code > git://github.com/openshift/kitchensink-example.git > 6) Access to the application. > > So the good news is that the error I encountered is not related to this > specific AeroGear cartridges, but the bad news is that is something more > general about OpenShift. > We need to investigate further and find out if there is a way to "flush" the > deletion, it seems that there is something appended or cached that prevent > the recreation of a cartridge with a same name. It's good that the issue you're running into isn't specific to the AeroGear cartridge. I've tried quite a few times today but I'm not able to reproduce the issue with the AeroGear cartridge or with the kitchensink application using the above steps. I suspect that there is indeed an OpenShift timing issue here. Let's check with the OpenShift team on this. Farah > We are currently doing some more tests on these process. > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > From fjuma at redhat.com Mon Jan 27 16:28:07 2014 From: fjuma at redhat.com (Farah Juma) Date: Mon, 27 Jan 2014 16:28:07 -0500 (EST) Subject: [aerogear-dev] Upgrading process for the OpenShift AeroGear UPS cartridge In-Reply-To: <2099059360.11646680.1390846051314.JavaMail.root@redhat.com> References: <676075311.5431814.1390843624382.JavaMail.root@redhat.com> <2099059360.11646680.1390846051314.JavaMail.root@redhat.com> Message-ID: <1403896808.11718517.1390858087208.JavaMail.root@redhat.com> After some more digging, I think I might know what's going on here. Andrea, are you using Firefox? I wasn't able to reproduce the issue with Chrome but was able to reproduce it just now with Firefox. The underlying issue seems to be that Firefox tends to save 301 redirects until you close it and re-open it. Note that when you delete an OpenShift instance and re-create it, its IP address changes. When accessing http://app-namespace.rhcloud after re-creating the instance, you'll actually be redirected to https://app-namespace.rhcloud/app. However, when using Firefox, this URL seems to get mapped to the old IP address resulting in this error: 'The requested URL /app was not found on this server.' After deleting and re-creating an OpenShift instance with the same name, if you restart Firefox, you should once again be able to access the application. I've verified that this does work. Similar issues with Firefox were actually mentioned in some OpenShift forum posts as well: https://www.openshift.com/forums/openshift/httpawm-pribylrhcloudcom-the-requested-url-was-not-found-on-this-server#comment-33570 https://www.openshift.com/forums/openshift/custom-domain-httpwwwxxxxxxxcom-is-redirecting-to-httpswwwxxxxxxxcomapp#comment-34215 Farah ----- Original Message ----- > From: "Farah Juma" > To: aerogear-dev at lists.jboss.org > Sent: Monday, January 27, 2014 1:07:31 PM > Subject: Re: [aerogear-dev] Upgrading process for the OpenShift AeroGear????????UPS????????cartridge > > > > From: "Andrea Vibelli" > > To: aerogear-dev at lists.jboss.org > > Sent: Monday, January 27, 2014 12:27:04 PM > > Subject: [aerogear-dev] Upgrading process for the OpenShift AeroGear UPS > > ????????cartridge > > > > Hello all, > > > > I just wanted to let you know that Farah is working on AGPUSH-504, a > > snapshot/restore approach for upgrading the downloadable cartridge. > > The overall idea is to take a snapshot of the database (and other > > configuration) for an older existing cartridge instance, delete this old > > instance, and then create a new instance based on the latest cartridge > > version and restore the new instance's database (and other configuration) > > to > > the state in the snapshot. The new instance must have the same name as the > > old instance. The main thing that she needed to determine was what needed > > to > > be included in the snapshot that's not already part of the MySQL database. > > The SimplePush token key was one of these things (we generate this value > > when a cartridge instance is created and it is used by the server for > > encryption and decryption of endpoint URLs). The standalone.xml file also > > needed to be backed up just in case the user made any changes to it. > > (Creating a backup of this file allows users to manually merge back any > > changes they may have made.) > > > > The snapshot/restore action hooks she has created can be found in [1]. > > > > The steps she has been using to try upgrading from an 0.8.1 instance are > > listed below. It would be great if you could try out these steps as well. > > There's one important caveat though: because an 0.8.1 instance won't have > > the necessary snapshot hook, you'll need to manually perform some commands > > to save the necessary data (step 3 below). If we include these > > snapshot/restore action hooks in the 0.10.0 cartridge release, users will > > be > > able to make use of these hooks for future upgrades, e.g., for upgrading > > from 0.10.0 to 0.11.0. > > ? > > 1) Create an 0.8.1 cartridge instance > > rhc create-app mypush > > "https://cartreflect-claytondev.rhcloud.com/reflect?github=aerogear/openshift-origin-cartridge-aerogear-push&commit=8aada257de52157a837db23a9f7b1a8574fdffab" > > mysql-5.1 > > > > 2) Log into the admin console, change password, create push applications, > > create variants, send push notifications, etc. > > > > 3) ssh into your instance and perform these commands (this step manually > > captures needed data) > > echo "$OPENSHIFT_AEROGEAR_PUSH_TOKEN_KEY" > > > $OPENSHIFT_DATA_DIR/aerogear_push_token_key > > cp $OPENSHIFT_AEROGEAR_PUSH_DIR/standalone/configuration/standalone.xml > > $OPENSHIFT_DATA_DIR/standalone.snapshot.xml > > > > 4) Create a snapshot of the 0.8.1 instance: rhc snapshot save mypush > > > > 5) Delete the 0.8.1 instance: rhc app delete mypush > > > > 6) Delete the local directory on the local machine (from step 1, you should > > have a directory named 'mypush') > > > > 7) Create a new cartridge instance (this uses her fork of the 0.9.0 > > cartridge > > repository that contains the snapshot/restore action hooks) > > rhc create-app mypush > > "https://cartreflect-claytondev.rhcloud.com/reflect?github=fjuma/openshift-origin-cartridge-aerogear-push&commit=956a4fc09edc93fe76394b86b265ceb1d238ccaf" > > mysql-5.1 > > > > 8) Restore the instance: rhc snapshot restore mypush -f > > /PATH/TO/mypush.tar.gz > > > > 9) You should now be able to log into the admin console with the same > > password you previously set, see existing push applications, variants, send > > push notifications, etc. > > > > One disadvantage of this snapshot/restore approach is the extra work for > > the > > user. It would be nice to have a single command that can do the snapshot, > > delete, create, and restore all at once. She is going to start looking into > > this "wrappering" functionality. > > > > > > Why am I writing about this? > > > > I have made some test about the above steps. At a first glance, it seemed > > that something was broken between steps 6 and 7. > > Doing various tests, what I saw in the logs (server.log) were different > > errors: > > > > 2014/01/26 10:19:18,061 ERROR [org.jboss.as] (MSC service thread 1-3) > > JBAS015875: JBoss AS 7.1.1.Final "Brontes" started (with errors) in > > 296088ms > > - Started 349 of 524 services (52 services failed or missing dependencies, > > 119 services are passive or on-demand) > > 2014/01/26 10:19:18,344 INFO ?[org.jboss.as.server] > > (DeploymentScanner-threads - 2) JBAS015870: Deploy of deployment "ROOT.war" > > was rolled back with failure message {"JBAS014771: Services with > > missing/unavailable dependencies" => > > ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]} > > 2014/01/26 10:19:19,390 INFO ?[org.jboss.as.server.deployment] (MSC service > > thread 1-2) JBAS015877: Stopped deployment ROOT.war in 1125ms > > 2014/01/26 10:19:19,393 INFO ?[org.jboss.as.controller] > > (DeploymentScanner-threads - 2) JBAS014774: Service status report > > JBAS014775: ? ?New missing/unsatisfied dependencies: > > ? ? ? service jboss.naming.context.java.jboss.datasources.PushEEDS > > ? ? ? (missing) > > ? ? ? dependents: [service > > ? ? ? jboss.persistenceunit."ROOT.war#unifiedpush-default", service > > ? ? ? jboss.persistenceunit."ROOT.war#picketlink-default"] > > > > > > 2014/01/26 10:19:19,440 ERROR [org.jboss.as.server.deployment.scanner] > > (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation failed > > and > > was rolled back. Steps that failed:" => {"Operation step-2" => > > {"JBAS014771: > > Services with missing/unavailable dependencies" => > > ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]}}} > > > It looks like the MySQL cartridge either wasn't added or wasn't able to start > successfully. The following command can be used to check the status of the > MySQL cartridge: > > rhc cartridge status -a APP -c mysql > > ? > > OR > > > > > > 2014/01/26 05:41:46,522 INFO ?[org.jboss.as.connector] (MSC service thread > > 1-1) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.9.Final) > > 2014/01/26 05:41:46,922 ERROR > > [org.jboss.as.controller.management-operation] > > (ServerService Thread Pool -- 62) Operation ("enable") failed - address: ([ > > ? ? ("subsystem" => "datasources"), > > ? ? ("data-source" => "PostgreSQLDS") > > ]) - failure description: "JBAS014802: Cannot resolve expression > > 'expression > > \"jdbcostgresql://${env.OPENSHIFT_POSTGRESQL_DB_HOST}:${env.OPENSHIFT_POSTGRESQL_DB_PORT}/mypush13\"' > > -- java.lang.IllegalStateException: Failed to resolve expression: > > ${env.OPENSHIFT_POSTGRESQL_DB_HOST}" > > > > > > OR > > > > > > no errors in the logs, but in the deployments directory I found > > 'ROOT.war.dodeploy' and 'ROOT.war.isdeploying' files, but no > > 'ROOT.war.deployed' file. > > > > > > Those error seemed to me as random and too strange (by the way, the > > creation > > of the cartridge is always correct, I never had problems if I created a new > > instance with a never used before name). > > > > To investigate further, I then tried to do the same steps with a completely > > different application: 'Kitchensink on OpenShift', and I had the same > > error! > > After the deletion and the recreation of a cartridge with a same name, I > > encountered: 'The requested URL /app was not found on this server.' > > The steps I have done are: > > 1) rhc app create -a kitchensink -t jbossas-7 --from-code > > git://github.com/openshift/kitchensink-example.git > > 2) rhc snapshot save kitchensink > > 3) rhc app delete kitchensink > > 4) rm -rf kitchensinkhtml5/ > > 5) rhc app create -a kitchensink -t jbossas-7 --from-code > > git://github.com/openshift/kitchensink-example.git > > 6) Access to the application. > > > > So the good news is that the error I encountered is not related to this > > specific AeroGear cartridges, but the bad news is that is something more > > general about OpenShift. > > We need to investigate further and find out if there is a way to "flush" > > the > > deletion, it seems that there is something appended or cached that prevent > > the recreation of a cartridge with a same name. > > It's good that the issue you're running into isn't specific to the AeroGear > cartridge. I've tried quite a few times today but I'm not able to reproduce > the issue with the AeroGear cartridge or with the kitchensink application > using the above steps. I suspect that there is indeed an OpenShift timing > issue here. Let's check with the OpenShift team on this. > > Farah > > > We are currently doing some more tests on these process. > > > > > > > > _______________________________________________ > > 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 Jan 28 03:26:26 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 28 Jan 2014 09:26:26 +0100 Subject: [aerogear-dev] Website restructure In-Reply-To: <3B1CEC27-5A2C-48BA-A016-877A2987CD9E@gmail.com> References: <2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com> <20140120123559.3a3aec13@kapy-ntb-x220> <52DE6B7B.6050202@redhat.com> <20140122130302.233deb81@kapy-ntb-x220> <52DFC3ED.2060405@redhat.com> <52E2AC04.1010306@redhat.com> <08ABCD4D-AF15-4D55-92B3-CC46A4BD9E08@gmail.com> <3B1CEC27-5A2C-48BA-A016-877A2987CD9E@gmail.com> Message-ID: <9BBFBABA-AE49-45B4-B835-5B1F6F65BE5C@gmail.com> > > @Hylke see my comments below >> >> On 24 Jan 2014, at 19:08, Hylke Bons wrote: >> >>> Hey, >>> >>> On 24/01/2014 14:58, Corinne Krych wrote: >>>> Hello All, >>>> >>>> I?ve being working on sass branch [1], the same branch Erik-Jan did its initial work. >>>> Here is more feedback on our site redesign >>>> >>>> 1. Example page with each language code snippet >>>> It?s a good idea, to show the unified aspect of our libs. Having a short snippet code is great, however it?s not possible to fit the detailed example we alreday have in our documentation. Rather than simplifying and not going into details, I think we could have a main page like [2] which give the definition + each snippet. Below the code snipet I?ve added a link: >>>> Read more on Pipes on Android / Pipes on iOS / Paging on Web >>>> which points to detailled page. >>>> >>>> I think we should keep this documetation. It goes deeper in the sample code as opposed to snippet which is not necessarly complete code. One think that we could do is use code sample extracted from our cookbook recipe. So we can point to the repository for the full app code. >>>> >>>> @Hylke Do you have a better idea than just a simple link? I think it?s not visual enough. And what should be the layout of the detailled example page? >>> >>> The [2] link is on localhost. :) >>> >>> How about we try it out for Pipes and see how it goes? Yes, we probably >>> would need to move some stuff out to other sections, but that's ok. >>> We'll have a better ideas what to do with the "excess" docs once we try >>> any simplify the multiple documents into one. >>> >>> Here's the idea for the scopes I had: >>> >>> - Examples => High level overview of AeroGear concepts and code snippets >>> about how they're used. Not neccesarily big programmes. >>> - Documentation >>> - Getting started => Download and setup >>> - API Browser => just a link to the full API overview >>> - Guides: We can go more all out here. Tutorials, example projects, more >>> complex configurations, etc. Basically everything else that doesn't fall >>> into the above categories. :) >>> >>> I know it's a lot of work... I do think it's the best way to go. I'd be >>> happy to help out on this too, though I've absolutely no clue on the >>> topic, but that may actually be a good thing for explaining stuff to >>> people new to the concepts. :) >>> >> >> Actually if you setup the sass batch link[1], you run your environment and then you go to link[2] loclhost as it?s running on our instance, you will see i?ve tried it out for Pipes. In order to do it i needed to split the documentation for iOS/Android (I haven?t done completely JS part). with this exercice what i understand is: >> 1. the first view should contain code snippet with shows the unified aspect of client lib. those sippet are not complete code, it should be simplified. >> 2. this simplified view is not enough for a developer. Selecting his platform tab, he will be redirected to android for ex complete description on Pipes. Ideally this description is based on a cookbook exemple. >> 3. if the developer want to test it himself he?ll have the option to download the complete sample code (github link to cookbook repo) and just run it >> >> So the explantion goes through 3 layers from 1)high level description (cross platform), 2) detailled explanation linked to a platform to 3) sample code implementation (obvious linked to a platform). >> >> My question is How to make the transition from 1) to 2) ? See picture below >> https://www.dropbox.com/s/tz25vzu8doh6jkk/agorg2.png > > >> >>> >>>> >>>> >>>> 5. Dracula theme vs White theme >>>> If you uncomment [3] you can have a white theme. A shame that with Dracula theme we loose the AeroGear blue and orange logo... >>>> @Hylke for the dracula theme we need AG logo in each of the 3 colors. >>> Yes, I'll send you those. Don't worry about the theming too much, as we >>> haven't really discussed that yet. The "Dracula" theme was more of an >>> example of how we can use colours to mark different sections of the >>> project/site. So if you'd like to see things different, let me know! :) >>> >>>> 5. Menu >>>> @Hylke you said you want to remove the actual menu, but what do you propose to navigate between topic: Core/Security/Push/Sync >>> I've actually added it back in the mockup (see the other email on the >>> thread). It was more of a time thing that I hadn't added it yet. It's >>> back now. >>> >>> Hylke >>> _______________________________________________ >>> 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/20140128/ce886a08/attachment.html From avibelli at redhat.com Tue Jan 28 03:46:02 2014 From: avibelli at redhat.com (Andrea Vibelli) Date: Tue, 28 Jan 2014 03:46:02 -0500 (EST) Subject: [aerogear-dev] Upgrading process for the OpenShift AeroGear UPS cartridge In-Reply-To: <1403896808.11718517.1390858087208.JavaMail.root@redhat.com> References: <676075311.5431814.1390843624382.JavaMail.root@redhat.com> <2099059360.11646680.1390846051314.JavaMail.root@redhat.com> <1403896808.11718517.1390858087208.JavaMail.root@redhat.com> Message-ID: <2034992562.5686126.1390898762650.JavaMail.root@redhat.com> Hi Farah, yes I do use FireFox. I have done the tests once again, and closing and reopening the browser solved my issue, great, nice catch! Maybe we could also include this additional step in the overall instructions, what do you think? Thank you Andrea ----- Messaggio originale ----- > Da: "Farah Juma" > A: "Andrea Vibelli" , aerogear-dev at lists.jboss.org > Inviato: Luned?, 27 gennaio 2014 22:28:07 > Oggetto: Re: [aerogear-dev] Upgrading process for the OpenShift AeroGear UPS cartridge > > After some more digging, I think I might know what's going on here. Andrea, > are you using Firefox? I wasn't able to reproduce the issue with Chrome but > was able to reproduce it just now with Firefox. The underlying issue seems > to be that Firefox tends to save 301 redirects until you close it and > re-open it. Note that when you delete an OpenShift instance and re-create > it, its IP address changes. When accessing http://app-namespace.rhcloud > after re-creating the instance, you'll actually be redirected to > https://app-namespace.rhcloud/app. However, when using Firefox, this URL > seems to get mapped to the old IP address resulting in this error: 'The > requested URL /app was not found on this server.' After deleting and > re-creating an OpenShift instance with the same name, if you restart > Firefox, you should once again be able to access the application. I've > verified that this does work. > > Similar issues with Firefox were actually mentioned in some OpenShift forum > posts as well: > > https://www.openshift.com/forums/openshift/httpawm-pribylrhcloudcom-the-requested-url-was-not-found-on-this-server#comment-33570 > https://www.openshift.com/forums/openshift/custom-domain-httpwwwxxxxxxxcom-is-redirecting-to-httpswwwxxxxxxxcomapp#comment-34215 > > > Farah > > ----- Original Message ----- > > From: "Farah Juma" > > To: aerogear-dev at lists.jboss.org > > Sent: Monday, January 27, 2014 1:07:31 PM > > Subject: Re: [aerogear-dev] Upgrading process for the OpenShift AeroGear > > ????????UPS????????cartridge > > > > > > > From: "Andrea Vibelli" > > > To: aerogear-dev at lists.jboss.org > > > Sent: Monday, January 27, 2014 12:27:04 PM > > > Subject: [aerogear-dev] Upgrading process for the OpenShift AeroGear UPS > > > ????????cartridge > > > > > > Hello all, > > > > > > I just wanted to let you know that Farah is working on AGPUSH-504, a > > > snapshot/restore approach for upgrading the downloadable cartridge. > > > The overall idea is to take a snapshot of the database (and other > > > configuration) for an older existing cartridge instance, delete this old > > > instance, and then create a new instance based on the latest cartridge > > > version and restore the new instance's database (and other configuration) > > > to > > > the state in the snapshot. The new instance must have the same name as > > > the > > > old instance. The main thing that she needed to determine was what needed > > > to > > > be included in the snapshot that's not already part of the MySQL > > > database. > > > The SimplePush token key was one of these things (we generate this value > > > when a cartridge instance is created and it is used by the server for > > > encryption and decryption of endpoint URLs). The standalone.xml file also > > > needed to be backed up just in case the user made any changes to it. > > > (Creating a backup of this file allows users to manually merge back any > > > changes they may have made.) > > > > > > The snapshot/restore action hooks she has created can be found in [1]. > > > > > > The steps she has been using to try upgrading from an 0.8.1 instance are > > > listed below. It would be great if you could try out these steps as well. > > > There's one important caveat though: because an 0.8.1 instance won't have > > > the necessary snapshot hook, you'll need to manually perform some > > > commands > > > to save the necessary data (step 3 below). If we include these > > > snapshot/restore action hooks in the 0.10.0 cartridge release, users will > > > be > > > able to make use of these hooks for future upgrades, e.g., for upgrading > > > from 0.10.0 to 0.11.0. > > > ? > > > 1) Create an 0.8.1 cartridge instance > > > rhc create-app mypush > > > "https://cartreflect-claytondev.rhcloud.com/reflect?github=aerogear/openshift-origin-cartridge-aerogear-push&commit=8aada257de52157a837db23a9f7b1a8574fdffab" > > > mysql-5.1 > > > > > > 2) Log into the admin console, change password, create push applications, > > > create variants, send push notifications, etc. > > > > > > 3) ssh into your instance and perform these commands (this step manually > > > captures needed data) > > > echo "$OPENSHIFT_AEROGEAR_PUSH_TOKEN_KEY" > > > > $OPENSHIFT_DATA_DIR/aerogear_push_token_key > > > cp $OPENSHIFT_AEROGEAR_PUSH_DIR/standalone/configuration/standalone.xml > > > $OPENSHIFT_DATA_DIR/standalone.snapshot.xml > > > > > > 4) Create a snapshot of the 0.8.1 instance: rhc snapshot save mypush > > > > > > 5) Delete the 0.8.1 instance: rhc app delete mypush > > > > > > 6) Delete the local directory on the local machine (from step 1, you > > > should > > > have a directory named 'mypush') > > > > > > 7) Create a new cartridge instance (this uses her fork of the 0.9.0 > > > cartridge > > > repository that contains the snapshot/restore action hooks) > > > rhc create-app mypush > > > "https://cartreflect-claytondev.rhcloud.com/reflect?github=fjuma/openshift-origin-cartridge-aerogear-push&commit=956a4fc09edc93fe76394b86b265ceb1d238ccaf" > > > mysql-5.1 > > > > > > 8) Restore the instance: rhc snapshot restore mypush -f > > > /PATH/TO/mypush.tar.gz > > > > > > 9) You should now be able to log into the admin console with the same > > > password you previously set, see existing push applications, variants, > > > send > > > push notifications, etc. > > > > > > One disadvantage of this snapshot/restore approach is the extra work for > > > the > > > user. It would be nice to have a single command that can do the snapshot, > > > delete, create, and restore all at once. She is going to start looking > > > into > > > this "wrappering" functionality. > > > > > > > > > Why am I writing about this? > > > > > > I have made some test about the above steps. At a first glance, it seemed > > > that something was broken between steps 6 and 7. > > > Doing various tests, what I saw in the logs (server.log) were different > > > errors: > > > > > > 2014/01/26 10:19:18,061 ERROR [org.jboss.as] (MSC service thread 1-3) > > > JBAS015875: JBoss AS 7.1.1.Final "Brontes" started (with errors) in > > > 296088ms > > > - Started 349 of 524 services (52 services failed or missing > > > dependencies, > > > 119 services are passive or on-demand) > > > 2014/01/26 10:19:18,344 INFO ?[org.jboss.as.server] > > > (DeploymentScanner-threads - 2) JBAS015870: Deploy of deployment > > > "ROOT.war" > > > was rolled back with failure message {"JBAS014771: Services with > > > missing/unavailable dependencies" => > > > ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]} > > > 2014/01/26 10:19:19,390 INFO ?[org.jboss.as.server.deployment] (MSC > > > service > > > thread 1-2) JBAS015877: Stopped deployment ROOT.war in 1125ms > > > 2014/01/26 10:19:19,393 INFO ?[org.jboss.as.controller] > > > (DeploymentScanner-threads - 2) JBAS014774: Service status report > > > JBAS014775: ? ?New missing/unsatisfied dependencies: > > > ? ? ? service jboss.naming.context.java.jboss.datasources.PushEEDS > > > ? ? ? (missing) > > > ? ? ? dependents: [service > > > ? ? ? jboss.persistenceunit."ROOT.war#unifiedpush-default", service > > > ? ? ? jboss.persistenceunit."ROOT.war#picketlink-default"] > > > > > > > > > 2014/01/26 10:19:19,440 ERROR [org.jboss.as.server.deployment.scanner] > > > (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation failed > > > and > > > was rolled back. Steps that failed:" => {"Operation step-2" => > > > {"JBAS014771: > > > Services with missing/unavailable dependencies" => > > > ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]}}} > > > > > > It looks like the MySQL cartridge either wasn't added or wasn't able to > > start > > successfully. The following command can be used to check the status of the > > MySQL cartridge: > > > > rhc cartridge status -a APP -c mysql > > > > ? > > > OR > > > > > > > > > 2014/01/26 05:41:46,522 INFO ?[org.jboss.as.connector] (MSC service > > > thread > > > 1-1) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.9.Final) > > > 2014/01/26 05:41:46,922 ERROR > > > [org.jboss.as.controller.management-operation] > > > (ServerService Thread Pool -- 62) Operation ("enable") failed - address: > > > ([ > > > ? ? ("subsystem" => "datasources"), > > > ? ? ("data-source" => "PostgreSQLDS") > > > ]) - failure description: "JBAS014802: Cannot resolve expression > > > 'expression > > > \"jdbcostgresql://${env.OPENSHIFT_POSTGRESQL_DB_HOST}:${env.OPENSHIFT_POSTGRESQL_DB_PORT}/mypush13\"' > > > -- java.lang.IllegalStateException: Failed to resolve expression: > > > ${env.OPENSHIFT_POSTGRESQL_DB_HOST}" > > > > > > > > > OR > > > > > > > > > no errors in the logs, but in the deployments directory I found > > > 'ROOT.war.dodeploy' and 'ROOT.war.isdeploying' files, but no > > > 'ROOT.war.deployed' file. > > > > > > > > > Those error seemed to me as random and too strange (by the way, the > > > creation > > > of the cartridge is always correct, I never had problems if I created a > > > new > > > instance with a never used before name). > > > > > > To investigate further, I then tried to do the same steps with a > > > completely > > > different application: 'Kitchensink on OpenShift', and I had the same > > > error! > > > After the deletion and the recreation of a cartridge with a same name, I > > > encountered: 'The requested URL /app was not found on this server.' > > > The steps I have done are: > > > 1) rhc app create -a kitchensink -t jbossas-7 --from-code > > > git://github.com/openshift/kitchensink-example.git > > > 2) rhc snapshot save kitchensink > > > 3) rhc app delete kitchensink > > > 4) rm -rf kitchensinkhtml5/ > > > 5) rhc app create -a kitchensink -t jbossas-7 --from-code > > > git://github.com/openshift/kitchensink-example.git > > > 6) Access to the application. > > > > > > So the good news is that the error I encountered is not related to this > > > specific AeroGear cartridges, but the bad news is that is something more > > > general about OpenShift. > > > We need to investigate further and find out if there is a way to "flush" > > > the > > > deletion, it seems that there is something appended or cached that > > > prevent > > > the recreation of a cartridge with a same name. > > > > It's good that the issue you're running into isn't specific to the AeroGear > > cartridge. I've tried quite a few times today but I'm not able to reproduce > > the issue with the AeroGear cartridge or with the kitchensink application > > using the above steps. I suspect that there is indeed an OpenShift timing > > issue here. Let's check with the OpenShift team on this. > > > > Farah > > > > > We are currently doing some more tests on these process. > > > > > > > > > > > > _______________________________________________ > > > 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 Jan 28 03:49:48 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 28 Jan 2014 09:49:48 +0100 Subject: [aerogear-dev] Website restructure In-Reply-To: <52E29F6F.7080300@redhat.com> References: <2A4CF6B8-B8DD-4E31-B764-C7452CD99D19@redhat.com> <20140120123559.3a3aec13@kapy-ntb-x220> <52E29F6F.7080300@redhat.com> Message-ID: <74EC3F01-08E4-4612-ACCB-7E86D4A95FA2@gmail.com> Hello Hylke, Somehow I can?t make AG core work in the proposed page2 and page 3 as per your screen shot, I rather have page3 in your page3 and then page 3 will be a detailled example with download link to cookbook. In the page2 we could have download button at the top and documentation with code snippet at he bottom. General setup documentation should amybe fit into dowlad section. Note that not all category nee setup. for AG Core there isn?t any complicated set up. It?s just a lib. wdyt? Corinne On 24 Jan 2014, at 18:14, Hylke Bons wrote: > Hi Corinne, > > I've updated the mockup with a sidebar to show the structure a bit better: https://raw2.github.com/hbons/aerogear-design/master/website-restructure/aerogear-project.png I think this is mostly like what you've described. > > Other changes are a simple menubar and the platform icons on the main page that we decided we wanted back. > > "where do we put documentation like: http://aerogear.org/docs/guides/GetStartedAndroid/ which is not features oriented but goes into the category setup " > > This should actually go right below the download options (see the second page in the mockup). There will also a link to it in the Docs sidebar. It's a bit hard to explain in an email, I think the mockup explains it better. :) > > Hylke > > > On 20/01/2014 17:31, Corinne Krych wrote: >> Hello All >> >> I think the original idea was to have a common text. I think we could have common part for exemple: >> http://aerogear.org/docs/guides/aerogear-android/AerogearAndroidPipes101/ >> http://aerogear.org/docs/guides/iOSCookbook/ (section on pipe) >> http://aerogear.org/docs/guides/GetStartedAeroGearJS.html (section Pipeline & Pipes) >> all defined Pipe and pipeline, they could have a common part but of course this will involve some serious documentation refactoring. >> >> => first task make common smaller pages >> >> However, we still need platform specific text. In all the previous exemple we give code snippet + code explantion. We could extend the tab to include text + sample. >> >> What will be nice to have as a POC is also: >> - the main documentation page with the 3 features section: Core/Push/Security >> - when we pick core, the display of the list of features: Pipe, Store etc?. which is actually missing from Hylke draft. >> - where do we put documentation like: >> http://aerogear.org/docs/guides/GetStartedAndroid/ >> which is not features oriented but goes into the category setup >> >> I?ll fork your branch and try to see how we can refactor documentation and give you more concrete feedbacks shortly. >> For the menu color I guess the best person to help is Hylke. >> >> ++ >> Corinne >> >> >> On 20 Jan 2014, at 12:44, Sebastien Blanc wrote: >> >>> >>> >>> On Mon, Jan 20, 2014 at 12:35 PM, Karel Piwko wrote: >>> Looks good! >>> +1 I like the dracula theme ! >>> >>> Apart for platform related code (JavaScript, Objective-C, Java), are there any >>> plans to support platform related text? >>> >>> E.g. pipes on Aerogear can be used within FragmentActivity, which is valid for >>> Android only; Javadoc is not related to iOS, etc. That's basically a merge of >>> our guides into a one per feature with information covering all the platforms. >>> >>> Which brings me to and idea of global platform switch. User/reader can switch >>> platform once and all code snippets and platform related blocks are >>> automatically selected. Can also be session based and affect all pages user >>> visits. >>> +1 , that would be really cool. I came accross such a layout on https://www.paymill.com/fr-fr/documentation/reference/api-reference/#document-authentication , check on the right, you have a tab where you can switch between different languages, the snippet is updated. >>> >>> There are also some online apps that does the job for you like apiary.io and https://www.mashape.com >>> >>> Karel >>> >>> On Mon, 20 Jan 2014 11:37:28 +0100 >>> Erik Jan de Wit wrote: >>> >>>> Hi, >>>> >>>> What I get from this thread is that we like the colour section idea, but we >>>> don?t want to re structure the entire site. So what we need to discuss is how >>>> are we going to use these sections if we don?t restructure. What I like about >>>> them is that it emphasises that our API?s are similar for all platforms and >>>> that we only have one document explaining for instance what pipes are. But >>>> the menu, doesn?t fit into this new colour scheme, so we need some decisions >>>> about how we are going to move forward. >>>> >>>> Based on the work Corinne did with the introduction of sass I?ve had a go at >>>> implementing a bit what Hylke proposed, have a look at my sass branch >>>> https://github.com/edewit/aerogear.org/tree/saas and the page I?ve updated >>>> http://localhost:4000/docs/guides/aerogear-android/AerogearAndroidPipes101/ >>>> to be in section layout. Don?t look at the header and footer as I haven?t >>>> changed those. >>>> >>>> There are a couple of things that I don?t like about the current >>>> implementation, to enable the code blocks I?ve added some html into the >>>> asciidoc and some jquery magic in the layout. Maybe we could make this better >>>> by chaining the rendering/backend or by introducing some sort of plugin into >>>> asciidoc? Other then that, I?m sure Hylke sees a lot of things that are still >>>> off, but it?s a start. >>>> >>>> What do you think? >>>> >>>> Cheers, >>>> Erik Jan >>>> >>>> p.s >>>> example picture https://www.dropbox.com/s/qtc4g0xwnyi0p41/Example.tiff >>>> >>> _______________________________________________ >>> 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 Tue Jan 28 04:21:42 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 28 Jan 2014 10:21:42 +0100 Subject: [aerogear-dev] Upgrading process for the OpenShift AeroGear UPS cartridge In-Reply-To: <2034992562.5686126.1390898762650.JavaMail.root@redhat.com> References: <676075311.5431814.1390843624382.JavaMail.root@redhat.com> <2099059360.11646680.1390846051314.JavaMail.root@redhat.com> <1403896808.11718517.1390858087208.JavaMail.root@redhat.com> <2034992562.5686126.1390898762650.JavaMail.root@redhat.com> Message-ID: Farah/Andrea, is that on _creation_ or,also w/ any redirect from http -> https (enforced by our Push cartridge) -Matthias On Tue, Jan 28, 2014 at 9:46 AM, Andrea Vibelli wrote: > Hi Farah, > yes I do use FireFox. > > I have done the tests once again, and closing and reopening the browser > solved my issue, great, nice catch! > Maybe we could also include this additional step in the overall > instructions, what do you think? > Thank you > Andrea > > ----- Messaggio originale ----- > > Da: "Farah Juma" > > A: "Andrea Vibelli" , aerogear-dev at lists.jboss.org > > Inviato: Luned?, 27 gennaio 2014 22:28:07 > > Oggetto: Re: [aerogear-dev] Upgrading process for the OpenShift AeroGear > UPS cartridge > > > > After some more digging, I think I might know what's going on here. > Andrea, > > are you using Firefox? I wasn't able to reproduce the issue with Chrome > but > > was able to reproduce it just now with Firefox. The underlying issue > seems > > to be that Firefox tends to save 301 redirects until you close it and > > re-open it. Note that when you delete an OpenShift instance and re-create > > it, its IP address changes. When accessing http://app-namespace.rhcloud > > after re-creating the instance, you'll actually be redirected to > > https://app-namespace.rhcloud/app. However, when using Firefox, this URL > > seems to get mapped to the old IP address resulting in this error: 'The > > requested URL /app was not found on this server.' After deleting and > > re-creating an OpenShift instance with the same name, if you restart > > Firefox, you should once again be able to access the application. I've > > verified that this does work. > > > > Similar issues with Firefox were actually mentioned in some OpenShift > forum > > posts as well: > > > > > https://www.openshift.com/forums/openshift/httpawm-pribylrhcloudcom-the-requested-url-was-not-found-on-this-server#comment-33570 > > > https://www.openshift.com/forums/openshift/custom-domain-httpwwwxxxxxxxcom-is-redirecting-to-httpswwwxxxxxxxcomapp#comment-34215 > > > > > > Farah > > > > ----- Original Message ----- > > > From: "Farah Juma" > > > To: aerogear-dev at lists.jboss.org > > > Sent: Monday, January 27, 2014 1:07:31 PM > > > Subject: Re: [aerogear-dev] Upgrading process for the OpenShift > AeroGear > > > UPS cartridge > > > > > > > > > > From: "Andrea Vibelli" > > > > To: aerogear-dev at lists.jboss.org > > > > Sent: Monday, January 27, 2014 12:27:04 PM > > > > Subject: [aerogear-dev] Upgrading process for the OpenShift AeroGear > UPS > > > > cartridge > > > > > > > > Hello all, > > > > > > > > I just wanted to let you know that Farah is working on AGPUSH-504, a > > > > snapshot/restore approach for upgrading the downloadable cartridge. > > > > The overall idea is to take a snapshot of the database (and other > > > > configuration) for an older existing cartridge instance, delete this > old > > > > instance, and then create a new instance based on the latest > cartridge > > > > version and restore the new instance's database (and other > configuration) > > > > to > > > > the state in the snapshot. The new instance must have the same name > as > > > > the > > > > old instance. The main thing that she needed to determine was what > needed > > > > to > > > > be included in the snapshot that's not already part of the MySQL > > > > database. > > > > The SimplePush token key was one of these things (we generate this > value > > > > when a cartridge instance is created and it is used by the server for > > > > encryption and decryption of endpoint URLs). The standalone.xml file > also > > > > needed to be backed up just in case the user made any changes to it. > > > > (Creating a backup of this file allows users to manually merge back > any > > > > changes they may have made.) > > > > > > > > The snapshot/restore action hooks she has created can be found in > [1]. > > > > > > > > The steps she has been using to try upgrading from an 0.8.1 instance > are > > > > listed below. It would be great if you could try out these steps as > well. > > > > There's one important caveat though: because an 0.8.1 instance won't > have > > > > the necessary snapshot hook, you'll need to manually perform some > > > > commands > > > > to save the necessary data (step 3 below). If we include these > > > > snapshot/restore action hooks in the 0.10.0 cartridge release, users > will > > > > be > > > > able to make use of these hooks for future upgrades, e.g., for > upgrading > > > > from 0.10.0 to 0.11.0. > > > > > > > > 1) Create an 0.8.1 cartridge instance > > > > rhc create-app mypush > > > > " > https://cartreflect-claytondev.rhcloud.com/reflect?github=aerogear/openshift-origin-cartridge-aerogear-push&commit=8aada257de52157a837db23a9f7b1a8574fdffab > " > > > > mysql-5.1 > > > > > > > > 2) Log into the admin console, change password, create push > applications, > > > > create variants, send push notifications, etc. > > > > > > > > 3) ssh into your instance and perform these commands (this step > manually > > > > captures needed data) > > > > echo "$OPENSHIFT_AEROGEAR_PUSH_TOKEN_KEY" > > > > > $OPENSHIFT_DATA_DIR/aerogear_push_token_key > > > > cp > $OPENSHIFT_AEROGEAR_PUSH_DIR/standalone/configuration/standalone.xml > > > > $OPENSHIFT_DATA_DIR/standalone.snapshot.xml > > > > > > > > 4) Create a snapshot of the 0.8.1 instance: rhc snapshot save mypush > > > > > > > > 5) Delete the 0.8.1 instance: rhc app delete mypush > > > > > > > > 6) Delete the local directory on the local machine (from step 1, you > > > > should > > > > have a directory named 'mypush') > > > > > > > > 7) Create a new cartridge instance (this uses her fork of the 0.9.0 > > > > cartridge > > > > repository that contains the snapshot/restore action hooks) > > > > rhc create-app mypush > > > > " > https://cartreflect-claytondev.rhcloud.com/reflect?github=fjuma/openshift-origin-cartridge-aerogear-push&commit=956a4fc09edc93fe76394b86b265ceb1d238ccaf > " > > > > mysql-5.1 > > > > > > > > 8) Restore the instance: rhc snapshot restore mypush -f > > > > /PATH/TO/mypush.tar.gz > > > > > > > > 9) You should now be able to log into the admin console with the same > > > > password you previously set, see existing push applications, > variants, > > > > send > > > > push notifications, etc. > > > > > > > > One disadvantage of this snapshot/restore approach is the extra work > for > > > > the > > > > user. It would be nice to have a single command that can do the > snapshot, > > > > delete, create, and restore all at once. She is going to start > looking > > > > into > > > > this "wrappering" functionality. > > > > > > > > > > > > Why am I writing about this? > > > > > > > > I have made some test about the above steps. At a first glance, it > seemed > > > > that something was broken between steps 6 and 7. > > > > Doing various tests, what I saw in the logs (server.log) were > different > > > > errors: > > > > > > > > 2014/01/26 10:19:18,061 ERROR [org.jboss.as] (MSC service thread > 1-3) > > > > JBAS015875: JBoss AS 7.1.1.Final "Brontes" started (with errors) in > > > > 296088ms > > > > - Started 349 of 524 services (52 services failed or missing > > > > dependencies, > > > > 119 services are passive or on-demand) > > > > 2014/01/26 10:19:18,344 INFO [org.jboss.as.server] > > > > (DeploymentScanner-threads - 2) JBAS015870: Deploy of deployment > > > > "ROOT.war" > > > > was rolled back with failure message {"JBAS014771: Services with > > > > missing/unavailable dependencies" => > > > > > ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]} > > > > 2014/01/26 10:19:19,390 INFO [org.jboss.as.server.deployment] (MSC > > > > service > > > > thread 1-2) JBAS015877: Stopped deployment ROOT.war in 1125ms > > > > 2014/01/26 10:19:19,393 INFO [org.jboss.as.controller] > > > > (DeploymentScanner-threads - 2) JBAS014774: Service status report > > > > JBAS014775: New missing/unsatisfied dependencies: > > > > service jboss.naming.context.java.jboss.datasources.PushEEDS > > > > (missing) > > > > dependents: [service > > > > jboss.persistenceunit."ROOT.war#unifiedpush-default", service > > > > jboss.persistenceunit."ROOT.war#picketlink-default"] > > > > > > > > > > > > 2014/01/26 10:19:19,440 ERROR > [org.jboss.as.server.deployment.scanner] > > > > (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation > failed > > > > and > > > > was rolled back. Steps that failed:" => {"Operation step-2" => > > > > {"JBAS014771: > > > > Services with missing/unavailable dependencies" => > > > > > ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]}}} > > > > > > > > > It looks like the MySQL cartridge either wasn't added or wasn't able to > > > start > > > successfully. The following command can be used to check the status of > the > > > MySQL cartridge: > > > > > > rhc cartridge status -a APP -c mysql > > > > > > > > > > OR > > > > > > > > > > > > 2014/01/26 05:41:46,522 INFO [org.jboss.as.connector] (MSC service > > > > thread > > > > 1-1) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar > 1.0.9.Final) > > > > 2014/01/26 05:41:46,922 ERROR > > > > [org.jboss.as.controller.management-operation] > > > > (ServerService Thread Pool -- 62) Operation ("enable") failed - > address: > > > > ([ > > > > ("subsystem" => "datasources"), > > > > ("data-source" => "PostgreSQLDS") > > > > ]) - failure description: "JBAS014802: Cannot resolve expression > > > > 'expression > > > > > \"jdbcostgresql://${env.OPENSHIFT_POSTGRESQL_DB_HOST}:${env.OPENSHIFT_POSTGRESQL_DB_PORT}/mypush13\"' > > > > -- java.lang.IllegalStateException: Failed to resolve expression: > > > > ${env.OPENSHIFT_POSTGRESQL_DB_HOST}" > > > > > > > > > > > > OR > > > > > > > > > > > > no errors in the logs, but in the deployments directory I found > > > > 'ROOT.war.dodeploy' and 'ROOT.war.isdeploying' files, but no > > > > 'ROOT.war.deployed' file. > > > > > > > > > > > > Those error seemed to me as random and too strange (by the way, the > > > > creation > > > > of the cartridge is always correct, I never had problems if I > created a > > > > new > > > > instance with a never used before name). > > > > > > > > To investigate further, I then tried to do the same steps with a > > > > completely > > > > different application: 'Kitchensink on OpenShift', and I had the same > > > > error! > > > > After the deletion and the recreation of a cartridge with a same > name, I > > > > encountered: 'The requested URL /app was not found on this server.' > > > > The steps I have done are: > > > > 1) rhc app create -a kitchensink -t jbossas-7 --from-code > > > > git://github.com/openshift/kitchensink-example.git > > > > 2) rhc snapshot save kitchensink > > > > 3) rhc app delete kitchensink > > > > 4) rm -rf kitchensinkhtml5/ > > > > 5) rhc app create -a kitchensink -t jbossas-7 --from-code > > > > git://github.com/openshift/kitchensink-example.git > > > > 6) Access to the application. > > > > > > > > So the good news is that the error I encountered is not related to > this > > > > specific AeroGear cartridges, but the bad news is that is something > more > > > > general about OpenShift. > > > > We need to investigate further and find out if there is a way to > "flush" > > > > the > > > > deletion, it seems that there is something appended or cached that > > > > prevent > > > > the recreation of a cartridge with a same name. > > > > > > It's good that the issue you're running into isn't specific to the > AeroGear > > > cartridge. I've tried quite a few times today but I'm not able to > reproduce > > > the issue with the AeroGear cartridge or with the kitchensink > application > > > using the above steps. I suspect that there is indeed an OpenShift > timing > > > issue here. Let's check with the OpenShift team on this. > > > > > > Farah > > > > > > > We are currently doing some more tests on these process. > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > -- 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/20140128/d4e5768b/attachment-0001.html From lholmqui at redhat.com Tue Jan 28 09:36:14 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 28 Jan 2014 09:36:14 -0500 Subject: [aerogear-dev] Data Sync Thoughts Message-ID: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> yup, this is another Data Sync thread, >From a client side perspective, i have concerns that there is still not a clear direction yet. I know there are multiple ideas floating around on what our model should be, i'm all for choice, but what about deciding on 1 model to get started with. Then later once we have this nailed down, we can have other "adapters" with different models perhaps From kpiwko at redhat.com Tue Jan 28 09:40:18 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Tue, 28 Jan 2014 15:40:18 +0100 Subject: [aerogear-dev] Browser Targets In-Reply-To: <92FEC0F0-7359-4B49-8AC9-3BCD18D8D3B5@redhat.com> References: <79E19B64-A584-4821-A1BA-EA3B49E08344@redhat.com> <9682E781-175D-4BD7-A193-1593509416D8@redhat.com> <92FEC0F0-7359-4B49-8AC9-3BCD18D8D3B5@redhat.com> Message-ID: <20140128154018.04629c33@kapy-ntb-x220> Given Crypto API is not supported on Android pre 4.0 - https://issues.jboss.org/browse/AGJS-132, is this right time to drop Android 2.3.3, 3.x stock web browsers? Or do you want to keep AGJS partially supported on Android 2.3, 3.x? Thanks, Karel On Mon, 20 Jan 2014 11:39:02 -0500 Lucas Holmquist wrote: > following up from the team meeting, here is the current link to our Browser > targets > > http://aerogear.org/docs/guides/AeroGearBrowserTargets/ > > when this was created, i think it was very early on in the project. > > the desktop browsers are probably ok at this point, ( i would like to remove > IE9, though ). > > Mobile Browsers i think can be revamped a little, Mobile Safari should > probably be 6 and 7 > > we can probably add in Chrome for Android and FireFox for Android > > > WRT the other platforms, i think there is a JIRA to create a Matrix > > On Jan 8, 2014, at 5:28 AM, Erik Jan de Wit wrote: > > >> > >> on this same topic, what % should we be looking at when thinking about > >> dropping support for other platforms, like android and iOS > > > > Don?t think we should have a hard (written in stone) rule, but try and to > > be pragmatic about what we support. > > > > Because if 10% would be the limit for browsers we could drop IE support all > > together ;) _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > From lholmqui at redhat.com Tue Jan 28 09:40:47 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 28 Jan 2014 09:40:47 -0500 Subject: [aerogear-dev] bower repos for custom builds Message-ID: <8B1AE989-453D-456E-8911-D1E4F31084D1@redhat.com> so i created this JIRA https://issues.jboss.org/browse/AGJS-133 It would kind of neat if we offered some custom builds in bower, this way it could make it super easy for someone to pull in just data manager for example $ bower install aerogear-datamanager each "custom" build would be in it's own repo, but they don;t have to be "aerogear" repos, similar to how the bower ember repo isn't actually an ember official repo wdyt? would be somewhat easier to get "new" features out without waiting on the official release -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140128/a305f758/attachment.html From matzew at apache.org Tue Jan 28 09:42:53 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 28 Jan 2014 15:42:53 +0100 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> Message-ID: On Tue, Jan 28, 2014 at 3:36 PM, Lucas Holmquist wrote: > yup, this is another Data Sync thread, > > >From a client side perspective, i have concerns that there is still not a > clear direction yet. > > I know there are multiple ideas floating around on what our model should > be, i'm all for choice, but what about deciding on 1 model to get started > with. Then later once we have this nailed down, we can have other > "adapters" with different models perhaps > +1 > > > > _______________________________________________ > 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/20140128/9d5c06f5/attachment.html From lholmqui at redhat.com Tue Jan 28 09:47:56 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 28 Jan 2014 09:47:56 -0500 Subject: [aerogear-dev] Browser Targets In-Reply-To: <20140128154018.04629c33@kapy-ntb-x220> References: <79E19B64-A584-4821-A1BA-EA3B49E08344@redhat.com> <9682E781-175D-4BD7-A193-1593509416D8@redhat.com> <92FEC0F0-7359-4B49-8AC9-3BCD18D8D3B5@redhat.com> <20140128154018.04629c33@kapy-ntb-x220> Message-ID: On Jan 28, 2014, at 9:40 AM, Karel Piwko wrote: > Given Crypto API is not supported on Android pre 4.0 - > https://issues.jboss.org/browse/AGJS-132, is this right time to drop Android > 2.3.3, 3.x stock web browsers? > > Or do you want to keep AGJS partially supported on Android 2.3, 3.x? Most everything works except that crypto bit, i'd hate to say no support at all, i'm not really sure what the stats are for 2.3 > > Thanks, > > Karel > > On Mon, 20 Jan 2014 11:39:02 -0500 > Lucas Holmquist wrote: > >> following up from the team meeting, here is the current link to our Browser >> targets >> >> http://aerogear.org/docs/guides/AeroGearBrowserTargets/ >> >> when this was created, i think it was very early on in the project. >> >> the desktop browsers are probably ok at this point, ( i would like to remove >> IE9, though ). >> >> Mobile Browsers i think can be revamped a little, Mobile Safari should >> probably be 6 and 7 >> >> we can probably add in Chrome for Android and FireFox for Android >> >> >> WRT the other platforms, i think there is a JIRA to create a Matrix >> >> On Jan 8, 2014, at 5:28 AM, Erik Jan de Wit wrote: >> >>>> >>>> on this same topic, what % should we be looking at when thinking about >>>> dropping support for other platforms, like android and iOS >>> >>> Don?t think we should have a hard (written in stone) rule, but try and to >>> be pragmatic about what we support. >>> >>> Because if 10% would be the limit for browsers we could drop IE support all >>> together ;) _______________________________________________ >>> 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 Jan 28 09:53:46 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Tue, 28 Jan 2014 20:23:46 +0530 Subject: [aerogear-dev] bower repos for custom builds In-Reply-To: <8B1AE989-453D-456E-8911-D1E4F31084D1@redhat.com> References: <8B1AE989-453D-456E-8911-D1E4F31084D1@redhat.com> Message-ID: <5C428201-CC94-4B1C-AC87-7D47B7C70832@gmail.com> +9001 Envoy? de mon iPhone Le Jan 28, 2014 ? 20:10, Lucas Holmquist a ?crit : > so i created this JIRA https://issues.jboss.org/browse/AGJS-133 > > It would kind of neat if we offered some custom builds in bower, > > this way it could make it super easy for someone to pull in just data manager for example > > $ bower install aerogear-datamanager > > each "custom" build would be in it's own repo, but they don;t have to be "aerogear" repos, similar to how the bower ember repo isn't actually an ember official repo > > wdyt? > > would be somewhat easier to get "new" features out without waiting on the official release > > _______________________________________________ > 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/20140128/fd3453a7/attachment.html From fjuma at redhat.com Tue Jan 28 10:03:16 2014 From: fjuma at redhat.com (Farah Juma) Date: Tue, 28 Jan 2014 10:03:16 -0500 (EST) Subject: [aerogear-dev] Upgrading process for the OpenShift AeroGear UPS cartridge In-Reply-To: <2034992562.5686126.1390898762650.JavaMail.root@redhat.com> References: <676075311.5431814.1390843624382.JavaMail.root@redhat.com> <2099059360.11646680.1390846051314.JavaMail.root@redhat.com> <1403896808.11718517.1390858087208.JavaMail.root@redhat.com> <2034992562.5686126.1390898762650.JavaMail.root@redhat.com> Message-ID: <830585923.11958735.1390921396801.JavaMail.root@redhat.com> > From: "Andrea Vibelli" > To: "Farah Juma" > Cc: aerogear-dev at lists.jboss.org > Sent: Tuesday, January 28, 2014 3:46:02 AM > Subject: Re: Re: [aerogear-dev] Upgrading process for the OpenShift AeroGear UPS cartridge > > Hi Farah, > yes I do use FireFox. > > I have done the tests once again, and closing and reopening the browser > solved my issue, great, nice catch! Great, I'm glad that's working for you now! > Maybe we could also include this additional step in the overall instructions, > what do you think? Yes, that's a good idea. I'm going to create a gist with our updated steps and post it here when done to get more feedback. Thanks, Farah > Thank you > Andrea > > ----- Messaggio originale ----- > > Da: "Farah Juma" > > A: "Andrea Vibelli" , aerogear-dev at lists.jboss.org > > Inviato: Luned?, 27 gennaio 2014 22:28:07 > > Oggetto: Re: [aerogear-dev] Upgrading process for the OpenShift AeroGear > > UPS cartridge > > > > After some more digging, I think I might know what's going on here. Andrea, > > are you using Firefox? I wasn't able to reproduce the issue with Chrome but > > was able to reproduce it just now with Firefox. The underlying issue seems > > to be that Firefox tends to save 301 redirects until you close it and > > re-open it. Note that when you delete an OpenShift instance and re-create > > it, its IP address changes. When accessing http://app-namespace.rhcloud > > after re-creating the instance, you'll actually be redirected to > > https://app-namespace.rhcloud/app. However, when using Firefox, this URL > > seems to get mapped to the old IP address resulting in this error: 'The > > requested URL /app was not found on this server.' After deleting and > > re-creating an OpenShift instance with the same name, if you restart > > Firefox, you should once again be able to access the application. I've > > verified that this does work. > > > > Similar issues with Firefox were actually mentioned in some OpenShift forum > > posts as well: > > > > https://www.openshift.com/forums/openshift/httpawm-pribylrhcloudcom-the-requested-url-was-not-found-on-this-server#comment-33570 > > https://www.openshift.com/forums/openshift/custom-domain-httpwwwxxxxxxxcom-is-redirecting-to-httpswwwxxxxxxxcomapp#comment-34215 > > > > > > Farah > > > > ----- Original Message ----- > > > From: "Farah Juma" > > > To: aerogear-dev at lists.jboss.org > > > Sent: Monday, January 27, 2014 1:07:31 PM > > > Subject: Re: [aerogear-dev] Upgrading process for the OpenShift AeroGear > > > ????????UPS????????cartridge > > > > > > > > > > From: "Andrea Vibelli" > > > > To: aerogear-dev at lists.jboss.org > > > > Sent: Monday, January 27, 2014 12:27:04 PM > > > > Subject: [aerogear-dev] Upgrading process for the OpenShift AeroGear > > > > UPS > > > > ????????cartridge > > > > > > > > Hello all, > > > > > > > > I just wanted to let you know that Farah is working on AGPUSH-504, a > > > > snapshot/restore approach for upgrading the downloadable cartridge. > > > > The overall idea is to take a snapshot of the database (and other > > > > configuration) for an older existing cartridge instance, delete this > > > > old > > > > instance, and then create a new instance based on the latest cartridge > > > > version and restore the new instance's database (and other > > > > configuration) > > > > to > > > > the state in the snapshot. The new instance must have the same name as > > > > the > > > > old instance. The main thing that she needed to determine was what > > > > needed > > > > to > > > > be included in the snapshot that's not already part of the MySQL > > > > database. > > > > The SimplePush token key was one of these things (we generate this > > > > value > > > > when a cartridge instance is created and it is used by the server for > > > > encryption and decryption of endpoint URLs). The standalone.xml file > > > > also > > > > needed to be backed up just in case the user made any changes to it. > > > > (Creating a backup of this file allows users to manually merge back any > > > > changes they may have made.) > > > > > > > > The snapshot/restore action hooks she has created can be found in [1]. > > > > > > > > The steps she has been using to try upgrading from an 0.8.1 instance > > > > are > > > > listed below. It would be great if you could try out these steps as > > > > well. > > > > There's one important caveat though: because an 0.8.1 instance won't > > > > have > > > > the necessary snapshot hook, you'll need to manually perform some > > > > commands > > > > to save the necessary data (step 3 below). If we include these > > > > snapshot/restore action hooks in the 0.10.0 cartridge release, users > > > > will > > > > be > > > > able to make use of these hooks for future upgrades, e.g., for > > > > upgrading > > > > from 0.10.0 to 0.11.0. > > > > ? > > > > 1) Create an 0.8.1 cartridge instance > > > > rhc create-app mypush > > > > "https://cartreflect-claytondev.rhcloud.com/reflect?github=aerogear/openshift-origin-cartridge-aerogear-push&commit=8aada257de52157a837db23a9f7b1a8574fdffab" > > > > mysql-5.1 > > > > > > > > 2) Log into the admin console, change password, create push > > > > applications, > > > > create variants, send push notifications, etc. > > > > > > > > 3) ssh into your instance and perform these commands (this step > > > > manually > > > > captures needed data) > > > > echo "$OPENSHIFT_AEROGEAR_PUSH_TOKEN_KEY" > > > > > $OPENSHIFT_DATA_DIR/aerogear_push_token_key > > > > cp $OPENSHIFT_AEROGEAR_PUSH_DIR/standalone/configuration/standalone.xml > > > > $OPENSHIFT_DATA_DIR/standalone.snapshot.xml > > > > > > > > 4) Create a snapshot of the 0.8.1 instance: rhc snapshot save mypush > > > > > > > > 5) Delete the 0.8.1 instance: rhc app delete mypush > > > > > > > > 6) Delete the local directory on the local machine (from step 1, you > > > > should > > > > have a directory named 'mypush') > > > > > > > > 7) Create a new cartridge instance (this uses her fork of the 0.9.0 > > > > cartridge > > > > repository that contains the snapshot/restore action hooks) > > > > rhc create-app mypush > > > > "https://cartreflect-claytondev.rhcloud.com/reflect?github=fjuma/openshift-origin-cartridge-aerogear-push&commit=956a4fc09edc93fe76394b86b265ceb1d238ccaf" > > > > mysql-5.1 > > > > > > > > 8) Restore the instance: rhc snapshot restore mypush -f > > > > /PATH/TO/mypush.tar.gz > > > > > > > > 9) You should now be able to log into the admin console with the same > > > > password you previously set, see existing push applications, variants, > > > > send > > > > push notifications, etc. > > > > > > > > One disadvantage of this snapshot/restore approach is the extra work > > > > for > > > > the > > > > user. It would be nice to have a single command that can do the > > > > snapshot, > > > > delete, create, and restore all at once. She is going to start looking > > > > into > > > > this "wrappering" functionality. > > > > > > > > > > > > Why am I writing about this? > > > > > > > > I have made some test about the above steps. At a first glance, it > > > > seemed > > > > that something was broken between steps 6 and 7. > > > > Doing various tests, what I saw in the logs (server.log) were different > > > > errors: > > > > > > > > 2014/01/26 10:19:18,061 ERROR [org.jboss.as] (MSC service thread 1-3) > > > > JBAS015875: JBoss AS 7.1.1.Final "Brontes" started (with errors) in > > > > 296088ms > > > > - Started 349 of 524 services (52 services failed or missing > > > > dependencies, > > > > 119 services are passive or on-demand) > > > > 2014/01/26 10:19:18,344 INFO ?[org.jboss.as.server] > > > > (DeploymentScanner-threads - 2) JBAS015870: Deploy of deployment > > > > "ROOT.war" > > > > was rolled back with failure message {"JBAS014771: Services with > > > > missing/unavailable dependencies" => > > > > ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]} > > > > 2014/01/26 10:19:19,390 INFO ?[org.jboss.as.server.deployment] (MSC > > > > service > > > > thread 1-2) JBAS015877: Stopped deployment ROOT.war in 1125ms > > > > 2014/01/26 10:19:19,393 INFO ?[org.jboss.as.controller] > > > > (DeploymentScanner-threads - 2) JBAS014774: Service status report > > > > JBAS014775: ? ?New missing/unsatisfied dependencies: > > > > ? ? ? service jboss.naming.context.java.jboss.datasources.PushEEDS > > > > ? ? ? (missing) > > > > ? ? ? dependents: [service > > > > ? ? ? jboss.persistenceunit."ROOT.war#unifiedpush-default", service > > > > ? ? ? jboss.persistenceunit."ROOT.war#picketlink-default"] > > > > > > > > > > > > 2014/01/26 10:19:19,440 ERROR [org.jboss.as.server.deployment.scanner] > > > > (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation > > > > failed > > > > and > > > > was rolled back. Steps that failed:" => {"Operation step-2" => > > > > {"JBAS014771: > > > > Services with missing/unavailable dependencies" => > > > > ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]}}} > > > > > > > > > It looks like the MySQL cartridge either wasn't added or wasn't able to > > > start > > > successfully. The following command can be used to check the status of > > > the > > > MySQL cartridge: > > > > > > rhc cartridge status -a APP -c mysql > > > > > > ? > > > > OR > > > > > > > > > > > > 2014/01/26 05:41:46,522 INFO ?[org.jboss.as.connector] (MSC service > > > > thread > > > > 1-1) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar 1.0.9.Final) > > > > 2014/01/26 05:41:46,922 ERROR > > > > [org.jboss.as.controller.management-operation] > > > > (ServerService Thread Pool -- 62) Operation ("enable") failed - > > > > address: > > > > ([ > > > > ? ? ("subsystem" => "datasources"), > > > > ? ? ("data-source" => "PostgreSQLDS") > > > > ]) - failure description: "JBAS014802: Cannot resolve expression > > > > 'expression > > > > \"jdbcostgresql://${env.OPENSHIFT_POSTGRESQL_DB_HOST}:${env.OPENSHIFT_POSTGRESQL_DB_PORT}/mypush13\"' > > > > -- java.lang.IllegalStateException: Failed to resolve expression: > > > > ${env.OPENSHIFT_POSTGRESQL_DB_HOST}" > > > > > > > > > > > > OR > > > > > > > > > > > > no errors in the logs, but in the deployments directory I found > > > > 'ROOT.war.dodeploy' and 'ROOT.war.isdeploying' files, but no > > > > 'ROOT.war.deployed' file. > > > > > > > > > > > > Those error seemed to me as random and too strange (by the way, the > > > > creation > > > > of the cartridge is always correct, I never had problems if I created a > > > > new > > > > instance with a never used before name). > > > > > > > > To investigate further, I then tried to do the same steps with a > > > > completely > > > > different application: 'Kitchensink on OpenShift', and I had the same > > > > error! > > > > After the deletion and the recreation of a cartridge with a same name, > > > > I > > > > encountered: 'The requested URL /app was not found on this server.' > > > > The steps I have done are: > > > > 1) rhc app create -a kitchensink -t jbossas-7 --from-code > > > > git://github.com/openshift/kitchensink-example.git > > > > 2) rhc snapshot save kitchensink > > > > 3) rhc app delete kitchensink > > > > 4) rm -rf kitchensinkhtml5/ > > > > 5) rhc app create -a kitchensink -t jbossas-7 --from-code > > > > git://github.com/openshift/kitchensink-example.git > > > > 6) Access to the application. > > > > > > > > So the good news is that the error I encountered is not related to this > > > > specific AeroGear cartridges, but the bad news is that is something > > > > more > > > > general about OpenShift. > > > > We need to investigate further and find out if there is a way to > > > > "flush" > > > > the > > > > deletion, it seems that there is something appended or cached that > > > > prevent > > > > the recreation of a cartridge with a same name. > > > > > > It's good that the issue you're running into isn't specific to the > > > AeroGear > > > cartridge. I've tried quite a few times today but I'm not able to > > > reproduce > > > the issue with the AeroGear cartridge or with the kitchensink application > > > using the above steps. I suspect that there is indeed an OpenShift timing > > > issue here. Let's check with the OpenShift team on this. > > > > > > Farah > > > > > > > We are currently doing some more tests on these process. > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 fjuma at redhat.com Tue Jan 28 10:14:14 2014 From: fjuma at redhat.com (Farah Juma) Date: Tue, 28 Jan 2014 10:14:14 -0500 (EST) Subject: [aerogear-dev] Upgrading process for the OpenShift AeroGear UPS cartridge In-Reply-To: References: <676075311.5431814.1390843624382.JavaMail.root@redhat.com> <2099059360.11646680.1390846051314.JavaMail.root@redhat.com> <1403896808.11718517.1390858087208.JavaMail.root@redhat.com> <2034992562.5686126.1390898762650.JavaMail.root@redhat.com> Message-ID: <543520314.11975883.1390922054544.JavaMail.root@redhat.com> This affects any redirect from http -> https but only seems to be problematic when the cartridge instance's IP is changed (e.g., on re-creation). Farah ----- Original Message ----- > From: "Matthias Wessendorf" > To: "AeroGear Developer Mailing List" > Cc: "Farah Juma" > Sent: Tuesday, January 28, 2014 4:21:42 AM > Subject: Re: [aerogear-dev] Upgrading process for the OpenShift AeroGear UPS cartridge > > Farah/Andrea, > > is that on _creation_ or,also w/ any redirect from http -> https (enforced > by our Push cartridge) > > -Matthias > > > On Tue, Jan 28, 2014 at 9:46 AM, Andrea Vibelli wrote: > > > Hi Farah, > > yes I do use FireFox. > > > > I have done the tests once again, and closing and reopening the browser > > solved my issue, great, nice catch! > > Maybe we could also include this additional step in the overall > > instructions, what do you think? > > Thank you > > Andrea > > > > ----- Messaggio originale ----- > > > Da: "Farah Juma" > > > A: "Andrea Vibelli" , aerogear-dev at lists.jboss.org > > > Inviato: Luned?, 27 gennaio 2014 22:28:07 > > > Oggetto: Re: [aerogear-dev] Upgrading process for the OpenShift AeroGear > > UPS cartridge > > > > > > After some more digging, I think I might know what's going on here. > > Andrea, > > > are you using Firefox? I wasn't able to reproduce the issue with Chrome > > but > > > was able to reproduce it just now with Firefox. The underlying issue > > seems > > > to be that Firefox tends to save 301 redirects until you close it and > > > re-open it. Note that when you delete an OpenShift instance and re-create > > > it, its IP address changes. When accessing http://app-namespace.rhcloud > > > after re-creating the instance, you'll actually be redirected to > > > https://app-namespace.rhcloud/app. However, when using Firefox, this URL > > > seems to get mapped to the old IP address resulting in this error: 'The > > > requested URL /app was not found on this server.' After deleting and > > > re-creating an OpenShift instance with the same name, if you restart > > > Firefox, you should once again be able to access the application. I've > > > verified that this does work. > > > > > > Similar issues with Firefox were actually mentioned in some OpenShift > > forum > > > posts as well: > > > > > > > > https://www.openshift.com/forums/openshift/httpawm-pribylrhcloudcom-the-requested-url-was-not-found-on-this-server#comment-33570 > > > > > https://www.openshift.com/forums/openshift/custom-domain-httpwwwxxxxxxxcom-is-redirecting-to-httpswwwxxxxxxxcomapp#comment-34215 > > > > > > > > > Farah > > > > > > ----- Original Message ----- > > > > From: "Farah Juma" > > > > To: aerogear-dev at lists.jboss.org > > > > Sent: Monday, January 27, 2014 1:07:31 PM > > > > Subject: Re: [aerogear-dev] Upgrading process for the OpenShift > > AeroGear > > > > UPS cartridge > > > > > > > > > > > > > From: "Andrea Vibelli" > > > > > To: aerogear-dev at lists.jboss.org > > > > > Sent: Monday, January 27, 2014 12:27:04 PM > > > > > Subject: [aerogear-dev] Upgrading process for the OpenShift AeroGear > > UPS > > > > > cartridge > > > > > > > > > > Hello all, > > > > > > > > > > I just wanted to let you know that Farah is working on AGPUSH-504, a > > > > > snapshot/restore approach for upgrading the downloadable cartridge. > > > > > The overall idea is to take a snapshot of the database (and other > > > > > configuration) for an older existing cartridge instance, delete this > > old > > > > > instance, and then create a new instance based on the latest > > cartridge > > > > > version and restore the new instance's database (and other > > configuration) > > > > > to > > > > > the state in the snapshot. The new instance must have the same name > > as > > > > > the > > > > > old instance. The main thing that she needed to determine was what > > needed > > > > > to > > > > > be included in the snapshot that's not already part of the MySQL > > > > > database. > > > > > The SimplePush token key was one of these things (we generate this > > value > > > > > when a cartridge instance is created and it is used by the server for > > > > > encryption and decryption of endpoint URLs). The standalone.xml file > > also > > > > > needed to be backed up just in case the user made any changes to it. > > > > > (Creating a backup of this file allows users to manually merge back > > any > > > > > changes they may have made.) > > > > > > > > > > The snapshot/restore action hooks she has created can be found in > > [1]. > > > > > > > > > > The steps she has been using to try upgrading from an 0.8.1 instance > > are > > > > > listed below. It would be great if you could try out these steps as > > well. > > > > > There's one important caveat though: because an 0.8.1 instance won't > > have > > > > > the necessary snapshot hook, you'll need to manually perform some > > > > > commands > > > > > to save the necessary data (step 3 below). If we include these > > > > > snapshot/restore action hooks in the 0.10.0 cartridge release, users > > will > > > > > be > > > > > able to make use of these hooks for future upgrades, e.g., for > > upgrading > > > > > from 0.10.0 to 0.11.0. > > > > > > > > > > 1) Create an 0.8.1 cartridge instance > > > > > rhc create-app mypush > > > > > " > > https://cartreflect-claytondev.rhcloud.com/reflect?github=aerogear/openshift-origin-cartridge-aerogear-push&commit=8aada257de52157a837db23a9f7b1a8574fdffab > > " > > > > > mysql-5.1 > > > > > > > > > > 2) Log into the admin console, change password, create push > > applications, > > > > > create variants, send push notifications, etc. > > > > > > > > > > 3) ssh into your instance and perform these commands (this step > > manually > > > > > captures needed data) > > > > > echo "$OPENSHIFT_AEROGEAR_PUSH_TOKEN_KEY" > > > > > > $OPENSHIFT_DATA_DIR/aerogear_push_token_key > > > > > cp > > $OPENSHIFT_AEROGEAR_PUSH_DIR/standalone/configuration/standalone.xml > > > > > $OPENSHIFT_DATA_DIR/standalone.snapshot.xml > > > > > > > > > > 4) Create a snapshot of the 0.8.1 instance: rhc snapshot save mypush > > > > > > > > > > 5) Delete the 0.8.1 instance: rhc app delete mypush > > > > > > > > > > 6) Delete the local directory on the local machine (from step 1, you > > > > > should > > > > > have a directory named 'mypush') > > > > > > > > > > 7) Create a new cartridge instance (this uses her fork of the 0.9.0 > > > > > cartridge > > > > > repository that contains the snapshot/restore action hooks) > > > > > rhc create-app mypush > > > > > " > > https://cartreflect-claytondev.rhcloud.com/reflect?github=fjuma/openshift-origin-cartridge-aerogear-push&commit=956a4fc09edc93fe76394b86b265ceb1d238ccaf > > " > > > > > mysql-5.1 > > > > > > > > > > 8) Restore the instance: rhc snapshot restore mypush -f > > > > > /PATH/TO/mypush.tar.gz > > > > > > > > > > 9) You should now be able to log into the admin console with the same > > > > > password you previously set, see existing push applications, > > variants, > > > > > send > > > > > push notifications, etc. > > > > > > > > > > One disadvantage of this snapshot/restore approach is the extra work > > for > > > > > the > > > > > user. It would be nice to have a single command that can do the > > snapshot, > > > > > delete, create, and restore all at once. She is going to start > > looking > > > > > into > > > > > this "wrappering" functionality. > > > > > > > > > > > > > > > Why am I writing about this? > > > > > > > > > > I have made some test about the above steps. At a first glance, it > > seemed > > > > > that something was broken between steps 6 and 7. > > > > > Doing various tests, what I saw in the logs (server.log) were > > different > > > > > errors: > > > > > > > > > > 2014/01/26 10:19:18,061 ERROR [org.jboss.as] (MSC service thread > > 1-3) > > > > > JBAS015875: JBoss AS 7.1.1.Final "Brontes" started (with errors) in > > > > > 296088ms > > > > > - Started 349 of 524 services (52 services failed or missing > > > > > dependencies, > > > > > 119 services are passive or on-demand) > > > > > 2014/01/26 10:19:18,344 INFO [org.jboss.as.server] > > > > > (DeploymentScanner-threads - 2) JBAS015870: Deploy of deployment > > > > > "ROOT.war" > > > > > was rolled back with failure message {"JBAS014771: Services with > > > > > missing/unavailable dependencies" => > > > > > > > ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]} > > > > > 2014/01/26 10:19:19,390 INFO [org.jboss.as.server.deployment] (MSC > > > > > service > > > > > thread 1-2) JBAS015877: Stopped deployment ROOT.war in 1125ms > > > > > 2014/01/26 10:19:19,393 INFO [org.jboss.as.controller] > > > > > (DeploymentScanner-threads - 2) JBAS014774: Service status report > > > > > JBAS014775: New missing/unsatisfied dependencies: > > > > > service jboss.naming.context.java.jboss.datasources.PushEEDS > > > > > (missing) > > > > > dependents: [service > > > > > jboss.persistenceunit."ROOT.war#unifiedpush-default", service > > > > > jboss.persistenceunit."ROOT.war#picketlink-default"] > > > > > > > > > > > > > > > 2014/01/26 10:19:19,440 ERROR > > [org.jboss.as.server.deployment.scanner] > > > > > (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation > > failed > > > > > and > > > > > was rolled back. Steps that failed:" => {"Operation step-2" => > > > > > {"JBAS014771: > > > > > Services with missing/unavailable dependencies" => > > > > > > > ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]}}} > > > > > > > > > > > > It looks like the MySQL cartridge either wasn't added or wasn't able to > > > > start > > > > successfully. The following command can be used to check the status of > > the > > > > MySQL cartridge: > > > > > > > > rhc cartridge status -a APP -c mysql > > > > > > > > > > > > > OR > > > > > > > > > > > > > > > 2014/01/26 05:41:46,522 INFO [org.jboss.as.connector] (MSC service > > > > > thread > > > > > 1-1) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar > > 1.0.9.Final) > > > > > 2014/01/26 05:41:46,922 ERROR > > > > > [org.jboss.as.controller.management-operation] > > > > > (ServerService Thread Pool -- 62) Operation ("enable") failed - > > address: > > > > > ([ > > > > > ("subsystem" => "datasources"), > > > > > ("data-source" => "PostgreSQLDS") > > > > > ]) - failure description: "JBAS014802: Cannot resolve expression > > > > > 'expression > > > > > > > \"jdbcostgresql://${env.OPENSHIFT_POSTGRESQL_DB_HOST}:${env.OPENSHIFT_POSTGRESQL_DB_PORT}/mypush13\"' > > > > > -- java.lang.IllegalStateException: Failed to resolve expression: > > > > > ${env.OPENSHIFT_POSTGRESQL_DB_HOST}" > > > > > > > > > > > > > > > OR > > > > > > > > > > > > > > > no errors in the logs, but in the deployments directory I found > > > > > 'ROOT.war.dodeploy' and 'ROOT.war.isdeploying' files, but no > > > > > 'ROOT.war.deployed' file. > > > > > > > > > > > > > > > Those error seemed to me as random and too strange (by the way, the > > > > > creation > > > > > of the cartridge is always correct, I never had problems if I > > created a > > > > > new > > > > > instance with a never used before name). > > > > > > > > > > To investigate further, I then tried to do the same steps with a > > > > > completely > > > > > different application: 'Kitchensink on OpenShift', and I had the same > > > > > error! > > > > > After the deletion and the recreation of a cartridge with a same > > name, I > > > > > encountered: 'The requested URL /app was not found on this server.' > > > > > The steps I have done are: > > > > > 1) rhc app create -a kitchensink -t jbossas-7 --from-code > > > > > git://github.com/openshift/kitchensink-example.git > > > > > 2) rhc snapshot save kitchensink > > > > > 3) rhc app delete kitchensink > > > > > 4) rm -rf kitchensinkhtml5/ > > > > > 5) rhc app create -a kitchensink -t jbossas-7 --from-code > > > > > git://github.com/openshift/kitchensink-example.git > > > > > 6) Access to the application. > > > > > > > > > > So the good news is that the error I encountered is not related to > > this > > > > > specific AeroGear cartridges, but the bad news is that is something > > more > > > > > general about OpenShift. > > > > > We need to investigate further and find out if there is a way to > > "flush" > > > > > the > > > > > deletion, it seems that there is something appended or cached that > > > > > prevent > > > > > the recreation of a cartridge with a same name. > > > > > > > > It's good that the issue you're running into isn't specific to the > > AeroGear > > > > cartridge. I've tried quite a few times today but I'm not able to > > reproduce > > > > the issue with the AeroGear cartridge or with the kitchensink > > application > > > > using the above steps. I suspect that there is indeed an OpenShift > > timing > > > > issue here. Let's check with the OpenShift team on this. > > > > > > > > Farah > > > > > > > > > We are currently doing some more tests on these process. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 > > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > From supittma at redhat.com Tue Jan 28 10:30:47 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 28 Jan 2014 10:30:47 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> Message-ID: <52E7CD27.2060206@redhat.com> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: > yup, this is another Data Sync thread, > > >From a client side perspective, i have concerns that there is still not a clear direction yet. > > I know there are multiple ideas floating around on what our model should be, i'm all for choice, but what about deciding on 1 model to get started with. Then later once we have this nailed down, we can have other "adapters" with different models perhaps All the data model is is an envelope of sync metadata around an object right? We also need to think about the API and server/client protocol as well. I think that for sync 1.0 we could focus on the following behavior (it worked for my demos at least) 1. We have a Sync factory similar to Pipeline, Authenticator, Registrar, and KeyService. 2. The Sync factory consumes/manages Synchronizer instances. 3. AG Synchronizer listens for sync messages using UnifiedPush endpoints. 4. AG Synchronizer sends sync messages using Pipes 5. AG Synchronizer holds local data in a store 6. When AGSynchronizer gets a message it is responsible for updating the Store and then notifying code listing for updates OR for notifying the code that an error has occurred and needs to be addressed. 7. When the developer updates data in the store, the synchronizer should package that data and send it to the server. The synchronizer is responsible for error handling, retrying, back-off, etc. 8. We should include multiple synchronizer implementations to deal with multiple very simple use cases which involve legacy systems. (For instance polling to load static data on a schedule.) Thoughts? Tomatoes? > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From lholmqui at redhat.com Tue Jan 28 10:48:14 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 28 Jan 2014 10:48:14 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <52E7CD27.2060206@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> Message-ID: On Jan 28, 2014, at 10:30 AM, Summers Pittman wrote: > On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >> yup, this is another Data Sync thread, >> >>> From a client side perspective, i have concerns that there is still not a clear direction yet. >> >> I know there are multiple ideas floating around on what our model should be, i'm all for choice, but what about deciding on 1 model to get started with. Then later once we have this nailed down, we can have other "adapters" with different models perhaps > All the data model is is an envelope of sync metadata around an object > right? right > > We also need to think about the API and server/client protocol as well. > > I think that for sync 1.0 we could focus on the following behavior (it > worked for my demos at least) > > 1. We have a Sync factory similar to Pipeline, Authenticator, > Registrar, and KeyService. > 2. The Sync factory consumes/manages Synchronizer instances. > 3. AG Synchronizer listens for sync messages using UnifiedPush endpoints. i thought for a 1.0 we weren't thinking about "realtime" > 4. AG Synchronizer sends sync messages using Pipes > 5. AG Synchronizer holds local data in a store > > 6. When AGSynchronizer gets a message it is responsible for updating > the Store and then notifying code listing for updates OR for notifying > the code that an error has occurred and needs to be addressed. > > 7. When the developer updates data in the store, the synchronizer > should package that data and send it to the server. The synchronizer is > responsible for error handling, retrying, back-off, etc. > > 8. We should include multiple synchronizer implementations to deal with > multiple very simple use cases which involve legacy systems. (For > instance polling to load static data on a schedule.) > > Thoughts? Tomatoes? >> >> >> >> _______________________________________________ >> 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 Jan 28 10:54:35 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 28 Jan 2014 10:54:35 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> Message-ID: <52E7D2BB.8060605@redhat.com> On 01/28/2014 10:48 AM, Lucas Holmquist wrote: > On Jan 28, 2014, at 10:30 AM, Summers Pittman wrote: > >> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >>> yup, this is another Data Sync thread, >>> >>>> From a client side perspective, i have concerns that there is still not a clear direction yet. >>> I know there are multiple ideas floating around on what our model should be, i'm all for choice, but what about deciding on 1 model to get started with. Then later once we have this nailed down, we can have other "adapters" with different models perhaps >> All the data model is is an envelope of sync metadata around an object >> right? > right > >> We also need to think about the API and server/client protocol as well. >> >> I think that for sync 1.0 we could focus on the following behavior (it >> worked for my demos at least) >> >> 1. We have a Sync factory similar to Pipeline, Authenticator, >> Registrar, and KeyService. >> 2. The Sync factory consumes/manages Synchronizer instances. >> 3. AG Synchronizer listens for sync messages using UnifiedPush endpoints. > i thought for a 1.0 we weren't thinking about "realtime" When I hear realtime I think sub 100 ms updates to all clients. (think gaming) What I thought we were going for was something closer to email. The data gets changed and at some point in the future the client knows. More specifically, the thing the ONE thing that makes sync special is it is a push instead of poll implementation. > >> 4. AG Synchronizer sends sync messages using Pipes >> 5. AG Synchronizer holds local data in a store >> >> 6. When AGSynchronizer gets a message it is responsible for updating >> the Store and then notifying code listing for updates OR for notifying >> the code that an error has occurred and needs to be addressed. >> >> 7. When the developer updates data in the store, the synchronizer >> should package that data and send it to the server. The synchronizer is >> responsible for error handling, retrying, back-off, etc. >> >> 8. We should include multiple synchronizer implementations to deal with >> multiple very simple use cases which involve legacy systems. (For >> instance polling to load static data on a schedule.) >> >> Thoughts? Tomatoes? >>> >>> >>> _______________________________________________ >>> 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 Tue Jan 28 10:58:54 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 28 Jan 2014 10:58:54 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <52E7D2BB.8060605@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> Message-ID: <5DCEB5A8-1942-4C0C-8C0E-3DFCB5521C0B@redhat.com> On Jan 28, 2014, at 10:54 AM, Summers Pittman wrote: > On 01/28/2014 10:48 AM, Lucas Holmquist wrote: >> On Jan 28, 2014, at 10:30 AM, Summers Pittman wrote: >> >>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >>>> yup, this is another Data Sync thread, >>>> >>>>> From a client side perspective, i have concerns that there is still not a clear direction yet. >>>> I know there are multiple ideas floating around on what our model should be, i'm all for choice, but what about deciding on 1 model to get started with. Then later once we have this nailed down, we can have other "adapters" with different models perhaps >>> All the data model is is an envelope of sync metadata around an object >>> right? >> right >> >>> We also need to think about the API and server/client protocol as well. >>> >>> I think that for sync 1.0 we could focus on the following behavior (it >>> worked for my demos at least) >>> >>> 1. We have a Sync factory similar to Pipeline, Authenticator, >>> Registrar, and KeyService. >>> 2. The Sync factory consumes/manages Synchronizer instances. >>> 3. AG Synchronizer listens for sync messages using UnifiedPush endpoints. >> i thought for a 1.0 we weren't thinking about "realtime" > When I hear realtime I think sub 100 ms updates to all clients. (think > gaming) > > What I thought we were going for was something closer to email. The > data gets changed and at some point in the future the client knows. More > specifically, the thing the ONE thing that makes sync special is it is a > push instead of poll implementation. this makes sense, but i guess it would be push when available. thinking web and crappy web socket support( dang you carriers ) > >> >>> 4. AG Synchronizer sends sync messages using Pipes >>> 5. AG Synchronizer holds local data in a store >>> >>> 6. When AGSynchronizer gets a message it is responsible for updating >>> the Store and then notifying code listing for updates OR for notifying >>> the code that an error has occurred and needs to be addressed. >>> >>> 7. When the developer updates data in the store, the synchronizer >>> should package that data and send it to the server. The synchronizer is >>> responsible for error handling, retrying, back-off, etc. >>> >>> 8. We should include multiple synchronizer implementations to deal with >>> multiple very simple use cases which involve legacy systems. (For >>> instance polling to load static data on a schedule.) >>> >>> Thoughts? Tomatoes? >>>> >>>> >>>> _______________________________________________ >>>> 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 Jan 28 11:01:57 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 28 Jan 2014 11:01:57 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <5DCEB5A8-1942-4C0C-8C0E-3DFCB5521C0B@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> <5DCEB5A8-1942-4C0C-8C0E-3DFCB5521C0B@redhat.com> Message-ID: <52E7D475.6060208@redhat.com> On 01/28/2014 10:58 AM, Lucas Holmquist wrote: > On Jan 28, 2014, at 10:54 AM, Summers Pittman wrote: > >> On 01/28/2014 10:48 AM, Lucas Holmquist wrote: >>> On Jan 28, 2014, at 10:30 AM, Summers Pittman wrote: >>> >>>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >>>>> yup, this is another Data Sync thread, >>>>> >>>>>> From a client side perspective, i have concerns that there is still not a clear direction yet. >>>>> I know there are multiple ideas floating around on what our model should be, i'm all for choice, but what about deciding on 1 model to get started with. Then later once we have this nailed down, we can have other "adapters" with different models perhaps >>>> All the data model is is an envelope of sync metadata around an object >>>> right? >>> right >>> >>>> We also need to think about the API and server/client protocol as well. >>>> >>>> I think that for sync 1.0 we could focus on the following behavior (it >>>> worked for my demos at least) >>>> >>>> 1. We have a Sync factory similar to Pipeline, Authenticator, >>>> Registrar, and KeyService. >>>> 2. The Sync factory consumes/manages Synchronizer instances. >>>> 3. AG Synchronizer listens for sync messages using UnifiedPush endpoints. >>> i thought for a 1.0 we weren't thinking about "realtime" >> When I hear realtime I think sub 100 ms updates to all clients. (think >> gaming) >> >> What I thought we were going for was something closer to email. The >> data gets changed and at some point in the future the client knows. More >> specifically, the thing the ONE thing that makes sync special is it is a >> push instead of poll implementation. > this makes sense, but i guess it would be push when available. thinking web and crappy web socket support( dang you carriers ) Right. I'm not saying lets do something complicated. I'm saying lets use GCM, iOS CM, and simple push to send notifications to tell the client something. In simplePush case it is "this data changed, get the new stuff and update yourself". In Android and iOS case it may be that or it may be "here is new data". In general, I am fine for getting a message saying something like Documents/Schedules/1/${revision}. Then I can check my revisions, fetch data if necessary, update my local data, and send any updates. That SHOULD (I think) be doable with simplepush as well right? > >>>> 4. AG Synchronizer sends sync messages using Pipes >>>> 5. AG Synchronizer holds local data in a store >>>> >>>> 6. When AGSynchronizer gets a message it is responsible for updating >>>> the Store and then notifying code listing for updates OR for notifying >>>> the code that an error has occurred and needs to be addressed. >>>> >>>> 7. When the developer updates data in the store, the synchronizer >>>> should package that data and send it to the server. The synchronizer is >>>> responsible for error handling, retrying, back-off, etc. >>>> >>>> 8. We should include multiple synchronizer implementations to deal with >>>> multiple very simple use cases which involve legacy systems. (For >>>> instance polling to load static data on a schedule.) >>>> >>>> Thoughts? Tomatoes? >>>>> >>>>> _______________________________________________ >>>>> 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 From corinnekrych at gmail.com Tue Jan 28 11:11:55 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Tue, 28 Jan 2014 17:11:55 +0100 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <52E7D475.6060208@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> <5DCEB5A8-1942-4C0C-8C0E-3DFCB5521C0B@redhat.com> <52E7D475.6060208@redhat.com> Message-ID: I think we still need the synchronisation mode in pull mode. How are we going to deal with this use case with simple push: UserA is offline update some data, then switch off his phone Some other users update data UserA open his app, he has missed some push notifications but still want to sync his app. ++ Corinne On 28 January 2014 17:01, Summers Pittman wrote: > On 01/28/2014 10:58 AM, Lucas Holmquist wrote: > > On Jan 28, 2014, at 10:54 AM, Summers Pittman > wrote: > > > >> On 01/28/2014 10:48 AM, Lucas Holmquist wrote: > >>> On Jan 28, 2014, at 10:30 AM, Summers Pittman > wrote: > >>> > >>>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: > >>>>> yup, this is another Data Sync thread, > >>>>> > >>>>>> From a client side perspective, i have concerns that there is > still not a clear direction yet. > >>>>> I know there are multiple ideas floating around on what our model > should be, i'm all for choice, but what about deciding on 1 model to get > started with. Then later once we have this nailed down, we can have other > "adapters" with different models perhaps > >>>> All the data model is is an envelope of sync metadata around an object > >>>> right? > >>> right > >>> > >>>> We also need to think about the API and server/client protocol as > well. > >>>> > >>>> I think that for sync 1.0 we could focus on the following behavior (it > >>>> worked for my demos at least) > >>>> > >>>> 1. We have a Sync factory similar to Pipeline, Authenticator, > >>>> Registrar, and KeyService. > >>>> 2. The Sync factory consumes/manages Synchronizer instances. > >>>> 3. AG Synchronizer listens for sync messages using UnifiedPush > endpoints. > >>> i thought for a 1.0 we weren't thinking about "realtime" > >> When I hear realtime I think sub 100 ms updates to all clients. (think > >> gaming) > >> > >> What I thought we were going for was something closer to email. The > >> data gets changed and at some point in the future the client knows. More > >> specifically, the thing the ONE thing that makes sync special is it is a > >> push instead of poll implementation. > > this makes sense, but i guess it would be push when available. thinking > web and crappy web socket support( dang you carriers ) > Right. I'm not saying lets do something complicated. I'm saying lets > use GCM, iOS CM, and simple push to send notifications to tell the > client something. In simplePush case it is "this data changed, get the > new stuff and update yourself". In Android and iOS case it may be that > or it may be "here is new data". > > In general, I am fine for getting a message saying something like > Documents/Schedules/1/${revision}. Then I can check my revisions, fetch > data if necessary, update my local data, and send any updates. That > SHOULD (I think) be doable with simplepush as well right? > > > > >>>> 4. AG Synchronizer sends sync messages using Pipes > >>>> 5. AG Synchronizer holds local data in a store > >>>> > >>>> 6. When AGSynchronizer gets a message it is responsible for updating > >>>> the Store and then notifying code listing for updates OR for notifying > >>>> the code that an error has occurred and needs to be addressed. > >>>> > >>>> 7. When the developer updates data in the store, the synchronizer > >>>> should package that data and send it to the server. The synchronizer > is > >>>> responsible for error handling, retrying, back-off, etc. > >>>> > >>>> 8. We should include multiple synchronizer implementations to deal > with > >>>> multiple very simple use cases which involve legacy systems. (For > >>>> instance polling to load static data on a schedule.) > >>>> > >>>> Thoughts? Tomatoes? > >>>>> > >>>>> _______________________________________________ > >>>>> 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/20140128/15d114a8/attachment.html From bruno at abstractj.org Tue Jan 28 11:21:36 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 28 Jan 2014 14:21:36 -0200 Subject: [aerogear-dev] Browser Targets In-Reply-To: References: <79E19B64-A584-4821-A1BA-EA3B49E08344@redhat.com> <9682E781-175D-4BD7-A193-1593509416D8@redhat.com> <92FEC0F0-7359-4B49-8AC9-3BCD18D8D3B5@redhat.com> <20140128154018.04629c33@kapy-ntb-x220> Message-ID: The crypto bit will fallback to sjcl implementation as far as I know (not safe) once the entropy doesn?t come from WebCrypto, but that works, as far as I know. -- abstractj On January 28, 2014 at 12:48:03 PM, Lucas Holmquist (lholmqui at redhat.com) wrote: > > Most everything works except that crypto bit, i'd hate to say > no support at all, i'm not really sure what the stats are for 2.3 > From lholmqui at redhat.com Tue Jan 28 11:41:04 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 28 Jan 2014 11:41:04 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <52E7D475.6060208@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> <5DCEB5A8-1942-4C0C-8C0E-3DFCB5521C0B@redhat.com> <52E7D475.6060208@redhat.com> Message-ID: On Jan 28, 2014, at 11:01 AM, Summers Pittman wrote: > On 01/28/2014 10:58 AM, Lucas Holmquist wrote: >> On Jan 28, 2014, at 10:54 AM, Summers Pittman wrote: >> >>> On 01/28/2014 10:48 AM, Lucas Holmquist wrote: >>>> On Jan 28, 2014, at 10:30 AM, Summers Pittman wrote: >>>> >>>>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >>>>>> yup, this is another Data Sync thread, >>>>>> >>>>>>> From a client side perspective, i have concerns that there is still not a clear direction yet. >>>>>> I know there are multiple ideas floating around on what our model should be, i'm all for choice, but what about deciding on 1 model to get started with. Then later once we have this nailed down, we can have other "adapters" with different models perhaps >>>>> All the data model is is an envelope of sync metadata around an object >>>>> right? >>>> right >>>> >>>>> We also need to think about the API and server/client protocol as well. >>>>> >>>>> I think that for sync 1.0 we could focus on the following behavior (it >>>>> worked for my demos at least) >>>>> >>>>> 1. We have a Sync factory similar to Pipeline, Authenticator, >>>>> Registrar, and KeyService. >>>>> 2. The Sync factory consumes/manages Synchronizer instances. >>>>> 3. AG Synchronizer listens for sync messages using UnifiedPush endpoints. >>>> i thought for a 1.0 we weren't thinking about "realtime" >>> When I hear realtime I think sub 100 ms updates to all clients. (think >>> gaming) >>> >>> What I thought we were going for was something closer to email. The >>> data gets changed and at some point in the future the client knows. More >>> specifically, the thing the ONE thing that makes sync special is it is a >>> push instead of poll implementation. >> this makes sense, but i guess it would be push when available. thinking web and crappy web socket support( dang you carriers ) > Right. I'm not saying lets do something complicated. I'm saying lets > use GCM, iOS CM, and simple push to send notifications to tell the > client something. In simplePush case it is "this data changed, get the > new stuff and update yourself". In Android and iOS case it may be that > or it may be "here is new data". > > In general, I am fine for getting a message saying something like > Documents/Schedules/1/${revision}. Then I can check my revisions, fetch > data if necessary, update my local data, and send any updates. That > SHOULD (I think) be doable with simplepush as well right? not sure how i feel about using "push"( APNS, GCM, SimplePush ) stuff for sync. then we are relying on these 3rd party services, > >> >>>>> 4. AG Synchronizer sends sync messages using Pipes >>>>> 5. AG Synchronizer holds local data in a store >>>>> >>>>> 6. When AGSynchronizer gets a message it is responsible for updating >>>>> the Store and then notifying code listing for updates OR for notifying >>>>> the code that an error has occurred and needs to be addressed. >>>>> >>>>> 7. When the developer updates data in the store, the synchronizer >>>>> should package that data and send it to the server. The synchronizer is >>>>> responsible for error handling, retrying, back-off, etc. >>>>> >>>>> 8. We should include multiple synchronizer implementations to deal with >>>>> multiple very simple use cases which involve legacy systems. (For >>>>> instance polling to load static data on a schedule.) >>>>> >>>>> Thoughts? Tomatoes? >>>>>> >>>>>> _______________________________________________ >>>>>> 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 From matzew at apache.org Tue Jan 28 11:44:23 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 28 Jan 2014 17:44:23 +0100 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <52E7CD27.2060206@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> Message-ID: On Tue, Jan 28, 2014 at 4:30 PM, Summers Pittman wrote: > On 01/28/2014 09:36 AM, Lucas Holmquist wrote: > > yup, this is another Data Sync thread, > > > > >From a client side perspective, i have concerns that there is still not > a clear direction yet. > > > > I know there are multiple ideas floating around on what our model should > be, i'm all for choice, but what about deciding on 1 model to get started > with. Then later once we have this nailed down, we can have other > "adapters" with different models perhaps > All the data model is is an envelope of sync metadata around an object > right? > > We also need to think about the API and server/client protocol as well. > > I think that for sync 1.0 we could focus on the following behavior (it > worked for my demos at least) > > 1. We have a Sync factory similar to Pipeline, Authenticator, > Registrar, and KeyService. > 2. The Sync factory consumes/manages Synchronizer instances. > 3. AG Synchronizer listens for sync messages using UnifiedPush endpoints. > W/ "sync message" you mean something like a 'heads-up' from the server it has something new, instead of the concrete delta/diff ? > 4. AG Synchronizer sends sync messages using Pipes > Like: "server, my local copy changed!" ? > 5. AG Synchronizer holds local data in a store > > 6. When AGSynchronizer gets a message it is responsible for updating > the Store and then notifying code listing for updates OR for notifying > the code that an error has occurred and needs to be addressed. > > 7. When the developer updates data in the store, the synchronizer > should package that data and send it to the server. The synchronizer is > responsible for error handling, retrying, back-off, etc. > > 8. We should include multiple synchronizer implementations to deal with > multiple very simple use cases which involve legacy systems. (For > instance polling to load static data on a schedule.) > > Thoughts? Tomatoes? > > > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140128/c46bdae7/attachment.html From matzew at apache.org Tue Jan 28 11:46:19 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 28 Jan 2014 17:46:19 +0100 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> Message-ID: On Tue, Jan 28, 2014 at 4:48 PM, Lucas Holmquist wrote: > > On Jan 28, 2014, at 10:30 AM, Summers Pittman wrote: > > > On 01/28/2014 09:36 AM, Lucas Holmquist wrote: > >> yup, this is another Data Sync thread, > >> > >>> From a client side perspective, i have concerns that there is still > not a clear direction yet. > >> > >> I know there are multiple ideas floating around on what our model > should be, i'm all for choice, but what about deciding on 1 model to get > started with. Then later once we have this nailed down, we can have other > "adapters" with different models perhaps > > All the data model is is an envelope of sync metadata around an object > > right? > > right > > > > > We also need to think about the API and server/client protocol as well. > > > > I think that for sync 1.0 we could focus on the following behavior (it > > worked for my demos at least) > > > > 1. We have a Sync factory similar to Pipeline, Authenticator, > > Registrar, and KeyService. > > 2. The Sync factory consumes/manages Synchronizer instances. > > 3. AG Synchronizer listens for sync messages using UnifiedPush > endpoints. > i thought for a 1.0 we weren't thinking about "realtime" > that is my impression as well, talking to Dan on IRC; ATM all is polling, but the sync-server will be cable of doing WebSocket/SockJS, so "connected" clients, can sync. Push should be really used for 'wake-up', instead of changing real information; Also SimplePush clients could not even integrate here (the protocol just uses version (or timestamps) > > > 4. AG Synchronizer sends sync messages using Pipes > > 5. AG Synchronizer holds local data in a store > > > > 6. When AGSynchronizer gets a message it is responsible for updating > > the Store and then notifying code listing for updates OR for notifying > > the code that an error has occurred and needs to be addressed. > > > > 7. When the developer updates data in the store, the synchronizer > > should package that data and send it to the server. The synchronizer is > > responsible for error handling, retrying, back-off, etc. > > > > 8. We should include multiple synchronizer implementations to deal with > > multiple very simple use cases which involve legacy systems. (For > > instance polling to load static data on a schedule.) > > > > Thoughts? Tomatoes? > >> > >> > >> > >> _______________________________________________ > >> 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 > -- 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/20140128/f6577434/attachment.html From matzew at apache.org Tue Jan 28 11:48:13 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 28 Jan 2014 17:48:13 +0100 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <52E7D2BB.8060605@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> Message-ID: On Tue, Jan 28, 2014 at 4:54 PM, Summers Pittman wrote: > On 01/28/2014 10:48 AM, Lucas Holmquist wrote: > > On Jan 28, 2014, at 10:30 AM, Summers Pittman > wrote: > > > >> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: > >>> yup, this is another Data Sync thread, > >>> > >>>> From a client side perspective, i have concerns that there is still > not a clear direction yet. > >>> I know there are multiple ideas floating around on what our model > should be, i'm all for choice, but what about deciding on 1 model to get > started with. Then later once we have this nailed down, we can have other > "adapters" with different models perhaps > >> All the data model is is an envelope of sync metadata around an object > >> right? > > right > > > >> We also need to think about the API and server/client protocol as well. > >> > >> I think that for sync 1.0 we could focus on the following behavior (it > >> worked for my demos at least) > >> > >> 1. We have a Sync factory similar to Pipeline, Authenticator, > >> Registrar, and KeyService. > >> 2. The Sync factory consumes/manages Synchronizer instances. > >> 3. AG Synchronizer listens for sync messages using UnifiedPush > endpoints. > > i thought for a 1.0 we weren't thinking about "realtime" > When I hear realtime I think sub 100 ms updates to all clients. (think > gaming) > > What I thought we were going for was something closer to email. The > data gets changed and at some point in the future the client knows. More > specifically, the thing the ONE thing that makes sync special is it is a > push instead of poll implementation. > You mean using Mobile Push to send actual content? Hrm, I guess that does not work w/ SimplePush; The mobile push is really more for notification that "something" has changed. Clients than could ping the sync-server for latest value > > > > >> 4. AG Synchronizer sends sync messages using Pipes > >> 5. AG Synchronizer holds local data in a store > >> > >> 6. When AGSynchronizer gets a message it is responsible for updating > >> the Store and then notifying code listing for updates OR for notifying > >> the code that an error has occurred and needs to be addressed. > >> > >> 7. When the developer updates data in the store, the synchronizer > >> should package that data and send it to the server. The synchronizer is > >> responsible for error handling, retrying, back-off, etc. > >> > >> 8. We should include multiple synchronizer implementations to deal with > >> multiple very simple use cases which involve legacy systems. (For > >> instance polling to load static data on a schedule.) > >> > >> Thoughts? Tomatoes? > >>> > >>> > >>> _______________________________________________ > >>> 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 > -- 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/20140128/fab1bee8/attachment.html From matzew at apache.org Tue Jan 28 11:49:54 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 28 Jan 2014 17:49:54 +0100 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <52E7D475.6060208@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> <5DCEB5A8-1942-4C0C-8C0E-3DFCB5521C0B@redhat.com> <52E7D475.6060208@redhat.com> Message-ID: On Tue, Jan 28, 2014 at 5:01 PM, Summers Pittman wrote: > On 01/28/2014 10:58 AM, Lucas Holmquist wrote: > > On Jan 28, 2014, at 10:54 AM, Summers Pittman > wrote: > > > >> On 01/28/2014 10:48 AM, Lucas Holmquist wrote: > >>> On Jan 28, 2014, at 10:30 AM, Summers Pittman > wrote: > >>> > >>>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: > >>>>> yup, this is another Data Sync thread, > >>>>> > >>>>>> From a client side perspective, i have concerns that there is > still not a clear direction yet. > >>>>> I know there are multiple ideas floating around on what our model > should be, i'm all for choice, but what about deciding on 1 model to get > started with. Then later once we have this nailed down, we can have other > "adapters" with different models perhaps > >>>> All the data model is is an envelope of sync metadata around an object > >>>> right? > >>> right > >>> > >>>> We also need to think about the API and server/client protocol as > well. > >>>> > >>>> I think that for sync 1.0 we could focus on the following behavior (it > >>>> worked for my demos at least) > >>>> > >>>> 1. We have a Sync factory similar to Pipeline, Authenticator, > >>>> Registrar, and KeyService. > >>>> 2. The Sync factory consumes/manages Synchronizer instances. > >>>> 3. AG Synchronizer listens for sync messages using UnifiedPush > endpoints. > >>> i thought for a 1.0 we weren't thinking about "realtime" > >> When I hear realtime I think sub 100 ms updates to all clients. (think > >> gaming) > >> > >> What I thought we were going for was something closer to email. The > >> data gets changed and at some point in the future the client knows. More > >> specifically, the thing the ONE thing that makes sync special is it is a > >> push instead of poll implementation. > > this makes sense, but i guess it would be push when available. thinking > web and crappy web socket support( dang you carriers ) > Right. I'm not saying lets do something complicated. I'm saying lets > use GCM, iOS CM, and simple push to send notifications to tell the > client something. In simplePush case it is "this data changed, get the > new stuff and update yourself". In Android and iOS case it may be that > or it may be "here is new data". > even iOS is _very_ limited in terms of payload. In Android you can push entire books :-), but not w/ iOS, nor w/ SimplePush > > In general, I am fine for getting a message saying something like > Documents/Schedules/1/${revision}. Then I can check my revisions, fetch > data if necessary, update my local data, and send any updates. That > SHOULD (I think) be doable with simplepush as well right? > > > > >>>> 4. AG Synchronizer sends sync messages using Pipes > >>>> 5. AG Synchronizer holds local data in a store > >>>> > >>>> 6. When AGSynchronizer gets a message it is responsible for updating > >>>> the Store and then notifying code listing for updates OR for notifying > >>>> the code that an error has occurred and needs to be addressed. > >>>> > >>>> 7. When the developer updates data in the store, the synchronizer > >>>> should package that data and send it to the server. The synchronizer > is > >>>> responsible for error handling, retrying, back-off, etc. > >>>> > >>>> 8. We should include multiple synchronizer implementations to deal > with > >>>> multiple very simple use cases which involve legacy systems. (For > >>>> instance polling to load static data on a schedule.) > >>>> > >>>> Thoughts? Tomatoes? > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > -- 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/20140128/daf44ee4/attachment-0001.html From matzew at apache.org Tue Jan 28 11:51:01 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 28 Jan 2014 17:51:01 +0100 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> <5DCEB5A8-1942-4C0C-8C0E-3DFCB5521C0B@redhat.com> <52E7D475.6060208@redhat.com> Message-ID: On Tue, Jan 28, 2014 at 5:41 PM, Lucas Holmquist wrote: > > On Jan 28, 2014, at 11:01 AM, Summers Pittman wrote: > > > On 01/28/2014 10:58 AM, Lucas Holmquist wrote: > >> On Jan 28, 2014, at 10:54 AM, Summers Pittman > wrote: > >> > >>> On 01/28/2014 10:48 AM, Lucas Holmquist wrote: > >>>> On Jan 28, 2014, at 10:30 AM, Summers Pittman > wrote: > >>>> > >>>>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: > >>>>>> yup, this is another Data Sync thread, > >>>>>> > >>>>>>> From a client side perspective, i have concerns that there is > still not a clear direction yet. > >>>>>> I know there are multiple ideas floating around on what our model > should be, i'm all for choice, but what about deciding on 1 model to get > started with. Then later once we have this nailed down, we can have other > "adapters" with different models perhaps > >>>>> All the data model is is an envelope of sync metadata around an > object > >>>>> right? > >>>> right > >>>> > >>>>> We also need to think about the API and server/client protocol as > well. > >>>>> > >>>>> I think that for sync 1.0 we could focus on the following behavior > (it > >>>>> worked for my demos at least) > >>>>> > >>>>> 1. We have a Sync factory similar to Pipeline, Authenticator, > >>>>> Registrar, and KeyService. > >>>>> 2. The Sync factory consumes/manages Synchronizer instances. > >>>>> 3. AG Synchronizer listens for sync messages using UnifiedPush > endpoints. > >>>> i thought for a 1.0 we weren't thinking about "realtime" > >>> When I hear realtime I think sub 100 ms updates to all clients. (think > >>> gaming) > >>> > >>> What I thought we were going for was something closer to email. The > >>> data gets changed and at some point in the future the client knows. > More > >>> specifically, the thing the ONE thing that makes sync special is it is > a > >>> push instead of poll implementation. > >> this makes sense, but i guess it would be push when available. > thinking web and crappy web socket support( dang you carriers ) > > Right. I'm not saying lets do something complicated. I'm saying lets > > use GCM, iOS CM, and simple push to send notifications to tell the > > client something. In simplePush case it is "this data changed, get the > > new stuff and update yourself". In Android and iOS case it may be that > > or it may be "here is new data". > > > > In general, I am fine for getting a message saying something like > > Documents/Schedules/1/${revision}. Then I can check my revisions, fetch > > data if necessary, update my local data, and send any updates. That > > SHOULD (I think) be doable with simplepush as well right? > > > not sure how i feel about using "push"( APNS, GCM, SimplePush ) stuff for > sync. > > then we are relying on these 3rd party services, > +1 > > > > >> > >>>>> 4. AG Synchronizer sends sync messages using Pipes > >>>>> 5. AG Synchronizer holds local data in a store > >>>>> > >>>>> 6. When AGSynchronizer gets a message it is responsible for updating > >>>>> the Store and then notifying code listing for updates OR for > notifying > >>>>> the code that an error has occurred and needs to be addressed. > >>>>> > >>>>> 7. When the developer updates data in the store, the synchronizer > >>>>> should package that data and send it to the server. The > synchronizer is > >>>>> responsible for error handling, retrying, back-off, etc. > >>>>> > >>>>> 8. We should include multiple synchronizer implementations to deal > with > >>>>> multiple very simple use cases which involve legacy systems. (For > >>>>> instance polling to load static data on a schedule.) > >>>>> > >>>>> Thoughts? Tomatoes? > >>>>>> > >>>>>> _______________________________________________ > >>>>>> 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 > -- 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/20140128/fd430f0f/attachment.html From matzew at apache.org Tue Jan 28 11:51:35 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 28 Jan 2014 17:51:35 +0100 Subject: [aerogear-dev] Upgrading process for the OpenShift AeroGear UPS cartridge In-Reply-To: <543520314.11975883.1390922054544.JavaMail.root@redhat.com> References: <676075311.5431814.1390843624382.JavaMail.root@redhat.com> <2099059360.11646680.1390846051314.JavaMail.root@redhat.com> <1403896808.11718517.1390858087208.JavaMail.root@redhat.com> <2034992562.5686126.1390898762650.JavaMail.root@redhat.com> <543520314.11975883.1390922054544.JavaMail.root@redhat.com> Message-ID: On Tue, Jan 28, 2014 at 4:14 PM, Farah Juma wrote: > This affects any redirect from http -> https but only seems to be > problematic when the cartridge instance's IP is changed (e.g., on > re-creation). > Fun problem :-) > > Farah > > ----- Original Message ----- > > From: "Matthias Wessendorf" > > To: "AeroGear Developer Mailing List" > > Cc: "Farah Juma" > > Sent: Tuesday, January 28, 2014 4:21:42 AM > > Subject: Re: [aerogear-dev] Upgrading process for the OpenShift AeroGear > UPS cartridge > > > > Farah/Andrea, > > > > is that on _creation_ or,also w/ any redirect from http -> https > (enforced > > by our Push cartridge) > > > > -Matthias > > > > > > On Tue, Jan 28, 2014 at 9:46 AM, Andrea Vibelli > wrote: > > > > > Hi Farah, > > > yes I do use FireFox. > > > > > > I have done the tests once again, and closing and reopening the browser > > > solved my issue, great, nice catch! > > > Maybe we could also include this additional step in the overall > > > instructions, what do you think? > > > Thank you > > > Andrea > > > > > > ----- Messaggio originale ----- > > > > Da: "Farah Juma" > > > > A: "Andrea Vibelli" , > aerogear-dev at lists.jboss.org > > > > Inviato: Luned?, 27 gennaio 2014 22:28:07 > > > > Oggetto: Re: [aerogear-dev] Upgrading process for the OpenShift > AeroGear > > > UPS cartridge > > > > > > > > After some more digging, I think I might know what's going on here. > > > Andrea, > > > > are you using Firefox? I wasn't able to reproduce the issue with > Chrome > > > but > > > > was able to reproduce it just now with Firefox. The underlying issue > > > seems > > > > to be that Firefox tends to save 301 redirects until you close it and > > > > re-open it. Note that when you delete an OpenShift instance and > re-create > > > > it, its IP address changes. When accessing > http://app-namespace.rhcloud > > > > after re-creating the instance, you'll actually be redirected to > > > > https://app-namespace.rhcloud/app. However, when using Firefox, > this URL > > > > seems to get mapped to the old IP address resulting in this error: > 'The > > > > requested URL /app was not found on this server.' After deleting and > > > > re-creating an OpenShift instance with the same name, if you restart > > > > Firefox, you should once again be able to access the application. > I've > > > > verified that this does work. > > > > > > > > Similar issues with Firefox were actually mentioned in some OpenShift > > > forum > > > > posts as well: > > > > > > > > > > > > https://www.openshift.com/forums/openshift/httpawm-pribylrhcloudcom-the-requested-url-was-not-found-on-this-server#comment-33570 > > > > > > > > https://www.openshift.com/forums/openshift/custom-domain-httpwwwxxxxxxxcom-is-redirecting-to-httpswwwxxxxxxxcomapp#comment-34215 > > > > > > > > > > > > Farah > > > > > > > > ----- Original Message ----- > > > > > From: "Farah Juma" > > > > > To: aerogear-dev at lists.jboss.org > > > > > Sent: Monday, January 27, 2014 1:07:31 PM > > > > > Subject: Re: [aerogear-dev] Upgrading process for the OpenShift > > > AeroGear > > > > > UPS cartridge > > > > > > > > > > > > > > > > From: "Andrea Vibelli" > > > > > > To: aerogear-dev at lists.jboss.org > > > > > > Sent: Monday, January 27, 2014 12:27:04 PM > > > > > > Subject: [aerogear-dev] Upgrading process for the OpenShift > AeroGear > > > UPS > > > > > > cartridge > > > > > > > > > > > > Hello all, > > > > > > > > > > > > I just wanted to let you know that Farah is working on > AGPUSH-504, a > > > > > > snapshot/restore approach for upgrading the downloadable > cartridge. > > > > > > The overall idea is to take a snapshot of the database (and other > > > > > > configuration) for an older existing cartridge instance, delete > this > > > old > > > > > > instance, and then create a new instance based on the latest > > > cartridge > > > > > > version and restore the new instance's database (and other > > > configuration) > > > > > > to > > > > > > the state in the snapshot. The new instance must have the same > name > > > as > > > > > > the > > > > > > old instance. The main thing that she needed to determine was > what > > > needed > > > > > > to > > > > > > be included in the snapshot that's not already part of the MySQL > > > > > > database. > > > > > > The SimplePush token key was one of these things (we generate > this > > > value > > > > > > when a cartridge instance is created and it is used by the > server for > > > > > > encryption and decryption of endpoint URLs). The standalone.xml > file > > > also > > > > > > needed to be backed up just in case the user made any changes to > it. > > > > > > (Creating a backup of this file allows users to manually merge > back > > > any > > > > > > changes they may have made.) > > > > > > > > > > > > The snapshot/restore action hooks she has created can be found in > > > [1]. > > > > > > > > > > > > The steps she has been using to try upgrading from an 0.8.1 > instance > > > are > > > > > > listed below. It would be great if you could try out these steps > as > > > well. > > > > > > There's one important caveat though: because an 0.8.1 instance > won't > > > have > > > > > > the necessary snapshot hook, you'll need to manually perform some > > > > > > commands > > > > > > to save the necessary data (step 3 below). If we include these > > > > > > snapshot/restore action hooks in the 0.10.0 cartridge release, > users > > > will > > > > > > be > > > > > > able to make use of these hooks for future upgrades, e.g., for > > > upgrading > > > > > > from 0.10.0 to 0.11.0. > > > > > > > > > > > > 1) Create an 0.8.1 cartridge instance > > > > > > rhc create-app mypush > > > > > > " > > > > https://cartreflect-claytondev.rhcloud.com/reflect?github=aerogear/openshift-origin-cartridge-aerogear-push&commit=8aada257de52157a837db23a9f7b1a8574fdffab > > > " > > > > > > mysql-5.1 > > > > > > > > > > > > 2) Log into the admin console, change password, create push > > > applications, > > > > > > create variants, send push notifications, etc. > > > > > > > > > > > > 3) ssh into your instance and perform these commands (this step > > > manually > > > > > > captures needed data) > > > > > > echo "$OPENSHIFT_AEROGEAR_PUSH_TOKEN_KEY" > > > > > > > $OPENSHIFT_DATA_DIR/aerogear_push_token_key > > > > > > cp > > > $OPENSHIFT_AEROGEAR_PUSH_DIR/standalone/configuration/standalone.xml > > > > > > $OPENSHIFT_DATA_DIR/standalone.snapshot.xml > > > > > > > > > > > > 4) Create a snapshot of the 0.8.1 instance: rhc snapshot save > mypush > > > > > > > > > > > > 5) Delete the 0.8.1 instance: rhc app delete mypush > > > > > > > > > > > > 6) Delete the local directory on the local machine (from step 1, > you > > > > > > should > > > > > > have a directory named 'mypush') > > > > > > > > > > > > 7) Create a new cartridge instance (this uses her fork of the > 0.9.0 > > > > > > cartridge > > > > > > repository that contains the snapshot/restore action hooks) > > > > > > rhc create-app mypush > > > > > > " > > > > https://cartreflect-claytondev.rhcloud.com/reflect?github=fjuma/openshift-origin-cartridge-aerogear-push&commit=956a4fc09edc93fe76394b86b265ceb1d238ccaf > > > " > > > > > > mysql-5.1 > > > > > > > > > > > > 8) Restore the instance: rhc snapshot restore mypush -f > > > > > > /PATH/TO/mypush.tar.gz > > > > > > > > > > > > 9) You should now be able to log into the admin console with the > same > > > > > > password you previously set, see existing push applications, > > > variants, > > > > > > send > > > > > > push notifications, etc. > > > > > > > > > > > > One disadvantage of this snapshot/restore approach is the extra > work > > > for > > > > > > the > > > > > > user. It would be nice to have a single command that can do the > > > snapshot, > > > > > > delete, create, and restore all at once. She is going to start > > > looking > > > > > > into > > > > > > this "wrappering" functionality. > > > > > > > > > > > > > > > > > > Why am I writing about this? > > > > > > > > > > > > I have made some test about the above steps. At a first glance, > it > > > seemed > > > > > > that something was broken between steps 6 and 7. > > > > > > Doing various tests, what I saw in the logs (server.log) were > > > different > > > > > > errors: > > > > > > > > > > > > 2014/01/26 10:19:18,061 ERROR [org.jboss.as] (MSC service thread > > > 1-3) > > > > > > JBAS015875: JBoss AS 7.1.1.Final "Brontes" started (with errors) > in > > > > > > 296088ms > > > > > > - Started 349 of 524 services (52 services failed or missing > > > > > > dependencies, > > > > > > 119 services are passive or on-demand) > > > > > > 2014/01/26 10:19:18,344 INFO [org.jboss.as.server] > > > > > > (DeploymentScanner-threads - 2) JBAS015870: Deploy of deployment > > > > > > "ROOT.war" > > > > > > was rolled back with failure message {"JBAS014771: Services with > > > > > > missing/unavailable dependencies" => > > > > > > > > > > ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]} > > > > > > 2014/01/26 10:19:19,390 INFO [org.jboss.as.server.deployment] > (MSC > > > > > > service > > > > > > thread 1-2) JBAS015877: Stopped deployment ROOT.war in 1125ms > > > > > > 2014/01/26 10:19:19,393 INFO [org.jboss.as.controller] > > > > > > (DeploymentScanner-threads - 2) JBAS014774: Service status report > > > > > > JBAS014775: New missing/unsatisfied dependencies: > > > > > > service > jboss.naming.context.java.jboss.datasources.PushEEDS > > > > > > (missing) > > > > > > dependents: [service > > > > > > jboss.persistenceunit."ROOT.war#unifiedpush-default", > service > > > > > > jboss.persistenceunit."ROOT.war#picketlink-default"] > > > > > > > > > > > > > > > > > > 2014/01/26 10:19:19,440 ERROR > > > [org.jboss.as.server.deployment.scanner] > > > > > > (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation > > > failed > > > > > > and > > > > > > was rolled back. Steps that failed:" => {"Operation step-2" => > > > > > > {"JBAS014771: > > > > > > Services with missing/unavailable dependencies" => > > > > > > > > > > ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]}}} > > > > > > > > > > > > > > > It looks like the MySQL cartridge either wasn't added or wasn't > able to > > > > > start > > > > > successfully. The following command can be used to check the > status of > > > the > > > > > MySQL cartridge: > > > > > > > > > > rhc cartridge status -a APP -c mysql > > > > > > > > > > > > > > > > OR > > > > > > > > > > > > > > > > > > 2014/01/26 05:41:46,522 INFO [org.jboss.as.connector] (MSC > service > > > > > > thread > > > > > > 1-1) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar > > > 1.0.9.Final) > > > > > > 2014/01/26 05:41:46,922 ERROR > > > > > > [org.jboss.as.controller.management-operation] > > > > > > (ServerService Thread Pool -- 62) Operation ("enable") failed - > > > address: > > > > > > ([ > > > > > > ("subsystem" => "datasources"), > > > > > > ("data-source" => "PostgreSQLDS") > > > > > > ]) - failure description: "JBAS014802: Cannot resolve expression > > > > > > 'expression > > > > > > > > > > \"jdbcostgresql://${env.OPENSHIFT_POSTGRESQL_DB_HOST}:${env.OPENSHIFT_POSTGRESQL_DB_PORT}/mypush13\"' > > > > > > -- java.lang.IllegalStateException: Failed to resolve expression: > > > > > > ${env.OPENSHIFT_POSTGRESQL_DB_HOST}" > > > > > > > > > > > > > > > > > > OR > > > > > > > > > > > > > > > > > > no errors in the logs, but in the deployments directory I found > > > > > > 'ROOT.war.dodeploy' and 'ROOT.war.isdeploying' files, but no > > > > > > 'ROOT.war.deployed' file. > > > > > > > > > > > > > > > > > > Those error seemed to me as random and too strange (by the way, > the > > > > > > creation > > > > > > of the cartridge is always correct, I never had problems if I > > > created a > > > > > > new > > > > > > instance with a never used before name). > > > > > > > > > > > > To investigate further, I then tried to do the same steps with a > > > > > > completely > > > > > > different application: 'Kitchensink on OpenShift', and I had the > same > > > > > > error! > > > > > > After the deletion and the recreation of a cartridge with a same > > > name, I > > > > > > encountered: 'The requested URL /app was not found on this > server.' > > > > > > The steps I have done are: > > > > > > 1) rhc app create -a kitchensink -t jbossas-7 --from-code > > > > > > git://github.com/openshift/kitchensink-example.git > > > > > > 2) rhc snapshot save kitchensink > > > > > > 3) rhc app delete kitchensink > > > > > > 4) rm -rf kitchensinkhtml5/ > > > > > > 5) rhc app create -a kitchensink -t jbossas-7 --from-code > > > > > > git://github.com/openshift/kitchensink-example.git > > > > > > 6) Access to the application. > > > > > > > > > > > > So the good news is that the error I encountered is not related > to > > > this > > > > > > specific AeroGear cartridges, but the bad news is that is > something > > > more > > > > > > general about OpenShift. > > > > > > We need to investigate further and find out if there is a way to > > > "flush" > > > > > > the > > > > > > deletion, it seems that there is something appended or cached > that > > > > > > prevent > > > > > > the recreation of a cartridge with a same name. > > > > > > > > > > It's good that the issue you're running into isn't specific to the > > > AeroGear > > > > > cartridge. I've tried quite a few times today but I'm not able to > > > reproduce > > > > > the issue with the AeroGear cartridge or with the kitchensink > > > application > > > > > using the above steps. I suspect that there is indeed an OpenShift > > > timing > > > > > issue here. Let's check with the OpenShift team on this. > > > > > > > > > > Farah > > > > > > > > > > > We are currently doing some more tests on these process. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 > > > > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > > -- 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/20140128/ef8ccb38/attachment-0001.html From supittma at redhat.com Tue Jan 28 12:05:51 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 28 Jan 2014 12:05:51 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> Message-ID: <52E7E36F.7020706@redhat.com> On 01/28/2014 11:44 AM, Matthias Wessendorf wrote: > > > > On Tue, Jan 28, 2014 at 4:30 PM, Summers Pittman > wrote: > > On 01/28/2014 09:36 AM, Lucas Holmquist wrote: > > yup, this is another Data Sync thread, > > > > >From a client side perspective, i have concerns that there is > still not a clear direction yet. > > > > I know there are multiple ideas floating around on what our > model should be, i'm all for choice, but what about deciding on 1 > model to get started with. Then later once we have this nailed > down, we can have other "adapters" with different models perhaps > All the data model is is an envelope of sync metadata around an object > right? > > We also need to think about the API and server/client protocol as > well. > > I think that for sync 1.0 we could focus on the following behavior (it > worked for my demos at least) > > 1. We have a Sync factory similar to Pipeline, Authenticator, > Registrar, and KeyService. > 2. The Sync factory consumes/manages Synchronizer instances. > 3. AG Synchronizer listens for sync messages using UnifiedPush > endpoints. > > > W/ "sync message" you mean something like a 'heads-up' from the server > it has something new, instead of the concrete delta/diff ? > > 4. AG Synchronizer sends sync messages using Pipes > > > Like: "server, my local copy changed!" ? Or, more specifically, "Here is new data" > > 5. AG Synchronizer holds local data in a store > > 6. When AGSynchronizer gets a message it is responsible for updating > the Store and then notifying code listing for updates OR for notifying > the code that an error has occurred and needs to be addressed. > > 7. When the developer updates data in the store, the synchronizer > should package that data and send it to the server. The > synchronizer is > responsible for error handling, retrying, back-off, etc. > > 8. We should include multiple synchronizer implementations to > deal with > multiple very simple use cases which involve legacy systems. (For > instance polling to load static data on a schedule.) > > Thoughts? Tomatoes? > > > > > > > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140128/c4eff223/attachment.html From supittma at redhat.com Tue Jan 28 12:08:09 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 28 Jan 2014 12:08:09 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> Message-ID: <52E7E3F9.5030409@redhat.com> On 01/28/2014 11:46 AM, Matthias Wessendorf wrote: > > > > On Tue, Jan 28, 2014 at 4:48 PM, Lucas Holmquist > wrote: > > > On Jan 28, 2014, at 10:30 AM, Summers Pittman > wrote: > > > On 01/28/2014 09:36 AM, Lucas Holmquist wrote: > >> yup, this is another Data Sync thread, > >> > >>> From a client side perspective, i have concerns that there is > still not a clear direction yet. > >> > >> I know there are multiple ideas floating around on what our > model should be, i'm all for choice, but what about deciding on 1 > model to get started with. Then later once we have this nailed > down, we can have other "adapters" with different models perhaps > > All the data model is is an envelope of sync metadata around an > object > > right? > > right > > > > > We also need to think about the API and server/client protocol > as well. > > > > I think that for sync 1.0 we could focus on the following > behavior (it > > worked for my demos at least) > > > > 1. We have a Sync factory similar to Pipeline, Authenticator, > > Registrar, and KeyService. > > 2. The Sync factory consumes/manages Synchronizer instances. > > 3. AG Synchronizer listens for sync messages using UnifiedPush > endpoints. > i thought for a 1.0 we weren't thinking about "realtime" > > > that is my impression as well, talking to Dan on IRC; > ATM all is polling, but the sync-server will be cable of doing > WebSocket/SockJS, so "connected" clients, can sync. Polling is MURDER on battery, performance, and "feel". WebSockets and SockJS are awesome ideas for a future implementation for "real time". > > Push should be really used for 'wake-up', instead of changing real > information; Also SimplePush clients could not even integrate here > (the protocol just uses version (or timestamps) Yes. On the topic of Simple Push, you push a URL so in theory you could push /Documents/${collecitonName}/${id}/${rev_id} and have simple push setup to accept URLS formatted that way right? Or is it more limited than that? > > > > > 4. AG Synchronizer sends sync messages using Pipes > > 5. AG Synchronizer holds local data in a store > > > > 6. When AGSynchronizer gets a message it is responsible for > updating > > the Store and then notifying code listing for updates OR for > notifying > > the code that an error has occurred and needs to be addressed. > > > > 7. When the developer updates data in the store, the synchronizer > > should package that data and send it to the server. The > synchronizer is > > responsible for error handling, retrying, back-off, etc. > > > > 8. We should include multiple synchronizer implementations to > deal with > > multiple very simple use cases which involve legacy systems. (For > > instance polling to load static data on a schedule.) > > > > Thoughts? Tomatoes? > >> > >> > >> > >> _______________________________________________ > >> 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 > > > > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140128/ce768387/attachment.html From supittma at redhat.com Tue Jan 28 12:09:00 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 28 Jan 2014 12:09:00 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> Message-ID: <52E7E42C.7000205@redhat.com> On 01/28/2014 11:48 AM, Matthias Wessendorf wrote: > > > > On Tue, Jan 28, 2014 at 4:54 PM, Summers Pittman > wrote: > > On 01/28/2014 10:48 AM, Lucas Holmquist wrote: > > On Jan 28, 2014, at 10:30 AM, Summers Pittman > > wrote: > > > >> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: > >>> yup, this is another Data Sync thread, > >>> > >>>> From a client side perspective, i have concerns that there > is still not a clear direction yet. > >>> I know there are multiple ideas floating around on what our > model should be, i'm all for choice, but what about deciding on 1 > model to get started with. Then later once we have this nailed > down, we can have other "adapters" with different models perhaps > >> All the data model is is an envelope of sync metadata around an > object > >> right? > > right > > > >> We also need to think about the API and server/client protocol > as well. > >> > >> I think that for sync 1.0 we could focus on the following > behavior (it > >> worked for my demos at least) > >> > >> 1. We have a Sync factory similar to Pipeline, Authenticator, > >> Registrar, and KeyService. > >> 2. The Sync factory consumes/manages Synchronizer instances. > >> 3. AG Synchronizer listens for sync messages using UnifiedPush > endpoints. > > i thought for a 1.0 we weren't thinking about "realtime" > When I hear realtime I think sub 100 ms updates to all clients. (think > gaming) > > What I thought we were going for was something closer to email. The > data gets changed and at some point in the future the client > knows. More > specifically, the thing the ONE thing that makes sync special is > it is a > push instead of poll implementation. > > > You mean using Mobile Push to send actual content? Hrm, I guess that > does not work w/ SimplePush; No not really. I mean what I said in the other email when you asked the same question ;) > The mobile push is really more for notification that "something" has > changed. Clients than could ping the sync-server for latest value Yes. This ^^. That is what my "ideal" will do for 1.0 > > > > > >> 4. AG Synchronizer sends sync messages using Pipes > >> 5. AG Synchronizer holds local data in a store > >> > >> 6. When AGSynchronizer gets a message it is responsible for > updating > >> the Store and then notifying code listing for updates OR for > notifying > >> the code that an error has occurred and needs to be addressed. > >> > >> 7. When the developer updates data in the store, the synchronizer > >> should package that data and send it to the server. The > synchronizer is > >> responsible for error handling, retrying, back-off, etc. > >> > >> 8. We should include multiple synchronizer implementations to > deal with > >> multiple very simple use cases which involve legacy systems. (For > >> instance polling to load static data on a schedule.) > >> > >> Thoughts? Tomatoes? > >>> > >>> > >>> _______________________________________________ > >>> 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 > > > > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140128/327863c4/attachment-0001.html From supittma at redhat.com Tue Jan 28 12:09:42 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 28 Jan 2014 12:09:42 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> <5DCEB5A8-1942-4C0C-8C0E-3DFCB5521C0B@redhat.com> <52E7D475.6060208@redhat.com> Message-ID: <52E7E456.5060309@redhat.com> On 01/28/2014 11:49 AM, Matthias Wessendorf wrote: > > > > On Tue, Jan 28, 2014 at 5:01 PM, Summers Pittman > wrote: > > On 01/28/2014 10:58 AM, Lucas Holmquist wrote: > > On Jan 28, 2014, at 10:54 AM, Summers Pittman > > wrote: > > > >> On 01/28/2014 10:48 AM, Lucas Holmquist wrote: > >>> On Jan 28, 2014, at 10:30 AM, Summers Pittman > > wrote: > >>> > >>>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: > >>>>> yup, this is another Data Sync thread, > >>>>> > >>>>>> From a client side perspective, i have concerns that there > is still not a clear direction yet. > >>>>> I know there are multiple ideas floating around on what our > model should be, i'm all for choice, but what about deciding on 1 > model to get started with. Then later once we have this nailed > down, we can have other "adapters" with different models perhaps > >>>> All the data model is is an envelope of sync metadata around > an object > >>>> right? > >>> right > >>> > >>>> We also need to think about the API and server/client > protocol as well. > >>>> > >>>> I think that for sync 1.0 we could focus on the following > behavior (it > >>>> worked for my demos at least) > >>>> > >>>> 1. We have a Sync factory similar to Pipeline, Authenticator, > >>>> Registrar, and KeyService. > >>>> 2. The Sync factory consumes/manages Synchronizer instances. > >>>> 3. AG Synchronizer listens for sync messages using > UnifiedPush endpoints. > >>> i thought for a 1.0 we weren't thinking about "realtime" > >> When I hear realtime I think sub 100 ms updates to all clients. > (think > >> gaming) > >> > >> What I thought we were going for was something closer to email. > The > >> data gets changed and at some point in the future the client > knows. More > >> specifically, the thing the ONE thing that makes sync special > is it is a > >> push instead of poll implementation. > > this makes sense, but i guess it would be push when available. > thinking web and crappy web socket support( dang you carriers ) > Right. I'm not saying lets do something complicated. I'm saying lets > use GCM, iOS CM, and simple push to send notifications to tell the > client something. In simplePush case it is "this data changed, > get the > new stuff and update yourself". In Android and iOS case it may be > that > or it may be "here is new data". > > > even iOS is _very_ limited in terms of payload. > > In Android you can push entire books :-), but not w/ iOS, nor w/ > SimplePush Android is still limited to 4K I think. I am fine with designing around the limitations of SimplePush. > > In general, I am fine for getting a message saying something like > Documents/Schedules/1/${revision}. Then I can check my revisions, > fetch > data if necessary, update my local data, and send any updates. That > SHOULD (I think) be doable with simplepush as well right? > > > > >>>> 4. AG Synchronizer sends sync messages using Pipes > >>>> 5. AG Synchronizer holds local data in a store > >>>> > >>>> 6. When AGSynchronizer gets a message it is responsible for > updating > >>>> the Store and then notifying code listing for updates OR for > notifying > >>>> the code that an error has occurred and needs to be addressed. > >>>> > >>>> 7. When the developer updates data in the store, the > synchronizer > >>>> should package that data and send it to the server. The > synchronizer is > >>>> responsible for error handling, retrying, back-off, etc. > >>>> > >>>> 8. We should include multiple synchronizer implementations > to deal with > >>>> multiple very simple use cases which involve legacy systems. (For > >>>> instance polling to load static data on a schedule.) > >>>> > >>>> Thoughts? Tomatoes? > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > > > > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140128/f40823f3/attachment.html From fjuma at redhat.com Tue Jan 28 12:10:53 2014 From: fjuma at redhat.com (Farah Juma) Date: Tue, 28 Jan 2014 12:10:53 -0500 (EST) Subject: [aerogear-dev] Upgrading process for the OpenShift AeroGear UPS cartridge In-Reply-To: <830585923.11958735.1390921396801.JavaMail.root@redhat.com> References: <676075311.5431814.1390843624382.JavaMail.root@redhat.com> <2099059360.11646680.1390846051314.JavaMail.root@redhat.com> <1403896808.11718517.1390858087208.JavaMail.root@redhat.com> <2034992562.5686126.1390898762650.JavaMail.root@redhat.com> <830585923.11958735.1390921396801.JavaMail.root@redhat.com> Message-ID: <1552758754.12035565.1390929053020.JavaMail.root@redhat.com> I've created the following gist that contains our updated list of steps for upgrading the cartridge: https://gist.github.com/fjuma/499827d650465a1a8f5a Farah ----- Original Message ----- > From: "Farah Juma" > To: aerogear-dev at lists.jboss.org > Cc: "Andrea Vibelli" > Sent: Tuesday, January 28, 2014 10:03:16 AM > Subject: Re: [aerogear-dev] Upgrading process for the OpenShift AeroGear UPS cartridge > > > > From: "Andrea Vibelli" > > To: "Farah Juma" > > Cc: aerogear-dev at lists.jboss.org > > Sent: Tuesday, January 28, 2014 3:46:02 AM > > Subject: Re: Re: [aerogear-dev] Upgrading process for the OpenShift > > AeroGear UPS cartridge > > > > Hi Farah, > > yes I do use FireFox. > > > > I have done the tests once again, and closing and reopening the browser > > solved my issue, great, nice catch! > > Great, I'm glad that's working for you now! > > > Maybe we could also include this additional step in the overall > > instructions, > > what do you think? > > Yes, that's a good idea. I'm going to create a gist with our updated steps > and post it here when done to get more feedback. > > Thanks, > Farah > > > > Thank you > > Andrea > > > > ----- Messaggio originale ----- > > > Da: "Farah Juma" > > > A: "Andrea Vibelli" , aerogear-dev at lists.jboss.org > > > Inviato: Luned?, 27 gennaio 2014 22:28:07 > > > Oggetto: Re: [aerogear-dev] Upgrading process for the OpenShift AeroGear > > > UPS cartridge > > > > > > After some more digging, I think I might know what's going on here. > > > Andrea, > > > are you using Firefox? I wasn't able to reproduce the issue with Chrome > > > but > > > was able to reproduce it just now with Firefox. The underlying issue > > > seems > > > to be that Firefox tends to save 301 redirects until you close it and > > > re-open it. Note that when you delete an OpenShift instance and re-create > > > it, its IP address changes. When accessing http://app-namespace.rhcloud > > > after re-creating the instance, you'll actually be redirected to > > > https://app-namespace.rhcloud/app. However, when using Firefox, this URL > > > seems to get mapped to the old IP address resulting in this error: 'The > > > requested URL /app was not found on this server.' After deleting and > > > re-creating an OpenShift instance with the same name, if you restart > > > Firefox, you should once again be able to access the application. I've > > > verified that this does work. > > > > > > Similar issues with Firefox were actually mentioned in some OpenShift > > > forum > > > posts as well: > > > > > > https://www.openshift.com/forums/openshift/httpawm-pribylrhcloudcom-the-requested-url-was-not-found-on-this-server#comment-33570 > > > https://www.openshift.com/forums/openshift/custom-domain-httpwwwxxxxxxxcom-is-redirecting-to-httpswwwxxxxxxxcomapp#comment-34215 > > > > > > > > > Farah > > > > > > ----- Original Message ----- > > > > From: "Farah Juma" > > > > To: aerogear-dev at lists.jboss.org > > > > Sent: Monday, January 27, 2014 1:07:31 PM > > > > Subject: Re: [aerogear-dev] Upgrading process for the OpenShift > > > > AeroGear > > > > ????????UPS????????cartridge > > > > > > > > > > > > > From: "Andrea Vibelli" > > > > > To: aerogear-dev at lists.jboss.org > > > > > Sent: Monday, January 27, 2014 12:27:04 PM > > > > > Subject: [aerogear-dev] Upgrading process for the OpenShift AeroGear > > > > > UPS > > > > > ????????cartridge > > > > > > > > > > Hello all, > > > > > > > > > > I just wanted to let you know that Farah is working on AGPUSH-504, a > > > > > snapshot/restore approach for upgrading the downloadable cartridge. > > > > > The overall idea is to take a snapshot of the database (and other > > > > > configuration) for an older existing cartridge instance, delete this > > > > > old > > > > > instance, and then create a new instance based on the latest > > > > > cartridge > > > > > version and restore the new instance's database (and other > > > > > configuration) > > > > > to > > > > > the state in the snapshot. The new instance must have the same name > > > > > as > > > > > the > > > > > old instance. The main thing that she needed to determine was what > > > > > needed > > > > > to > > > > > be included in the snapshot that's not already part of the MySQL > > > > > database. > > > > > The SimplePush token key was one of these things (we generate this > > > > > value > > > > > when a cartridge instance is created and it is used by the server for > > > > > encryption and decryption of endpoint URLs). The standalone.xml file > > > > > also > > > > > needed to be backed up just in case the user made any changes to it. > > > > > (Creating a backup of this file allows users to manually merge back > > > > > any > > > > > changes they may have made.) > > > > > > > > > > The snapshot/restore action hooks she has created can be found in > > > > > [1]. > > > > > > > > > > The steps she has been using to try upgrading from an 0.8.1 instance > > > > > are > > > > > listed below. It would be great if you could try out these steps as > > > > > well. > > > > > There's one important caveat though: because an 0.8.1 instance won't > > > > > have > > > > > the necessary snapshot hook, you'll need to manually perform some > > > > > commands > > > > > to save the necessary data (step 3 below). If we include these > > > > > snapshot/restore action hooks in the 0.10.0 cartridge release, users > > > > > will > > > > > be > > > > > able to make use of these hooks for future upgrades, e.g., for > > > > > upgrading > > > > > from 0.10.0 to 0.11.0. > > > > > ? > > > > > 1) Create an 0.8.1 cartridge instance > > > > > rhc create-app mypush > > > > > "https://cartreflect-claytondev.rhcloud.com/reflect?github=aerogear/openshift-origin-cartridge-aerogear-push&commit=8aada257de52157a837db23a9f7b1a8574fdffab" > > > > > mysql-5.1 > > > > > > > > > > 2) Log into the admin console, change password, create push > > > > > applications, > > > > > create variants, send push notifications, etc. > > > > > > > > > > 3) ssh into your instance and perform these commands (this step > > > > > manually > > > > > captures needed data) > > > > > echo "$OPENSHIFT_AEROGEAR_PUSH_TOKEN_KEY" > > > > > > $OPENSHIFT_DATA_DIR/aerogear_push_token_key > > > > > cp > > > > > $OPENSHIFT_AEROGEAR_PUSH_DIR/standalone/configuration/standalone.xml > > > > > $OPENSHIFT_DATA_DIR/standalone.snapshot.xml > > > > > > > > > > 4) Create a snapshot of the 0.8.1 instance: rhc snapshot save mypush > > > > > > > > > > 5) Delete the 0.8.1 instance: rhc app delete mypush > > > > > > > > > > 6) Delete the local directory on the local machine (from step 1, you > > > > > should > > > > > have a directory named 'mypush') > > > > > > > > > > 7) Create a new cartridge instance (this uses her fork of the 0.9.0 > > > > > cartridge > > > > > repository that contains the snapshot/restore action hooks) > > > > > rhc create-app mypush > > > > > "https://cartreflect-claytondev.rhcloud.com/reflect?github=fjuma/openshift-origin-cartridge-aerogear-push&commit=956a4fc09edc93fe76394b86b265ceb1d238ccaf" > > > > > mysql-5.1 > > > > > > > > > > 8) Restore the instance: rhc snapshot restore mypush -f > > > > > /PATH/TO/mypush.tar.gz > > > > > > > > > > 9) You should now be able to log into the admin console with the same > > > > > password you previously set, see existing push applications, > > > > > variants, > > > > > send > > > > > push notifications, etc. > > > > > > > > > > One disadvantage of this snapshot/restore approach is the extra work > > > > > for > > > > > the > > > > > user. It would be nice to have a single command that can do the > > > > > snapshot, > > > > > delete, create, and restore all at once. She is going to start > > > > > looking > > > > > into > > > > > this "wrappering" functionality. > > > > > > > > > > > > > > > Why am I writing about this? > > > > > > > > > > I have made some test about the above steps. At a first glance, it > > > > > seemed > > > > > that something was broken between steps 6 and 7. > > > > > Doing various tests, what I saw in the logs (server.log) were > > > > > different > > > > > errors: > > > > > > > > > > 2014/01/26 10:19:18,061 ERROR [org.jboss.as] (MSC service thread 1-3) > > > > > JBAS015875: JBoss AS 7.1.1.Final "Brontes" started (with errors) in > > > > > 296088ms > > > > > - Started 349 of 524 services (52 services failed or missing > > > > > dependencies, > > > > > 119 services are passive or on-demand) > > > > > 2014/01/26 10:19:18,344 INFO ?[org.jboss.as.server] > > > > > (DeploymentScanner-threads - 2) JBAS015870: Deploy of deployment > > > > > "ROOT.war" > > > > > was rolled back with failure message {"JBAS014771: Services with > > > > > missing/unavailable dependencies" => > > > > > ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]} > > > > > 2014/01/26 10:19:19,390 INFO ?[org.jboss.as.server.deployment] (MSC > > > > > service > > > > > thread 1-2) JBAS015877: Stopped deployment ROOT.war in 1125ms > > > > > 2014/01/26 10:19:19,393 INFO ?[org.jboss.as.controller] > > > > > (DeploymentScanner-threads - 2) JBAS014774: Service status report > > > > > JBAS014775: ? ?New missing/unsatisfied dependencies: > > > > > ? ? ? service jboss.naming.context.java.jboss.datasources.PushEEDS > > > > > ? ? ? (missing) > > > > > ? ? ? dependents: [service > > > > > ? ? ? jboss.persistenceunit."ROOT.war#unifiedpush-default", service > > > > > ? ? ? jboss.persistenceunit."ROOT.war#picketlink-default"] > > > > > > > > > > > > > > > 2014/01/26 10:19:19,440 ERROR > > > > > [org.jboss.as.server.deployment.scanner] > > > > > (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation > > > > > failed > > > > > and > > > > > was rolled back. Steps that failed:" => {"Operation step-2" => > > > > > {"JBAS014771: > > > > > Services with missing/unavailable dependencies" => > > > > > ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]}}} > > > > > > > > > > > > It looks like the MySQL cartridge either wasn't added or wasn't able to > > > > start > > > > successfully. The following command can be used to check the status of > > > > the > > > > MySQL cartridge: > > > > > > > > rhc cartridge status -a APP -c mysql > > > > > > > > ? > > > > > OR > > > > > > > > > > > > > > > 2014/01/26 05:41:46,522 INFO ?[org.jboss.as.connector] (MSC service > > > > > thread > > > > > 1-1) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar > > > > > 1.0.9.Final) > > > > > 2014/01/26 05:41:46,922 ERROR > > > > > [org.jboss.as.controller.management-operation] > > > > > (ServerService Thread Pool -- 62) Operation ("enable") failed - > > > > > address: > > > > > ([ > > > > > ? ? ("subsystem" => "datasources"), > > > > > ? ? ("data-source" => "PostgreSQLDS") > > > > > ]) - failure description: "JBAS014802: Cannot resolve expression > > > > > 'expression > > > > > \"jdbcostgresql://${env.OPENSHIFT_POSTGRESQL_DB_HOST}:${env.OPENSHIFT_POSTGRESQL_DB_PORT}/mypush13\"' > > > > > -- java.lang.IllegalStateException: Failed to resolve expression: > > > > > ${env.OPENSHIFT_POSTGRESQL_DB_HOST}" > > > > > > > > > > > > > > > OR > > > > > > > > > > > > > > > no errors in the logs, but in the deployments directory I found > > > > > 'ROOT.war.dodeploy' and 'ROOT.war.isdeploying' files, but no > > > > > 'ROOT.war.deployed' file. > > > > > > > > > > > > > > > Those error seemed to me as random and too strange (by the way, the > > > > > creation > > > > > of the cartridge is always correct, I never had problems if I created > > > > > a > > > > > new > > > > > instance with a never used before name). > > > > > > > > > > To investigate further, I then tried to do the same steps with a > > > > > completely > > > > > different application: 'Kitchensink on OpenShift', and I had the same > > > > > error! > > > > > After the deletion and the recreation of a cartridge with a same > > > > > name, > > > > > I > > > > > encountered: 'The requested URL /app was not found on this server.' > > > > > The steps I have done are: > > > > > 1) rhc app create -a kitchensink -t jbossas-7 --from-code > > > > > git://github.com/openshift/kitchensink-example.git > > > > > 2) rhc snapshot save kitchensink > > > > > 3) rhc app delete kitchensink > > > > > 4) rm -rf kitchensinkhtml5/ > > > > > 5) rhc app create -a kitchensink -t jbossas-7 --from-code > > > > > git://github.com/openshift/kitchensink-example.git > > > > > 6) Access to the application. > > > > > > > > > > So the good news is that the error I encountered is not related to > > > > > this > > > > > specific AeroGear cartridges, but the bad news is that is something > > > > > more > > > > > general about OpenShift. > > > > > We need to investigate further and find out if there is a way to > > > > > "flush" > > > > > the > > > > > deletion, it seems that there is something appended or cached that > > > > > prevent > > > > > the recreation of a cartridge with a same name. > > > > > > > > It's good that the issue you're running into isn't specific to the > > > > AeroGear > > > > cartridge. I've tried quite a few times today but I'm not able to > > > > reproduce > > > > the issue with the AeroGear cartridge or with the kitchensink > > > > application > > > > using the above steps. I suspect that there is indeed an OpenShift > > > > timing > > > > issue here. Let's check with the OpenShift team on this. > > > > > > > > Farah > > > > > > > > > We are currently doing some more tests on these process. > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > 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 matzew at apache.org Tue Jan 28 12:13:36 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 28 Jan 2014 18:13:36 +0100 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <52E7E3F9.5030409@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7E3F9.5030409@redhat.com> Message-ID: On Tue, Jan 28, 2014 at 6:08 PM, Summers Pittman wrote: > On 01/28/2014 11:46 AM, Matthias Wessendorf wrote: > > > > > On Tue, Jan 28, 2014 at 4:48 PM, Lucas Holmquist wrote: > >> >> On Jan 28, 2014, at 10:30 AM, Summers Pittman >> wrote: >> >> > On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >> >> yup, this is another Data Sync thread, >> >> >> >>> From a client side perspective, i have concerns that there is still >> not a clear direction yet. >> >> >> >> I know there are multiple ideas floating around on what our model >> should be, i'm all for choice, but what about deciding on 1 model to get >> started with. Then later once we have this nailed down, we can have other >> "adapters" with different models perhaps >> > All the data model is is an envelope of sync metadata around an object >> > right? >> >> right >> >> > >> > We also need to think about the API and server/client protocol as well. >> > >> > I think that for sync 1.0 we could focus on the following behavior (it >> > worked for my demos at least) >> > >> > 1. We have a Sync factory similar to Pipeline, Authenticator, >> > Registrar, and KeyService. >> > 2. The Sync factory consumes/manages Synchronizer instances. >> > 3. AG Synchronizer listens for sync messages using UnifiedPush >> endpoints. >> i thought for a 1.0 we weren't thinking about "realtime" >> > > that is my impression as well, talking to Dan on IRC; > ATM all is polling, but the sync-server will be cable of doing > WebSocket/SockJS, so "connected" clients, can sync. > > Polling is MURDER on battery, performance, and "feel". WebSockets and > SockJS are awesome ideas for a future implementation for "real time". > As far as I understood it, the sync-server just started w/ polling (pure HTTP). I think that WebSocket/SockJS is not really that far away, in terms of 'future' > > > Push should be really used for 'wake-up', instead of changing real > information; Also SimplePush clients could not even integrate here (the > protocol just uses version (or timestamps) > > Yes. > > On the topic of Simple Push, you push a URL so in theory you could push > /Documents/${collecitonName}/${id}/${rev_id} and have simple push setup to > accept URLS formatted that way right? Or is it more limited than that? > you can simply ONLY push a version number, that's it > > > > > >> >> > 4. AG Synchronizer sends sync messages using Pipes >> > 5. AG Synchronizer holds local data in a store >> > >> > 6. When AGSynchronizer gets a message it is responsible for updating >> > the Store and then notifying code listing for updates OR for notifying >> > the code that an error has occurred and needs to be addressed. >> > >> > 7. When the developer updates data in the store, the synchronizer >> > should package that data and send it to the server. The synchronizer is >> > responsible for error handling, retrying, back-off, etc. >> > >> > 8. We should include multiple synchronizer implementations to deal with >> > multiple very simple use cases which involve legacy systems. (For >> > instance polling to load static data on a schedule.) >> > >> > Thoughts? Tomatoes? >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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 >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > 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 > -- 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/20140128/23505b55/attachment.html From kpiwko at redhat.com Tue Jan 28 12:13:55 2014 From: kpiwko at redhat.com (Karel Piwko) Date: Tue, 28 Jan 2014 18:13:55 +0100 Subject: [aerogear-dev] Browser Targets In-Reply-To: References: <79E19B64-A584-4821-A1BA-EA3B49E08344@redhat.com> <9682E781-175D-4BD7-A193-1593509416D8@redhat.com> <92FEC0F0-7359-4B49-8AC9-3BCD18D8D3B5@redhat.com> <20140128154018.04629c33@kapy-ntb-x220> Message-ID: <20140128181355.78f333a4@kapy-ntb-x220> Commented in jira. I guess that we need to get rid of typed arrays so we can test the fallback is indeed working. If that means a serious performance bottleneck, maybe that could be solved by some polyfill approach. Karel On Tue, 28 Jan 2014 14:21:36 -0200 Bruno Oliveira wrote: > The crypto bit will fallback to sjcl implementation as far as I know (not > safe) once the entropy doesn?t come from WebCrypto, but that works, as far as > I know. > > -- > abstractj > > On January 28, 2014 at 12:48:03 PM, Lucas Holmquist (lholmqui at redhat.com) > wrote: > > > Most everything works except that crypto bit, i'd hate to say > > no support at all, i'm not really sure what the stats are for 2.3 > > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From supittma at redhat.com Tue Jan 28 12:14:51 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 28 Jan 2014 12:14:51 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> <5DCEB5A8-1942-4C0C-8C0E-3DFCB5521C0B@redhat.com> <52E7D475.6060208@redhat.com> Message-ID: <52E7E58B.5070606@redhat.com> On 01/28/2014 11:41 AM, Lucas Holmquist wrote: > On Jan 28, 2014, at 11:01 AM, Summers Pittman wrote: > >> On 01/28/2014 10:58 AM, Lucas Holmquist wrote: >>> On Jan 28, 2014, at 10:54 AM, Summers Pittman wrote: >>> >>>> On 01/28/2014 10:48 AM, Lucas Holmquist wrote: >>>>> On Jan 28, 2014, at 10:30 AM, Summers Pittman wrote: >>>>> >>>>>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >>>>>>> yup, this is another Data Sync thread, >>>>>>> >>>>>>>> From a client side perspective, i have concerns that there is still not a clear direction yet. >>>>>>> I know there are multiple ideas floating around on what our model should be, i'm all for choice, but what about deciding on 1 model to get started with. Then later once we have this nailed down, we can have other "adapters" with different models perhaps >>>>>> All the data model is is an envelope of sync metadata around an object >>>>>> right? >>>>> right >>>>> >>>>>> We also need to think about the API and server/client protocol as well. >>>>>> >>>>>> I think that for sync 1.0 we could focus on the following behavior (it >>>>>> worked for my demos at least) >>>>>> >>>>>> 1. We have a Sync factory similar to Pipeline, Authenticator, >>>>>> Registrar, and KeyService. >>>>>> 2. The Sync factory consumes/manages Synchronizer instances. >>>>>> 3. AG Synchronizer listens for sync messages using UnifiedPush endpoints. >>>>> i thought for a 1.0 we weren't thinking about "realtime" >>>> When I hear realtime I think sub 100 ms updates to all clients. (think >>>> gaming) >>>> >>>> What I thought we were going for was something closer to email. The >>>> data gets changed and at some point in the future the client knows. More >>>> specifically, the thing the ONE thing that makes sync special is it is a >>>> push instead of poll implementation. >>> this makes sense, but i guess it would be push when available. thinking web and crappy web socket support( dang you carriers ) >> Right. I'm not saying lets do something complicated. I'm saying lets >> use GCM, iOS CM, and simple push to send notifications to tell the >> client something. In simplePush case it is "this data changed, get the >> new stuff and update yourself". In Android and iOS case it may be that >> or it may be "here is new data". >> >> In general, I am fine for getting a message saying something like >> Documents/Schedules/1/${revision}. Then I can check my revisions, fetch >> data if necessary, update my local data, and send any updates. That >> SHOULD (I think) be doable with simplepush as well right? > > not sure how i feel about using "push"( APNS, GCM, SimplePush ) stuff for sync. > then we are relying on these 3rd party services, That is a valid concern. I think making our entire sync product based on polling is a bad thing. (Battery, performance, etc etc etc). I think making sync based on TCP sockets/WebSockets/SockJS is a good thing, but it is past 1.0 I think making our sync product demand proprietary technology is a bad thing, but I don't know of a service which is as easy as APNS or GCM for iOS and Android devs. > >>>>>> 4. AG Synchronizer sends sync messages using Pipes >>>>>> 5. AG Synchronizer holds local data in a store >>>>>> >>>>>> 6. When AGSynchronizer gets a message it is responsible for updating >>>>>> the Store and then notifying code listing for updates OR for notifying >>>>>> the code that an error has occurred and needs to be addressed. >>>>>> >>>>>> 7. When the developer updates data in the store, the synchronizer >>>>>> should package that data and send it to the server. The synchronizer is >>>>>> responsible for error handling, retrying, back-off, etc. >>>>>> >>>>>> 8. We should include multiple synchronizer implementations to deal with >>>>>> multiple very simple use cases which involve legacy systems. (For >>>>>> instance polling to load static data on a schedule.) >>>>>> >>>>>> Thoughts? Tomatoes? >>>>>>> _______________________________________________ >>>>>>> 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 From matzew at apache.org Tue Jan 28 12:17:16 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 28 Jan 2014 18:17:16 +0100 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <52E7E456.5060309@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> <5DCEB5A8-1942-4C0C-8C0E-3DFCB5521C0B@redhat.com> <52E7D475.6060208@redhat.com> <52E7E456.5060309@redhat.com> Message-ID: On Tue, Jan 28, 2014 at 6:09 PM, Summers Pittman wrote: > On 01/28/2014 11:49 AM, Matthias Wessendorf wrote: > > > > > On Tue, Jan 28, 2014 at 5:01 PM, Summers Pittman wrote: > >> On 01/28/2014 10:58 AM, Lucas Holmquist wrote: >> > On Jan 28, 2014, at 10:54 AM, Summers Pittman >> wrote: >> > >> >> On 01/28/2014 10:48 AM, Lucas Holmquist wrote: >> >>> On Jan 28, 2014, at 10:30 AM, Summers Pittman >> wrote: >> >>> >> >>>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >> >>>>> yup, this is another Data Sync thread, >> >>>>> >> >>>>>> From a client side perspective, i have concerns that there is >> still not a clear direction yet. >> >>>>> I know there are multiple ideas floating around on what our model >> should be, i'm all for choice, but what about deciding on 1 model to get >> started with. Then later once we have this nailed down, we can have other >> "adapters" with different models perhaps >> >>>> All the data model is is an envelope of sync metadata around an >> object >> >>>> right? >> >>> right >> >>> >> >>>> We also need to think about the API and server/client protocol as >> well. >> >>>> >> >>>> I think that for sync 1.0 we could focus on the following behavior >> (it >> >>>> worked for my demos at least) >> >>>> >> >>>> 1. We have a Sync factory similar to Pipeline, Authenticator, >> >>>> Registrar, and KeyService. >> >>>> 2. The Sync factory consumes/manages Synchronizer instances. >> >>>> 3. AG Synchronizer listens for sync messages using UnifiedPush >> endpoints. >> >>> i thought for a 1.0 we weren't thinking about "realtime" >> >> When I hear realtime I think sub 100 ms updates to all clients. (think >> >> gaming) >> >> >> >> What I thought we were going for was something closer to email. The >> >> data gets changed and at some point in the future the client knows. >> More >> >> specifically, the thing the ONE thing that makes sync special is it is >> a >> >> push instead of poll implementation. >> > this makes sense, but i guess it would be push when available. >> thinking web and crappy web socket support( dang you carriers ) >> Right. I'm not saying lets do something complicated. I'm saying lets >> use GCM, iOS CM, and simple push to send notifications to tell the >> client something. In simplePush case it is "this data changed, get the >> new stuff and update yourself". In Android and iOS case it may be that >> or it may be "here is new data". >> > > even iOS is _very_ limited in terms of payload. > > In Android you can push entire books :-), but not w/ iOS, nor w/ > SimplePush > > Android is still limited to 4K I think. > Ok, not books - but a novel :-) > > I am fine with designing around the limitations of SimplePush. > the concept of pushing a URL is more doable for iOS; However, I still prefer a 'real-time' connection type (e.g. websocket/sockjs/mqtt), rather than sticking the push server into this > > > >> >> In general, I am fine for getting a message saying something like >> Documents/Schedules/1/${revision}. Then I can check my revisions, fetch >> data if necessary, update my local data, and send any updates. That >> SHOULD (I think) be doable with simplepush as well right? >> >> > >> >>>> 4. AG Synchronizer sends sync messages using Pipes >> >>>> 5. AG Synchronizer holds local data in a store >> >>>> >> >>>> 6. When AGSynchronizer gets a message it is responsible for updating >> >>>> the Store and then notifying code listing for updates OR for >> notifying >> >>>> the code that an error has occurred and needs to be addressed. >> >>>> >> >>>> 7. When the developer updates data in the store, the synchronizer >> >>>> should package that data and send it to the server. The >> synchronizer is >> >>>> responsible for error handling, retrying, back-off, etc. >> >>>> >> >>>> 8. We should include multiple synchronizer implementations to deal >> with >> >>>> multiple very simple use cases which involve legacy systems. (For >> >>>> instance polling to load static data on a schedule.) >> >>>> >> >>>> Thoughts? Tomatoes? >> >>>>> >> >>>>> _______________________________________________ >> >>>>> 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 >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > 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 > -- 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/20140128/10eaefd0/attachment-0001.html From matzew at apache.org Tue Jan 28 12:19:56 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 28 Jan 2014 18:19:56 +0100 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <52E7E58B.5070606@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> <5DCEB5A8-1942-4C0C-8C0E-3DFCB5521C0B@redhat.com> <52E7D475.6060208@redhat.com> <52E7E58B.5070606@redhat.com> Message-ID: On Tue, Jan 28, 2014 at 6:14 PM, Summers Pittman wrote: > On 01/28/2014 11:41 AM, Lucas Holmquist wrote: > > On Jan 28, 2014, at 11:01 AM, Summers Pittman > wrote: > > > >> On 01/28/2014 10:58 AM, Lucas Holmquist wrote: > >>> On Jan 28, 2014, at 10:54 AM, Summers Pittman > wrote: > >>> > >>>> On 01/28/2014 10:48 AM, Lucas Holmquist wrote: > >>>>> On Jan 28, 2014, at 10:30 AM, Summers Pittman > wrote: > >>>>> > >>>>>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: > >>>>>>> yup, this is another Data Sync thread, > >>>>>>> > >>>>>>>> From a client side perspective, i have concerns that there is > still not a clear direction yet. > >>>>>>> I know there are multiple ideas floating around on what our model > should be, i'm all for choice, but what about deciding on 1 model to get > started with. Then later once we have this nailed down, we can have other > "adapters" with different models perhaps > >>>>>> All the data model is is an envelope of sync metadata around an > object > >>>>>> right? > >>>>> right > >>>>> > >>>>>> We also need to think about the API and server/client protocol as > well. > >>>>>> > >>>>>> I think that for sync 1.0 we could focus on the following behavior > (it > >>>>>> worked for my demos at least) > >>>>>> > >>>>>> 1. We have a Sync factory similar to Pipeline, Authenticator, > >>>>>> Registrar, and KeyService. > >>>>>> 2. The Sync factory consumes/manages Synchronizer instances. > >>>>>> 3. AG Synchronizer listens for sync messages using UnifiedPush > endpoints. > >>>>> i thought for a 1.0 we weren't thinking about "realtime" > >>>> When I hear realtime I think sub 100 ms updates to all clients. (think > >>>> gaming) > >>>> > >>>> What I thought we were going for was something closer to email. The > >>>> data gets changed and at some point in the future the client knows. > More > >>>> specifically, the thing the ONE thing that makes sync special is it > is a > >>>> push instead of poll implementation. > >>> this makes sense, but i guess it would be push when available. > thinking web and crappy web socket support( dang you carriers ) > >> Right. I'm not saying lets do something complicated. I'm saying lets > >> use GCM, iOS CM, and simple push to send notifications to tell the > >> client something. In simplePush case it is "this data changed, get the > >> new stuff and update yourself". In Android and iOS case it may be that > >> or it may be "here is new data". > >> > >> In general, I am fine for getting a message saying something like > >> Documents/Schedules/1/${revision}. Then I can check my revisions, fetch > >> data if necessary, update my local data, and send any updates. That > >> SHOULD (I think) be doable with simplepush as well right? > > > > not sure how i feel about using "push"( APNS, GCM, SimplePush ) stuff > for sync. > > then we are relying on these 3rd party services, > That is a valid concern. > > I think making our entire sync product based on polling is a bad thing. > (Battery, performance, etc etc etc). > I think making sync based on TCP sockets/WebSockets/SockJS is a good > thing, but it is past 1.0 > regarding 1.0 - I am not even sure what that version should be done; but for me (personal thought), I (again, personally) have serious doubts that the first sync offerings (March/April?) will be the ones labeled as '1.0.0'; > I think making our sync product demand proprietary technology is a bad > thing, but I don't know of a service which is as easy as APNS or GCM for > iOS and Android devs. > > > > > > >>>>>> 4. AG Synchronizer sends sync messages using Pipes > >>>>>> 5. AG Synchronizer holds local data in a store > >>>>>> > >>>>>> 6. When AGSynchronizer gets a message it is responsible for > updating > >>>>>> the Store and then notifying code listing for updates OR for > notifying > >>>>>> the code that an error has occurred and needs to be addressed. > >>>>>> > >>>>>> 7. When the developer updates data in the store, the synchronizer > >>>>>> should package that data and send it to the server. The > synchronizer is > >>>>>> responsible for error handling, retrying, back-off, etc. > >>>>>> > >>>>>> 8. We should include multiple synchronizer implementations to deal > with > >>>>>> multiple very simple use cases which involve legacy systems. (For > >>>>>> instance polling to load static data on a schedule.) > >>>>>> > >>>>>> Thoughts? Tomatoes? > >>>>>>> _______________________________________________ > >>>>>>> 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 > > _______________________________________________ > 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/20140128/b3392d38/attachment.html From supittma at redhat.com Tue Jan 28 12:20:47 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 28 Jan 2014 12:20:47 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> <5DCEB5A8-1942-4C0C-8C0E-3DFCB5521C0B@redhat.com> <52E7D475.6060208@redhat.com> <52E7E456.5060309@redhat.com> Message-ID: <52E7E6EF.4020309@redhat.com> On 01/28/2014 12:17 PM, Matthias Wessendorf wrote: > > > > On Tue, Jan 28, 2014 at 6:09 PM, Summers Pittman > wrote: > > On 01/28/2014 11:49 AM, Matthias Wessendorf wrote: >> >> >> >> On Tue, Jan 28, 2014 at 5:01 PM, Summers Pittman >> > wrote: >> >> On 01/28/2014 10:58 AM, Lucas Holmquist wrote: >> > On Jan 28, 2014, at 10:54 AM, Summers Pittman >> > wrote: >> > >> >> On 01/28/2014 10:48 AM, Lucas Holmquist wrote: >> >>> On Jan 28, 2014, at 10:30 AM, Summers Pittman >> > wrote: >> >>> >> >>>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >> >>>>> yup, this is another Data Sync thread, >> >>>>> >> >>>>>> From a client side perspective, i have concerns that >> there is still not a clear direction yet. >> >>>>> I know there are multiple ideas floating around on what >> our model should be, i'm all for choice, but what about >> deciding on 1 model to get started with. Then later once we >> have this nailed down, we can have other "adapters" with >> different models perhaps >> >>>> All the data model is is an envelope of sync metadata >> around an object >> >>>> right? >> >>> right >> >>> >> >>>> We also need to think about the API and server/client >> protocol as well. >> >>>> >> >>>> I think that for sync 1.0 we could focus on the >> following behavior (it >> >>>> worked for my demos at least) >> >>>> >> >>>> 1. We have a Sync factory similar to Pipeline, >> Authenticator, >> >>>> Registrar, and KeyService. >> >>>> 2. The Sync factory consumes/manages Synchronizer >> instances. >> >>>> 3. AG Synchronizer listens for sync messages using >> UnifiedPush endpoints. >> >>> i thought for a 1.0 we weren't thinking about "realtime" >> >> When I hear realtime I think sub 100 ms updates to all >> clients. (think >> >> gaming) >> >> >> >> What I thought we were going for was something closer to >> email. The >> >> data gets changed and at some point in the future the >> client knows. More >> >> specifically, the thing the ONE thing that makes sync >> special is it is a >> >> push instead of poll implementation. >> > this makes sense, but i guess it would be push when >> available. thinking web and crappy web socket support( dang >> you carriers ) >> Right. I'm not saying lets do something complicated. I'm >> saying lets >> use GCM, iOS CM, and simple push to send notifications to >> tell the >> client something. In simplePush case it is "this data >> changed, get the >> new stuff and update yourself". In Android and iOS case it >> may be that >> or it may be "here is new data". >> >> >> even iOS is _very_ limited in terms of payload. >> >> In Android you can push entire books :-), but not w/ iOS, nor w/ >> SimplePush > Android is still limited to 4K I think. > > > Ok, not books - but a novel :-) > > > I am fine with designing around the limitations of SimplePush. > > > the concept of pushing a URL is more doable for iOS; > > However, I still prefer a 'real-time' connection type (e.g. > websocket/sockjs/mqtt), rather than sticking the push server into this The idea is for version 1.0 to let the server be able to 'alert' devices that there is new data. For 1.1 we could manage things like websockets, sockjs, mqtt, bsd sockects, etc. > >> >> In general, I am fine for getting a message saying something like >> Documents/Schedules/1/${revision}. Then I can check my >> revisions, fetch >> data if necessary, update my local data, and send any >> updates. That >> SHOULD (I think) be doable with simplepush as well right? >> >> > >> >>>> 4. AG Synchronizer sends sync messages using Pipes >> >>>> 5. AG Synchronizer holds local data in a store >> >>>> >> >>>> 6. When AGSynchronizer gets a message it is responsible >> for updating >> >>>> the Store and then notifying code listing for updates OR >> for notifying >> >>>> the code that an error has occurred and needs to be >> addressed. >> >>>> >> >>>> 7. When the developer updates data in the store, the >> synchronizer >> >>>> should package that data and send it to the server. The >> synchronizer is >> >>>> responsible for error handling, retrying, back-off, etc. >> >>>> >> >>>> 8. We should include multiple synchronizer >> implementations to deal with >> >>>> multiple very simple use cases which involve legacy >> systems. (For >> >>>> instance polling to load static data on a schedule.) >> >>>> >> >>>> Thoughts? Tomatoes? >> >>>>> >> >>>>> _______________________________________________ >> >>>>> 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 >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140128/763498b9/attachment-0001.html From supittma at redhat.com Tue Jan 28 12:25:49 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 28 Jan 2014 12:25:49 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> <5DCEB5A8-1942-4C0C-8C0E-3DFCB5521C0B@redhat.com> <52E7D475.6060208@redhat.com> <52E7E58B.5070606@redhat.com> Message-ID: <52E7E81D.2020608@redhat.com> On 01/28/2014 12:19 PM, Matthias Wessendorf wrote: > > > > On Tue, Jan 28, 2014 at 6:14 PM, Summers Pittman > wrote: > > On 01/28/2014 11:41 AM, Lucas Holmquist wrote: > > On Jan 28, 2014, at 11:01 AM, Summers Pittman > > wrote: > > > >> On 01/28/2014 10:58 AM, Lucas Holmquist wrote: > >>> On Jan 28, 2014, at 10:54 AM, Summers Pittman > > wrote: > >>> > >>>> On 01/28/2014 10:48 AM, Lucas Holmquist wrote: > >>>>> On Jan 28, 2014, at 10:30 AM, Summers Pittman > > wrote: > >>>>> > >>>>>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: > >>>>>>> yup, this is another Data Sync thread, > >>>>>>> > >>>>>>>> From a client side perspective, i have concerns that > there is still not a clear direction yet. > >>>>>>> I know there are multiple ideas floating around on what > our model should be, i'm all for choice, but what about deciding > on 1 model to get started with. Then later once we have this > nailed down, we can have other "adapters" with different models > perhaps > >>>>>> All the data model is is an envelope of sync metadata > around an object > >>>>>> right? > >>>>> right > >>>>> > >>>>>> We also need to think about the API and server/client > protocol as well. > >>>>>> > >>>>>> I think that for sync 1.0 we could focus on the following > behavior (it > >>>>>> worked for my demos at least) > >>>>>> > >>>>>> 1. We have a Sync factory similar to Pipeline, Authenticator, > >>>>>> Registrar, and KeyService. > >>>>>> 2. The Sync factory consumes/manages Synchronizer instances. > >>>>>> 3. AG Synchronizer listens for sync messages using > UnifiedPush endpoints. > >>>>> i thought for a 1.0 we weren't thinking about "realtime" > >>>> When I hear realtime I think sub 100 ms updates to all > clients. (think > >>>> gaming) > >>>> > >>>> What I thought we were going for was something closer to > email. The > >>>> data gets changed and at some point in the future the client > knows. More > >>>> specifically, the thing the ONE thing that makes sync special > is it is a > >>>> push instead of poll implementation. > >>> this makes sense, but i guess it would be push when > available. thinking web and crappy web socket support( dang you > carriers ) > >> Right. I'm not saying lets do something complicated. I'm > saying lets > >> use GCM, iOS CM, and simple push to send notifications to tell the > >> client something. In simplePush case it is "this data changed, > get the > >> new stuff and update yourself". In Android and iOS case it may > be that > >> or it may be "here is new data". > >> > >> In general, I am fine for getting a message saying something like > >> Documents/Schedules/1/${revision}. Then I can check my > revisions, fetch > >> data if necessary, update my local data, and send any updates. > That > >> SHOULD (I think) be doable with simplepush as well right? > > > > not sure how i feel about using "push"( APNS, GCM, SimplePush ) > stuff for sync. > > then we are relying on these 3rd party services, > That is a valid concern. > > I think making our entire sync product based on polling is a bad > thing. > (Battery, performance, etc etc etc). > I think making sync based on TCP sockets/WebSockets/SockJS is a good > thing, but it is past 1.0 > > > regarding 1.0 - I am not even sure what that version should be done; > but for me (personal thought), > I (again, personally) have serious doubts that the first sync > offerings (March/April?) will be the ones labeled as '1.0.0'; I think one of the minimum features for our first client release should have is push initiated synchronization. This doesn't mean push based or real time, just a push message causes an update. > > I think making our sync product demand proprietary technology is a bad > thing, but I don't know of a service which is as easy as APNS or > GCM for > iOS and Android devs. > > > > > > >>>>>> 4. AG Synchronizer sends sync messages using Pipes > >>>>>> 5. AG Synchronizer holds local data in a store > >>>>>> > >>>>>> 6. When AGSynchronizer gets a message it is responsible > for updating > >>>>>> the Store and then notifying code listing for updates OR > for notifying > >>>>>> the code that an error has occurred and needs to be addressed. > >>>>>> > >>>>>> 7. When the developer updates data in the store, the > synchronizer > >>>>>> should package that data and send it to the server. The > synchronizer is > >>>>>> responsible for error handling, retrying, back-off, etc. > >>>>>> > >>>>>> 8. We should include multiple synchronizer implementations > to deal with > >>>>>> multiple very simple use cases which involve legacy > systems. (For > >>>>>> instance polling to load static data on a schedule.) > >>>>>> > >>>>>> Thoughts? Tomatoes? > >>>>>>> _______________________________________________ > >>>>>>> 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 > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140128/e52406f3/attachment.html From supittma at redhat.com Tue Jan 28 12:26:55 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 28 Jan 2014 12:26:55 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7E3F9.5030409@redhat.com> Message-ID: <52E7E85F.1010709@redhat.com> On 01/28/2014 12:13 PM, Matthias Wessendorf wrote: > > > > On Tue, Jan 28, 2014 at 6:08 PM, Summers Pittman > wrote: > > On 01/28/2014 11:46 AM, Matthias Wessendorf wrote: >> >> >> >> On Tue, Jan 28, 2014 at 4:48 PM, Lucas Holmquist >> > wrote: >> >> >> On Jan 28, 2014, at 10:30 AM, Summers Pittman >> > wrote: >> >> > On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >> >> yup, this is another Data Sync thread, >> >> >> >>> From a client side perspective, i have concerns that >> there is still not a clear direction yet. >> >> >> >> I know there are multiple ideas floating around on what >> our model should be, i'm all for choice, but what about >> deciding on 1 model to get started with. Then later once we >> have this nailed down, we can have other "adapters" with >> different models perhaps >> > All the data model is is an envelope of sync metadata >> around an object >> > right? >> >> right >> >> > >> > We also need to think about the API and server/client >> protocol as well. >> > >> > I think that for sync 1.0 we could focus on the following >> behavior (it >> > worked for my demos at least) >> > >> > 1. We have a Sync factory similar to Pipeline, Authenticator, >> > Registrar, and KeyService. >> > 2. The Sync factory consumes/manages Synchronizer instances. >> > 3. AG Synchronizer listens for sync messages using >> UnifiedPush endpoints. >> i thought for a 1.0 we weren't thinking about "realtime" >> >> >> that is my impression as well, talking to Dan on IRC; >> ATM all is polling, but the sync-server will be cable of doing >> WebSocket/SockJS, so "connected" clients, can sync. > Polling is MURDER on battery, performance, and "feel". WebSockets > and SockJS are awesome ideas for a future implementation for "real > time". > > > As far as I understood it, the sync-server just started w/ polling > (pure HTTP). I think that WebSocket/SockJS is not really that far > away, in terms of 'future' > > >> >> Push should be really used for 'wake-up', instead of changing >> real information; Also SimplePush clients could not even >> integrate here (the protocol just uses version (or timestamps) > Yes. > > On the topic of Simple Push, you push a URL so in theory you could > push /Documents/${collecitonName}/${id}/${rev_id} and have simple > push setup to accept URLS formatted that way right? Or is it more > limited than that? > > > you can simply ONLY push a version number, that's it I just reread things. It is worse than that. You can (should) only push an increasing version number. So anything checksum based will fail. > > > > >> >> >> >> > 4. AG Synchronizer sends sync messages using Pipes >> > 5. AG Synchronizer holds local data in a store >> > >> > 6. When AGSynchronizer gets a message it is responsible >> for updating >> > the Store and then notifying code listing for updates OR >> for notifying >> > the code that an error has occurred and needs to be addressed. >> > >> > 7. When the developer updates data in the store, the >> synchronizer >> > should package that data and send it to the server. The >> synchronizer is >> > responsible for error handling, retrying, back-off, etc. >> > >> > 8. We should include multiple synchronizer implementations >> to deal with >> > multiple very simple use cases which involve legacy >> systems. (For >> > instance polling to load static data on a schedule.) >> > >> > Thoughts? Tomatoes? >> >> >> >> >> >> >> >> _______________________________________________ >> >> 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 >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140128/9f860095/attachment-0001.html From matzew at apache.org Tue Jan 28 12:32:16 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 28 Jan 2014 18:32:16 +0100 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <52E7E85F.1010709@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7E3F9.5030409@redhat.com> <52E7E85F.1010709@redhat.com> Message-ID: On Tue, Jan 28, 2014 at 6:26 PM, Summers Pittman wrote: > On 01/28/2014 12:13 PM, Matthias Wessendorf wrote: > > > > > On Tue, Jan 28, 2014 at 6:08 PM, Summers Pittman wrote: > >> On 01/28/2014 11:46 AM, Matthias Wessendorf wrote: >> >> >> >> >> On Tue, Jan 28, 2014 at 4:48 PM, Lucas Holmquist wrote: >> >>> >>> On Jan 28, 2014, at 10:30 AM, Summers Pittman >>> wrote: >>> >>> > On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >>> >> yup, this is another Data Sync thread, >>> >> >>> >>> From a client side perspective, i have concerns that there is still >>> not a clear direction yet. >>> >> >>> >> I know there are multiple ideas floating around on what our model >>> should be, i'm all for choice, but what about deciding on 1 model to get >>> started with. Then later once we have this nailed down, we can have other >>> "adapters" with different models perhaps >>> > All the data model is is an envelope of sync metadata around an object >>> > right? >>> >>> right >>> >>> > >>> > We also need to think about the API and server/client protocol as well. >>> > >>> > I think that for sync 1.0 we could focus on the following behavior (it >>> > worked for my demos at least) >>> > >>> > 1. We have a Sync factory similar to Pipeline, Authenticator, >>> > Registrar, and KeyService. >>> > 2. The Sync factory consumes/manages Synchronizer instances. >>> > 3. AG Synchronizer listens for sync messages using UnifiedPush >>> endpoints. >>> i thought for a 1.0 we weren't thinking about "realtime" >>> >> >> that is my impression as well, talking to Dan on IRC; >> ATM all is polling, but the sync-server will be cable of doing >> WebSocket/SockJS, so "connected" clients, can sync. >> >> Polling is MURDER on battery, performance, and "feel". WebSockets and >> SockJS are awesome ideas for a future implementation for "real time". >> > > As far as I understood it, the sync-server just started w/ polling (pure > HTTP). I think that WebSocket/SockJS is not really that far away, in terms > of 'future' > > >> >> >> Push should be really used for 'wake-up', instead of changing real >> information; Also SimplePush clients could not even integrate here (the >> protocol just uses version (or timestamps) >> >> Yes. >> >> On the topic of Simple Push, you push a URL so in theory you could push >> /Documents/${collecitonName}/${id}/${rev_id} and have simple push setup to >> accept URLS formatted that way right? Or is it more limited than that? >> > > you can simply ONLY push a version number, that's it > > I just reread things. It is worse than that. You can (should) only push > an increasing version number. So anything checksum based will fail. > best practice is 'timestamp' - that's all you can push over to those devices > > > > > > >> >> >> >> >> >>> >>> > 4. AG Synchronizer sends sync messages using Pipes >>> > 5. AG Synchronizer holds local data in a store >>> > >>> > 6. When AGSynchronizer gets a message it is responsible for updating >>> > the Store and then notifying code listing for updates OR for notifying >>> > the code that an error has occurred and needs to be addressed. >>> > >>> > 7. When the developer updates data in the store, the synchronizer >>> > should package that data and send it to the server. The synchronizer >>> is >>> > responsible for error handling, retrying, back-off, etc. >>> > >>> > 8. We should include multiple synchronizer implementations to deal >>> with >>> > multiple very simple use cases which involve legacy systems. (For >>> > instance polling to load static data on a schedule.) >>> > >>> > Thoughts? Tomatoes? >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> 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 >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> >> _______________________________________________ >> 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 >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > 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 > -- 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/20140128/2a587ed0/attachment.html From matzew at apache.org Tue Jan 28 12:32:28 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 28 Jan 2014 18:32:28 +0100 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7E3F9.5030409@redhat.com> <52E7E85F.1010709@redhat.com> Message-ID: On Tue, Jan 28, 2014 at 6:32 PM, Matthias Wessendorf wrote: > > > > On Tue, Jan 28, 2014 at 6:26 PM, Summers Pittman wrote: > >> On 01/28/2014 12:13 PM, Matthias Wessendorf wrote: >> >> >> >> >> On Tue, Jan 28, 2014 at 6:08 PM, Summers Pittman wrote: >> >>> On 01/28/2014 11:46 AM, Matthias Wessendorf wrote: >>> >>> >>> >>> >>> On Tue, Jan 28, 2014 at 4:48 PM, Lucas Holmquist wrote: >>> >>>> >>>> On Jan 28, 2014, at 10:30 AM, Summers Pittman >>>> wrote: >>>> >>>> > On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >>>> >> yup, this is another Data Sync thread, >>>> >> >>>> >>> From a client side perspective, i have concerns that there is still >>>> not a clear direction yet. >>>> >> >>>> >> I know there are multiple ideas floating around on what our model >>>> should be, i'm all for choice, but what about deciding on 1 model to get >>>> started with. Then later once we have this nailed down, we can have other >>>> "adapters" with different models perhaps >>>> > All the data model is is an envelope of sync metadata around an object >>>> > right? >>>> >>>> right >>>> >>>> > >>>> > We also need to think about the API and server/client protocol as >>>> well. >>>> > >>>> > I think that for sync 1.0 we could focus on the following behavior (it >>>> > worked for my demos at least) >>>> > >>>> > 1. We have a Sync factory similar to Pipeline, Authenticator, >>>> > Registrar, and KeyService. >>>> > 2. The Sync factory consumes/manages Synchronizer instances. >>>> > 3. AG Synchronizer listens for sync messages using UnifiedPush >>>> endpoints. >>>> i thought for a 1.0 we weren't thinking about "realtime" >>>> >>> >>> that is my impression as well, talking to Dan on IRC; >>> ATM all is polling, but the sync-server will be cable of doing >>> WebSocket/SockJS, so "connected" clients, can sync. >>> >>> Polling is MURDER on battery, performance, and "feel". WebSockets and >>> SockJS are awesome ideas for a future implementation for "real time". >>> >> >> As far as I understood it, the sync-server just started w/ polling >> (pure HTTP). I think that WebSocket/SockJS is not really that far away, in >> terms of 'future' >> >> >>> >>> >>> Push should be really used for 'wake-up', instead of changing real >>> information; Also SimplePush clients could not even integrate here (the >>> protocol just uses version (or timestamps) >>> >>> Yes. >>> >>> On the topic of Simple Push, you push a URL so in theory you could push >>> /Documents/${collecitonName}/${id}/${rev_id} and have simple push setup to >>> accept URLS formatted that way right? Or is it more limited than that? >>> >> >> you can simply ONLY push a version number, that's it >> >> I just reread things. It is worse than that. You can (should) only push >> an increasing version number. So anything checksum based will fail. >> > > > best practice is 'timestamp' - that's all you can push over to those > devices > for a good reason > > >> >> >> >> >> >> >>> >>> >>> >>> >>> >>>> >>>> > 4. AG Synchronizer sends sync messages using Pipes >>>> > 5. AG Synchronizer holds local data in a store >>>> > >>>> > 6. When AGSynchronizer gets a message it is responsible for updating >>>> > the Store and then notifying code listing for updates OR for notifying >>>> > the code that an error has occurred and needs to be addressed. >>>> > >>>> > 7. When the developer updates data in the store, the synchronizer >>>> > should package that data and send it to the server. The synchronizer >>>> is >>>> > responsible for error handling, retrying, back-off, etc. >>>> > >>>> > 8. We should include multiple synchronizer implementations to deal >>>> with >>>> > multiple very simple use cases which involve legacy systems. (For >>>> > instance polling to load static data on a schedule.) >>>> > >>>> > Thoughts? Tomatoes? >>>> >> >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> 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 >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> >>> _______________________________________________ >>> 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 >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> >> _______________________________________________ >> 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 >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- 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/20140128/a9b8cb85/attachment-0001.html From supittma at redhat.com Tue Jan 28 12:36:07 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 28 Jan 2014 12:36:07 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7E3F9.5030409@redhat.com> <52E7E85F.1010709@redhat.com> Message-ID: <52E7EA87.9060705@redhat.com> On 01/28/2014 12:32 PM, Matthias Wessendorf wrote: > > > > On Tue, Jan 28, 2014 at 6:32 PM, Matthias Wessendorf > > wrote: > > > > > On Tue, Jan 28, 2014 at 6:26 PM, Summers Pittman > > wrote: > > On 01/28/2014 12:13 PM, Matthias Wessendorf wrote: >> >> >> >> On Tue, Jan 28, 2014 at 6:08 PM, Summers Pittman >> > wrote: >> >> On 01/28/2014 11:46 AM, Matthias Wessendorf wrote: >>> >>> >>> >>> On Tue, Jan 28, 2014 at 4:48 PM, Lucas Holmquist >>> > wrote: >>> >>> >>> On Jan 28, 2014, at 10:30 AM, Summers Pittman >>> > >>> wrote: >>> >>> > On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >>> >> yup, this is another Data Sync thread, >>> >> >>> >>> From a client side perspective, i have concerns >>> that there is still not a clear direction yet. >>> >> >>> >> I know there are multiple ideas floating around >>> on what our model should be, i'm all for choice, >>> but what about deciding on 1 model to get started >>> with. Then later once we have this nailed down, we >>> can have other "adapters" with different models perhaps >>> > All the data model is is an envelope of sync >>> metadata around an object >>> > right? >>> >>> right >>> >>> > >>> > We also need to think about the API and >>> server/client protocol as well. >>> > >>> > I think that for sync 1.0 we could focus on the >>> following behavior (it >>> > worked for my demos at least) >>> > >>> > 1. We have a Sync factory similar to Pipeline, >>> Authenticator, >>> > Registrar, and KeyService. >>> > 2. The Sync factory consumes/manages Synchronizer >>> instances. >>> > 3. AG Synchronizer listens for sync messages >>> using UnifiedPush endpoints. >>> i thought for a 1.0 we weren't thinking about "realtime" >>> >>> >>> that is my impression as well, talking to Dan on IRC; >>> ATM all is polling, but the sync-server will be cable of >>> doing WebSocket/SockJS, so "connected" clients, can sync. >> Polling is MURDER on battery, performance, and "feel". >> WebSockets and SockJS are awesome ideas for a future >> implementation for "real time". >> >> >> As far as I understood it, the sync-server just started w/ >> polling (pure HTTP). I think that WebSocket/SockJS is not >> really that far away, in terms of 'future' >> >> >>> >>> Push should be really used for 'wake-up', instead of >>> changing real information; Also SimplePush clients could >>> not even integrate here (the protocol just uses version >>> (or timestamps) >> Yes. >> >> On the topic of Simple Push, you push a URL so in theory >> you could push >> /Documents/${collecitonName}/${id}/${rev_id} and have >> simple push setup to accept URLS formatted that way >> right? Or is it more limited than that? >> >> >> you can simply ONLY push a version number, that's it > I just reread things. It is worse than that. You can > (should) only push an increasing version number. So anything > checksum based will fail. > > > > best practice is 'timestamp' - that's all you can push over to > those devices > > > for a good reason Yeah. I keep forgetting how simple simplepush is. My original though on simple push was that a client to register as a listener for /Documents/Collections and it would receive pushes to /Documents/Collections/foo/bar. I was totally wrong :) This gives a much better context to everything that is also going on. > >> >> >> >> >>> >>> >>> >>> > 4. AG Synchronizer sends sync messages using Pipes >>> > 5. AG Synchronizer holds local data in a store >>> > >>> > 6. When AGSynchronizer gets a message it is >>> responsible for updating >>> > the Store and then notifying code listing for >>> updates OR for notifying >>> > the code that an error has occurred and needs to >>> be addressed. >>> > >>> > 7. When the developer updates data in the store, >>> the synchronizer >>> > should package that data and send it to the >>> server. The synchronizer is >>> > responsible for error handling, retrying, >>> back-off, etc. >>> > >>> > 8. We should include multiple synchronizer >>> implementations to deal with >>> > multiple very simple use cases which involve >>> legacy systems. (For >>> > instance polling to load static data on a schedule.) >>> > >>> > Thoughts? Tomatoes? >>> >> >>> >> >>> >> >>> >> _______________________________________________ >>> >> 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 >>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140128/6b49304d/attachment-0001.html From matzew at apache.org Tue Jan 28 12:37:26 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 28 Jan 2014 18:37:26 +0100 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <52E7EA87.9060705@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7E3F9.5030409@redhat.com> <52E7E85F.1010709@redhat.com> <52E7EA87.9060705@redhat.com> Message-ID: On Tue, Jan 28, 2014 at 6:36 PM, Summers Pittman wrote: > On 01/28/2014 12:32 PM, Matthias Wessendorf wrote: > > > > > On Tue, Jan 28, 2014 at 6:32 PM, Matthias Wessendorf wrote: > >> >> >> >> On Tue, Jan 28, 2014 at 6:26 PM, Summers Pittman wrote: >> >>> On 01/28/2014 12:13 PM, Matthias Wessendorf wrote: >>> >>> >>> >>> >>> On Tue, Jan 28, 2014 at 6:08 PM, Summers Pittman wrote: >>> >>>> On 01/28/2014 11:46 AM, Matthias Wessendorf wrote: >>>> >>>> >>>> >>>> >>>> On Tue, Jan 28, 2014 at 4:48 PM, Lucas Holmquist wrote: >>>> >>>>> >>>>> On Jan 28, 2014, at 10:30 AM, Summers Pittman >>>>> wrote: >>>>> >>>>> > On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >>>>> >> yup, this is another Data Sync thread, >>>>> >> >>>>> >>> From a client side perspective, i have concerns that there is >>>>> still not a clear direction yet. >>>>> >> >>>>> >> I know there are multiple ideas floating around on what our model >>>>> should be, i'm all for choice, but what about deciding on 1 model to get >>>>> started with. Then later once we have this nailed down, we can have other >>>>> "adapters" with different models perhaps >>>>> > All the data model is is an envelope of sync metadata around an >>>>> object >>>>> > right? >>>>> >>>>> right >>>>> >>>>> > >>>>> > We also need to think about the API and server/client protocol as >>>>> well. >>>>> > >>>>> > I think that for sync 1.0 we could focus on the following behavior >>>>> (it >>>>> > worked for my demos at least) >>>>> > >>>>> > 1. We have a Sync factory similar to Pipeline, Authenticator, >>>>> > Registrar, and KeyService. >>>>> > 2. The Sync factory consumes/manages Synchronizer instances. >>>>> > 3. AG Synchronizer listens for sync messages using UnifiedPush >>>>> endpoints. >>>>> i thought for a 1.0 we weren't thinking about "realtime" >>>>> >>>> >>>> that is my impression as well, talking to Dan on IRC; >>>> ATM all is polling, but the sync-server will be cable of doing >>>> WebSocket/SockJS, so "connected" clients, can sync. >>>> >>>> Polling is MURDER on battery, performance, and "feel". WebSockets and >>>> SockJS are awesome ideas for a future implementation for "real time". >>>> >>> >>> As far as I understood it, the sync-server just started w/ polling >>> (pure HTTP). I think that WebSocket/SockJS is not really that far away, in >>> terms of 'future' >>> >>> >>>> >>>> >>>> Push should be really used for 'wake-up', instead of changing real >>>> information; Also SimplePush clients could not even integrate here (the >>>> protocol just uses version (or timestamps) >>>> >>>> Yes. >>>> >>>> On the topic of Simple Push, you push a URL so in theory you could push >>>> /Documents/${collecitonName}/${id}/${rev_id} and have simple push setup to >>>> accept URLS formatted that way right? Or is it more limited than that? >>>> >>> >>> you can simply ONLY push a version number, that's it >>> >>> I just reread things. It is worse than that. You can (should) only >>> push an increasing version number. So anything checksum based will fail. >>> >> >> >> best practice is 'timestamp' - that's all you can push over to those >> devices >> > > for a good reason > > Yeah. I keep forgetting how simple simplepush is. > > My original though on simple push was that a client to register as a > listener for /Documents/Collections and it would receive pushes to > /Documents/Collections/foo/bar. I was totally wrong :) > > This gives a much better context to everything that is also going on. > you are now buying the real-time ? > > > >> >>> >>> >>> >>> >>> >>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> > 4. AG Synchronizer sends sync messages using Pipes >>>>> > 5. AG Synchronizer holds local data in a store >>>>> > >>>>> > 6. When AGSynchronizer gets a message it is responsible for updating >>>>> > the Store and then notifying code listing for updates OR for >>>>> notifying >>>>> > the code that an error has occurred and needs to be addressed. >>>>> > >>>>> > 7. When the developer updates data in the store, the synchronizer >>>>> > should package that data and send it to the server. The >>>>> synchronizer is >>>>> > responsible for error handling, retrying, back-off, etc. >>>>> > >>>>> > 8. We should include multiple synchronizer implementations to deal >>>>> with >>>>> > multiple very simple use cases which involve legacy systems. (For >>>>> > instance polling to load static data on a schedule.) >>>>> > >>>>> > Thoughts? Tomatoes? >>>>> >> >>>>> >> >>>>> >> >>>>> >> _______________________________________________ >>>>> >> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> >>>> _______________________________________________ >>>> 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 >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> >>> _______________________________________________ >>> 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 >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > 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 > -- 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/20140128/39c08b2f/attachment-0001.html From supittma at redhat.com Tue Jan 28 12:43:21 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 28 Jan 2014 12:43:21 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7E3F9.5030409@redhat.com> <52E7E85F.1010709@redhat.com> <52E7EA87.9060705@redhat.com> Message-ID: <52E7EC39.5030809@redhat.com> On 01/28/2014 12:37 PM, Matthias Wessendorf wrote: > > > > On Tue, Jan 28, 2014 at 6:36 PM, Summers Pittman > wrote: > > On 01/28/2014 12:32 PM, Matthias Wessendorf wrote: >> >> >> >> On Tue, Jan 28, 2014 at 6:32 PM, Matthias Wessendorf >> > wrote: >> >> >> >> >> On Tue, Jan 28, 2014 at 6:26 PM, Summers Pittman >> > wrote: >> >> On 01/28/2014 12:13 PM, Matthias Wessendorf wrote: >>> >>> >>> >>> On Tue, Jan 28, 2014 at 6:08 PM, Summers Pittman >>> > wrote: >>> >>> On 01/28/2014 11:46 AM, Matthias Wessendorf wrote: >>>> >>>> >>>> >>>> On Tue, Jan 28, 2014 at 4:48 PM, Lucas Holmquist >>>> > >>>> wrote: >>>> >>>> >>>> On Jan 28, 2014, at 10:30 AM, Summers Pittman >>>> >>> > wrote: >>>> >>>> > On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >>>> >> yup, this is another Data Sync thread, >>>> >> >>>> >>> From a client side perspective, i have >>>> concerns that there is still not a clear >>>> direction yet. >>>> >> >>>> >> I know there are multiple ideas floating >>>> around on what our model should be, i'm all >>>> for choice, but what about deciding on 1 model >>>> to get started with. Then later once we have >>>> this nailed down, we can have other "adapters" >>>> with different models perhaps >>>> > All the data model is is an envelope of sync >>>> metadata around an object >>>> > right? >>>> >>>> right >>>> >>>> > >>>> > We also need to think about the API and >>>> server/client protocol as well. >>>> > >>>> > I think that for sync 1.0 we could focus on >>>> the following behavior (it >>>> > worked for my demos at least) >>>> > >>>> > 1. We have a Sync factory similar to >>>> Pipeline, Authenticator, >>>> > Registrar, and KeyService. >>>> > 2. The Sync factory consumes/manages >>>> Synchronizer instances. >>>> > 3. AG Synchronizer listens for sync messages >>>> using UnifiedPush endpoints. >>>> i thought for a 1.0 we weren't thinking about >>>> "realtime" >>>> >>>> >>>> that is my impression as well, talking to Dan on IRC; >>>> ATM all is polling, but the sync-server will be >>>> cable of doing WebSocket/SockJS, so "connected" >>>> clients, can sync. >>> Polling is MURDER on battery, performance, and >>> "feel". WebSockets and SockJS are awesome ideas for >>> a future implementation for "real time". >>> >>> >>> As far as I understood it, the sync-server just started >>> w/ polling (pure HTTP). I think that WebSocket/SockJS is >>> not really that far away, in terms of 'future' >>> >>> >>>> >>>> Push should be really used for 'wake-up', instead >>>> of changing real information; Also SimplePush >>>> clients could not even integrate here (the protocol >>>> just uses version (or timestamps) >>> Yes. >>> >>> On the topic of Simple Push, you push a URL so in >>> theory you could push >>> /Documents/${collecitonName}/${id}/${rev_id} and >>> have simple push setup to accept URLS formatted that >>> way right? Or is it more limited than that? >>> >>> >>> you can simply ONLY push a version number, that's it >> I just reread things. It is worse than that. You can >> (should) only push an increasing version number. So >> anything checksum based will fail. >> >> >> >> best practice is 'timestamp' - that's all you can push over >> to those devices >> >> >> for a good reason > Yeah. I keep forgetting how simple simplepush is. > > My original though on simple push was that a client to register as > a listener for /Documents/Collections and it would receive pushes > to /Documents/Collections/foo/bar. I was totally wrong :) > > This gives a much better context to everything that is also going on. > > > you are now buying the real-time ? I still say skipping push initiated sync and going straight to real time isn't a great first release idea. What I am buying now is [polling]->[push initialed]->[beefing up push adapters to include good mqtt and websocket]->[real time] In my earlier real time text demo I wrote a websocket push adapter so there exists code to help with that hump. > > > >> >>> >>> >>> >>> >>>> >>>> >>>> >>>> > 4. AG Synchronizer sends sync messages using >>>> Pipes >>>> > 5. AG Synchronizer holds local data in a store >>>> > >>>> > 6. When AGSynchronizer gets a message it is >>>> responsible for updating >>>> > the Store and then notifying code listing for >>>> updates OR for notifying >>>> > the code that an error has occurred and needs >>>> to be addressed. >>>> > >>>> > 7. When the developer updates data in the >>>> store, the synchronizer >>>> > should package that data and send it to the >>>> server. The synchronizer is >>>> > responsible for error handling, retrying, >>>> back-off, etc. >>>> > >>>> > 8. We should include multiple synchronizer >>>> implementations to deal with >>>> > multiple very simple use cases which involve >>>> legacy systems. (For >>>> > instance polling to load static data on a >>>> schedule.) >>>> > >>>> > Thoughts? Tomatoes? >>>> >> >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> 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 >>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140128/e8f453c4/attachment-0001.html From matzew at apache.org Tue Jan 28 12:45:52 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 28 Jan 2014 18:45:52 +0100 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <52E7EC39.5030809@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7E3F9.5030409@redhat.com> <52E7E85F.1010709@redhat.com> <52E7EA87.9060705@redhat.com> <52E7EC39.5030809@redhat.com> Message-ID: On Tue, Jan 28, 2014 at 6:43 PM, Summers Pittman wrote: > On 01/28/2014 12:37 PM, Matthias Wessendorf wrote: > > > > > On Tue, Jan 28, 2014 at 6:36 PM, Summers Pittman wrote: > >> On 01/28/2014 12:32 PM, Matthias Wessendorf wrote: >> >> >> >> >> On Tue, Jan 28, 2014 at 6:32 PM, Matthias Wessendorf wrote: >> >>> >>> >>> >>> On Tue, Jan 28, 2014 at 6:26 PM, Summers Pittman wrote: >>> >>>> On 01/28/2014 12:13 PM, Matthias Wessendorf wrote: >>>> >>>> >>>> >>>> >>>> On Tue, Jan 28, 2014 at 6:08 PM, Summers Pittman wrote: >>>> >>>>> On 01/28/2014 11:46 AM, Matthias Wessendorf wrote: >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Jan 28, 2014 at 4:48 PM, Lucas Holmquist wrote: >>>>> >>>>>> >>>>>> On Jan 28, 2014, at 10:30 AM, Summers Pittman >>>>>> wrote: >>>>>> >>>>>> > On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >>>>>> >> yup, this is another Data Sync thread, >>>>>> >> >>>>>> >>> From a client side perspective, i have concerns that there is >>>>>> still not a clear direction yet. >>>>>> >> >>>>>> >> I know there are multiple ideas floating around on what our model >>>>>> should be, i'm all for choice, but what about deciding on 1 model to get >>>>>> started with. Then later once we have this nailed down, we can have other >>>>>> "adapters" with different models perhaps >>>>>> > All the data model is is an envelope of sync metadata around an >>>>>> object >>>>>> > right? >>>>>> >>>>>> right >>>>>> >>>>>> > >>>>>> > We also need to think about the API and server/client protocol as >>>>>> well. >>>>>> > >>>>>> > I think that for sync 1.0 we could focus on the following behavior >>>>>> (it >>>>>> > worked for my demos at least) >>>>>> > >>>>>> > 1. We have a Sync factory similar to Pipeline, Authenticator, >>>>>> > Registrar, and KeyService. >>>>>> > 2. The Sync factory consumes/manages Synchronizer instances. >>>>>> > 3. AG Synchronizer listens for sync messages using UnifiedPush >>>>>> endpoints. >>>>>> i thought for a 1.0 we weren't thinking about "realtime" >>>>>> >>>>> >>>>> that is my impression as well, talking to Dan on IRC; >>>>> ATM all is polling, but the sync-server will be cable of doing >>>>> WebSocket/SockJS, so "connected" clients, can sync. >>>>> >>>>> Polling is MURDER on battery, performance, and "feel". WebSockets >>>>> and SockJS are awesome ideas for a future implementation for "real time". >>>>> >>>> >>>> As far as I understood it, the sync-server just started w/ polling >>>> (pure HTTP). I think that WebSocket/SockJS is not really that far away, in >>>> terms of 'future' >>>> >>>> >>>>> >>>>> >>>>> Push should be really used for 'wake-up', instead of changing real >>>>> information; Also SimplePush clients could not even integrate here (the >>>>> protocol just uses version (or timestamps) >>>>> >>>>> Yes. >>>>> >>>>> On the topic of Simple Push, you push a URL so in theory you could >>>>> push /Documents/${collecitonName}/${id}/${rev_id} and have simple push >>>>> setup to accept URLS formatted that way right? Or is it more limited than >>>>> that? >>>>> >>>> >>>> you can simply ONLY push a version number, that's it >>>> >>>> I just reread things. It is worse than that. You can (should) only >>>> push an increasing version number. So anything checksum based will fail. >>>> >>> >>> >>> best practice is 'timestamp' - that's all you can push over to those >>> devices >>> >> >> for a good reason >> >> Yeah. I keep forgetting how simple simplepush is. >> >> My original though on simple push was that a client to register as a >> listener for /Documents/Collections and it would receive pushes to >> /Documents/Collections/foo/bar. I was totally wrong :) >> >> This gives a much better context to everything that is also going on. >> > > you are now buying the real-time ? > > I still say skipping push initiated sync and going straight to real time > isn't a great first release idea. > > What I am buying now is [polling]->[push initialed]->[beefing up push > adapters to include good mqtt and websocket]->[real time] > I doubt that push is (always) needed - not sure every mobile _really_ wants to receive a notification "something is new". If an application relies on push in order to function it is fundamentally broken > > In my earlier real time text demo I wrote a websocket push adapter so > there exists code to help with that hump. > > > > > >> >> >> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> > 4. AG Synchronizer sends sync messages using Pipes >>>>>> > 5. AG Synchronizer holds local data in a store >>>>>> > >>>>>> > 6. When AGSynchronizer gets a message it is responsible for >>>>>> updating >>>>>> > the Store and then notifying code listing for updates OR for >>>>>> notifying >>>>>> > the code that an error has occurred and needs to be addressed. >>>>>> > >>>>>> > 7. When the developer updates data in the store, the synchronizer >>>>>> > should package that data and send it to the server. The >>>>>> synchronizer is >>>>>> > responsible for error handling, retrying, back-off, etc. >>>>>> > >>>>>> > 8. We should include multiple synchronizer implementations to deal >>>>>> with >>>>>> > multiple very simple use cases which involve legacy systems. (For >>>>>> > instance polling to load static data on a schedule.) >>>>>> > >>>>>> > Thoughts? Tomatoes? >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> _______________________________________________ >>>>>> >> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> >>>> _______________________________________________ >>>> 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 >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> >> _______________________________________________ >> 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 >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > 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 > -- 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/20140128/28319b97/attachment-0001.html From supittma at redhat.com Tue Jan 28 12:53:19 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 28 Jan 2014 12:53:19 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7E3F9.5030409@redhat.com> <52E7E85F.1010709@redhat.com> <52E7EA87.9060705@redhat.com> <52E7EC39.5030809@redhat.com> Message-ID: <52E7EE8F.7020400@redhat.com> On 01/28/2014 12:45 PM, Matthias Wessendorf wrote: > > > > On Tue, Jan 28, 2014 at 6:43 PM, Summers Pittman > wrote: > > On 01/28/2014 12:37 PM, Matthias Wessendorf wrote: >> >> >> >> On Tue, Jan 28, 2014 at 6:36 PM, Summers Pittman >> > wrote: >> >> On 01/28/2014 12:32 PM, Matthias Wessendorf wrote: >>> >>> >>> >>> On Tue, Jan 28, 2014 at 6:32 PM, Matthias Wessendorf >>> > wrote: >>> >>> >>> >>> >>> On Tue, Jan 28, 2014 at 6:26 PM, Summers Pittman >>> > wrote: >>> >>> On 01/28/2014 12:13 PM, Matthias Wessendorf wrote: >>>> >>>> >>>> >>>> On Tue, Jan 28, 2014 at 6:08 PM, Summers Pittman >>>> > >>>> wrote: >>>> >>>> On 01/28/2014 11:46 AM, Matthias Wessendorf wrote: >>>>> >>>>> >>>>> >>>>> On Tue, Jan 28, 2014 at 4:48 PM, Lucas >>>>> Holmquist >>>> > wrote: >>>>> >>>>> >>>>> On Jan 28, 2014, at 10:30 AM, Summers >>>>> Pittman >>>> > wrote: >>>>> >>>>> > On 01/28/2014 09:36 AM, Lucas Holmquist >>>>> wrote: >>>>> >> yup, this is another Data Sync thread, >>>>> >> >>>>> >>> From a client side perspective, i have >>>>> concerns that there is still not a clear >>>>> direction yet. >>>>> >> >>>>> >> I know there are multiple ideas >>>>> floating around on what our model should >>>>> be, i'm all for choice, but what about >>>>> deciding on 1 model to get started with. >>>>> Then later once we have this nailed down, >>>>> we can have other "adapters" with >>>>> different models perhaps >>>>> > All the data model is is an envelope of >>>>> sync metadata around an object >>>>> > right? >>>>> >>>>> right >>>>> >>>>> > >>>>> > We also need to think about the API and >>>>> server/client protocol as well. >>>>> > >>>>> > I think that for sync 1.0 we could focus >>>>> on the following behavior (it >>>>> > worked for my demos at least) >>>>> > >>>>> > 1. We have a Sync factory similar to >>>>> Pipeline, Authenticator, >>>>> > Registrar, and KeyService. >>>>> > 2. The Sync factory consumes/manages >>>>> Synchronizer instances. >>>>> > 3. AG Synchronizer listens for sync >>>>> messages using UnifiedPush endpoints. >>>>> i thought for a 1.0 we weren't thinking >>>>> about "realtime" >>>>> >>>>> >>>>> that is my impression as well, talking to Dan >>>>> on IRC; >>>>> ATM all is polling, but the sync-server will >>>>> be cable of doing WebSocket/SockJS, so >>>>> "connected" clients, can sync. >>>> Polling is MURDER on battery, performance, and >>>> "feel". WebSockets and SockJS are awesome ideas >>>> for a future implementation for "real time". >>>> >>>> >>>> As far as I understood it, the sync-server just >>>> started w/ polling (pure HTTP). I think that >>>> WebSocket/SockJS is not really that far away, in >>>> terms of 'future' >>>> >>>> >>>>> >>>>> Push should be really used for 'wake-up', >>>>> instead of changing real information; Also >>>>> SimplePush clients could not even integrate >>>>> here (the protocol just uses version (or >>>>> timestamps) >>>> Yes. >>>> >>>> On the topic of Simple Push, you push a URL so >>>> in theory you could push >>>> /Documents/${collecitonName}/${id}/${rev_id} >>>> and have simple push setup to accept URLS >>>> formatted that way right? Or is it more >>>> limited than that? >>>> >>>> >>>> you can simply ONLY push a version number, that's it >>> I just reread things. It is worse than that. You >>> can (should) only push an increasing version >>> number. So anything checksum based will fail. >>> >>> >>> >>> best practice is 'timestamp' - that's all you can push >>> over to those devices >>> >>> >>> for a good reason >> Yeah. I keep forgetting how simple simplepush is. >> >> My original though on simple push was that a client to >> register as a listener for /Documents/Collections and it >> would receive pushes to /Documents/Collections/foo/bar. I >> was totally wrong :) >> >> This gives a much better context to everything that is also >> going on. >> >> >> you are now buying the real-time ? > I still say skipping push initiated sync and going straight to > real time isn't a great first release idea. > > What I am buying now is [polling]->[push initialed]->[beefing up > push adapters to include good mqtt and websocket]->[real time] > > > I doubt that push is (always) needed - not sure every mobile _really_ > wants to receive a notification "something is new". > > If an application relies on push in order to function it is > fundamentally broken Well that depends. If the purpose of the application is to get updates on non critical data then push is a fundamental part of the apps identity. Polling is too low and frequent polling is too wasteful. If the application just has to update once every few hours then polling is just peachy. There is no reason we can't have multiple adapters, some which need push, some which need real time bidirecitonal channels, and some which just need to get data a few times a day. A good API can hide all of these details and let a dev pick/choose/implement what she needs at design time. > > > In my earlier real time text demo I wrote a websocket push adapter > so there exists code to help with that hump. > > >> >> >> >>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> > 4. AG Synchronizer sends sync messages >>>>> using Pipes >>>>> > 5. AG Synchronizer holds local data in >>>>> a store >>>>> > >>>>> > 6. When AGSynchronizer gets a message >>>>> it is responsible for updating >>>>> > the Store and then notifying code >>>>> listing for updates OR for notifying >>>>> > the code that an error has occurred and >>>>> needs to be addressed. >>>>> > >>>>> > 7. When the developer updates data in >>>>> the store, the synchronizer >>>>> > should package that data and send it to >>>>> the server. The synchronizer is >>>>> > responsible for error handling, >>>>> retrying, back-off, etc. >>>>> > >>>>> > 8. We should include multiple >>>>> synchronizer implementations to deal with >>>>> > multiple very simple use cases which >>>>> involve legacy systems. (For >>>>> > instance polling to load static data on >>>>> a schedule.) >>>>> > >>>>> > Thoughts? Tomatoes? >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >>>>> >> 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 >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140128/e2f20bd5/attachment-0001.html From supittma at redhat.com Tue Jan 28 13:01:51 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 28 Jan 2014 13:01:51 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7E3F9.5030409@redhat.com> <52E7E85F.1010709@redhat.com> <52E7EA87.9060705@redhat.com> <52E7EC39.5030809@redhat.com> Message-ID: <52E7F08F.4090605@redhat.com> On 01/28/2014 12:45 PM, Matthias Wessendorf wrote: > > > > On Tue, Jan 28, 2014 at 6:43 PM, Summers Pittman > wrote: > > On 01/28/2014 12:37 PM, Matthias Wessendorf wrote: >> >> >> >> On Tue, Jan 28, 2014 at 6:36 PM, Summers Pittman >> > wrote: >> >> On 01/28/2014 12:32 PM, Matthias Wessendorf wrote: >>> >>> >>> >>> On Tue, Jan 28, 2014 at 6:32 PM, Matthias Wessendorf >>> > wrote: >>> >>> >>> >>> >>> On Tue, Jan 28, 2014 at 6:26 PM, Summers Pittman >>> > wrote: >>> >>> On 01/28/2014 12:13 PM, Matthias Wessendorf wrote: >>>> >>>> >>>> >>>> On Tue, Jan 28, 2014 at 6:08 PM, Summers Pittman >>>> > >>>> wrote: >>>> >>>> On 01/28/2014 11:46 AM, Matthias Wessendorf wrote: >>>>> >>>>> >>>>> >>>>> On Tue, Jan 28, 2014 at 4:48 PM, Lucas >>>>> Holmquist >>>> > wrote: >>>>> >>>>> >>>>> On Jan 28, 2014, at 10:30 AM, Summers >>>>> Pittman >>>> > wrote: >>>>> >>>>> > On 01/28/2014 09:36 AM, Lucas Holmquist >>>>> wrote: >>>>> >> yup, this is another Data Sync thread, >>>>> >> >>>>> >>> From a client side perspective, i have >>>>> concerns that there is still not a clear >>>>> direction yet. >>>>> >> >>>>> >> I know there are multiple ideas >>>>> floating around on what our model should >>>>> be, i'm all for choice, but what about >>>>> deciding on 1 model to get started with. >>>>> Then later once we have this nailed down, >>>>> we can have other "adapters" with >>>>> different models perhaps >>>>> > All the data model is is an envelope of >>>>> sync metadata around an object >>>>> > right? >>>>> >>>>> right >>>>> >>>>> > >>>>> > We also need to think about the API and >>>>> server/client protocol as well. >>>>> > >>>>> > I think that for sync 1.0 we could focus >>>>> on the following behavior (it >>>>> > worked for my demos at least) >>>>> > >>>>> > 1. We have a Sync factory similar to >>>>> Pipeline, Authenticator, >>>>> > Registrar, and KeyService. >>>>> > 2. The Sync factory consumes/manages >>>>> Synchronizer instances. >>>>> > 3. AG Synchronizer listens for sync >>>>> messages using UnifiedPush endpoints. >>>>> i thought for a 1.0 we weren't thinking >>>>> about "realtime" >>>>> >>>>> >>>>> that is my impression as well, talking to Dan >>>>> on IRC; >>>>> ATM all is polling, but the sync-server will >>>>> be cable of doing WebSocket/SockJS, so >>>>> "connected" clients, can sync. >>>> Polling is MURDER on battery, performance, and >>>> "feel". WebSockets and SockJS are awesome ideas >>>> for a future implementation for "real time". >>>> >>>> >>>> As far as I understood it, the sync-server just >>>> started w/ polling (pure HTTP). I think that >>>> WebSocket/SockJS is not really that far away, in >>>> terms of 'future' >>>> >>>> >>>>> >>>>> Push should be really used for 'wake-up', >>>>> instead of changing real information; Also >>>>> SimplePush clients could not even integrate >>>>> here (the protocol just uses version (or >>>>> timestamps) >>>> Yes. >>>> >>>> On the topic of Simple Push, you push a URL so >>>> in theory you could push >>>> /Documents/${collecitonName}/${id}/${rev_id} >>>> and have simple push setup to accept URLS >>>> formatted that way right? Or is it more >>>> limited than that? >>>> >>>> >>>> you can simply ONLY push a version number, that's it >>> I just reread things. It is worse than that. You >>> can (should) only push an increasing version >>> number. So anything checksum based will fail. >>> >>> >>> >>> best practice is 'timestamp' - that's all you can push >>> over to those devices >>> >>> >>> for a good reason >> Yeah. I keep forgetting how simple simplepush is. >> >> My original though on simple push was that a client to >> register as a listener for /Documents/Collections and it >> would receive pushes to /Documents/Collections/foo/bar. I >> was totally wrong :) >> >> This gives a much better context to everything that is also >> going on. >> >> >> you are now buying the real-time ? > I still say skipping push initiated sync and going straight to > real time isn't a great first release idea. > > What I am buying now is [polling]->[push initialed]->[beefing up > push adapters to include good mqtt and websocket]->[real time] > > > I doubt that push is (always) needed - not sure every mobile _really_ > wants to receive a notification "something is new". > > If an application relies on push in order to function it is > fundamentally broken I think we are saying the same thing. The only difference is you think push is an optional feature for our first release and I think it isn't. I think polling is allowable and simple but it shouldn't be the only option in the first release. Did I miss interpret something? > > > In my earlier real time text demo I wrote a websocket push adapter > so there exists code to help with that hump. > > >> >> >> >>> >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> >>>>> > 4. AG Synchronizer sends sync messages >>>>> using Pipes >>>>> > 5. AG Synchronizer holds local data in >>>>> a store >>>>> > >>>>> > 6. When AGSynchronizer gets a message >>>>> it is responsible for updating >>>>> > the Store and then notifying code >>>>> listing for updates OR for notifying >>>>> > the code that an error has occurred and >>>>> needs to be addressed. >>>>> > >>>>> > 7. When the developer updates data in >>>>> the store, the synchronizer >>>>> > should package that data and send it to >>>>> the server. The synchronizer is >>>>> > responsible for error handling, >>>>> retrying, back-off, etc. >>>>> > >>>>> > 8. We should include multiple >>>>> synchronizer implementations to deal with >>>>> > multiple very simple use cases which >>>>> involve legacy systems. (For >>>>> > instance polling to load static data on >>>>> a schedule.) >>>>> > >>>>> > Thoughts? Tomatoes? >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> _______________________________________________ >>>>> >> 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 >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > -- > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140128/531ed87d/attachment-0001.html From matzew at apache.org Tue Jan 28 13:05:54 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Tue, 28 Jan 2014 19:05:54 +0100 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <52E7EE8F.7020400@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7E3F9.5030409@redhat.com> <52E7E85F.1010709@redhat.com> <52E7EA87.9060705@redhat.com> <52E7EC39.5030809@redhat.com> <52E7EE8F.7020400@redhat.com> Message-ID: On Tue, Jan 28, 2014 at 6:53 PM, Summers Pittman wrote: > On 01/28/2014 12:45 PM, Matthias Wessendorf wrote: > > > > > On Tue, Jan 28, 2014 at 6:43 PM, Summers Pittman wrote: > >> On 01/28/2014 12:37 PM, Matthias Wessendorf wrote: >> >> >> >> >> On Tue, Jan 28, 2014 at 6:36 PM, Summers Pittman wrote: >> >>> On 01/28/2014 12:32 PM, Matthias Wessendorf wrote: >>> >>> >>> >>> >>> On Tue, Jan 28, 2014 at 6:32 PM, Matthias Wessendorf wrote: >>> >>>> >>>> >>>> >>>> On Tue, Jan 28, 2014 at 6:26 PM, Summers Pittman wrote: >>>> >>>>> On 01/28/2014 12:13 PM, Matthias Wessendorf wrote: >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Jan 28, 2014 at 6:08 PM, Summers Pittman wrote: >>>>> >>>>>> On 01/28/2014 11:46 AM, Matthias Wessendorf wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jan 28, 2014 at 4:48 PM, Lucas Holmquist >>>>> > wrote: >>>>>> >>>>>>> >>>>>>> On Jan 28, 2014, at 10:30 AM, Summers Pittman >>>>>>> wrote: >>>>>>> >>>>>>> > On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >>>>>>> >> yup, this is another Data Sync thread, >>>>>>> >> >>>>>>> >>> From a client side perspective, i have concerns that there is >>>>>>> still not a clear direction yet. >>>>>>> >> >>>>>>> >> I know there are multiple ideas floating around on what our model >>>>>>> should be, i'm all for choice, but what about deciding on 1 model to get >>>>>>> started with. Then later once we have this nailed down, we can have other >>>>>>> "adapters" with different models perhaps >>>>>>> > All the data model is is an envelope of sync metadata around an >>>>>>> object >>>>>>> > right? >>>>>>> >>>>>>> right >>>>>>> >>>>>>> > >>>>>>> > We also need to think about the API and server/client protocol as >>>>>>> well. >>>>>>> > >>>>>>> > I think that for sync 1.0 we could focus on the following behavior >>>>>>> (it >>>>>>> > worked for my demos at least) >>>>>>> > >>>>>>> > 1. We have a Sync factory similar to Pipeline, Authenticator, >>>>>>> > Registrar, and KeyService. >>>>>>> > 2. The Sync factory consumes/manages Synchronizer instances. >>>>>>> > 3. AG Synchronizer listens for sync messages using UnifiedPush >>>>>>> endpoints. >>>>>>> i thought for a 1.0 we weren't thinking about "realtime" >>>>>>> >>>>>> >>>>>> that is my impression as well, talking to Dan on IRC; >>>>>> ATM all is polling, but the sync-server will be cable of doing >>>>>> WebSocket/SockJS, so "connected" clients, can sync. >>>>>> >>>>>> Polling is MURDER on battery, performance, and "feel". WebSockets >>>>>> and SockJS are awesome ideas for a future implementation for "real time". >>>>>> >>>>> >>>>> As far as I understood it, the sync-server just started w/ polling >>>>> (pure HTTP). I think that WebSocket/SockJS is not really that far away, in >>>>> terms of 'future' >>>>> >>>>> >>>>>> >>>>>> >>>>>> Push should be really used for 'wake-up', instead of changing real >>>>>> information; Also SimplePush clients could not even integrate here (the >>>>>> protocol just uses version (or timestamps) >>>>>> >>>>>> Yes. >>>>>> >>>>>> On the topic of Simple Push, you push a URL so in theory you could >>>>>> push /Documents/${collecitonName}/${id}/${rev_id} and have simple push >>>>>> setup to accept URLS formatted that way right? Or is it more limited than >>>>>> that? >>>>>> >>>>> >>>>> you can simply ONLY push a version number, that's it >>>>> >>>>> I just reread things. It is worse than that. You can (should) only >>>>> push an increasing version number. So anything checksum based will fail. >>>>> >>>> >>>> >>>> best practice is 'timestamp' - that's all you can push over to those >>>> devices >>>> >>> >>> for a good reason >>> >>> Yeah. I keep forgetting how simple simplepush is. >>> >>> My original though on simple push was that a client to register as a >>> listener for /Documents/Collections and it would receive pushes to >>> /Documents/Collections/foo/bar. I was totally wrong :) >>> >>> This gives a much better context to everything that is also going on. >>> >> >> you are now buying the real-time ? >> >> I still say skipping push initiated sync and going straight to real >> time isn't a great first release idea. >> >> What I am buying now is [polling]->[push initialed]->[beefing up push >> adapters to include good mqtt and websocket]->[real time] >> > > I doubt that push is (always) needed - not sure every mobile _really_ > wants to receive a notification "something is new". > > If an application relies on push in order to function it is > fundamentally broken > > > Well that depends. > well, on iOS a user of an app can say "No" to the feature of receiving push notifications. If the app, using our sync bits, does NOT work when no push is available, the api is broken. Push, as part of the sync, should be optional, not required. for the apple app-store guidelines it's similar: if an app only works when it is allowed to receive push-notifications: You dont get an approval. Push optional to wake-up: yes - but that's not really sync :) that's more a trigger, which may cause the app connecting to our real-time service on the sync server > If the purpose of the application is to get updates on non critical data > then push is a fundamental part of the apps identity. Polling is too low > and frequent polling is too wasteful. > > If the application just has to update once every few hours then polling is > just peachy. > > There is no reason we can't have multiple adapters, some which need push, > some which need real time bidirecitonal channels, and some which just need > to get data a few times a day. A good API can hide all of these details > and let a dev pick/choose/implement what she needs at design time. > > > > > >> >> In my earlier real time text demo I wrote a websocket push adapter so >> there exists code to help with that hump. >> >> >> >> >> >>> >>> >>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> > 4. AG Synchronizer sends sync messages using Pipes >>>>>>> > 5. AG Synchronizer holds local data in a store >>>>>>> > >>>>>>> > 6. When AGSynchronizer gets a message it is responsible for >>>>>>> updating >>>>>>> > the Store and then notifying code listing for updates OR for >>>>>>> notifying >>>>>>> > the code that an error has occurred and needs to be addressed. >>>>>>> > >>>>>>> > 7. When the developer updates data in the store, the synchronizer >>>>>>> > should package that data and send it to the server. The >>>>>>> synchronizer is >>>>>>> > responsible for error handling, retrying, back-off, etc. >>>>>>> > >>>>>>> > 8. We should include multiple synchronizer implementations to >>>>>>> deal with >>>>>>> > multiple very simple use cases which involve legacy systems. (For >>>>>>> > instance polling to load static data on a schedule.) >>>>>>> > >>>>>>> > Thoughts? Tomatoes? >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> _______________________________________________ >>>>>>> >> 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 >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> >>> _______________________________________________ >>> 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 >>> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> >> _______________________________________________ >> 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 >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > 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 > -- 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/20140128/490b82be/attachment-0001.html From qmx at qmx.me Tue Jan 28 13:07:46 2014 From: qmx at qmx.me (Douglas Campos) Date: Tue, 28 Jan 2014 16:07:46 -0200 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> Message-ID: <20140128180746.GE20528@rohan.local> On Tue, Jan 28, 2014 at 10:48:14AM -0500, Lucas Holmquist wrote: > > On Jan 28, 2014, at 10:30 AM, Summers Pittman wrote: > > > On 01/28/2014 09:36 AM, Lucas Holmquist wrote: > > 3. AG Synchronizer listens for sync messages using UnifiedPush endpoints. > i thought for a 1.0 we weren't thinking about "realtime" Yep, and I'm still against realtime for 1.0 -- qmx From supittma at redhat.com Tue Jan 28 13:11:18 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 28 Jan 2014 13:11:18 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <20140128180746.GE20528@rohan.local> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <20140128180746.GE20528@rohan.local> Message-ID: <52E7F2C6.2090608@redhat.com> On 01/28/2014 01:07 PM, Douglas Campos wrote: > On Tue, Jan 28, 2014 at 10:48:14AM -0500, Lucas Holmquist wrote: >> On Jan 28, 2014, at 10:30 AM, Summers Pittman wrote: >> >>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >>> 3. AG Synchronizer listens for sync messages using UnifiedPush endpoints. >> i thought for a 1.0 we weren't thinking about "realtime" > Yep, and I'm still against realtime for 1.0 So I think I may be a bit confused on what "realtime" is. When I hear realtime I'm thinking there is a socket open and messages are being sent to it hand handled in < 100ms. What I was proposing by `AG Synchronizer listens for sync messages using UnifiedPush endpoints` is being able for the server to send "wake up and poll" messages to clients. That does not hit my "real time" definition. > > From qmx at qmx.me Tue Jan 28 13:11:41 2014 From: qmx at qmx.me (Douglas Campos) Date: Tue, 28 Jan 2014 16:11:41 -0200 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <52E7E456.5060309@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> <5DCEB5A8-1942-4C0C-8C0E-3DFCB5521C0B@redhat.com> <52E7D475.6060208@redhat.com> <52E7E456.5060309@redhat.com> Message-ID: <20140128181141.GF20528@rohan.local> On Tue, Jan 28, 2014 at 12:09:42PM -0500, Summers Pittman wrote: > I am fine with designing around the limitations of SimplePush. > s/limitations/features/ :) -- qmx From supittma at redhat.com Tue Jan 28 13:15:11 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 28 Jan 2014 13:15:11 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7E3F9.5030409@redhat.com> <52E7E85F.1010709@redhat.com> <52E7EA87.9060705@redhat.com> <52E7EC39.5030809@redhat.com> <52E7EE8F.7020400@redhat.com> Message-ID: <52E7F3AF.7090901@redhat.com> On 01/28/2014 01:05 PM, Matthias Wessendorf wrote: > > > > On Tue, Jan 28, 2014 at 6:53 PM, Summers Pittman > wrote: > > On 01/28/2014 12:45 PM, Matthias Wessendorf wrote: >> >> >> >> On Tue, Jan 28, 2014 at 6:43 PM, Summers Pittman >> > wrote: >> >> On 01/28/2014 12:37 PM, Matthias Wessendorf wrote: >>> >>> >>> >>> On Tue, Jan 28, 2014 at 6:36 PM, Summers Pittman >>> > wrote: >>> >>> On 01/28/2014 12:32 PM, Matthias Wessendorf wrote: >>>> >>>> >>>> >>>> On Tue, Jan 28, 2014 at 6:32 PM, Matthias Wessendorf >>>> > wrote: >>>> >>>> >>>> >>>> >>>> On Tue, Jan 28, 2014 at 6:26 PM, Summers Pittman >>>> > >>>> wrote: >>>> >>>> On 01/28/2014 12:13 PM, Matthias Wessendorf wrote: >>>>> >>>>> >>>>> >>>>> On Tue, Jan 28, 2014 at 6:08 PM, Summers >>>>> Pittman >>>> > wrote: >>>>> >>>>> On 01/28/2014 11:46 AM, Matthias >>>>> Wessendorf wrote: >>>>>> >>>>>> >>>>>> >>>>>> On Tue, Jan 28, 2014 at 4:48 PM, Lucas >>>>>> Holmquist >>>>> > wrote: >>>>>> >>>>>> >>>>>> On Jan 28, 2014, at 10:30 AM, Summers >>>>>> Pittman >>>>> > wrote: >>>>>> >>>>>> > On 01/28/2014 09:36 AM, Lucas >>>>>> Holmquist wrote: >>>>>> >> yup, this is another Data Sync thread, >>>>>> >> >>>>>> >>> From a client side perspective, i >>>>>> have concerns that there is still not >>>>>> a clear direction yet. >>>>>> >> >>>>>> >> I know there are multiple ideas >>>>>> floating around on what our model >>>>>> should be, i'm all for choice, but >>>>>> what about deciding on 1 model to get >>>>>> started with. Then later once we >>>>>> have this nailed down, we can have >>>>>> other "adapters" with different >>>>>> models perhaps >>>>>> > All the data model is is an >>>>>> envelope of sync metadata around an >>>>>> object >>>>>> > right? >>>>>> >>>>>> right >>>>>> >>>>>> > >>>>>> > We also need to think about the API >>>>>> and server/client protocol as well. >>>>>> > >>>>>> > I think that for sync 1.0 we could >>>>>> focus on the following behavior (it >>>>>> > worked for my demos at least) >>>>>> > >>>>>> > 1. We have a Sync factory similar >>>>>> to Pipeline, Authenticator, >>>>>> > Registrar, and KeyService. >>>>>> > 2. The Sync factory >>>>>> consumes/manages Synchronizer instances. >>>>>> > 3. AG Synchronizer listens for >>>>>> sync messages using UnifiedPush >>>>>> endpoints. >>>>>> i thought for a 1.0 we weren't >>>>>> thinking about "realtime" >>>>>> >>>>>> >>>>>> that is my impression as well, talking to >>>>>> Dan on IRC; >>>>>> ATM all is polling, but the sync-server >>>>>> will be cable of doing WebSocket/SockJS, >>>>>> so "connected" clients, can sync. >>>>> Polling is MURDER on battery, performance, >>>>> and "feel". WebSockets and SockJS are >>>>> awesome ideas for a future implementation >>>>> for "real time". >>>>> >>>>> >>>>> As far as I understood it, the sync-server >>>>> just started w/ polling (pure HTTP). I think >>>>> that WebSocket/SockJS is not really that far >>>>> away, in terms of 'future' >>>>> >>>>> >>>>>> >>>>>> Push should be really used for 'wake-up', >>>>>> instead of changing real information; >>>>>> Also SimplePush clients could not even >>>>>> integrate here (the protocol just uses >>>>>> version (or timestamps) >>>>> Yes. >>>>> >>>>> On the topic of Simple Push, you push a >>>>> URL so in theory you could push >>>>> /Documents/${collecitonName}/${id}/${rev_id} >>>>> and have simple push setup to accept URLS >>>>> formatted that way right? Or is it more >>>>> limited than that? >>>>> >>>>> >>>>> you can simply ONLY push a version number, >>>>> that's it >>>> I just reread things. It is worse than that. >>>> You can (should) only push an increasing >>>> version number. So anything checksum based >>>> will fail. >>>> >>>> >>>> >>>> best practice is 'timestamp' - that's all you can >>>> push over to those devices >>>> >>>> >>>> for a good reason >>> Yeah. I keep forgetting how simple simplepush is. >>> >>> My original though on simple push was that a client to >>> register as a listener for /Documents/Collections and it >>> would receive pushes to /Documents/Collections/foo/bar. >>> I was totally wrong :) >>> >>> This gives a much better context to everything that is >>> also going on. >>> >>> >>> you are now buying the real-time ? >> I still say skipping push initiated sync and going straight >> to real time isn't a great first release idea. >> >> What I am buying now is [polling]->[push initialed]->[beefing >> up push adapters to include good mqtt and websocket]->[real time] >> >> >> I doubt that push is (always) needed - not sure every mobile >> _really_ wants to receive a notification "something is new". >> >> If an application relies on push in order to function it is >> fundamentally broken > > Well that depends. > > > well, on iOS a user of an app can say "No" to the feature of receiving > push notifications. > If the app, using our sync bits, does NOT work when no push is > available, the api is broken. > > Push, as part of the sync, should be optional, not required. > > for the apple app-store guidelines it's similar: if an app only works > when it is allowed to receive push-notifications: You dont get an > approval. Thanks for reminding me why I think iOS is a dead end platform divorced from reality ;) > > Push optional to wake-up: yes - but that's not really sync :) that's > more a trigger, which may cause the app connecting to our real-time > service on the sync server Sync is being able to resolve changes in remote and local data in response to a trigger. That trigger can be time (polling every x), user input (a ugly refresh button), push messages (a proprietary tether to a closed source software stack), or responses to crystal telepathy (Bluetooth accessory only compatible with iOS 9) for all I care ;) We should make a point to nail down which ones we listen to for 1.0 and which ones we punt. > > If the purpose of the application is to get updates on non > critical data then push is a fundamental part of the apps > identity. Polling is too low and frequent polling is too wasteful. > > If the application just has to update once every few hours then > polling is just peachy. > > There is no reason we can't have multiple adapters, some which > need push, some which need real time bidirecitonal channels, and > some which just need to get data a few times a day. A good API > can hide all of these details and let a dev pick/choose/implement > what she needs at design time. > > >> >> >> In my earlier real time text demo I wrote a websocket push >> adapter so there exists code to help with that hump. >> >> >>> >>> >>> >>>> >>>>> >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> > 4. AG Synchronizer sends sync >>>>>> messages using Pipes >>>>>> > 5. AG Synchronizer holds local >>>>>> data in a store >>>>>> > >>>>>> > 6. When AGSynchronizer gets a >>>>>> message it is responsible for updating >>>>>> > the Store and then notifying code >>>>>> listing for updates OR for notifying >>>>>> > the code that an error has occurred >>>>>> and needs to be addressed. >>>>>> > >>>>>> > 7. When the developer updates data >>>>>> in the store, the synchronizer >>>>>> > should package that data and send >>>>>> it to the server. The synchronizer is >>>>>> > responsible for error handling, >>>>>> retrying, back-off, etc. >>>>>> > >>>>>> > 8. We should include multiple >>>>>> synchronizer implementations to deal with >>>>>> > multiple very simple use cases >>>>>> which involve legacy systems. (For >>>>>> > instance polling to load static >>>>>> data on a schedule.) >>>>>> > >>>>>> > Thoughts? Tomatoes? >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> >> >>>>>> _______________________________________________ >>>>>> >> 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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Matthias Wessendorf >>>>>> >>>>>> blog: >>>>>> http://matthiaswessendorf.wordpress.com/ >>>>>> sessions: >>>>>> http://www.slideshare.net/mwessendorf >>>>>> twitter: http://twitter.com/mwessendorf >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> aerogear-dev mailing list >>>>>> aerogear-dev at lists.jboss.org >>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matthias Wessendorf >>>>> >>>>> blog: http://matthiaswessendorf.wordpress.com/ >>>>> sessions: http://www.slideshare.net/mwessendorf >>>>> twitter: http://twitter.com/mwessendorf >>>>> >>>>> >>>>> _______________________________________________ >>>>> aerogear-dev mailing list >>>>> aerogear-dev at lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140128/0c7cfa34/attachment-0001.html From supittma at redhat.com Tue Jan 28 13:22:40 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 28 Jan 2014 13:22:40 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> <5DCEB5A8-1942-4C0C-8C0E-3DFCB5521C0B@redhat.com> <52E7D475.6060208@redhat.com> Message-ID: <52E7F570.7040101@redhat.com> On 01/28/2014 11:11 AM, Corinne Krych wrote: > I think we still need the synchronisation mode in pull mode. > > How are we going to deal with this use case with simple push: > UserA is offline update some data, then switch off his phone > Some other users update data > UserA open his app, he has missed some push notifications but still > want to sync his app. That is the magic of Push systems. He gets the messages when he comes online. Device A and B and Server have data with a checksum of 42. Device A goes offline. Device A changes its data and has a checksum of 64. Device B changes its data and has a checksum of 192. Device B sends the expected server checksum of 42 and its new data to the server. Server accepts B's Data, updates its checksum to 192, and sends a message to all Devices ( in this case just A) Device B and Server go on a long date, but things don't work out and they end up splitting the check 50/50. Device B is annoyed because she only got a salad but Server got the Surf and Turf. Device A comes online and receives a message from the server. Device A notices the server's checksum data is a change from 42 -> 192 and not 42 -> 64. Thus its copy is out of sync and fires a message to the User of Device A to resolve the data. User A resolves the data and Device A sends the merged data to the server. Device B gets a message of new data and updates to what the server has. > > ++ > Corinne > > > On 28 January 2014 17:01, Summers Pittman > wrote: > > On 01/28/2014 10:58 AM, Lucas Holmquist wrote: > > On Jan 28, 2014, at 10:54 AM, Summers Pittman > > wrote: > > > >> On 01/28/2014 10:48 AM, Lucas Holmquist wrote: > >>> On Jan 28, 2014, at 10:30 AM, Summers Pittman > > wrote: > >>> > >>>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: > >>>>> yup, this is another Data Sync thread, > >>>>> > >>>>>> From a client side perspective, i have concerns that there > is still not a clear direction yet. > >>>>> I know there are multiple ideas floating around on what our > model should be, i'm all for choice, but what about deciding on 1 > model to get started with. Then later once we have this nailed > down, we can have other "adapters" with different models perhaps > >>>> All the data model is is an envelope of sync metadata around > an object > >>>> right? > >>> right > >>> > >>>> We also need to think about the API and server/client > protocol as well. > >>>> > >>>> I think that for sync 1.0 we could focus on the following > behavior (it > >>>> worked for my demos at least) > >>>> > >>>> 1. We have a Sync factory similar to Pipeline, Authenticator, > >>>> Registrar, and KeyService. > >>>> 2. The Sync factory consumes/manages Synchronizer instances. > >>>> 3. AG Synchronizer listens for sync messages using > UnifiedPush endpoints. > >>> i thought for a 1.0 we weren't thinking about "realtime" > >> When I hear realtime I think sub 100 ms updates to all clients. > (think > >> gaming) > >> > >> What I thought we were going for was something closer to email. > The > >> data gets changed and at some point in the future the client > knows. More > >> specifically, the thing the ONE thing that makes sync special > is it is a > >> push instead of poll implementation. > > this makes sense, but i guess it would be push when available. > thinking web and crappy web socket support( dang you carriers ) > Right. I'm not saying lets do something complicated. I'm saying lets > use GCM, iOS CM, and simple push to send notifications to tell the > client something. In simplePush case it is "this data changed, > get the > new stuff and update yourself". In Android and iOS case it may be > that > or it may be "here is new data". > > In general, I am fine for getting a message saying something like > Documents/Schedules/1/${revision}. Then I can check my revisions, > fetch > data if necessary, update my local data, and send any updates. That > SHOULD (I think) be doable with simplepush as well right? > > > > >>>> 4. AG Synchronizer sends sync messages using Pipes > >>>> 5. AG Synchronizer holds local data in a store > >>>> > >>>> 6. When AGSynchronizer gets a message it is responsible for > updating > >>>> the Store and then notifying code listing for updates OR for > notifying > >>>> the code that an error has occurred and needs to be addressed. > >>>> > >>>> 7. When the developer updates data in the store, the > synchronizer > >>>> should package that data and send it to the server. The > synchronizer is > >>>> responsible for error handling, retrying, back-off, etc. > >>>> > >>>> 8. We should include multiple synchronizer implementations > to deal with > >>>> multiple very simple use cases which involve legacy systems. (For > >>>> instance polling to load static data on a schedule.) > >>>> > >>>> Thoughts? Tomatoes? > >>>>> > >>>>> _______________________________________________ > >>>>> 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140128/4efb07f9/attachment.html From lholmqui at redhat.com Tue Jan 28 13:22:42 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 28 Jan 2014 13:22:42 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <20140128180746.GE20528@rohan.local> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <20140128180746.GE20528@rohan.local> Message-ID: <42219F44-0687-4FFB-B044-16F17A31EC21@redhat.com> when i was looking at pouchDB, they do long polling, only if you set the "continuous" flag. On Jan 28, 2014, at 1:07 PM, Douglas Campos wrote: > On Tue, Jan 28, 2014 at 10:48:14AM -0500, Lucas Holmquist wrote: >> >> On Jan 28, 2014, at 10:30 AM, Summers Pittman wrote: >> >>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >>> 3. AG Synchronizer listens for sync messages using UnifiedPush endpoints. >> i thought for a 1.0 we weren't thinking about "realtime" > > Yep, and I'm still against realtime for 1.0 > > > -- > qmx > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From qmx at qmx.me Tue Jan 28 13:24:00 2014 From: qmx at qmx.me (Douglas Campos) Date: Tue, 28 Jan 2014 16:24:00 -0200 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <52E7CD27.2060206@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> Message-ID: <20140128182400.GG20528@rohan.local> On Tue, Jan 28, 2014 at 10:30:47AM -0500, Summers Pittman wrote: > On 01/28/2014 09:36 AM, Lucas Holmquist wrote: > > yup, this is another Data Sync thread, > > > > >From a client side perspective, i have concerns that there is still not a clear direction yet. > > > > I know there are multiple ideas floating around on what our model should be, i'm all for choice, but what about deciding on 1 model to get started with. Then later once we have this nailed down, we can have other "adapters" with different models perhaps > All the data model is is an envelope of sync metadata around an object > right? > > We also need to think about the API and server/client protocol as well. > > I think that for sync 1.0 we could focus on the following behavior (it > worked for my demos at least) > > 1. We have a Sync factory similar to Pipeline, Authenticator, > Registrar, and KeyService. > 2. The Sync factory consumes/manages Synchronizer instances. > 3. AG Synchronizer listens for sync messages using UnifiedPush endpoints. > 4. AG Synchronizer sends sync messages using Pipes > 5. AG Synchronizer holds local data in a store > > 6. When AGSynchronizer gets a message it is responsible for updating > the Store and then notifying code listing for updates OR for notifying > the code that an error has occurred and needs to be addressed. > > 7. When the developer updates data in the store, the synchronizer > should package that data and send it to the server. The synchronizer is > responsible for error handling, retrying, back-off, etc. > > 8. We should include multiple synchronizer implementations to deal with > multiple very simple use cases which involve legacy systems. (For > instance polling to load static data on a schedule.) The thing I have against all this is its curse and its blessing at the same time. I prefer to ship small-ish tools that the developer can use the way she wants instead of a full-blown-zomg-unicorns full-stack solution. Even the pipeline API requires some level of buy-in, and I really wish our DataSync API to be as decoupled as possible from the other parts. This was my main concern when I was saying: "focus on the datamodel first, then the update protocol, then...." If we start with a fully integrated solution, it will be awesome, if we have buy-in from the developer. And we all know that things not necessarily go this way with OSS projects, hence my kerfuffle against increasing sync's scope for 1.0. What's the MVP for the sync to be a good foundation for all the shiny bits? That's the question I want to have a good answer for. > > Thoughts? Tomatoes? > > > > > > > > _______________________________________________ > > 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 -- qmx From bsutter at redhat.com Tue Jan 28 13:25:47 2014 From: bsutter at redhat.com (Burr Sutter) Date: Tue, 28 Jan 2014 13:25:47 -0500 Subject: [aerogear-dev] Aerogear Cordova Push Plugin Message-ID: <31CB8979-F7A8-4A93-BBB6-1FFE309368DE@redhat.com> https://github.com/aerogear/aerogear-pushplugin-cordova/ My project/notes in the readme.md - it could be that I have missed a step, so I tried to describe my steps carefully in the readme, everything from the command line right now - I will attempt JBoss Tools once the command line steps seem to work. https://github.com/burrsutter/hellopush I have also tested with https://github.com/edewit/aerogear-pushplugin-cordova/tree/agdroid-195 It only works on Android 4.3, funny enough that was the first device I tried - perhaps there is some "affinity" for a single device? :-) It fails on: Android 2.3.4 Android 4.4.2 (two different devices) iOS 6.1.5 iOS 7.0.4 Let's define "fail": - the app always deploys but... - the additional devices never register a device token in the UPS console. I assume I will see "instances" for the various devices - in the case of iOS, the deviceready does not even fire correctly - in the case of Android (all versions), the onError handler is called with "no value for pushconfig" - including the 4.3 where things do work. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140128/768cdfee/attachment-0001.html From lholmqui at redhat.com Tue Jan 28 13:28:54 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 28 Jan 2014 13:28:54 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <20140128182400.GG20528@rohan.local> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <20140128182400.GG20528@rohan.local> Message-ID: <3F6E0977-B64B-494E-BA7A-726081ED83D2@redhat.com> On Jan 28, 2014, at 1:24 PM, Douglas Campos wrote: > On Tue, Jan 28, 2014 at 10:30:47AM -0500, Summers Pittman wrote: >> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >>> yup, this is another Data Sync thread, >>> >>>> From a client side perspective, i have concerns that there is still not a clear direction yet. >>> >>> I know there are multiple ideas floating around on what our model should be, i'm all for choice, but what about deciding on 1 model to get started with. Then later once we have this nailed down, we can have other "adapters" with different models perhaps >> All the data model is is an envelope of sync metadata around an object >> right? >> >> We also need to think about the API and server/client protocol as well. >> >> I think that for sync 1.0 we could focus on the following behavior (it >> worked for my demos at least) >> >> 1. We have a Sync factory similar to Pipeline, Authenticator, >> Registrar, and KeyService. >> 2. The Sync factory consumes/manages Synchronizer instances. >> 3. AG Synchronizer listens for sync messages using UnifiedPush endpoints. >> 4. AG Synchronizer sends sync messages using Pipes >> 5. AG Synchronizer holds local data in a store >> >> 6. When AGSynchronizer gets a message it is responsible for updating >> the Store and then notifying code listing for updates OR for notifying >> the code that an error has occurred and needs to be addressed. >> >> 7. When the developer updates data in the store, the synchronizer >> should package that data and send it to the server. The synchronizer is >> responsible for error handling, retrying, back-off, etc. >> >> 8. We should include multiple synchronizer implementations to deal with >> multiple very simple use cases which involve legacy systems. (For >> instance polling to load static data on a schedule.) > > The thing I have against all this is its curse and its blessing at the > same time. I prefer to ship small-ish tools that the developer can use > the way she wants instead of a full-blown-zomg-unicorns full-stack > solution. > > Even the pipeline API requires some level of buy-in, and I really wish > our DataSync API to be as decoupled as possible from the other parts. my initial stab at the JS lib for data sync had no dependency on the other parts, ( expect for maybe Notifier ) the idea is to be able to have the "sync" lib, "mixin" with DataManager, > > This was my main concern when I was saying: "focus on the datamodel > first, then the update protocol, then...." > > If we start with a fully integrated solution, it will be awesome, if we > have buy-in from the developer. And we all know that things not > necessarily go this way with OSS projects, hence my kerfuffle against > increasing sync's scope for 1.0. > > What's the MVP for the sync to be a good foundation for all the shiny > bits? That's the question I want to have a good answer for. > >> >> Thoughts? Tomatoes? >>> >>> >>> >>> _______________________________________________ >>> 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 > > -- > qmx > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From supittma at redhat.com Tue Jan 28 13:32:42 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 28 Jan 2014 13:32:42 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <20140128182400.GG20528@rohan.local> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <20140128182400.GG20528@rohan.local> Message-ID: <52E7F7CA.8060504@redhat.com> On 01/28/2014 01:24 PM, Douglas Campos wrote: > On Tue, Jan 28, 2014 at 10:30:47AM -0500, Summers Pittman wrote: >> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >>> yup, this is another Data Sync thread, >>> >>> >From a client side perspective, i have concerns that there is still not a clear direction yet. >>> >>> I know there are multiple ideas floating around on what our model should be, i'm all for choice, but what about deciding on 1 model to get started with. Then later once we have this nailed down, we can have other "adapters" with different models perhaps >> All the data model is is an envelope of sync metadata around an object >> right? >> >> We also need to think about the API and server/client protocol as well. >> >> I think that for sync 1.0 we could focus on the following behavior (it >> worked for my demos at least) >> >> 1. We have a Sync factory similar to Pipeline, Authenticator, >> Registrar, and KeyService. >> 2. The Sync factory consumes/manages Synchronizer instances. >> 3. AG Synchronizer listens for sync messages using UnifiedPush endpoints. >> 4. AG Synchronizer sends sync messages using Pipes >> 5. AG Synchronizer holds local data in a store >> >> 6. When AGSynchronizer gets a message it is responsible for updating >> the Store and then notifying code listing for updates OR for notifying >> the code that an error has occurred and needs to be addressed. >> >> 7. When the developer updates data in the store, the synchronizer >> should package that data and send it to the server. The synchronizer is >> responsible for error handling, retrying, back-off, etc. >> >> 8. We should include multiple synchronizer implementations to deal with >> multiple very simple use cases which involve legacy systems. (For >> instance polling to load static data on a schedule.) > The thing I have against all this is its curse and its blessing at the > same time. I prefer to ship small-ish tools that the developer can use > the way she wants instead of a full-blown-zomg-unicorns full-stack > solution. > > Even the pipeline API requires some level of buy-in, and I really wish > our DataSync API to be as decoupled as possible from the other parts. > > This was my main concern when I was saying: "focus on the datamodel > first, then the update protocol, then...." > > If we start with a fully integrated solution, it will be awesome, if we > have buy-in from the developer. And we all know that things not > necessarily go this way with OSS projects, hence my kerfuffle against > increasing sync's scope for 1.0. > > What's the MVP for the sync to be a good foundation for all the shiny > bits? That's the question I want to have a good answer for. I shifting into Java speak here for a second because it is easier for me. What I want as a MVP is a good Interface for the bit of sychronization the developer will interact with. Everything else is an implementation detail that we can write and rewrite until the checks stop cashing :) The data model is one part of this, it is how the code which implements the Interface will see its own data and also what it will send to the server. The how of that is whatever. It can use a pipe, it can send the data over a websocket. Both are easily done. The next implementation detail is how does remote data get on the device? Does the server send via a websocket updated data (again based on our data model enveolope), does it send a ping message (via a push service) and the client pulls down new data? Does the client poll? It doesn't matter as long as our public interfaces can be forced to do all of them in a non insane way. I think we are saying the same thing, at least I didn't hear you say anything that made me say "wat?!". >> Thoughts? Tomatoes? >>> >>> >>> _______________________________________________ >>> 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 Jan 28 13:36:32 2014 From: supittma at redhat.com (Summers Pittman) Date: Tue, 28 Jan 2014 13:36:32 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <3F6E0977-B64B-494E-BA7A-726081ED83D2@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <20140128182400.GG20528@rohan.local> <3F6E0977-B64B-494E-BA7A-726081ED83D2@redhat.com> Message-ID: <52E7F8B0.60300@redhat.com> On 01/28/2014 01:28 PM, Lucas Holmquist wrote: > On Jan 28, 2014, at 1:24 PM, Douglas Campos wrote: > >> On Tue, Jan 28, 2014 at 10:30:47AM -0500, Summers Pittman wrote: >>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >>>> yup, this is another Data Sync thread, >>>> >>>>> From a client side perspective, i have concerns that there is still not a clear direction yet. >>>> I know there are multiple ideas floating around on what our model should be, i'm all for choice, but what about deciding on 1 model to get started with. Then later once we have this nailed down, we can have other "adapters" with different models perhaps >>> All the data model is is an envelope of sync metadata around an object >>> right? >>> >>> We also need to think about the API and server/client protocol as well. >>> >>> I think that for sync 1.0 we could focus on the following behavior (it >>> worked for my demos at least) >>> >>> 1. We have a Sync factory similar to Pipeline, Authenticator, >>> Registrar, and KeyService. >>> 2. The Sync factory consumes/manages Synchronizer instances. >>> 3. AG Synchronizer listens for sync messages using UnifiedPush endpoints. >>> 4. AG Synchronizer sends sync messages using Pipes >>> 5. AG Synchronizer holds local data in a store >>> >>> 6. When AGSynchronizer gets a message it is responsible for updating >>> the Store and then notifying code listing for updates OR for notifying >>> the code that an error has occurred and needs to be addressed. >>> >>> 7. When the developer updates data in the store, the synchronizer >>> should package that data and send it to the server. The synchronizer is >>> responsible for error handling, retrying, back-off, etc. >>> >>> 8. We should include multiple synchronizer implementations to deal with >>> multiple very simple use cases which involve legacy systems. (For >>> instance polling to load static data on a schedule.) >> The thing I have against all this is its curse and its blessing at the >> same time. I prefer to ship small-ish tools that the developer can use >> the way she wants instead of a full-blown-zomg-unicorns full-stack >> solution. >> >> Even the pipeline API requires some level of buy-in, and I really wish >> our DataSync API to be as decoupled as possible from the other parts. > my initial stab at the JS lib for data sync had no dependency on the other parts, ( expect for maybe Notifier ) > > the idea is to be able to have the "sync" lib, "mixin" with DataManager, My initial stab for the Android impl was to make the user write as little code to handle "boring things". Boring things are: Is there new remote data? Did the local data change? What local Data changed? Is there a conflict between the incoming remote data and the local data? Sending new local data to the server. This is a little bit of all of our tech and it works together pretty well. > > > >> This was my main concern when I was saying: "focus on the datamodel >> first, then the update protocol, then...." >> >> If we start with a fully integrated solution, it will be awesome, if we >> have buy-in from the developer. And we all know that things not >> necessarily go this way with OSS projects, hence my kerfuffle against >> increasing sync's scope for 1.0. >> >> What's the MVP for the sync to be a good foundation for all the shiny >> bits? That's the question I want to have a good answer for. >> >>> Thoughts? Tomatoes? >>>> >>>> >>>> _______________________________________________ >>>> 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 >> -- >> qmx >> _______________________________________________ >> 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 Tue Jan 28 13:54:53 2014 From: daniel at passos.me (Daniel Passos) Date: Tue, 28 Jan 2014 16:54:53 -0200 Subject: [aerogear-dev] bower repos for custom builds In-Reply-To: <5C428201-CC94-4B1C-AC87-7D47B7C70832@gmail.com> References: <8B1AE989-453D-456E-8911-D1E4F31084D1@redhat.com> <5C428201-CC94-4B1C-AC87-7D47B7C70832@gmail.com> Message-ID: +1 --? Daniel Passos On January 28, 2014 at 12:54:08 PM, S?bastien Blanc (scm.blanc at gmail.com) wrote: +9001 Envoy? de mon iPhone Le Jan 28, 2014 ? 20:10, Lucas Holmquist a ?crit?: so i created this JIRA?https://issues.jboss.org/browse/AGJS-133 It would kind of neat if we offered some custom builds in bower, this way it could make it super easy for someone to pull in just data manager for example $ bower install aerogear-datamanager each "custom" build would be in it's own repo, ?but they don;t have to be "aerogear" repos, ?similar to how the bower ember repo isn't actually an ember official repo wdyt? would be somewhat easier to get "new" features out without waiting on the official release _______________________________________________ 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/20140128/1162d7e0/attachment.html From bruno at abstractj.org Tue Jan 28 14:03:04 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 28 Jan 2014 17:03:04 -0200 Subject: [aerogear-dev] bower repos for custom builds In-Reply-To: References: <8B1AE989-453D-456E-8911-D1E4F31084D1@redhat.com> <5C428201-CC94-4B1C-AC87-7D47B7C70832@gmail.com> Message-ID: Go for it -- abstractj On January 28, 2014 at 4:55:05 PM, Daniel Passos (daniel at passos.me) wrote: > > so i created this JIRA https://issues.jboss.org/browse/AGJS-133 > > It would kind of neat if we offered some custom builds in bower, > > this way it could make it super easy for someone to pull in just > data manager for example > > $ bower install aerogear-datamanager > > each "custom" build would be in it's own repo, but they don;t have > to be "aerogear" repos, similar to how the bower ember repo isn't > actually an ember official repo > > wdyt? > > would be somewhat easier to get "new" features out without waiting > on the official release From qmx at qmx.me Tue Jan 28 14:08:52 2014 From: qmx at qmx.me (Douglas Campos) Date: Tue, 28 Jan 2014 17:08:52 -0200 Subject: [aerogear-dev] bower repos for custom builds In-Reply-To: <8B1AE989-453D-456E-8911-D1E4F31084D1@redhat.com> References: <8B1AE989-453D-456E-8911-D1E4F31084D1@redhat.com> Message-ID: <20140128190852.GH20528@rohan.local> On Tue, Jan 28, 2014 at 09:40:47AM -0500, Lucas Holmquist wrote: > so i created this JIRA https://issues.jboss.org/browse/AGJS-133 > > It would kind of neat if we offered some custom builds in bower, > > this way it could make it super easy for someone to pull in just data > manager for example > > $ bower install aerogear-datamanager > > each "custom" build would be in it's own repo, but they don;t have to > be "aerogear" repos, similar to how the bower ember repo isn't > actually an ember official repo > > wdyt? > > would be somewhat easier to get "new" features out without waiting on > the official release Thought we were doing it this way already, +1 -- qmx From jbalunas at redhat.com Tue Jan 28 14:28:39 2014 From: jbalunas at redhat.com (Jay Balunas) Date: Tue, 28 Jan 2014 14:28:39 -0500 Subject: [aerogear-dev] Browser Targets In-Reply-To: <92FEC0F0-7359-4B49-8AC9-3BCD18D8D3B5@redhat.com> References: <79E19B64-A584-4821-A1BA-EA3B49E08344@redhat.com> <9682E781-175D-4BD7-A193-1593509416D8@redhat.com> <92FEC0F0-7359-4B49-8AC9-3BCD18D8D3B5@redhat.com> Message-ID: <60E1BF91-B017-4703-AED6-3D205B6D0BE8@redhat.com> On Jan 20, 2014, at 11:39 AM, Lucas Holmquist wrote: > following up from the team meeting, here is the current link to our Browser targets > > http://aerogear.org/docs/guides/AeroGearBrowserTargets/ > > when this was created, i think it was very early on in the project. Agreed, even the title is browser specific, and should be changed to something like "AeroGear Support Matrix" or something like that. > > the desktop browsers are probably ok at this point, ( i would like to remove IE9, though ). +1 on dropping IE9 > > Mobile Browsers i think can be revamped a little, Mobile Safari should probably be 6 and 7 > > we can probably add in Chrome for Android and FireFox for Android Perhaps this could be listed as "should" work? at least for now? > > > WRT the other platforms, i think there is a JIRA to create a Matrix +1 on getting this matrix decided and posted. It will help us and QE know what needs to be tested. > > On Jan 8, 2014, at 5:28 AM, Erik Jan de Wit wrote: > >>> >>> on this same topic, what % should we be looking at when thinking about dropping support for other platforms, like android and iOS >> >> Don?t think we should have a hard (written in stone) rule, but try and to be pragmatic about what we support. >> >> Because if 10% would be the limit for browsers we could drop IE support all together ;) >> _______________________________________________ >> 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/20140128/84c54aae/attachment.html From lholmqui at redhat.com Tue Jan 28 14:13:05 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Tue, 28 Jan 2014 14:13:05 -0500 Subject: [aerogear-dev] bower repos for custom builds In-Reply-To: <20140128190852.GH20528@rohan.local> References: <8B1AE989-453D-456E-8911-D1E4F31084D1@redhat.com> <20140128190852.GH20528@rohan.local> Message-ID: On Jan 28, 2014, at 2:08 PM, Douglas Campos wrote: > On Tue, Jan 28, 2014 at 09:40:47AM -0500, Lucas Holmquist wrote: >> so i created this JIRA https://issues.jboss.org/browse/AGJS-133 >> >> It would kind of neat if we offered some custom builds in bower, >> >> this way it could make it super easy for someone to pull in just data >> manager for example >> >> $ bower install aerogear-datamanager >> >> each "custom" build would be in it's own repo, but they don;t have to >> be "aerogear" repos, similar to how the bower ember repo isn't >> actually an ember official repo >> >> wdyt? >> >> would be somewhat easier to get "new" features out without waiting on >> the official release > > Thought we were doing it this way already, +1 at the moment we only have "official releases", but it would be interesting to have the "development release" also available since these are really just tags > > -- > qmx > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From qmx at qmx.me Tue Jan 28 14:41:29 2014 From: qmx at qmx.me (Douglas Campos) Date: Tue, 28 Jan 2014 17:41:29 -0200 Subject: [aerogear-dev] Browser Targets In-Reply-To: <60E1BF91-B017-4703-AED6-3D205B6D0BE8@redhat.com> References: <79E19B64-A584-4821-A1BA-EA3B49E08344@redhat.com> <9682E781-175D-4BD7-A193-1593509416D8@redhat.com> <92FEC0F0-7359-4B49-8AC9-3BCD18D8D3B5@redhat.com> <60E1BF91-B017-4703-AED6-3D205B6D0BE8@redhat.com> Message-ID: <20140128194129.GJ20528@rohan.local> On Tue, Jan 28, 2014 at 02:28:39PM -0500, Jay Balunas wrote: > > On Jan 20, 2014, at 11:39 AM, Lucas Holmquist wrote: > > > following up from the team meeting, here is the current link to our Browser targets > > > > http://aerogear.org/docs/guides/AeroGearBrowserTargets/ > > > > when this was created, i think it was very early on in the project. > > Agreed, even the title is browser specific, and should be changed to > something like "AeroGear Support Matrix" or something like that. +1 > > > > > the desktop browsers are probably ok at this point, ( i would like > > to remove IE9, though ). > > +1 on dropping IE9 yay! > > > > > Mobile Browsers i think can be revamped a little, Mobile Safari should probably be 6 and 7 > > > > we can probably add in Chrome for Android and FireFox for Android > > Perhaps this could be listed as "should" work? at least for now? > > > > > > > WRT the other platforms, i think there is a JIRA to create a Matrix > > +1 on getting this matrix decided and posted. It will help us and QE know what needs to be tested. > > > > > On Jan 8, 2014, at 5:28 AM, Erik Jan de Wit wrote: > > > >>> > >>> on this same topic, what % should we be looking at when thinking about dropping support for other platforms, like android and iOS > >> > >> Don?t think we should have a hard (written in stone) rule, but try and to be pragmatic about what we support. > >> > >> Because if 10% would be the limit for browsers we could drop IE support all together ;) > >> _______________________________________________ > >> 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 -- qmx From bsutter at redhat.com Tue Jan 28 18:05:52 2014 From: bsutter at redhat.com (Burr Sutter) Date: Tue, 28 Jan 2014 18:05:52 -0500 Subject: [aerogear-dev] Aerogear Cordova Push Plugin In-Reply-To: <31CB8979-F7A8-4A93-BBB6-1FFE309368DE@redhat.com> References: <31CB8979-F7A8-4A93-BBB6-1FFE309368DE@redhat.com> Message-ID: OK, the real gotcha was... https://issues.jboss.org/browse/AGPUSH-525 There were some smaller issues: - I found the readme.md to be inaccurate - the video is incomplete http://www.youtube.com/watch?v=a7QVWfEkSpc i watched it several times last week, pausing, trying to tease out the commands needed to replicate the experience - I believe iOS also requires the console plugin be installed - as device ready was failing due to the console.log the sample app contains. - Hand editing the config.xml to provide the App Name and package/bundleID I wanted did not seem to "stick" - I was better off using the command line like so: cordova create hellopush com.burrsutter.hellopush "Hello Push" instead cordova create hellopush and editing the config.xml that was generated on Android 2.3, the app loads but blows up on launch https://issues.jboss.org/browse/AGPUSH-526 And there is inconsistency between iOS and Android https://issues.jboss.org/browse/AGPUSH-527 And can we "hide" the older UPS docs that focus on curl and bring the ones that focus on the web UI to the foreground? For instance, at the bottom of this page: http://aerogear.org/docs/guides/aerogear-push-android/google-setup/ it links to the curl version - curl is great, but more of an advanced topic this is the doc that needs more link love http://aerogear.org/docs/guides/AdminConsoleGuide/ I attempted to document the complete set of steps in my readme.txt https://github.com/burrsutter/hellopush I suspect I forgot something along the way On Jan 28, 2014, at 1:25 PM, Burr Sutter wrote: > https://github.com/aerogear/aerogear-pushplugin-cordova/ > My project/notes in the readme.md - it could be that I have missed a step, so I tried to describe my steps carefully in the readme, everything from the command line right now - I will attempt JBoss Tools once the command line steps seem to work. > https://github.com/burrsutter/hellopush > > I have also tested with > https://github.com/edewit/aerogear-pushplugin-cordova/tree/agdroid-195 > > It only works on Android 4.3, funny enough that was the first device I tried - perhaps there is some "affinity" for a single device? :-) > > It fails on: > Android 2.3.4 > Android 4.4.2 (two different devices) > iOS 6.1.5 > iOS 7.0.4 > > Let's define "fail": > - the app always deploys but... > - the additional devices never register a device token in the UPS console. I assume I will see "instances" for the various devices > - in the case of iOS, the deviceready does not even fire correctly > - in the case of Android (all versions), the onError handler is called with "no value for pushconfig" - including the 4.3 where things do work. > > > > _______________________________________________ > 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/20140128/2166b61a/attachment.html From bruno at abstractj.org Tue Jan 28 19:49:20 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Tue, 28 Jan 2014 22:49:20 -0200 Subject: [aerogear-dev] Aerogear Cordova Push Plugin In-Reply-To: References: <31CB8979-F7A8-4A93-BBB6-1FFE309368DE@redhat.com> Message-ID: As always, patches are very welcome. > On Jan 28, 2014, at 9:05 PM, Burr Sutter wrote: > > There were some smaller issues: > - I found the readme.md to be inaccurate From matzew at apache.org Wed Jan 29 03:03:20 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 29 Jan 2014 09:03:20 +0100 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <52E7F570.7040101@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> <5DCEB5A8-1942-4C0C-8C0E-3DFCB5521C0B@redhat.com> <52E7D475.6060208@redhat.com> <52E7F570.7040101@redhat.com> Message-ID: On Tue, Jan 28, 2014 at 7:22 PM, Summers Pittman wrote: > On 01/28/2014 11:11 AM, Corinne Krych wrote: > > I think we still need the synchronisation mode in pull mode. > > How are we going to deal with this use case with simple push: > UserA is offline update some data, then switch off his phone > Some other users update data > UserA open his app, he has missed some push notifications but still want > to sync his app. > > That is the magic of Push systems. He gets the messages when he comes > online. > > Device A and B and Server have data with a checksum of 42. > Device A goes offline. > Device A changes its data and has a checksum of 64. > Device B changes its data and has a checksum of 192. > Device B sends the expected server checksum of 42 and its new data to the > server. > Server accepts B's Data, updates its checksum to 192, and sends a message > to all Devices ( in this case just A) > sending the data does not work via 'mobile push' - we need something like 'real-time' for that sending; > > Device B and Server go on a long date, but things don't work out and they > end up splitting the check 50/50. Device B is annoyed because she only got > a salad but Server got the Surf and Turf. > > Device A comes online and receives a message from the server. > Device A notices the server's checksum data is a change from 42 -> 192 and > not 42 -> 64. Thus its copy is out of sync and fires a message to the User > of Device A to resolve the data. > User A resolves the data and Device A sends the merged data to the server. > Device B gets a message of new data and updates to what the server has. > > > > ++ > Corinne > > > On 28 January 2014 17:01, Summers Pittman wrote: > >> On 01/28/2014 10:58 AM, Lucas Holmquist wrote: >> > On Jan 28, 2014, at 10:54 AM, Summers Pittman >> wrote: >> > >> >> On 01/28/2014 10:48 AM, Lucas Holmquist wrote: >> >>> On Jan 28, 2014, at 10:30 AM, Summers Pittman >> wrote: >> >>> >> >>>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >> >>>>> yup, this is another Data Sync thread, >> >>>>> >> >>>>>> From a client side perspective, i have concerns that there is >> still not a clear direction yet. >> >>>>> I know there are multiple ideas floating around on what our model >> should be, i'm all for choice, but what about deciding on 1 model to get >> started with. Then later once we have this nailed down, we can have other >> "adapters" with different models perhaps >> >>>> All the data model is is an envelope of sync metadata around an >> object >> >>>> right? >> >>> right >> >>> >> >>>> We also need to think about the API and server/client protocol as >> well. >> >>>> >> >>>> I think that for sync 1.0 we could focus on the following behavior >> (it >> >>>> worked for my demos at least) >> >>>> >> >>>> 1. We have a Sync factory similar to Pipeline, Authenticator, >> >>>> Registrar, and KeyService. >> >>>> 2. The Sync factory consumes/manages Synchronizer instances. >> >>>> 3. AG Synchronizer listens for sync messages using UnifiedPush >> endpoints. >> >>> i thought for a 1.0 we weren't thinking about "realtime" >> >> When I hear realtime I think sub 100 ms updates to all clients. (think >> >> gaming) >> >> >> >> What I thought we were going for was something closer to email. The >> >> data gets changed and at some point in the future the client knows. >> More >> >> specifically, the thing the ONE thing that makes sync special is it is >> a >> >> push instead of poll implementation. >> > this makes sense, but i guess it would be push when available. >> thinking web and crappy web socket support( dang you carriers ) >> Right. I'm not saying lets do something complicated. I'm saying lets >> use GCM, iOS CM, and simple push to send notifications to tell the >> client something. In simplePush case it is "this data changed, get the >> new stuff and update yourself". In Android and iOS case it may be that >> or it may be "here is new data". >> >> In general, I am fine for getting a message saying something like >> Documents/Schedules/1/${revision}. Then I can check my revisions, fetch >> data if necessary, update my local data, and send any updates. That >> SHOULD (I think) be doable with simplepush as well right? >> >> > >> >>>> 4. AG Synchronizer sends sync messages using Pipes >> >>>> 5. AG Synchronizer holds local data in a store >> >>>> >> >>>> 6. When AGSynchronizer gets a message it is responsible for updating >> >>>> the Store and then notifying code listing for updates OR for >> notifying >> >>>> the code that an error has occurred and needs to be addressed. >> >>>> >> >>>> 7. When the developer updates data in the store, the synchronizer >> >>>> should package that data and send it to the server. The >> synchronizer is >> >>>> responsible for error handling, retrying, back-off, etc. >> >>>> >> >>>> 8. We should include multiple synchronizer implementations to deal >> with >> >>>> multiple very simple use cases which involve legacy systems. (For >> >>>> instance polling to load static data on a schedule.) >> >>>> >> >>>> Thoughts? Tomatoes? >> >>>>> >> >>>>> _______________________________________________ >> >>>>> 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 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 > -- 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/20140129/514395ef/attachment-0001.html From matzew at apache.org Wed Jan 29 03:08:56 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 29 Jan 2014 09:08:56 +0100 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <20140128182400.GG20528@rohan.local> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <20140128182400.GG20528@rohan.local> Message-ID: On Tue, Jan 28, 2014 at 7:24 PM, Douglas Campos wrote: > On Tue, Jan 28, 2014 at 10:30:47AM -0500, Summers Pittman wrote: > > On 01/28/2014 09:36 AM, Lucas Holmquist wrote: > > > yup, this is another Data Sync thread, > > > > > > >From a client side perspective, i have concerns that there is still > not a clear direction yet. > > > > > > I know there are multiple ideas floating around on what our model > should be, i'm all for choice, but what about deciding on 1 model to get > started with. Then later once we have this nailed down, we can have other > "adapters" with different models perhaps > > All the data model is is an envelope of sync metadata around an object > > right? > > > > We also need to think about the API and server/client protocol as well. > > > > I think that for sync 1.0 we could focus on the following behavior (it > > worked for my demos at least) > > > > 1. We have a Sync factory similar to Pipeline, Authenticator, > > Registrar, and KeyService. > > 2. The Sync factory consumes/manages Synchronizer instances. > > 3. AG Synchronizer listens for sync messages using UnifiedPush > endpoints. > > 4. AG Synchronizer sends sync messages using Pipes > > 5. AG Synchronizer holds local data in a store > > > > 6. When AGSynchronizer gets a message it is responsible for updating > > the Store and then notifying code listing for updates OR for notifying > > the code that an error has occurred and needs to be addressed. > > > > 7. When the developer updates data in the store, the synchronizer > > should package that data and send it to the server. The synchronizer is > > responsible for error handling, retrying, back-off, etc. > > > > 8. We should include multiple synchronizer implementations to deal with > > multiple very simple use cases which involve legacy systems. (For > > instance polling to load static data on a schedule.) > > The thing I have against all this is its curse and its blessing at the > same time. I prefer to ship small-ish tools that the developer can use > the way she wants instead of a full-blown-zomg-unicorns full-stack > solution. > > Even the pipeline API requires some level of buy-in, and I really wish > our DataSync API to be as decoupled as possible from the other parts. > I agree on the decoupling. That's pretty much what the iOS lib does today: Only dependency is AFNetworking; The JS bits are similar, nothing is weaved into the existing APIs there as well > This was my main concern when I was saying: "focus on the datamodel > first, then the update protocol, then...." > I think we somewhat agreed already on a document based model, now it looks like several POCs are build to integrate w/ our sync-server bits > > If we start with a fully integrated solution, it will be awesome, if we > have buy-in from the developer. And we all know that things not > necessarily go this way with OSS projects, hence my kerfuffle against > increasing sync's scope for 1.0. > So, what will the scope be? And will there be a 1.0 ? I am not really sure that we will have a 1.0.0 in the next few month. -Matthias > What's the MVP for the sync to be a good foundation for all the shiny > bits? That's the question I want to have a good answer for. > > > > > Thoughts? Tomatoes? > > > > > > > > > > > > _______________________________________________ > > > 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 > > -- > qmx > _______________________________________________ > 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/20140129/d0c6c68b/attachment.html From matzew at apache.org Wed Jan 29 03:11:03 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 29 Jan 2014 09:11:03 +0100 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <52E7F7CA.8060504@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <20140128182400.GG20528@rohan.local> <52E7F7CA.8060504@redhat.com> Message-ID: On Tue, Jan 28, 2014 at 7:32 PM, Summers Pittman wrote: > On 01/28/2014 01:24 PM, Douglas Campos wrote: > > On Tue, Jan 28, 2014 at 10:30:47AM -0500, Summers Pittman wrote: > >> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: > >>> yup, this is another Data Sync thread, > >>> > >>> >From a client side perspective, i have concerns that there is still > not a clear direction yet. > >>> > >>> I know there are multiple ideas floating around on what our model > should be, i'm all for choice, but what about deciding on 1 model to get > started with. Then later once we have this nailed down, we can have other > "adapters" with different models perhaps > >> All the data model is is an envelope of sync metadata around an object > >> right? > >> > >> We also need to think about the API and server/client protocol as well. > >> > >> I think that for sync 1.0 we could focus on the following behavior (it > >> worked for my demos at least) > >> > >> 1. We have a Sync factory similar to Pipeline, Authenticator, > >> Registrar, and KeyService. > >> 2. The Sync factory consumes/manages Synchronizer instances. > >> 3. AG Synchronizer listens for sync messages using UnifiedPush > endpoints. > >> 4. AG Synchronizer sends sync messages using Pipes > >> 5. AG Synchronizer holds local data in a store > >> > >> 6. When AGSynchronizer gets a message it is responsible for updating > >> the Store and then notifying code listing for updates OR for notifying > >> the code that an error has occurred and needs to be addressed. > >> > >> 7. When the developer updates data in the store, the synchronizer > >> should package that data and send it to the server. The synchronizer is > >> responsible for error handling, retrying, back-off, etc. > >> > >> 8. We should include multiple synchronizer implementations to deal with > >> multiple very simple use cases which involve legacy systems. (For > >> instance polling to load static data on a schedule.) > > The thing I have against all this is its curse and its blessing at the > > same time. I prefer to ship small-ish tools that the developer can use > > the way she wants instead of a full-blown-zomg-unicorns full-stack > > solution. > > > > Even the pipeline API requires some level of buy-in, and I really wish > > our DataSync API to be as decoupled as possible from the other parts. > > > > This was my main concern when I was saying: "focus on the datamodel > > first, then the update protocol, then...." > > > > If we start with a fully integrated solution, it will be awesome, if we > > have buy-in from the developer. And we all know that things not > > necessarily go this way with OSS projects, hence my kerfuffle against > > increasing sync's scope for 1.0. > > > > What's the MVP for the sync to be a good foundation for all the shiny > > bits? That's the question I want to have a good answer for. > I shifting into Java speak here for a second because it is easier for me. > > What I want as a MVP is a good Interface for the bit of sychronization > the developer will interact with. Everything else is an implementation > detail that we can write and rewrite until the checks stop cashing :) > > The data model is one part of this, it is how the code which implements > the Interface will see its own data and also what it will send to the > server. > > The how of that is whatever. It can use a pipe, it can send the data > over a websocket. Both are easily done. > > The next implementation detail is how does remote data get on the > device? Does the server send via a websocket updated data (again based > on our data model enveolope), does it send a ping message (via a push > service) and the client pulls down new data? Does the client poll? It > doesn't matter as long as our public interfaces can be forced to do all > of them in a non insane way. > I think we all agree that we need some 'interface' like that and that the actual details are good hidden by the actual implementation > > I think we are saying the same thing, at least I didn't hear you say > anything that made me say "wat?!". > > > >> Thoughts? Tomatoes? > >>> > >>> > >>> _______________________________________________ > >>> 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 > -- 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/20140129/ddd10696/attachment.html From fabrice.matrat at gmail.com Wed Jan 29 03:23:32 2014 From: fabrice.matrat at gmail.com (Fabrice Matrat) Date: Wed, 29 Jan 2014 09:23:32 +0100 Subject: [aerogear-dev] Conflicts & Reconciliation Message-ID: Hi AeroGear team, Mattias pinged me on twitter on Monday on the topic of Synchronization following a presentation[1] I gave at nodejsconf [2]. I think it's important to separate concerns, here's a gist to sum up my ideas [3]. I've read the mailing, speak with Corinne and looked at your different poc and I have a couple of questions: Do you guys want to develop a fully integrated solution? Is it a requirements to never touch the business server? or do you want to develop a set of libraries that can be integrated within the business server? I'd love to get more involved, this is a great area of interest. More to come soon. Cheers, Fabrice [1] http://mathbruyen.github.io/nodejsconfit2014 [2] http://nodejsconf.it/ [3] https://gist.github.com/fabricematrat/8666682 -- Best regards, http://rivieragug.org/ http://3musket33rs.github.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140129/b13da091/attachment-0001.html From supittma at redhat.com Wed Jan 29 03:31:02 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 29 Jan 2014 03:31:02 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> <5DCEB5A8-1942-4C0C-8C0E-3DFCB5521C0B@redhat.com> <52E7D475.6060208@redhat.com> <52E7F570.7040101@redhat.com> Message-ID: <52E8BC46.4030006@redhat.com> On 01/29/2014 03:03 AM, Matthias Wessendorf wrote: > > > > On Tue, Jan 28, 2014 at 7:22 PM, Summers Pittman > wrote: > > On 01/28/2014 11:11 AM, Corinne Krych wrote: >> I think we still need the synchronisation mode in pull mode. >> >> How are we going to deal with this use case with simple push: >> UserA is offline update some data, then switch off his phone >> Some other users update data >> UserA open his app, he has missed some push notifications but >> still want to sync his app. > That is the magic of Push systems. He gets the messages when he > comes online. > > Device A and B and Server have data with a checksum of 42. > Device A goes offline. > Device A changes its data and has a checksum of 64. > Device B changes its data and has a checksum of 192. > Device B sends the expected server checksum of 42 and its new data > to the server. > Server accepts B's Data, updates its checksum to 192, and sends a > message to all Devices ( in this case just A) > > > sending the data does not work via 'mobile push' - we need something > like 'real-time' for that sending; Well it does work with GCM. In this example I was specifically thinking about using a Pipe to send data. Honestly that is an implementation detail and can be hand waved in any number of ways. > > > Device B and Server go on a long date, but things don't work out > and they end up splitting the check 50/50. Device B is annoyed > because she only got a salad but Server got the Surf and Turf. > > Device A comes online and receives a message from the server. > Device A notices the server's checksum data is a change from 42 -> > 192 and not 42 -> 64. Thus its copy is out of sync and fires a > message to the User of Device A to resolve the data. > User A resolves the data and Device A sends the merged data to the > server. > Device B gets a message of new data and updates to what the server > has. > > >> >> ++ >> Corinne >> >> >> On 28 January 2014 17:01, Summers Pittman > > wrote: >> >> On 01/28/2014 10:58 AM, Lucas Holmquist wrote: >> > On Jan 28, 2014, at 10:54 AM, Summers Pittman >> > wrote: >> > >> >> On 01/28/2014 10:48 AM, Lucas Holmquist wrote: >> >>> On Jan 28, 2014, at 10:30 AM, Summers Pittman >> > wrote: >> >>> >> >>>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >> >>>>> yup, this is another Data Sync thread, >> >>>>> >> >>>>>> From a client side perspective, i have concerns that >> there is still not a clear direction yet. >> >>>>> I know there are multiple ideas floating around on what >> our model should be, i'm all for choice, but what about >> deciding on 1 model to get started with. Then later once we >> have this nailed down, we can have other "adapters" with >> different models perhaps >> >>>> All the data model is is an envelope of sync metadata >> around an object >> >>>> right? >> >>> right >> >>> >> >>>> We also need to think about the API and server/client >> protocol as well. >> >>>> >> >>>> I think that for sync 1.0 we could focus on the >> following behavior (it >> >>>> worked for my demos at least) >> >>>> >> >>>> 1. We have a Sync factory similar to Pipeline, >> Authenticator, >> >>>> Registrar, and KeyService. >> >>>> 2. The Sync factory consumes/manages Synchronizer >> instances. >> >>>> 3. AG Synchronizer listens for sync messages using >> UnifiedPush endpoints. >> >>> i thought for a 1.0 we weren't thinking about "realtime" >> >> When I hear realtime I think sub 100 ms updates to all >> clients. (think >> >> gaming) >> >> >> >> What I thought we were going for was something closer to >> email. The >> >> data gets changed and at some point in the future the >> client knows. More >> >> specifically, the thing the ONE thing that makes sync >> special is it is a >> >> push instead of poll implementation. >> > this makes sense, but i guess it would be push when >> available. thinking web and crappy web socket support( dang >> you carriers ) >> Right. I'm not saying lets do something complicated. I'm >> saying lets >> use GCM, iOS CM, and simple push to send notifications to >> tell the >> client something. In simplePush case it is "this data >> changed, get the >> new stuff and update yourself". In Android and iOS case it >> may be that >> or it may be "here is new data". >> >> In general, I am fine for getting a message saying something like >> Documents/Schedules/1/${revision}. Then I can check my >> revisions, fetch >> data if necessary, update my local data, and send any >> updates. That >> SHOULD (I think) be doable with simplepush as well right? >> >> > >> >>>> 4. AG Synchronizer sends sync messages using Pipes >> >>>> 5. AG Synchronizer holds local data in a store >> >>>> >> >>>> 6. When AGSynchronizer gets a message it is responsible >> for updating >> >>>> the Store and then notifying code listing for updates OR >> for notifying >> >>>> the code that an error has occurred and needs to be >> addressed. >> >>>> >> >>>> 7. When the developer updates data in the store, the >> synchronizer >> >>>> should package that data and send it to the server. The >> synchronizer is >> >>>> responsible for error handling, retrying, back-off, etc. >> >>>> >> >>>> 8. We should include multiple synchronizer >> implementations to deal with >> >>>> multiple very simple use cases which involve legacy >> systems. (For >> >>>> instance polling to load static data on a schedule.) >> >>>> >> >>>> Thoughts? Tomatoes? >> >>>>> >> >>>>> _______________________________________________ >> >>>>> 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 > > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140129/4d3d9ace/attachment-0001.html From supittma at redhat.com Wed Jan 29 03:33:43 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 29 Jan 2014 03:33:43 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <20140128182400.GG20528@rohan.local> Message-ID: <52E8BCE7.4000807@redhat.com> On 01/29/2014 03:08 AM, Matthias Wessendorf wrote: > > > > On Tue, Jan 28, 2014 at 7:24 PM, Douglas Campos > wrote: > > On Tue, Jan 28, 2014 at 10:30:47AM -0500, Summers Pittman wrote: > > On 01/28/2014 09:36 AM, Lucas Holmquist wrote: > > > yup, this is another Data Sync thread, > > > > > > >From a client side perspective, i have concerns that there is > still not a clear direction yet. > > > > > > I know there are multiple ideas floating around on what our > model should be, i'm all for choice, but what about deciding on 1 > model to get started with. Then later once we have this nailed > down, we can have other "adapters" with different models perhaps > > All the data model is is an envelope of sync metadata around an > object > > right? > > > > We also need to think about the API and server/client protocol > as well. > > > > I think that for sync 1.0 we could focus on the following > behavior (it > > worked for my demos at least) > > > > 1. We have a Sync factory similar to Pipeline, Authenticator, > > Registrar, and KeyService. > > 2. The Sync factory consumes/manages Synchronizer instances. > > 3. AG Synchronizer listens for sync messages using UnifiedPush > endpoints. > > 4. AG Synchronizer sends sync messages using Pipes > > 5. AG Synchronizer holds local data in a store > > > > 6. When AGSynchronizer gets a message it is responsible for > updating > > the Store and then notifying code listing for updates OR for > notifying > > the code that an error has occurred and needs to be addressed. > > > > 7. When the developer updates data in the store, the synchronizer > > should package that data and send it to the server. The > synchronizer is > > responsible for error handling, retrying, back-off, etc. > > > > 8. We should include multiple synchronizer implementations to > deal with > > multiple very simple use cases which involve legacy systems. (For > > instance polling to load static data on a schedule.) > > The thing I have against all this is its curse and its blessing at the > same time. I prefer to ship small-ish tools that the developer can use > the way she wants instead of a full-blown-zomg-unicorns full-stack > solution. > > Even the pipeline API requires some level of buy-in, and I really wish > our DataSync API to be as decoupled as possible from the other parts. > > > I agree on the decoupling. That's pretty much what the iOS lib does > today: Only dependency is AFNetworking; > The JS bits are similar, nothing is weaved into the existing APIs > there as well > > This was my main concern when I was saying: "focus on the datamodel > first, then the update protocol, then...." > > > I think we somewhat agreed already on a document based model, now it > looks like several POCs are build to integrate w/ our sync-server bits Just out of curiosity, what other models are there? [Also I think it will be better to say metadata + object model instead of document. Document is 1) very generic and 2) has very different definitions depending on what we are thinking] > > > If we start with a fully integrated solution, it will be awesome, > if we > have buy-in from the developer. And we all know that things not > necessarily go this way with OSS projects, hence my kerfuffle against > increasing sync's scope for 1.0. > > > > So, what will the scope be? And will there be a 1.0 ? ^^ This. One of the things we have been failing at doing (and failing hard) is defining a scope for sync. > I am not really sure that we will have a 1.0.0 in the next few month. > > -Matthias > > > What's the MVP for the sync to be a good foundation for all the shiny > bits? That's the question I want to have a good answer for. > > > > > Thoughts? Tomatoes? > > > > > > > > > > > > _______________________________________________ > > > 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 > > -- > qmx > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140129/2e0bcca8/attachment.html From matzew at apache.org Wed Jan 29 03:49:30 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 29 Jan 2014 09:49:30 +0100 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <52E8BCE7.4000807@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <20140128182400.GG20528@rohan.local> <52E8BCE7.4000807@redhat.com> Message-ID: On Wed, Jan 29, 2014 at 9:33 AM, Summers Pittman wrote: > On 01/29/2014 03:08 AM, Matthias Wessendorf wrote: > > > > > On Tue, Jan 28, 2014 at 7:24 PM, Douglas Campos wrote: > >> On Tue, Jan 28, 2014 at 10:30:47AM -0500, Summers Pittman wrote: >> > On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >> > > yup, this is another Data Sync thread, >> > > >> > > >From a client side perspective, i have concerns that there is still >> not a clear direction yet. >> > > >> > > I know there are multiple ideas floating around on what our model >> should be, i'm all for choice, but what about deciding on 1 model to get >> started with. Then later once we have this nailed down, we can have other >> "adapters" with different models perhaps >> > All the data model is is an envelope of sync metadata around an object >> > right? >> > >> > We also need to think about the API and server/client protocol as well. >> > >> > I think that for sync 1.0 we could focus on the following behavior (it >> > worked for my demos at least) >> > >> > 1. We have a Sync factory similar to Pipeline, Authenticator, >> > Registrar, and KeyService. >> > 2. The Sync factory consumes/manages Synchronizer instances. >> > 3. AG Synchronizer listens for sync messages using UnifiedPush >> endpoints. >> > 4. AG Synchronizer sends sync messages using Pipes >> > 5. AG Synchronizer holds local data in a store >> > >> > 6. When AGSynchronizer gets a message it is responsible for updating >> > the Store and then notifying code listing for updates OR for notifying >> > the code that an error has occurred and needs to be addressed. >> > >> > 7. When the developer updates data in the store, the synchronizer >> > should package that data and send it to the server. The synchronizer is >> > responsible for error handling, retrying, back-off, etc. >> > >> > 8. We should include multiple synchronizer implementations to deal with >> > multiple very simple use cases which involve legacy systems. (For >> > instance polling to load static data on a schedule.) >> >> The thing I have against all this is its curse and its blessing at the >> same time. I prefer to ship small-ish tools that the developer can use >> the way she wants instead of a full-blown-zomg-unicorns full-stack >> solution. >> >> Even the pipeline API requires some level of buy-in, and I really wish >> our DataSync API to be as decoupled as possible from the other parts. >> > > I agree on the decoupling. That's pretty much what the iOS lib does > today: Only dependency is AFNetworking; > The JS bits are similar, nothing is weaved into the existing APIs there as > well > > > >> This was my main concern when I was saying: "focus on the datamodel >> first, then the update protocol, then...." >> > > I think we somewhat agreed already on a document based model, now it > looks like several POCs are build to integrate w/ our sync-server bits > > Just out of curiosity, what other models are there? > some here, JPA integration: https://github.com/edewit/sync-server/blob/master/src/main/java/org/jboss/aerogear/poc/Car.java#L15 > [Also I think it will be better to say metadata + object model instead of > document. Document is 1) very generic and 2) has very different > definitions depending on what we are thinking] > Agree on "metadata + object model" > > > > >> >> If we start with a fully integrated solution, it will be awesome, if we >> have buy-in from the developer. And we all know that things not >> necessarily go this way with OSS projects, hence my kerfuffle against >> increasing sync's scope for 1.0. >> > > > So, what will the scope be? And will there be a 1.0 ? > > ^^ This. One of the things we have been failing at doing (and failing > hard) is defining a scope for sync. > > I am not really sure that we will have a 1.0.0 in the next few month. > > -Matthias > > >> What's the MVP for the sync to be a good foundation for all the shiny >> bits? That's the question I want to have a good answer for. >> >> > >> > Thoughts? Tomatoes? >> > > >> > > >> > > >> > > _______________________________________________ >> > > 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 >> >> -- >> qmx >> _______________________________________________ >> 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 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 > -- 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/20140129/91d0d79c/attachment-0001.html From matzew at apache.org Wed Jan 29 04:04:12 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 29 Jan 2014 10:04:12 +0100 Subject: [aerogear-dev] Conflicts & Reconciliation In-Reply-To: References: Message-ID: Hello Fabrice! On Wed, Jan 29, 2014 at 9:23 AM, Fabrice Matrat wrote: > Hi AeroGear team, > > Mattias pinged me on twitter on Monday on the topic of Synchronization > following a presentation[1] I gave at nodejsconf [2]. > yes! great slides, hence I reached out ( https://twitter.com/fabricematrat/status/427734199781449728) > I think it's important to separate concerns, here's a gist to sum up my > ideas [3]. > Interesting read and a solid list of good items around the topic; Will read it again before replying on the content of the gist; > I've read the mailing, speak with Corinne and looked at your different poc > and I have a couple of questions: > > Do you guys want to develop a fully integrated solution? > hrm, I think eventually, several month down the road, the answer would be yes. For now: I guess... well, "nope" to "it depends" > Is it a requirements to never touch the business server? or do you want to > develop a set of libraries that can be integrated within the business > server? > these are good questions. I like the couch-driven approach of our server, as it can be plugged in on the side. While Erik's POC is great for JavaEE users, offering a simple way to 'integrate' w/ current applications. > I'd love to get more involved, this is a great area of interest. More to > come soon. > we are happy to here more > Cheers, > > Fabrice > > [1] http://mathbruyen.github.io/nodejsconfit2014 > > [2] http://nodejsconf.it/ > > [3] https://gist.github.com/fabricematrat/8666682 > > -- > Best regards, > > http://rivieragug.org/ > http://3musket33rs.github.com/ > > _______________________________________________ > 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/20140129/f365e4df/attachment.html From avibelli at redhat.com Wed Jan 29 04:34:37 2014 From: avibelli at redhat.com (Andrea Vibelli) Date: Wed, 29 Jan 2014 04:34:37 -0500 (EST) Subject: [aerogear-dev] Upgrading process for the OpenShift AeroGear UPS cartridge In-Reply-To: <1552758754.12035565.1390929053020.JavaMail.root@redhat.com> References: <676075311.5431814.1390843624382.JavaMail.root@redhat.com> <2099059360.11646680.1390846051314.JavaMail.root@redhat.com> <1403896808.11718517.1390858087208.JavaMail.root@redhat.com> <2034992562.5686126.1390898762650.JavaMail.root@redhat.com> <830585923.11958735.1390921396801.JavaMail.root@redhat.com> <1552758754.12035565.1390929053020.JavaMail.root@redhat.com> Message-ID: <59183402.6125947.1390988077765.JavaMail.root@redhat.com> Hi Farah, great, the steps are really neat now. One last minor observation: the manifest.yml file for both the 0.8.1 and the 0.9.1 instances contains version 0.8.0 and 0.9.0. Thanks! Andrea ----- Messaggio originale ----- > Da: "Farah Juma" > A: aerogear-dev at lists.jboss.org, "Andrea Vibelli" > Inviato: Marted?, 28 gennaio 2014 18:10:53 > Oggetto: Re: [aerogear-dev] Upgrading process for the OpenShift AeroGear UPS cartridge > > I've created the following gist that contains our updated list of steps for > upgrading the cartridge: > > https://gist.github.com/fjuma/499827d650465a1a8f5a > > > Farah > > ----- Original Message ----- > > From: "Farah Juma" > > To: aerogear-dev at lists.jboss.org > > Cc: "Andrea Vibelli" > > Sent: Tuesday, January 28, 2014 10:03:16 AM > > Subject: Re: [aerogear-dev] Upgrading process for the OpenShift AeroGear > > UPS cartridge > > > > > > > From: "Andrea Vibelli" > > > To: "Farah Juma" > > > Cc: aerogear-dev at lists.jboss.org > > > Sent: Tuesday, January 28, 2014 3:46:02 AM > > > Subject: Re: Re: [aerogear-dev] Upgrading process for the OpenShift > > > AeroGear UPS cartridge > > > > > > Hi Farah, > > > yes I do use FireFox. > > > > > > I have done the tests once again, and closing and reopening the browser > > > solved my issue, great, nice catch! > > > > Great, I'm glad that's working for you now! > > > > > Maybe we could also include this additional step in the overall > > > instructions, > > > what do you think? > > > > Yes, that's a good idea. I'm going to create a gist with our updated steps > > and post it here when done to get more feedback. > > > > Thanks, > > Farah > > > > > > > Thank you > > > Andrea > > > > > > ----- Messaggio originale ----- > > > > Da: "Farah Juma" > > > > A: "Andrea Vibelli" , aerogear-dev at lists.jboss.org > > > > Inviato: Luned?, 27 gennaio 2014 22:28:07 > > > > Oggetto: Re: [aerogear-dev] Upgrading process for the OpenShift > > > > AeroGear > > > > UPS cartridge > > > > > > > > After some more digging, I think I might know what's going on here. > > > > Andrea, > > > > are you using Firefox? I wasn't able to reproduce the issue with Chrome > > > > but > > > > was able to reproduce it just now with Firefox. The underlying issue > > > > seems > > > > to be that Firefox tends to save 301 redirects until you close it and > > > > re-open it. Note that when you delete an OpenShift instance and > > > > re-create > > > > it, its IP address changes. When accessing http://app-namespace.rhcloud > > > > after re-creating the instance, you'll actually be redirected to > > > > https://app-namespace.rhcloud/app. However, when using Firefox, this > > > > URL > > > > seems to get mapped to the old IP address resulting in this error: 'The > > > > requested URL /app was not found on this server.' After deleting and > > > > re-creating an OpenShift instance with the same name, if you restart > > > > Firefox, you should once again be able to access the application. I've > > > > verified that this does work. > > > > > > > > Similar issues with Firefox were actually mentioned in some OpenShift > > > > forum > > > > posts as well: > > > > > > > > https://www.openshift.com/forums/openshift/httpawm-pribylrhcloudcom-the-requested-url-was-not-found-on-this-server#comment-33570 > > > > https://www.openshift.com/forums/openshift/custom-domain-httpwwwxxxxxxxcom-is-redirecting-to-httpswwwxxxxxxxcomapp#comment-34215 > > > > > > > > > > > > Farah > > > > > > > > ----- Original Message ----- > > > > > From: "Farah Juma" > > > > > To: aerogear-dev at lists.jboss.org > > > > > Sent: Monday, January 27, 2014 1:07:31 PM > > > > > Subject: Re: [aerogear-dev] Upgrading process for the OpenShift > > > > > AeroGear > > > > > ????????UPS????????cartridge > > > > > > > > > > > > > > > > From: "Andrea Vibelli" > > > > > > To: aerogear-dev at lists.jboss.org > > > > > > Sent: Monday, January 27, 2014 12:27:04 PM > > > > > > Subject: [aerogear-dev] Upgrading process for the OpenShift > > > > > > AeroGear > > > > > > UPS > > > > > > ????????cartridge > > > > > > > > > > > > Hello all, > > > > > > > > > > > > I just wanted to let you know that Farah is working on AGPUSH-504, > > > > > > a > > > > > > snapshot/restore approach for upgrading the downloadable cartridge. > > > > > > The overall idea is to take a snapshot of the database (and other > > > > > > configuration) for an older existing cartridge instance, delete > > > > > > this > > > > > > old > > > > > > instance, and then create a new instance based on the latest > > > > > > cartridge > > > > > > version and restore the new instance's database (and other > > > > > > configuration) > > > > > > to > > > > > > the state in the snapshot. The new instance must have the same name > > > > > > as > > > > > > the > > > > > > old instance. The main thing that she needed to determine was what > > > > > > needed > > > > > > to > > > > > > be included in the snapshot that's not already part of the MySQL > > > > > > database. > > > > > > The SimplePush token key was one of these things (we generate this > > > > > > value > > > > > > when a cartridge instance is created and it is used by the server > > > > > > for > > > > > > encryption and decryption of endpoint URLs). The standalone.xml > > > > > > file > > > > > > also > > > > > > needed to be backed up just in case the user made any changes to > > > > > > it. > > > > > > (Creating a backup of this file allows users to manually merge back > > > > > > any > > > > > > changes they may have made.) > > > > > > > > > > > > The snapshot/restore action hooks she has created can be found in > > > > > > [1]. > > > > > > > > > > > > The steps she has been using to try upgrading from an 0.8.1 > > > > > > instance > > > > > > are > > > > > > listed below. It would be great if you could try out these steps as > > > > > > well. > > > > > > There's one important caveat though: because an 0.8.1 instance > > > > > > won't > > > > > > have > > > > > > the necessary snapshot hook, you'll need to manually perform some > > > > > > commands > > > > > > to save the necessary data (step 3 below). If we include these > > > > > > snapshot/restore action hooks in the 0.10.0 cartridge release, > > > > > > users > > > > > > will > > > > > > be > > > > > > able to make use of these hooks for future upgrades, e.g., for > > > > > > upgrading > > > > > > from 0.10.0 to 0.11.0. > > > > > > ? > > > > > > 1) Create an 0.8.1 cartridge instance > > > > > > rhc create-app mypush > > > > > > "https://cartreflect-claytondev.rhcloud.com/reflect?github=aerogear/openshift-origin-cartridge-aerogear-push&commit=8aada257de52157a837db23a9f7b1a8574fdffab" > > > > > > mysql-5.1 > > > > > > > > > > > > 2) Log into the admin console, change password, create push > > > > > > applications, > > > > > > create variants, send push notifications, etc. > > > > > > > > > > > > 3) ssh into your instance and perform these commands (this step > > > > > > manually > > > > > > captures needed data) > > > > > > echo "$OPENSHIFT_AEROGEAR_PUSH_TOKEN_KEY" > > > > > > > $OPENSHIFT_DATA_DIR/aerogear_push_token_key > > > > > > cp > > > > > > $OPENSHIFT_AEROGEAR_PUSH_DIR/standalone/configuration/standalone.xml > > > > > > $OPENSHIFT_DATA_DIR/standalone.snapshot.xml > > > > > > > > > > > > 4) Create a snapshot of the 0.8.1 instance: rhc snapshot save > > > > > > mypush > > > > > > > > > > > > 5) Delete the 0.8.1 instance: rhc app delete mypush > > > > > > > > > > > > 6) Delete the local directory on the local machine (from step 1, > > > > > > you > > > > > > should > > > > > > have a directory named 'mypush') > > > > > > > > > > > > 7) Create a new cartridge instance (this uses her fork of the 0.9.0 > > > > > > cartridge > > > > > > repository that contains the snapshot/restore action hooks) > > > > > > rhc create-app mypush > > > > > > "https://cartreflect-claytondev.rhcloud.com/reflect?github=fjuma/openshift-origin-cartridge-aerogear-push&commit=956a4fc09edc93fe76394b86b265ceb1d238ccaf" > > > > > > mysql-5.1 > > > > > > > > > > > > 8) Restore the instance: rhc snapshot restore mypush -f > > > > > > /PATH/TO/mypush.tar.gz > > > > > > > > > > > > 9) You should now be able to log into the admin console with the > > > > > > same > > > > > > password you previously set, see existing push applications, > > > > > > variants, > > > > > > send > > > > > > push notifications, etc. > > > > > > > > > > > > One disadvantage of this snapshot/restore approach is the extra > > > > > > work > > > > > > for > > > > > > the > > > > > > user. It would be nice to have a single command that can do the > > > > > > snapshot, > > > > > > delete, create, and restore all at once. She is going to start > > > > > > looking > > > > > > into > > > > > > this "wrappering" functionality. > > > > > > > > > > > > > > > > > > Why am I writing about this? > > > > > > > > > > > > I have made some test about the above steps. At a first glance, it > > > > > > seemed > > > > > > that something was broken between steps 6 and 7. > > > > > > Doing various tests, what I saw in the logs (server.log) were > > > > > > different > > > > > > errors: > > > > > > > > > > > > 2014/01/26 10:19:18,061 ERROR [org.jboss.as] (MSC service thread > > > > > > 1-3) > > > > > > JBAS015875: JBoss AS 7.1.1.Final "Brontes" started (with errors) in > > > > > > 296088ms > > > > > > - Started 349 of 524 services (52 services failed or missing > > > > > > dependencies, > > > > > > 119 services are passive or on-demand) > > > > > > 2014/01/26 10:19:18,344 INFO ?[org.jboss.as.server] > > > > > > (DeploymentScanner-threads - 2) JBAS015870: Deploy of deployment > > > > > > "ROOT.war" > > > > > > was rolled back with failure message {"JBAS014771: Services with > > > > > > missing/unavailable dependencies" => > > > > > > ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]} > > > > > > 2014/01/26 10:19:19,390 INFO ?[org.jboss.as.server.deployment] (MSC > > > > > > service > > > > > > thread 1-2) JBAS015877: Stopped deployment ROOT.war in 1125ms > > > > > > 2014/01/26 10:19:19,393 INFO ?[org.jboss.as.controller] > > > > > > (DeploymentScanner-threads - 2) JBAS014774: Service status report > > > > > > JBAS014775: ? ?New missing/unsatisfied dependencies: > > > > > > ? ? ? service jboss.naming.context.java.jboss.datasources.PushEEDS > > > > > > ? ? ? (missing) > > > > > > ? ? ? dependents: [service > > > > > > ? ? ? jboss.persistenceunit."ROOT.war#unifiedpush-default", service > > > > > > ? ? ? jboss.persistenceunit."ROOT.war#picketlink-default"] > > > > > > > > > > > > > > > > > > 2014/01/26 10:19:19,440 ERROR > > > > > > [org.jboss.as.server.deployment.scanner] > > > > > > (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation > > > > > > failed > > > > > > and > > > > > > was rolled back. Steps that failed:" => {"Operation step-2" => > > > > > > {"JBAS014771: > > > > > > Services with missing/unavailable dependencies" => > > > > > > ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]}}} > > > > > > > > > > > > > > > It looks like the MySQL cartridge either wasn't added or wasn't able > > > > > to > > > > > start > > > > > successfully. The following command can be used to check the status > > > > > of > > > > > the > > > > > MySQL cartridge: > > > > > > > > > > rhc cartridge status -a APP -c mysql > > > > > > > > > > ? > > > > > > OR > > > > > > > > > > > > > > > > > > 2014/01/26 05:41:46,522 INFO ?[org.jboss.as.connector] (MSC service > > > > > > thread > > > > > > 1-1) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar > > > > > > 1.0.9.Final) > > > > > > 2014/01/26 05:41:46,922 ERROR > > > > > > [org.jboss.as.controller.management-operation] > > > > > > (ServerService Thread Pool -- 62) Operation ("enable") failed - > > > > > > address: > > > > > > ([ > > > > > > ? ? ("subsystem" => "datasources"), > > > > > > ? ? ("data-source" => "PostgreSQLDS") > > > > > > ]) - failure description: "JBAS014802: Cannot resolve expression > > > > > > 'expression > > > > > > \"jdbcostgresql://${env.OPENSHIFT_POSTGRESQL_DB_HOST}:${env.OPENSHIFT_POSTGRESQL_DB_PORT}/mypush13\"' > > > > > > -- java.lang.IllegalStateException: Failed to resolve expression: > > > > > > ${env.OPENSHIFT_POSTGRESQL_DB_HOST}" > > > > > > > > > > > > > > > > > > OR > > > > > > > > > > > > > > > > > > no errors in the logs, but in the deployments directory I found > > > > > > 'ROOT.war.dodeploy' and 'ROOT.war.isdeploying' files, but no > > > > > > 'ROOT.war.deployed' file. > > > > > > > > > > > > > > > > > > Those error seemed to me as random and too strange (by the way, the > > > > > > creation > > > > > > of the cartridge is always correct, I never had problems if I > > > > > > created > > > > > > a > > > > > > new > > > > > > instance with a never used before name). > > > > > > > > > > > > To investigate further, I then tried to do the same steps with a > > > > > > completely > > > > > > different application: 'Kitchensink on OpenShift', and I had the > > > > > > same > > > > > > error! > > > > > > After the deletion and the recreation of a cartridge with a same > > > > > > name, > > > > > > I > > > > > > encountered: 'The requested URL /app was not found on this server.' > > > > > > The steps I have done are: > > > > > > 1) rhc app create -a kitchensink -t jbossas-7 --from-code > > > > > > git://github.com/openshift/kitchensink-example.git > > > > > > 2) rhc snapshot save kitchensink > > > > > > 3) rhc app delete kitchensink > > > > > > 4) rm -rf kitchensinkhtml5/ > > > > > > 5) rhc app create -a kitchensink -t jbossas-7 --from-code > > > > > > git://github.com/openshift/kitchensink-example.git > > > > > > 6) Access to the application. > > > > > > > > > > > > So the good news is that the error I encountered is not related to > > > > > > this > > > > > > specific AeroGear cartridges, but the bad news is that is something > > > > > > more > > > > > > general about OpenShift. > > > > > > We need to investigate further and find out if there is a way to > > > > > > "flush" > > > > > > the > > > > > > deletion, it seems that there is something appended or cached that > > > > > > prevent > > > > > > the recreation of a cartridge with a same name. > > > > > > > > > > It's good that the issue you're running into isn't specific to the > > > > > AeroGear > > > > > cartridge. I've tried quite a few times today but I'm not able to > > > > > reproduce > > > > > the issue with the AeroGear cartridge or with the kitchensink > > > > > application > > > > > using the above steps. I suspect that there is indeed an OpenShift > > > > > timing > > > > > issue here. Let's check with the OpenShift team on this. > > > > > > > > > > Farah > > > > > > > > > > > We are currently doing some more tests on these process. > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > 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 matzew at apache.org Wed Jan 29 05:17:40 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 29 Jan 2014 11:17:40 +0100 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: References: <1390738834902.6b58437e@Nodemailer> Message-ID: I have now rebased our branch ([1]) against our master and removed the AdminUI src inclusion; More updates will follow soon -Matthias [1] https://github.com/matzew/aerogear-unifiedpush-server/tree/keycloak On Sun, Jan 26, 2014 at 1:41 PM, Matthias Wessendorf wrote: > Hello Bruno, > > > On Sun, Jan 26, 2014 at 1:20 PM, Bruno Oliveira wrote: > >> Any specific reason to limit the scope to admin page only? I'm thinking >> about login for regular users > > > Not sure I follow. What do you mean w/ "regular users"? > > > Before my change very thing was restricted by Keycloak (/*). I did not > really change there a lot, however I just removed the URLs for > 'device-registration' and 'sending': > > https://github.com/matzew/aerogear-unifiedpush-server/blob/keycloak/src/main/webapp/WEB-INF/web.xml#L42-L50 > > So, currently the following is protected by Keycloak: > * Admin UI (not speaking about a specific admin user) > * REST APIs that are accessed by the Admin UI, like: > - http://aerogear.org/docs/specs/aerogear-push-rest/PushApplication/ > - http://aerogear.org/docs/specs/aerogear-push-rest/Variants/ > > Perviously the 'device-registration' and 'sending' URL were protected as > well. Removing them from the 'keycloak protection' is really the only change > > Greetings, > Matthias > > > >> -- >> abstractj >> >> >> On Sun, Jan 26, 2014 at 9:11 AM, Matthias Wessendorf wrote: >> >>> Hello! >>> >>> I have a few more updates: >>> >>> On my branch (a fork from Bruno's branch), the URLs for the actual >>> sending and the device-registration (both 'protected' via HTTP-Basic), now >>> work again. I have 'limited' the scope of the Keycloak 'protection' to the >>> AdminUI. >>> >>> Greetings, >>> Matthias >>> >>> >>> >>> On Fri, Jan 24, 2014 at 6:05 PM, Matthias Wessendorf wrote: >>> >>>> I have updated the branch w/ their recent changes from this weeks >>>> alpha-1 release, and submitted a PR against abstractj's repo: >>>> https://github.com/abstractj/aerogear-unifiedpush-server/pull/1 >>>> >>>> More to come >>>> >>>> Greetings, >>>> Matthias >>>> >>>> >>>> >>>> On Fri, Dec 20, 2013 at 1:11 PM, Bruno Oliveira wrote: >>>> >>>>> Good morning peeps, yesterday I started to replace AeroGear Security >>>>> on Unified Push server by Keycloak and you might be asking: "Why?". >>>>> Keycloak is a SSO with some handy features like TOTP, OAuth2, user >>>>> management support and I think we have too much to contribute, is the only >>>>> way to have some success with security, "divide to conquer" (at least for >>>>> authorization and authentication). >>>>> >>>>> So will ag-security be discontinued? No! Keycloak is still on Alpha >>>>> and we have to test it against our projects before fully replace >>>>> ag-security, but the only way to upstream our needs, is to using it. >>>>> >>>>> This replacement only applies to authentication/authorization >>>>> features, we still have a ton of projects which Keycloak is not able to >>>>> replace like: TOTP, crypto and OAuth2 on mobile, our focus. >>>>> >>>>> - PoC >>>>> >>>>> So let's talk about this replacement, any dependency on ag-security >>>>> was removed from the push server and replaced by Keycloak: >>>>> https://github.com/abstractj/aerogear-unifiedpush-server/tree/openshift >>>>> >>>>> Based on Keycloak examples, I just did copy & paste from one of the >>>>> demos (https://github.com/abstractj/auth-server/tree/openshift) to >>>>> create a server. Keycloak requires Resteasy 3.0.4, for this reason I had to >>>>> manually replace some modules on JBoss. >>>>> >>>>> To test it go to: http://push-abstractj.rhcloud.com/ag-push/ you must >>>>> be redirected to Keycloak, enter: >>>>> >>>>> username: john at doe.com >>>>> password: password >>>>> >>>>> You must be redirected to agpush console, keep in mind that I took >>>>> some shortcuts to get this demo working, so for example the create will >>>>> fail because I removed everything related into the ember interface. >>>>> >>>>> Is also possible to enable TOTP, user's registration and whatever you >>>>> want. >>>>> >>>>> So what do you think? >>>>> >>>>> -- >>>>> abstractj >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >>> >>> -- >>> 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 >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- 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/20140129/99422da4/attachment-0001.html From bruno at abstractj.org Wed Jan 29 07:43:11 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 29 Jan 2014 10:43:11 -0200 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> <5DCEB5A8-1942-4C0C-8C0E-3DFCB5521C0B@redhat.com> <52E7D475.6060208@redhat.com> <52E7F570.7040101@redhat.com> Message-ID: My 2 non technical cents, I really think we should separate "push" from "sync" and integrate later, bet on simple. In my opinion we are just adding one more level of complexity. For example: would be perfect to add digital signatures, encrypted data for that storage and all the sick things from security. But that would add an extra level of complexity which would lead us to several months of development. Is just my opinion, but if you guys think that we REALLY need Push, MVP or whatever atm, that's fine. On Wed, Jan 29, 2014 at 6:03 AM, Matthias Wessendorf wrote: > > > > On Tue, Jan 28, 2014 at 7:22 PM, Summers Pittman wrote: > >> On 01/28/2014 11:11 AM, Corinne Krych wrote: >> >> I think we still need the synchronisation mode in pull mode. >> >> How are we going to deal with this use case with simple push: >> UserA is offline update some data, then switch off his phone >> Some other users update data >> UserA open his app, he has missed some push notifications but still want >> to sync his app. >> >> That is the magic of Push systems. He gets the messages when he comes >> online. >> >> Device A and B and Server have data with a checksum of 42. >> Device A goes offline. >> Device A changes its data and has a checksum of 64. >> Device B changes its data and has a checksum of 192. >> Device B sends the expected server checksum of 42 and its new data to the >> server. >> Server accepts B's Data, updates its checksum to 192, and sends a message >> to all Devices ( in this case just A) >> > > sending the data does not work via 'mobile push' - we need something like > 'real-time' for that sending; > > >> >> Device B and Server go on a long date, but things don't work out and they >> end up splitting the check 50/50. Device B is annoyed because she only got >> a salad but Server got the Surf and Turf. >> >> Device A comes online and receives a message from the server. >> Device A notices the server's checksum data is a change from 42 -> 192 >> and not 42 -> 64. Thus its copy is out of sync and fires a message to the >> User of Device A to resolve the data. >> User A resolves the data and Device A sends the merged data to the server. >> Device B gets a message of new data and updates to what the server has. >> >> >> >> ++ >> Corinne >> >> >> On 28 January 2014 17:01, Summers Pittman wrote: >> >>> On 01/28/2014 10:58 AM, Lucas Holmquist wrote: >>> > On Jan 28, 2014, at 10:54 AM, Summers Pittman >>> wrote: >>> > >>> >> On 01/28/2014 10:48 AM, Lucas Holmquist wrote: >>> >>> On Jan 28, 2014, at 10:30 AM, Summers Pittman >>> wrote: >>> >>> >>> >>>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >>> >>>>> yup, this is another Data Sync thread, >>> >>>>> >>> >>>>>> From a client side perspective, i have concerns that there is >>> still not a clear direction yet. >>> >>>>> I know there are multiple ideas floating around on what our model >>> should be, i'm all for choice, but what about deciding on 1 model to get >>> started with. Then later once we have this nailed down, we can have other >>> "adapters" with different models perhaps >>> >>>> All the data model is is an envelope of sync metadata around an >>> object >>> >>>> right? >>> >>> right >>> >>> >>> >>>> We also need to think about the API and server/client protocol as >>> well. >>> >>>> >>> >>>> I think that for sync 1.0 we could focus on the following behavior >>> (it >>> >>>> worked for my demos at least) >>> >>>> >>> >>>> 1. We have a Sync factory similar to Pipeline, Authenticator, >>> >>>> Registrar, and KeyService. >>> >>>> 2. The Sync factory consumes/manages Synchronizer instances. >>> >>>> 3. AG Synchronizer listens for sync messages using UnifiedPush >>> endpoints. >>> >>> i thought for a 1.0 we weren't thinking about "realtime" >>> >> When I hear realtime I think sub 100 ms updates to all clients. (think >>> >> gaming) >>> >> >>> >> What I thought we were going for was something closer to email. The >>> >> data gets changed and at some point in the future the client knows. >>> More >>> >> specifically, the thing the ONE thing that makes sync special is it >>> is a >>> >> push instead of poll implementation. >>> > this makes sense, but i guess it would be push when available. >>> thinking web and crappy web socket support( dang you carriers ) >>> Right. I'm not saying lets do something complicated. I'm saying lets >>> use GCM, iOS CM, and simple push to send notifications to tell the >>> client something. In simplePush case it is "this data changed, get the >>> new stuff and update yourself". In Android and iOS case it may be that >>> or it may be "here is new data". >>> >>> In general, I am fine for getting a message saying something like >>> Documents/Schedules/1/${revision}. Then I can check my revisions, fetch >>> data if necessary, update my local data, and send any updates. That >>> SHOULD (I think) be doable with simplepush as well right? >>> >>> > >>> >>>> 4. AG Synchronizer sends sync messages using Pipes >>> >>>> 5. AG Synchronizer holds local data in a store >>> >>>> >>> >>>> 6. When AGSynchronizer gets a message it is responsible for >>> updating >>> >>>> the Store and then notifying code listing for updates OR for >>> notifying >>> >>>> the code that an error has occurred and needs to be addressed. >>> >>>> >>> >>>> 7. When the developer updates data in the store, the synchronizer >>> >>>> should package that data and send it to the server. The >>> synchronizer is >>> >>>> responsible for error handling, retrying, back-off, etc. >>> >>>> >>> >>>> 8. We should include multiple synchronizer implementations to deal >>> with >>> >>>> multiple very simple use cases which involve legacy systems. (For >>> >>>> instance polling to load static data on a schedule.) >>> >>>> >>> >>>> Thoughts? Tomatoes? >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> 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 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 >> > > > > -- > 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 > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140129/a4771992/attachment.html From matzew at apache.org Wed Jan 29 07:49:55 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 29 Jan 2014 13:49:55 +0100 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> <5DCEB5A8-1942-4C0C-8C0E-3DFCB5521C0B@redhat.com> <52E7D475.6060208@redhat.com> <52E7F570.7040101@redhat.com> Message-ID: On Wed, Jan 29, 2014 at 1:43 PM, Bruno Oliveira wrote: > My 2 non technical cents, I really think we should separate "push" from > "sync" and integrate later, bet on simple. In my opinion we are just > adding one more level of complexity. > > For example: would be perfect to add digital signatures, encrypted data > for that storage and all the sick things from security. But that would add > an extra level of complexity which would lead us to several months of > development. > +1 > > Is just my opinion, but if you guys think that we REALLY need Push, MVP or > whatever atm, that's fine. > > > On Wed, Jan 29, 2014 at 6:03 AM, Matthias Wessendorf wrote: > >> >> >> >> On Tue, Jan 28, 2014 at 7:22 PM, Summers Pittman wrote: >> >>> On 01/28/2014 11:11 AM, Corinne Krych wrote: >>> >>> I think we still need the synchronisation mode in pull mode. >>> >>> How are we going to deal with this use case with simple push: >>> UserA is offline update some data, then switch off his phone >>> Some other users update data >>> UserA open his app, he has missed some push notifications but still want >>> to sync his app. >>> >>> That is the magic of Push systems. He gets the messages when he comes >>> online. >>> >>> Device A and B and Server have data with a checksum of 42. >>> Device A goes offline. >>> Device A changes its data and has a checksum of 64. >>> Device B changes its data and has a checksum of 192. >>> Device B sends the expected server checksum of 42 and its new data to >>> the server. >>> Server accepts B's Data, updates its checksum to 192, and sends a >>> message to all Devices ( in this case just A) >>> >> >> sending the data does not work via 'mobile push' - we need something like >> 'real-time' for that sending; >> >> >>> >>> Device B and Server go on a long date, but things don't work out and >>> they end up splitting the check 50/50. Device B is annoyed because she >>> only got a salad but Server got the Surf and Turf. >>> >>> Device A comes online and receives a message from the server. >>> Device A notices the server's checksum data is a change from 42 -> 192 >>> and not 42 -> 64. Thus its copy is out of sync and fires a message to the >>> User of Device A to resolve the data. >>> User A resolves the data and Device A sends the merged data to the >>> server. >>> Device B gets a message of new data and updates to what the server has. >>> >>> >>> >>> ++ >>> Corinne >>> >>> >>> On 28 January 2014 17:01, Summers Pittman wrote: >>> >>>> On 01/28/2014 10:58 AM, Lucas Holmquist wrote: >>>> > On Jan 28, 2014, at 10:54 AM, Summers Pittman >>>> wrote: >>>> > >>>> >> On 01/28/2014 10:48 AM, Lucas Holmquist wrote: >>>> >>> On Jan 28, 2014, at 10:30 AM, Summers Pittman >>>> wrote: >>>> >>> >>>> >>>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >>>> >>>>> yup, this is another Data Sync thread, >>>> >>>>> >>>> >>>>>> From a client side perspective, i have concerns that there is >>>> still not a clear direction yet. >>>> >>>>> I know there are multiple ideas floating around on what our model >>>> should be, i'm all for choice, but what about deciding on 1 model to get >>>> started with. Then later once we have this nailed down, we can have other >>>> "adapters" with different models perhaps >>>> >>>> All the data model is is an envelope of sync metadata around an >>>> object >>>> >>>> right? >>>> >>> right >>>> >>> >>>> >>>> We also need to think about the API and server/client protocol as >>>> well. >>>> >>>> >>>> >>>> I think that for sync 1.0 we could focus on the following behavior >>>> (it >>>> >>>> worked for my demos at least) >>>> >>>> >>>> >>>> 1. We have a Sync factory similar to Pipeline, Authenticator, >>>> >>>> Registrar, and KeyService. >>>> >>>> 2. The Sync factory consumes/manages Synchronizer instances. >>>> >>>> 3. AG Synchronizer listens for sync messages using UnifiedPush >>>> endpoints. >>>> >>> i thought for a 1.0 we weren't thinking about "realtime" >>>> >> When I hear realtime I think sub 100 ms updates to all clients. >>>> (think >>>> >> gaming) >>>> >> >>>> >> What I thought we were going for was something closer to email. The >>>> >> data gets changed and at some point in the future the client knows. >>>> More >>>> >> specifically, the thing the ONE thing that makes sync special is it >>>> is a >>>> >> push instead of poll implementation. >>>> > this makes sense, but i guess it would be push when available. >>>> thinking web and crappy web socket support( dang you carriers ) >>>> Right. I'm not saying lets do something complicated. I'm saying lets >>>> use GCM, iOS CM, and simple push to send notifications to tell the >>>> client something. In simplePush case it is "this data changed, get the >>>> new stuff and update yourself". In Android and iOS case it may be that >>>> or it may be "here is new data". >>>> >>>> In general, I am fine for getting a message saying something like >>>> Documents/Schedules/1/${revision}. Then I can check my revisions, fetch >>>> data if necessary, update my local data, and send any updates. That >>>> SHOULD (I think) be doable with simplepush as well right? >>>> >>>> > >>>> >>>> 4. AG Synchronizer sends sync messages using Pipes >>>> >>>> 5. AG Synchronizer holds local data in a store >>>> >>>> >>>> >>>> 6. When AGSynchronizer gets a message it is responsible for >>>> updating >>>> >>>> the Store and then notifying code listing for updates OR for >>>> notifying >>>> >>>> the code that an error has occurred and needs to be addressed. >>>> >>>> >>>> >>>> 7. When the developer updates data in the store, the synchronizer >>>> >>>> should package that data and send it to the server. The >>>> synchronizer is >>>> >>>> responsible for error handling, retrying, back-off, etc. >>>> >>>> >>>> >>>> 8. We should include multiple synchronizer implementations to >>>> deal with >>>> >>>> multiple very simple use cases which involve legacy systems. (For >>>> >>>> instance polling to load static data on a schedule.) >>>> >>>> >>>> >>>> Thoughts? Tomatoes? >>>> >>>>> >>>> >>>>> _______________________________________________ >>>> >>>>> 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 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 >>> >> >> >> >> -- >> 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 >> > > > > -- > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > > _______________________________________________ > 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/20140129/61b35ffa/attachment-0001.html From supittma at redhat.com Wed Jan 29 09:14:20 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 29 Jan 2014 09:14:20 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> <5DCEB5A8-1942-4C0C-8C0E-3DFCB5521C0B@redhat.com> <52E7D475.6060208@redhat.com> <52E7F570.7040101@redhat.com> Message-ID: <52E90CBC.2020205@redhat.com> On 01/29/2014 07:43 AM, Bruno Oliveira wrote: > My 2 non technical cents, I really think we should separate "push" > from "sync" and integrate later, bet on simple. In my opinion we are > just adding one more level of complexity. > > For example: would be perfect to add digital signatures, encrypted > data for that storage and all the sick things from security. But that > would add an extra level of complexity which would lead us to several > months of development. > > Is just my opinion, but if you guys think that we REALLY need Push, > MVP or whatever atm, that's fine. Then what we are talking about is no longer sync. It is revision control. > > > On Wed, Jan 29, 2014 at 6:03 AM, Matthias Wessendorf > > wrote: > > > > > On Tue, Jan 28, 2014 at 7:22 PM, Summers Pittman > > wrote: > > On 01/28/2014 11:11 AM, Corinne Krych wrote: >> I think we still need the synchronisation mode in pull mode. >> >> How are we going to deal with this use case with simple push: >> UserA is offline update some data, then switch off his phone >> Some other users update data >> UserA open his app, he has missed some push notifications but >> still want to sync his app. > That is the magic of Push systems. He gets the messages when > he comes online. > > Device A and B and Server have data with a checksum of 42. > Device A goes offline. > Device A changes its data and has a checksum of 64. > Device B changes its data and has a checksum of 192. > Device B sends the expected server checksum of 42 and its new > data to the server. > Server accepts B's Data, updates its checksum to 192, and > sends a message to all Devices ( in this case just A) > > > sending the data does not work via 'mobile push' - we need > something like 'real-time' for that sending; > > > Device B and Server go on a long date, but things don't work > out and they end up splitting the check 50/50. Device B is > annoyed because she only got a salad but Server got the Surf > and Turf. > > Device A comes online and receives a message from the server. > Device A notices the server's checksum data is a change from > 42 -> 192 and not 42 -> 64. Thus its copy is out of sync and > fires a message to the User of Device A to resolve the data. > User A resolves the data and Device A sends the merged data to > the server. > Device B gets a message of new data and updates to what the > server has. > > >> >> ++ >> Corinne >> >> >> On 28 January 2014 17:01, Summers Pittman >> > wrote: >> >> On 01/28/2014 10:58 AM, Lucas Holmquist wrote: >> > On Jan 28, 2014, at 10:54 AM, Summers Pittman >> > wrote: >> > >> >> On 01/28/2014 10:48 AM, Lucas Holmquist wrote: >> >>> On Jan 28, 2014, at 10:30 AM, Summers Pittman >> > wrote: >> >>> >> >>>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >> >>>>> yup, this is another Data Sync thread, >> >>>>> >> >>>>>> From a client side perspective, i have concerns >> that there is still not a clear direction yet. >> >>>>> I know there are multiple ideas floating around on >> what our model should be, i'm all for choice, but what >> about deciding on 1 model to get started with. Then >> later once we have this nailed down, we can have other >> "adapters" with different models perhaps >> >>>> All the data model is is an envelope of sync >> metadata around an object >> >>>> right? >> >>> right >> >>> >> >>>> We also need to think about the API and >> server/client protocol as well. >> >>>> >> >>>> I think that for sync 1.0 we could focus on the >> following behavior (it >> >>>> worked for my demos at least) >> >>>> >> >>>> 1. We have a Sync factory similar to Pipeline, >> Authenticator, >> >>>> Registrar, and KeyService. >> >>>> 2. The Sync factory consumes/manages Synchronizer >> instances. >> >>>> 3. AG Synchronizer listens for sync messages using >> UnifiedPush endpoints. >> >>> i thought for a 1.0 we weren't thinking about "realtime" >> >> When I hear realtime I think sub 100 ms updates to all >> clients. (think >> >> gaming) >> >> >> >> What I thought we were going for was something closer >> to email. The >> >> data gets changed and at some point in the future the >> client knows. More >> >> specifically, the thing the ONE thing that makes sync >> special is it is a >> >> push instead of poll implementation. >> > this makes sense, but i guess it would be push when >> available. thinking web and crappy web socket support( >> dang you carriers ) >> Right. I'm not saying lets do something complicated. >> I'm saying lets >> use GCM, iOS CM, and simple push to send notifications to >> tell the >> client something. In simplePush case it is "this data >> changed, get the >> new stuff and update yourself". In Android and iOS case >> it may be that >> or it may be "here is new data". >> >> In general, I am fine for getting a message saying >> something like >> Documents/Schedules/1/${revision}. Then I can check my >> revisions, fetch >> data if necessary, update my local data, and send any >> updates. That >> SHOULD (I think) be doable with simplepush as well right? >> >> > >> >>>> 4. AG Synchronizer sends sync messages using Pipes >> >>>> 5. AG Synchronizer holds local data in a store >> >>>> >> >>>> 6. When AGSynchronizer gets a message it is >> responsible for updating >> >>>> the Store and then notifying code listing for >> updates OR for notifying >> >>>> the code that an error has occurred and needs to be >> addressed. >> >>>> >> >>>> 7. When the developer updates data in the store, >> the synchronizer >> >>>> should package that data and send it to the server. >> The synchronizer is >> >>>> responsible for error handling, retrying, back-off, etc. >> >>>> >> >>>> 8. We should include multiple synchronizer >> implementations to deal with >> >>>> multiple very simple use cases which involve legacy >> systems. (For >> >>>> instance polling to load static data on a schedule.) >> >>>> >> >>>> Thoughts? Tomatoes? >> >>>>> >> >>>>> _______________________________________________ >> >>>>> 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 > > > _______________________________________________ > 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 > > > > > -- > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > > > _______________________________________________ > 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/20140129/baeaab97/attachment-0001.html From bruno at abstractj.org Wed Jan 29 09:20:09 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 29 Jan 2014 12:20:09 -0200 Subject: [aerogear-dev] Security roadmap updates Message-ID: Good morning peeps, a proposal was sent to change the security roadmap?https://github.com/aerogear/aerogear.org/pull/242. If you have any concern, let me know. -- abstractj From bruno at abstractj.org Wed Jan 29 09:21:10 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 29 Jan 2014 12:21:10 -0200 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <52E90CBC.2020205@redhat.com> References: <72F2CBDF-791A-4BA6-A35A-7BED03B4A7C8@redhat.com> <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> <5DCEB5A8-1942-4C0C-8C0E-3DFCB5521C0B@redhat.com> <52E7D475.6060208@redhat.com> <52E7F570.7040101@redhat.com> <52E90CBC.2020205@redhat.com> Message-ID: Name it to whatever name you think is better, but IMO, the basics first. -- abstractj On January 29, 2014 at 12:14:26 PM, Summers Pittman (supittma at redhat.com) wrote: > > Then what we are talking about is no longer sync. It is revision > control. From qmx at qmx.me Wed Jan 29 09:24:46 2014 From: qmx at qmx.me (Douglas Campos) Date: Wed, 29 Jan 2014 12:24:46 -0200 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <52E90CBC.2020205@redhat.com> References: <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> <5DCEB5A8-1942-4C0C-8C0E-3DFCB5521C0B@redhat.com> <52E7D475.6060208@redhat.com> <52E7F570.7040101@redhat.com> <52E90CBC.2020205@redhat.com> Message-ID: <20140129142446.GN20528@rohan.local> On Wed, Jan 29, 2014 at 09:14:20AM -0500, Summers Pittman wrote: > On 01/29/2014 07:43 AM, Bruno Oliveira wrote: > >My 2 non technical cents, I really think we should separate "push" from > >"sync" and integrate later, bet on simple. In my opinion we are just > >adding one more level of complexity. > > > >For example: would be perfect to add digital signatures, encrypted data > >for that storage and all the sick things from security. But that would add > >an extra level of complexity which would lead us to several months of > >development. > > > >Is just my opinion, but if you guys think that we REALLY need Push, MVP or > >whatever atm, that's fine. > Then what we are talking about is no longer sync. It is revision control. Well, what if I the developer want to download the files from Dropbox API and do the sync locally? (YNAB app works like this) It still is sync, at least from my POV > > > > > >On Wed, Jan 29, 2014 at 6:03 AM, Matthias Wessendorf >> wrote: > > > > > > > > > > On Tue, Jan 28, 2014 at 7:22 PM, Summers Pittman > > > wrote: > > > > On 01/28/2014 11:11 AM, Corinne Krych wrote: > >> I think we still need the synchronisation mode in pull mode. > >> > >> How are we going to deal with this use case with simple push: > >> UserA is offline update some data, then switch off his phone > >> Some other users update data > >> UserA open his app, he has missed some push notifications but > >> still want to sync his app. > > That is the magic of Push systems. He gets the messages when > > he comes online. > > > > Device A and B and Server have data with a checksum of 42. > > Device A goes offline. > > Device A changes its data and has a checksum of 64. > > Device B changes its data and has a checksum of 192. > > Device B sends the expected server checksum of 42 and its new > > data to the server. > > Server accepts B's Data, updates its checksum to 192, and > > sends a message to all Devices ( in this case just A) > > > > > > sending the data does not work via 'mobile push' - we need > > something like 'real-time' for that sending; > > > > > > Device B and Server go on a long date, but things don't work > > out and they end up splitting the check 50/50. Device B is > > annoyed because she only got a salad but Server got the Surf > > and Turf. > > > > Device A comes online and receives a message from the server. > > Device A notices the server's checksum data is a change from > > 42 -> 192 and not 42 -> 64. Thus its copy is out of sync and > > fires a message to the User of Device A to resolve the data. > > User A resolves the data and Device A sends the merged data to > > the server. > > Device B gets a message of new data and updates to what the > > server has. > > > > > >> > >> ++ > >> Corinne > >> > >> > >> On 28 January 2014 17:01, Summers Pittman > >> > wrote: > >> > >> On 01/28/2014 10:58 AM, Lucas Holmquist wrote: > >> > On Jan 28, 2014, at 10:54 AM, Summers Pittman > >> > wrote: > >> > > >> >> On 01/28/2014 10:48 AM, Lucas Holmquist wrote: > >> >>> On Jan 28, 2014, at 10:30 AM, Summers Pittman > >> > wrote: > >> >>> > >> >>>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: > >> >>>>> yup, this is another Data Sync thread, > >> >>>>> > >> >>>>>> From a client side perspective, i have concerns > >> that there is still not a clear direction yet. > >> >>>>> I know there are multiple ideas floating around on > >> what our model should be, i'm all for choice, but what > >> about deciding on 1 model to get started with. Then > >> later once we have this nailed down, we can have other > >> "adapters" with different models perhaps > >> >>>> All the data model is is an envelope of sync > >> metadata around an object > >> >>>> right? > >> >>> right > >> >>> > >> >>>> We also need to think about the API and > >> server/client protocol as well. > >> >>>> > >> >>>> I think that for sync 1.0 we could focus on the > >> following behavior (it > >> >>>> worked for my demos at least) > >> >>>> > >> >>>> 1. We have a Sync factory similar to Pipeline, > >> Authenticator, > >> >>>> Registrar, and KeyService. > >> >>>> 2. The Sync factory consumes/manages Synchronizer > >> instances. > >> >>>> 3. AG Synchronizer listens for sync messages using > >> UnifiedPush endpoints. > >> >>> i thought for a 1.0 we weren't thinking about "realtime" > >> >> When I hear realtime I think sub 100 ms updates to all > >> clients. (think > >> >> gaming) > >> >> > >> >> What I thought we were going for was something closer > >> to email. The > >> >> data gets changed and at some point in the future the > >> client knows. More > >> >> specifically, the thing the ONE thing that makes sync > >> special is it is a > >> >> push instead of poll implementation. > >> > this makes sense, but i guess it would be push when > >> available. thinking web and crappy web socket support( > >> dang you carriers ) > >> Right. I'm not saying lets do something complicated. > >> I'm saying lets > >> use GCM, iOS CM, and simple push to send notifications to > >> tell the > >> client something. In simplePush case it is "this data > >> changed, get the > >> new stuff and update yourself". In Android and iOS case > >> it may be that > >> or it may be "here is new data". > >> > >> In general, I am fine for getting a message saying > >> something like > >> Documents/Schedules/1/${revision}. Then I can check my > >> revisions, fetch > >> data if necessary, update my local data, and send any > >> updates. That > >> SHOULD (I think) be doable with simplepush as well right? > >> > >> > > >> >>>> 4. AG Synchronizer sends sync messages using Pipes > >> >>>> 5. AG Synchronizer holds local data in a store > >> >>>> > >> >>>> 6. When AGSynchronizer gets a message it is > >> responsible for updating > >> >>>> the Store and then notifying code listing for > >> updates OR for notifying > >> >>>> the code that an error has occurred and needs to be > >> addressed. > >> >>>> > >> >>>> 7. When the developer updates data in the store, > >> the synchronizer > >> >>>> should package that data and send it to the server. > >> The synchronizer is > >> >>>> responsible for error handling, retrying, back-off, etc. > >> >>>> > >> >>>> 8. We should include multiple synchronizer > >> implementations to deal with > >> >>>> multiple very simple use cases which involve legacy > >> systems. (For > >> >>>> instance polling to load static data on a schedule.) > >> >>>> > >> >>>> Thoughts? Tomatoes? > >> >>>>> > >> >>>>> _______________________________________________ > >> >>>>> 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 > > > > > > _______________________________________________ > > 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 > > > > > > > > > >-- > > > >-- > >"The measure of a man is what he does with power" - Plato > >- > >@abstractj > >- > >Volenti Nihil Difficile > > > > > >_______________________________________________ > >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 -- qmx From supittma at redhat.com Wed Jan 29 09:50:50 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 29 Jan 2014 09:50:50 -0500 Subject: [aerogear-dev] Data Sync Thoughts In-Reply-To: <20140129142446.GN20528@rohan.local> References: <52E7CD27.2060206@redhat.com> <52E7D2BB.8060605@redhat.com> <5DCEB5A8-1942-4C0C-8C0E-3DFCB5521C0B@redhat.com> <52E7D475.6060208@redhat.com> <52E7F570.7040101@redhat.com> <52E90CBC.2020205@redhat.com> <20140129142446.GN20528@rohan.local> Message-ID: <52E9154A.10401@redhat.com> On Wed 29 Jan 2014 09:24:46 AM EST, Douglas Campos wrote: > On Wed, Jan 29, 2014 at 09:14:20AM -0500, Summers Pittman wrote: >> On 01/29/2014 07:43 AM, Bruno Oliveira wrote: >>> My 2 non technical cents, I really think we should separate "push" from >>> "sync" and integrate later, bet on simple. In my opinion we are just >>> adding one more level of complexity. >>> >>> For example: would be perfect to add digital signatures, encrypted data >>> for that storage and all the sick things from security. But that would add >>> an extra level of complexity which would lead us to several months of >>> development. >>> >>> Is just my opinion, but if you guys think that we REALLY need Push, MVP or >>> whatever atm, that's fine. >> Then what we are talking about is no longer sync. It is revision control. > > Well, what if I the developer want to download the files from Dropbox > API and do the sync locally? (YNAB app works like this) > > It still is sync, at least from my POV Even in that scenario Drop Box is still pushing a message to a listener which wakes your code up to the fact there is new data. > >>> >>> >>> On Wed, Jan 29, 2014 at 6:03 AM, Matthias Wessendorf >> > wrote: >>> >>> >>> >>> >>> On Tue, Jan 28, 2014 at 7:22 PM, Summers Pittman >>> > wrote: >>> >>> On 01/28/2014 11:11 AM, Corinne Krych wrote: >>>> I think we still need the synchronisation mode in pull mode. >>>> >>>> How are we going to deal with this use case with simple push: >>>> UserA is offline update some data, then switch off his phone >>>> Some other users update data >>>> UserA open his app, he has missed some push notifications but >>>> still want to sync his app. >>> That is the magic of Push systems. He gets the messages when >>> he comes online. >>> >>> Device A and B and Server have data with a checksum of 42. >>> Device A goes offline. >>> Device A changes its data and has a checksum of 64. >>> Device B changes its data and has a checksum of 192. >>> Device B sends the expected server checksum of 42 and its new >>> data to the server. >>> Server accepts B's Data, updates its checksum to 192, and >>> sends a message to all Devices ( in this case just A) >>> >>> >>> sending the data does not work via 'mobile push' - we need >>> something like 'real-time' for that sending; >>> >>> >>> Device B and Server go on a long date, but things don't work >>> out and they end up splitting the check 50/50. Device B is >>> annoyed because she only got a salad but Server got the Surf >>> and Turf. >>> >>> Device A comes online and receives a message from the server. >>> Device A notices the server's checksum data is a change from >>> 42 -> 192 and not 42 -> 64. Thus its copy is out of sync and >>> fires a message to the User of Device A to resolve the data. >>> User A resolves the data and Device A sends the merged data to >>> the server. >>> Device B gets a message of new data and updates to what the >>> server has. >>> >>> >>>> >>>> ++ >>>> Corinne >>>> >>>> >>>> On 28 January 2014 17:01, Summers Pittman >>>> > wrote: >>>> >>>> On 01/28/2014 10:58 AM, Lucas Holmquist wrote: >>>> > On Jan 28, 2014, at 10:54 AM, Summers Pittman >>>> > wrote: >>>> > >>>> >> On 01/28/2014 10:48 AM, Lucas Holmquist wrote: >>>> >>> On Jan 28, 2014, at 10:30 AM, Summers Pittman >>>> > wrote: >>>> >>> >>>> >>>> On 01/28/2014 09:36 AM, Lucas Holmquist wrote: >>>> >>>>> yup, this is another Data Sync thread, >>>> >>>>> >>>> >>>>>> From a client side perspective, i have concerns >>>> that there is still not a clear direction yet. >>>> >>>>> I know there are multiple ideas floating around on >>>> what our model should be, i'm all for choice, but what >>>> about deciding on 1 model to get started with. Then >>>> later once we have this nailed down, we can have other >>>> "adapters" with different models perhaps >>>> >>>> All the data model is is an envelope of sync >>>> metadata around an object >>>> >>>> right? >>>> >>> right >>>> >>> >>>> >>>> We also need to think about the API and >>>> server/client protocol as well. >>>> >>>> >>>> >>>> I think that for sync 1.0 we could focus on the >>>> following behavior (it >>>> >>>> worked for my demos at least) >>>> >>>> >>>> >>>> 1. We have a Sync factory similar to Pipeline, >>>> Authenticator, >>>> >>>> Registrar, and KeyService. >>>> >>>> 2. The Sync factory consumes/manages Synchronizer >>>> instances. >>>> >>>> 3. AG Synchronizer listens for sync messages using >>>> UnifiedPush endpoints. >>>> >>> i thought for a 1.0 we weren't thinking about "realtime" >>>> >> When I hear realtime I think sub 100 ms updates to all >>>> clients. (think >>>> >> gaming) >>>> >> >>>> >> What I thought we were going for was something closer >>>> to email. The >>>> >> data gets changed and at some point in the future the >>>> client knows. More >>>> >> specifically, the thing the ONE thing that makes sync >>>> special is it is a >>>> >> push instead of poll implementation. >>>> > this makes sense, but i guess it would be push when >>>> available. thinking web and crappy web socket support( >>>> dang you carriers ) >>>> Right. I'm not saying lets do something complicated. >>>> I'm saying lets >>>> use GCM, iOS CM, and simple push to send notifications to >>>> tell the >>>> client something. In simplePush case it is "this data >>>> changed, get the >>>> new stuff and update yourself". In Android and iOS case >>>> it may be that >>>> or it may be "here is new data". >>>> >>>> In general, I am fine for getting a message saying >>>> something like >>>> Documents/Schedules/1/${revision}. Then I can check my >>>> revisions, fetch >>>> data if necessary, update my local data, and send any >>>> updates. That >>>> SHOULD (I think) be doable with simplepush as well right? >>>> >>>> > >>>> >>>> 4. AG Synchronizer sends sync messages using Pipes >>>> >>>> 5. AG Synchronizer holds local data in a store >>>> >>>> >>>> >>>> 6. When AGSynchronizer gets a message it is >>>> responsible for updating >>>> >>>> the Store and then notifying code listing for >>>> updates OR for notifying >>>> >>>> the code that an error has occurred and needs to be >>>> addressed. >>>> >>>> >>>> >>>> 7. When the developer updates data in the store, >>>> the synchronizer >>>> >>>> should package that data and send it to the server. >>>> The synchronizer is >>>> >>>> responsible for error handling, retrying, back-off, etc. >>>> >>>> >>>> >>>> 8. We should include multiple synchronizer >>>> implementations to deal with >>>> >>>> multiple very simple use cases which involve legacy >>>> systems. (For >>>> >>>> instance polling to load static data on a schedule.) >>>> >>>> >>>> >>>> Thoughts? Tomatoes? >>>> >>>>> >>>> >>>>> _______________________________________________ >>>> >>>>> 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 >>> >>> >>> _______________________________________________ >>> 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 >>> >>> >>> >>> >>> -- >>> >>> -- >>> "The measure of a man is what he does with power" - Plato >>> - >>> @abstractj >>> - >>> Volenti Nihil Difficile >>> >>> >>> _______________________________________________ >>> 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 bruno at abstractj.org Wed Jan 29 09:57:53 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 29 Jan 2014 12:57:53 -0200 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: References: <1390738834902.6b58437e@Nodemailer> Message-ID: Sorry I just missed your e-mail during while the syncalipse was happening. What I meant was something like: admin, developers, regular users and how to deal with these roles. Maybe this is planned to the next steps, but at some point we need to test how KeyCloak could protect our endpoints and deal with multiple roles. On Sun, Jan 26, 2014 at 10:41 AM, Matthias Wessendorf wrote: > Hello Bruno, > > > On Sun, Jan 26, 2014 at 1:20 PM, Bruno Oliveira wrote: > >> Any specific reason to limit the scope to admin page only? I'm thinking >> about login for regular users > > > Not sure I follow. What do you mean w/ "regular users"? > > > Before my change very thing was restricted by Keycloak (/*). I did not > really change there a lot, however I just removed the URLs for > 'device-registration' and 'sending': > > https://github.com/matzew/aerogear-unifiedpush-server/blob/keycloak/src/main/webapp/WEB-INF/web.xml#L42-L50 > > So, currently the following is protected by Keycloak: > * Admin UI (not speaking about a specific admin user) > * REST APIs that are accessed by the Admin UI, like: > - http://aerogear.org/docs/specs/aerogear-push-rest/PushApplication/ > - http://aerogear.org/docs/specs/aerogear-push-rest/Variants/ > > Perviously the 'device-registration' and 'sending' URL were protected as > well. Removing them from the 'keycloak protection' is really the only change > > Greetings, > Matthias > > > >> -- >> abstractj >> >> >> On Sun, Jan 26, 2014 at 9:11 AM, Matthias Wessendorf wrote: >> >>> Hello! >>> >>> I have a few more updates: >>> >>> On my branch (a fork from Bruno's branch), the URLs for the actual >>> sending and the device-registration (both 'protected' via HTTP-Basic), now >>> work again. I have 'limited' the scope of the Keycloak 'protection' to the >>> AdminUI. >>> >>> Greetings, >>> Matthias >>> >>> >>> >>> On Fri, Jan 24, 2014 at 6:05 PM, Matthias Wessendorf wrote: >>> >>>> I have updated the branch w/ their recent changes from this weeks >>>> alpha-1 release, and submitted a PR against abstractj's repo: >>>> https://github.com/abstractj/aerogear-unifiedpush-server/pull/1 >>>> >>>> More to come >>>> >>>> Greetings, >>>> Matthias >>>> >>>> >>>> >>>> On Fri, Dec 20, 2013 at 1:11 PM, Bruno Oliveira wrote: >>>> >>>>> Good morning peeps, yesterday I started to replace AeroGear Security >>>>> on Unified Push server by Keycloak and you might be asking: "Why?". >>>>> Keycloak is a SSO with some handy features like TOTP, OAuth2, user >>>>> management support and I think we have too much to contribute, is the only >>>>> way to have some success with security, "divide to conquer" (at least for >>>>> authorization and authentication). >>>>> >>>>> So will ag-security be discontinued? No! Keycloak is still on Alpha >>>>> and we have to test it against our projects before fully replace >>>>> ag-security, but the only way to upstream our needs, is to using it. >>>>> >>>>> This replacement only applies to authentication/authorization >>>>> features, we still have a ton of projects which Keycloak is not able to >>>>> replace like: TOTP, crypto and OAuth2 on mobile, our focus. >>>>> >>>>> - PoC >>>>> >>>>> So let's talk about this replacement, any dependency on ag-security >>>>> was removed from the push server and replaced by Keycloak: >>>>> https://github.com/abstractj/aerogear-unifiedpush-server/tree/openshift >>>>> >>>>> Based on Keycloak examples, I just did copy & paste from one of the >>>>> demos (https://github.com/abstractj/auth-server/tree/openshift) to >>>>> create a server. Keycloak requires Resteasy 3.0.4, for this reason I had to >>>>> manually replace some modules on JBoss. >>>>> >>>>> To test it go to: http://push-abstractj.rhcloud.com/ag-push/ you must >>>>> be redirected to Keycloak, enter: >>>>> >>>>> username: john at doe.com >>>>> password: password >>>>> >>>>> You must be redirected to agpush console, keep in mind that I took >>>>> some shortcuts to get this demo working, so for example the create will >>>>> fail because I removed everything related into the ember interface. >>>>> >>>>> Is also possible to enable TOTP, user's registration and whatever you >>>>> want. >>>>> >>>>> So what do you think? >>>>> >>>>> -- >>>>> abstractj >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >>> >>> >>> -- >>> 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 >> > > > > -- > 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 > -- -- "The measure of a man is what he does with power" - Plato - @abstractj - Volenti Nihil Difficile -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140129/53b3f1f2/attachment.html From jbalunas at redhat.com Wed Jan 29 09:59:27 2014 From: jbalunas at redhat.com (Jay Balunas) Date: Wed, 29 Jan 2014 09:59:27 -0500 Subject: [aerogear-dev] Aerogear Cordova Push Plugin In-Reply-To: References: <31CB8979-F7A8-4A93-BBB6-1FFE309368DE@redhat.com> Message-ID: <0129A2CC-7F68-41BF-83CD-8B36EAEDE5D0@redhat.com> Wow, this is a detailed investigation! Thanks a lot for digging in like this and the jiras! I think getting these addressed, and other UX items for getting started is a big priority for us going forward. As well as how to catch these issues sooner. On Jan 28, 2014, at 6:05 PM, Burr Sutter wrote: > OK, the real gotcha was... > https://issues.jboss.org/browse/AGPUSH-525 > > There were some smaller issues: > - I found the readme.md to be inaccurate > - the video is incomplete http://www.youtube.com/watch?v=a7QVWfEkSpc > i watched it several times last week, pausing, trying to tease out the commands needed to replicate the experience > - I believe iOS also requires the console plugin be installed - as device ready was failing due to the console.log the sample app contains. > - Hand editing the config.xml to provide the App Name and package/bundleID I wanted did not seem to "stick" - I was better off using the command line like so: > cordova create hellopush com.burrsutter.hellopush "Hello Push" > instead > cordova create hellopush and editing the config.xml that was generated > > on Android 2.3, the app loads but blows up on launch > https://issues.jboss.org/browse/AGPUSH-526 > > And there is inconsistency between iOS and Android > https://issues.jboss.org/browse/AGPUSH-527 > > And can we "hide" the older UPS docs that focus on curl and bring the ones that focus on the web UI to the foreground? > For instance, at the bottom of this page: > http://aerogear.org/docs/guides/aerogear-push-android/google-setup/ > it links to the curl version - curl is great, but more of an advanced topic > this is the doc that needs more link love > http://aerogear.org/docs/guides/AdminConsoleGuide/ > > > I attempted to document the complete set of steps in my readme.txt > https://github.com/burrsutter/hellopush > > I suspect I forgot something along the way > > > On Jan 28, 2014, at 1:25 PM, Burr Sutter wrote: > >> https://github.com/aerogear/aerogear-pushplugin-cordova/ >> My project/notes in the readme.md - it could be that I have missed a step, so I tried to describe my steps carefully in the readme, everything from the command line right now - I will attempt JBoss Tools once the command line steps seem to work. >> https://github.com/burrsutter/hellopush >> >> I have also tested with >> https://github.com/edewit/aerogear-pushplugin-cordova/tree/agdroid-195 >> >> It only works on Android 4.3, funny enough that was the first device I tried - perhaps there is some "affinity" for a single device? :-) >> >> It fails on: >> Android 2.3.4 >> Android 4.4.2 (two different devices) >> iOS 6.1.5 >> iOS 7.0.4 >> >> Let's define "fail": >> - the app always deploys but... >> - the additional devices never register a device token in the UPS console. I assume I will see "instances" for the various devices >> - in the case of iOS, the deviceready does not even fire correctly >> - in the case of Android (all versions), the onError handler is called with "no value for pushconfig" - including the 4.3 where things do work. >> >> >> >> _______________________________________________ >> 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/20140129/edb1c367/attachment.html From matzew at apache.org Wed Jan 29 10:02:23 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 29 Jan 2014 16:02:23 +0100 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: References: <1390738834902.6b58437e@Nodemailer> Message-ID: On Wed, Jan 29, 2014 at 3:57 PM, Bruno Oliveira wrote: > Sorry I just missed your e-mail during while the syncalipse was happening. > > What I meant was something like: admin, developers, regular users and how > to deal with these roles. Maybe this is planned to the next steps, but at > some point we need to test how KeyCloak could protect our endpoints and > deal with multiple roles. > yes, the 'ui part' (and the underlying endpoints) being protected by keycloak; On the next steps is also looking at different roles for this. I was never speaking about a specific user/role - more generically protecting the "Admin UI", which can be consumed by users w/ different roles -Matthias > > > On Sun, Jan 26, 2014 at 10:41 AM, Matthias Wessendorf wrote: > >> Hello Bruno, >> >> >> On Sun, Jan 26, 2014 at 1:20 PM, Bruno Oliveira wrote: >> >>> Any specific reason to limit the scope to admin page only? I'm thinking >>> about login for regular users >> >> >> Not sure I follow. What do you mean w/ "regular users"? >> >> >> Before my change very thing was restricted by Keycloak (/*). I did not >> really change there a lot, however I just removed the URLs for >> 'device-registration' and 'sending': >> >> https://github.com/matzew/aerogear-unifiedpush-server/blob/keycloak/src/main/webapp/WEB-INF/web.xml#L42-L50 >> >> So, currently the following is protected by Keycloak: >> * Admin UI (not speaking about a specific admin user) >> * REST APIs that are accessed by the Admin UI, like: >> - http://aerogear.org/docs/specs/aerogear-push-rest/PushApplication/ >> - http://aerogear.org/docs/specs/aerogear-push-rest/Variants/ >> >> Perviously the 'device-registration' and 'sending' URL were protected as >> well. Removing them from the 'keycloak protection' is really the only change >> >> Greetings, >> Matthias >> >> >> >>> -- >>> abstractj >>> >>> >>> On Sun, Jan 26, 2014 at 9:11 AM, Matthias Wessendorf wrote: >>> >>>> Hello! >>>> >>>> I have a few more updates: >>>> >>>> On my branch (a fork from Bruno's branch), the URLs for the actual >>>> sending and the device-registration (both 'protected' via HTTP-Basic), now >>>> work again. I have 'limited' the scope of the Keycloak 'protection' to the >>>> AdminUI. >>>> >>>> Greetings, >>>> Matthias >>>> >>>> >>>> >>>> On Fri, Jan 24, 2014 at 6:05 PM, Matthias Wessendorf >>> > wrote: >>>> >>>>> I have updated the branch w/ their recent changes from this weeks >>>>> alpha-1 release, and submitted a PR against abstractj's repo: >>>>> https://github.com/abstractj/aerogear-unifiedpush-server/pull/1 >>>>> >>>>> More to come >>>>> >>>>> Greetings, >>>>> Matthias >>>>> >>>>> >>>>> >>>>> On Fri, Dec 20, 2013 at 1:11 PM, Bruno Oliveira wrote: >>>>> >>>>>> Good morning peeps, yesterday I started to replace AeroGear Security >>>>>> on Unified Push server by Keycloak and you might be asking: "Why?". >>>>>> Keycloak is a SSO with some handy features like TOTP, OAuth2, user >>>>>> management support and I think we have too much to contribute, is the only >>>>>> way to have some success with security, "divide to conquer" (at least for >>>>>> authorization and authentication). >>>>>> >>>>>> So will ag-security be discontinued? No! Keycloak is still on Alpha >>>>>> and we have to test it against our projects before fully replace >>>>>> ag-security, but the only way to upstream our needs, is to using it. >>>>>> >>>>>> This replacement only applies to authentication/authorization >>>>>> features, we still have a ton of projects which Keycloak is not able to >>>>>> replace like: TOTP, crypto and OAuth2 on mobile, our focus. >>>>>> >>>>>> - PoC >>>>>> >>>>>> So let's talk about this replacement, any dependency on ag-security >>>>>> was removed from the push server and replaced by Keycloak: >>>>>> https://github.com/abstractj/aerogear-unifiedpush-server/tree/openshift >>>>>> >>>>>> Based on Keycloak examples, I just did copy & paste from one of the >>>>>> demos (https://github.com/abstractj/auth-server/tree/openshift) to >>>>>> create a server. Keycloak requires Resteasy 3.0.4, for this reason I had to >>>>>> manually replace some modules on JBoss. >>>>>> >>>>>> To test it go to: http://push-abstractj.rhcloud.com/ag-push/ you >>>>>> must be redirected to Keycloak, enter: >>>>>> >>>>>> username: john at doe.com >>>>>> password: password >>>>>> >>>>>> You must be redirected to agpush console, keep in mind that I took >>>>>> some shortcuts to get this demo working, so for example the create will >>>>>> fail because I removed everything related into the ember interface. >>>>>> >>>>>> Is also possible to enable TOTP, user's registration and whatever you >>>>>> want. >>>>>> >>>>>> So what do you think? >>>>>> >>>>>> -- >>>>>> abstractj >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> 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 >>> >> >> >> >> -- >> 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 >> > > > > -- > > -- > "The measure of a man is what he does with power" - Plato > - > @abstractj > - > Volenti Nihil Difficile > > _______________________________________________ > 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/20140129/e13ff999/attachment-0001.html From fjuma at redhat.com Wed Jan 29 10:31:06 2014 From: fjuma at redhat.com (Farah Juma) Date: Wed, 29 Jan 2014 10:31:06 -0500 (EST) Subject: [aerogear-dev] Upgrading process for the OpenShift AeroGear UPS cartridge In-Reply-To: <59183402.6125947.1390988077765.JavaMail.root@redhat.com> References: <676075311.5431814.1390843624382.JavaMail.root@redhat.com> <2099059360.11646680.1390846051314.JavaMail.root@redhat.com> <1403896808.11718517.1390858087208.JavaMail.root@redhat.com> <2034992562.5686126.1390898762650.JavaMail.root@redhat.com> <830585923.11958735.1390921396801.JavaMail.root@redhat.com> <1552758754.12035565.1390929053020.JavaMail.root@redhat.com> <59183402.6125947.1390988077765.JavaMail.root@redhat.com> Message-ID: <566106841.12369095.1391009466277.JavaMail.root@redhat.com> > From: "Andrea Vibelli" > To: "Farah Juma" > Cc: aerogear-dev at lists.jboss.org > Sent: Wednesday, January 29, 2014 4:34:37 AM > Subject: Re: [aerogear-dev] Upgrading process for the OpenShift AeroGear UPS cartridge > > Hi Farah, > great, the steps are really neat now. > One last minor observation: the manifest.yml file for both the 0.8.1 and the > 0.9.1 instances contains version 0.8.0 and 0.9.0. Correct, since very few changes were made for the 0.8.1 release, we actually didn't change the version in the manifest (so you'll still see version 0.8.0 there). My fork of the cartridge repository that has the snapshot/restore action hooks contains the 0.9.0 Push Server bits. We'll update the manifest version for the UnifiedPush 0.10.0 release. Thanks, Farah > Thanks! > Andrea > ----- Messaggio originale ----- > > Da: "Farah Juma" > > A: aerogear-dev at lists.jboss.org, "Andrea Vibelli" > > Inviato: Marted?, 28 gennaio 2014 18:10:53 > > Oggetto: Re: [aerogear-dev] Upgrading process for the OpenShift AeroGear > > UPS cartridge > > > > I've created the following gist that contains our updated list of steps for > > upgrading the cartridge: > > > > https://gist.github.com/fjuma/499827d650465a1a8f5a > > > > > > Farah > > > > ----- Original Message ----- > > > From: "Farah Juma" > > > To: aerogear-dev at lists.jboss.org > > > Cc: "Andrea Vibelli" > > > Sent: Tuesday, January 28, 2014 10:03:16 AM > > > Subject: Re: [aerogear-dev] Upgrading process for the OpenShift AeroGear > > > UPS cartridge > > > > > > > > > > From: "Andrea Vibelli" > > > > To: "Farah Juma" > > > > Cc: aerogear-dev at lists.jboss.org > > > > Sent: Tuesday, January 28, 2014 3:46:02 AM > > > > Subject: Re: Re: [aerogear-dev] Upgrading process for the OpenShift > > > > AeroGear UPS cartridge > > > > > > > > Hi Farah, > > > > yes I do use FireFox. > > > > > > > > I have done the tests once again, and closing and reopening the browser > > > > solved my issue, great, nice catch! > > > > > > Great, I'm glad that's working for you now! > > > > > > > Maybe we could also include this additional step in the overall > > > > instructions, > > > > what do you think? > > > > > > Yes, that's a good idea. I'm going to create a gist with our updated > > > steps > > > and post it here when done to get more feedback. > > > > > > Thanks, > > > Farah > > > > > > > > > > Thank you > > > > Andrea > > > > > > > > ----- Messaggio originale ----- > > > > > Da: "Farah Juma" > > > > > A: "Andrea Vibelli" , > > > > > aerogear-dev at lists.jboss.org > > > > > Inviato: Luned?, 27 gennaio 2014 22:28:07 > > > > > Oggetto: Re: [aerogear-dev] Upgrading process for the OpenShift > > > > > AeroGear > > > > > UPS cartridge > > > > > > > > > > After some more digging, I think I might know what's going on here. > > > > > Andrea, > > > > > are you using Firefox? I wasn't able to reproduce the issue with > > > > > Chrome > > > > > but > > > > > was able to reproduce it just now with Firefox. The underlying issue > > > > > seems > > > > > to be that Firefox tends to save 301 redirects until you close it and > > > > > re-open it. Note that when you delete an OpenShift instance and > > > > > re-create > > > > > it, its IP address changes. When accessing > > > > > http://app-namespace.rhcloud > > > > > after re-creating the instance, you'll actually be redirected to > > > > > https://app-namespace.rhcloud/app. However, when using Firefox, this > > > > > URL > > > > > seems to get mapped to the old IP address resulting in this error: > > > > > 'The > > > > > requested URL /app was not found on this server.' After deleting and > > > > > re-creating an OpenShift instance with the same name, if you restart > > > > > Firefox, you should once again be able to access the application. > > > > > I've > > > > > verified that this does work. > > > > > > > > > > Similar issues with Firefox were actually mentioned in some OpenShift > > > > > forum > > > > > posts as well: > > > > > > > > > > https://www.openshift.com/forums/openshift/httpawm-pribylrhcloudcom-the-requested-url-was-not-found-on-this-server#comment-33570 > > > > > https://www.openshift.com/forums/openshift/custom-domain-httpwwwxxxxxxxcom-is-redirecting-to-httpswwwxxxxxxxcomapp#comment-34215 > > > > > > > > > > > > > > > Farah > > > > > > > > > > ----- Original Message ----- > > > > > > From: "Farah Juma" > > > > > > To: aerogear-dev at lists.jboss.org > > > > > > Sent: Monday, January 27, 2014 1:07:31 PM > > > > > > Subject: Re: [aerogear-dev] Upgrading process for the OpenShift > > > > > > AeroGear > > > > > > ????????UPS????????cartridge > > > > > > > > > > > > > > > > > > > From: "Andrea Vibelli" > > > > > > > To: aerogear-dev at lists.jboss.org > > > > > > > Sent: Monday, January 27, 2014 12:27:04 PM > > > > > > > Subject: [aerogear-dev] Upgrading process for the OpenShift > > > > > > > AeroGear > > > > > > > UPS > > > > > > > ????????cartridge > > > > > > > > > > > > > > Hello all, > > > > > > > > > > > > > > I just wanted to let you know that Farah is working on > > > > > > > AGPUSH-504, > > > > > > > a > > > > > > > snapshot/restore approach for upgrading the downloadable > > > > > > > cartridge. > > > > > > > The overall idea is to take a snapshot of the database (and other > > > > > > > configuration) for an older existing cartridge instance, delete > > > > > > > this > > > > > > > old > > > > > > > instance, and then create a new instance based on the latest > > > > > > > cartridge > > > > > > > version and restore the new instance's database (and other > > > > > > > configuration) > > > > > > > to > > > > > > > the state in the snapshot. The new instance must have the same > > > > > > > name > > > > > > > as > > > > > > > the > > > > > > > old instance. The main thing that she needed to determine was > > > > > > > what > > > > > > > needed > > > > > > > to > > > > > > > be included in the snapshot that's not already part of the MySQL > > > > > > > database. > > > > > > > The SimplePush token key was one of these things (we generate > > > > > > > this > > > > > > > value > > > > > > > when a cartridge instance is created and it is used by the server > > > > > > > for > > > > > > > encryption and decryption of endpoint URLs). The standalone.xml > > > > > > > file > > > > > > > also > > > > > > > needed to be backed up just in case the user made any changes to > > > > > > > it. > > > > > > > (Creating a backup of this file allows users to manually merge > > > > > > > back > > > > > > > any > > > > > > > changes they may have made.) > > > > > > > > > > > > > > The snapshot/restore action hooks she has created can be found in > > > > > > > [1]. > > > > > > > > > > > > > > The steps she has been using to try upgrading from an 0.8.1 > > > > > > > instance > > > > > > > are > > > > > > > listed below. It would be great if you could try out these steps > > > > > > > as > > > > > > > well. > > > > > > > There's one important caveat though: because an 0.8.1 instance > > > > > > > won't > > > > > > > have > > > > > > > the necessary snapshot hook, you'll need to manually perform some > > > > > > > commands > > > > > > > to save the necessary data (step 3 below). If we include these > > > > > > > snapshot/restore action hooks in the 0.10.0 cartridge release, > > > > > > > users > > > > > > > will > > > > > > > be > > > > > > > able to make use of these hooks for future upgrades, e.g., for > > > > > > > upgrading > > > > > > > from 0.10.0 to 0.11.0. > > > > > > > ? > > > > > > > 1) Create an 0.8.1 cartridge instance > > > > > > > rhc create-app mypush > > > > > > > "https://cartreflect-claytondev.rhcloud.com/reflect?github=aerogear/openshift-origin-cartridge-aerogear-push&commit=8aada257de52157a837db23a9f7b1a8574fdffab" > > > > > > > mysql-5.1 > > > > > > > > > > > > > > 2) Log into the admin console, change password, create push > > > > > > > applications, > > > > > > > create variants, send push notifications, etc. > > > > > > > > > > > > > > 3) ssh into your instance and perform these commands (this step > > > > > > > manually > > > > > > > captures needed data) > > > > > > > echo "$OPENSHIFT_AEROGEAR_PUSH_TOKEN_KEY" > > > > > > > > $OPENSHIFT_DATA_DIR/aerogear_push_token_key > > > > > > > cp > > > > > > > $OPENSHIFT_AEROGEAR_PUSH_DIR/standalone/configuration/standalone.xml > > > > > > > $OPENSHIFT_DATA_DIR/standalone.snapshot.xml > > > > > > > > > > > > > > 4) Create a snapshot of the 0.8.1 instance: rhc snapshot save > > > > > > > mypush > > > > > > > > > > > > > > 5) Delete the 0.8.1 instance: rhc app delete mypush > > > > > > > > > > > > > > 6) Delete the local directory on the local machine (from step 1, > > > > > > > you > > > > > > > should > > > > > > > have a directory named 'mypush') > > > > > > > > > > > > > > 7) Create a new cartridge instance (this uses her fork of the > > > > > > > 0.9.0 > > > > > > > cartridge > > > > > > > repository that contains the snapshot/restore action hooks) > > > > > > > rhc create-app mypush > > > > > > > "https://cartreflect-claytondev.rhcloud.com/reflect?github=fjuma/openshift-origin-cartridge-aerogear-push&commit=956a4fc09edc93fe76394b86b265ceb1d238ccaf" > > > > > > > mysql-5.1 > > > > > > > > > > > > > > 8) Restore the instance: rhc snapshot restore mypush -f > > > > > > > /PATH/TO/mypush.tar.gz > > > > > > > > > > > > > > 9) You should now be able to log into the admin console with the > > > > > > > same > > > > > > > password you previously set, see existing push applications, > > > > > > > variants, > > > > > > > send > > > > > > > push notifications, etc. > > > > > > > > > > > > > > One disadvantage of this snapshot/restore approach is the extra > > > > > > > work > > > > > > > for > > > > > > > the > > > > > > > user. It would be nice to have a single command that can do the > > > > > > > snapshot, > > > > > > > delete, create, and restore all at once. She is going to start > > > > > > > looking > > > > > > > into > > > > > > > this "wrappering" functionality. > > > > > > > > > > > > > > > > > > > > > Why am I writing about this? > > > > > > > > > > > > > > I have made some test about the above steps. At a first glance, > > > > > > > it > > > > > > > seemed > > > > > > > that something was broken between steps 6 and 7. > > > > > > > Doing various tests, what I saw in the logs (server.log) were > > > > > > > different > > > > > > > errors: > > > > > > > > > > > > > > 2014/01/26 10:19:18,061 ERROR [org.jboss.as] (MSC service thread > > > > > > > 1-3) > > > > > > > JBAS015875: JBoss AS 7.1.1.Final "Brontes" started (with errors) > > > > > > > in > > > > > > > 296088ms > > > > > > > - Started 349 of 524 services (52 services failed or missing > > > > > > > dependencies, > > > > > > > 119 services are passive or on-demand) > > > > > > > 2014/01/26 10:19:18,344 INFO ?[org.jboss.as.server] > > > > > > > (DeploymentScanner-threads - 2) JBAS015870: Deploy of deployment > > > > > > > "ROOT.war" > > > > > > > was rolled back with failure message {"JBAS014771: Services with > > > > > > > missing/unavailable dependencies" => > > > > > > > ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]} > > > > > > > 2014/01/26 10:19:19,390 INFO ?[org.jboss.as.server.deployment] > > > > > > > (MSC > > > > > > > service > > > > > > > thread 1-2) JBAS015877: Stopped deployment ROOT.war in 1125ms > > > > > > > 2014/01/26 10:19:19,393 INFO ?[org.jboss.as.controller] > > > > > > > (DeploymentScanner-threads - 2) JBAS014774: Service status report > > > > > > > JBAS014775: ? ?New missing/unsatisfied dependencies: > > > > > > > ? ? ? service > > > > > > > ? ? ? jboss.naming.context.java.jboss.datasources.PushEEDS > > > > > > > ? ? ? (missing) > > > > > > > ? ? ? dependents: [service > > > > > > > ? ? ? jboss.persistenceunit."ROOT.war#unifiedpush-default", > > > > > > > ? ? ? service > > > > > > > ? ? ? jboss.persistenceunit."ROOT.war#picketlink-default"] > > > > > > > > > > > > > > > > > > > > > 2014/01/26 10:19:19,440 ERROR > > > > > > > [org.jboss.as.server.deployment.scanner] > > > > > > > (DeploymentScanner-threads - 1) {"JBAS014653: Composite operation > > > > > > > failed > > > > > > > and > > > > > > > was rolled back. Steps that failed:" => {"Operation step-2" => > > > > > > > {"JBAS014771: > > > > > > > Services with missing/unavailable dependencies" => > > > > > > > ["jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#unifiedpush-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]","jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDSMissing[jboss.persistenceunit.\"ROOT.war#picketlink-default\"jboss.naming.context.java.jboss.datasources.PushEEDS]"]}}} > > > > > > > > > > > > > > > > > > It looks like the MySQL cartridge either wasn't added or wasn't > > > > > > able > > > > > > to > > > > > > start > > > > > > successfully. The following command can be used to check the status > > > > > > of > > > > > > the > > > > > > MySQL cartridge: > > > > > > > > > > > > rhc cartridge status -a APP -c mysql > > > > > > > > > > > > ? > > > > > > > OR > > > > > > > > > > > > > > > > > > > > > 2014/01/26 05:41:46,522 INFO ?[org.jboss.as.connector] (MSC > > > > > > > service > > > > > > > thread > > > > > > > 1-1) JBAS010408: Starting JCA Subsystem (JBoss IronJacamar > > > > > > > 1.0.9.Final) > > > > > > > 2014/01/26 05:41:46,922 ERROR > > > > > > > [org.jboss.as.controller.management-operation] > > > > > > > (ServerService Thread Pool -- 62) Operation ("enable") failed - > > > > > > > address: > > > > > > > ([ > > > > > > > ? ? ("subsystem" => "datasources"), > > > > > > > ? ? ("data-source" => "PostgreSQLDS") > > > > > > > ]) - failure description: "JBAS014802: Cannot resolve expression > > > > > > > 'expression > > > > > > > \"jdbcostgresql://${env.OPENSHIFT_POSTGRESQL_DB_HOST}:${env.OPENSHIFT_POSTGRESQL_DB_PORT}/mypush13\"' > > > > > > > -- java.lang.IllegalStateException: Failed to resolve expression: > > > > > > > ${env.OPENSHIFT_POSTGRESQL_DB_HOST}" > > > > > > > > > > > > > > > > > > > > > OR > > > > > > > > > > > > > > > > > > > > > no errors in the logs, but in the deployments directory I found > > > > > > > 'ROOT.war.dodeploy' and 'ROOT.war.isdeploying' files, but no > > > > > > > 'ROOT.war.deployed' file. > > > > > > > > > > > > > > > > > > > > > Those error seemed to me as random and too strange (by the way, > > > > > > > the > > > > > > > creation > > > > > > > of the cartridge is always correct, I never had problems if I > > > > > > > created > > > > > > > a > > > > > > > new > > > > > > > instance with a never used before name). > > > > > > > > > > > > > > To investigate further, I then tried to do the same steps with a > > > > > > > completely > > > > > > > different application: 'Kitchensink on OpenShift', and I had the > > > > > > > same > > > > > > > error! > > > > > > > After the deletion and the recreation of a cartridge with a same > > > > > > > name, > > > > > > > I > > > > > > > encountered: 'The requested URL /app was not found on this > > > > > > > server.' > > > > > > > The steps I have done are: > > > > > > > 1) rhc app create -a kitchensink -t jbossas-7 --from-code > > > > > > > git://github.com/openshift/kitchensink-example.git > > > > > > > 2) rhc snapshot save kitchensink > > > > > > > 3) rhc app delete kitchensink > > > > > > > 4) rm -rf kitchensinkhtml5/ > > > > > > > 5) rhc app create -a kitchensink -t jbossas-7 --from-code > > > > > > > git://github.com/openshift/kitchensink-example.git > > > > > > > 6) Access to the application. > > > > > > > > > > > > > > So the good news is that the error I encountered is not related > > > > > > > to > > > > > > > this > > > > > > > specific AeroGear cartridges, but the bad news is that is > > > > > > > something > > > > > > > more > > > > > > > general about OpenShift. > > > > > > > We need to investigate further and find out if there is a way to > > > > > > > "flush" > > > > > > > the > > > > > > > deletion, it seems that there is something appended or cached > > > > > > > that > > > > > > > prevent > > > > > > > the recreation of a cartridge with a same name. > > > > > > > > > > > > It's good that the issue you're running into isn't specific to the > > > > > > AeroGear > > > > > > cartridge. I've tried quite a few times today but I'm not able to > > > > > > reproduce > > > > > > the issue with the AeroGear cartridge or with the kitchensink > > > > > > application > > > > > > using the above steps. I suspect that there is indeed an OpenShift > > > > > > timing > > > > > > issue here. Let's check with the OpenShift team on this. > > > > > > > > > > > > Farah > > > > > > > > > > > > > We are currently doing some more tests on these process. > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > 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 Wed Jan 29 10:41:29 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 29 Jan 2014 10:41:29 -0500 Subject: [aerogear-dev] Sync Day 2: All our cars are frozen in ice Message-ID: <52E92129.3070004@redhat.com> I'm going to take some time to roll up yesterday's Sync Thread so we can stop chasing down individual ideas. Also I am going to propose a potential milestone conga line. I think one of the things that keeps happening in these discussions is everyone has an idea of what sync is but we don't really know what order things should be done or released in. If everyone likes this I'll slice things into JIRA epics. # M1 - Basic revision Control, Data Model, Change Management, Server <-> Client Contract * We seem to be in agreement on a basic set of metadata to be kept for each object. [objectId, revision, object]. * We should have a basic server definition which supports CRUD and keeps our revision numbers in check. This may not be a server product but just a spec that can be implemented by anything at this point. * We should have basic client code which keeps up with revisions, can check the server for new revisions, and alert the user if there is a sync conflict. M2 - Sync Listener w/ Polling based sync listener, conflict management, Serve user management * We define on the client how callbacks will work for alerts when remote data changes * We implement a listener which polls a data source and delivers changes to the user. * We define how conflicts are managed * The server should have a basic authentication and authorization plan for controlling how data is synced M3 - Push based Sync Listener, Network Management, Serverside session management * We will build on our previous Listener work from M2 to include a Push listener that the server can speak to. * We will define in the client how network state and sync state interact. IE how to handle errors in fetching new data when the Listener is alerted. (Exponential back off, retry, etc) * The server will need to have some mechanism for managing user "sessions". This is what users are actively being synced. M4 - "Real Time" Sync Listener. Bidirectional automatic sync * Instead of using push, Realtime Sync uses something like web sockects. to automatically sync local and remote data. * Previous Sync listeners may have to be upgraded to include "upload" abilities. * The server will need to support this as well. M5 - Conflict resolution, Error detection and support * Provide a more comprehensive strategy for managing conflicts. * Provide some automated conflict resolvers * The server could get a larger set of conflict and errors messages M6 - Sync connection Upgrading * The client and server will negotiate when it is appropriate to switch between polling, push, and realtime sync strategies. M7 - Party * We have a sync party. From bruno at abstractj.org Wed Jan 29 11:05:33 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Wed, 29 Jan 2014 14:05:33 -0200 Subject: [aerogear-dev] Sync Day 2: All our cars are frozen in ice In-Reply-To: <52E92129.3070004@redhat.com> References: <52E92129.3070004@redhat.com> Message-ID: +1 Agreed on all points, thanks Summers! -- abstractj On January 29, 2014 at 1:41:38 PM, Summers Pittman (supittma at redhat.com) wrote: > > I'm going to take some time to roll up yesterday's Sync Thread > so we can > stop chasing down individual ideas. > > Also I am going to propose a potential milestone conga line. I > think > one of the things that keeps happening in these discussions is > everyone > has an idea of what sync is but we don't really know what order things > should be done or released in. > > If everyone likes this I'll slice things into JIRA epics. > > # M1 - Basic revision Control, Data Model, Change Management, > Server <-> > Client Contract > > * We seem to be in agreement on a basic set of metadata to be kept > for > each object. [objectId, revision, object]. > * We should have a basic server definition which supports CRUD > and > keeps our revision numbers in check. This may not be a server product > but just a spec that can be implemented by anything at this point. > * We should have basic client code which keeps up with revisions, > can > check the server for new revisions, and alert the user if there > is a > sync conflict. > > > M2 - Sync Listener w/ Polling based sync listener, conflict management, > Serve user management > * We define on the client how callbacks will work for alerts when > remote data changes > * We implement a listener which polls a data source and delivers > changes to the user. > * We define how conflicts are managed > * The server should have a basic authentication and authorization > plan > for controlling how data is synced > > M3 - Push based Sync Listener, Network Management, Serverside > session > management > * We will build on our previous Listener work from M2 to include > a > Push listener that the server can speak to. > * We will define in the client how network state and sync state > interact. IE how to handle errors in fetching new data when the > Listener is alerted. (Exponential back off, retry, etc) > * The server will need to have some mechanism for managing user > "sessions". This is what users are actively being synced. > > M4 - "Real Time" Sync Listener. Bidirectional automatic sync > * Instead of using push, Realtime Sync uses something like web > sockects. to automatically sync local and remote data. > * Previous Sync listeners may have to be upgraded to include "upload" > abilities. > * The server will need to support this as well. > > M5 - Conflict resolution, Error detection and support > * Provide a more comprehensive strategy for managing conflicts. > * Provide some automated conflict resolvers > * The server could get a larger set of conflict and errors messages > > M6 - Sync connection Upgrading > * The client and server will negotiate when it is appropriate > to > switch between polling, push, and realtime sync strategies. > > M7 - Party > * We have a sync party. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > From lholmqui at redhat.com Wed Jan 29 11:18:51 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 29 Jan 2014 11:18:51 -0500 Subject: [aerogear-dev] Sync Day 2: All our cars are frozen in ice In-Reply-To: <52E92129.3070004@redhat.com> References: <52E92129.3070004@redhat.com> Message-ID: <3CFAEC87-A48E-4A23-85D1-8B8FB6BB087B@redhat.com> On Jan 29, 2014, at 10:41 AM, Summers Pittman wrote: > I'm going to take some time to roll up yesterday's Sync Thread so we can > stop chasing down individual ideas. > > Also I am going to propose a potential milestone conga line. I think > one of the things that keeps happening in these discussions is everyone > has an idea of what sync is but we don't really know what order things > should be done or released in. > > If everyone likes this I'll slice things into JIRA epics. > > # M1 - Basic revision Control, Data Model, Change Management, Server <-> > Client Contract > > * We seem to be in agreement on a basic set of metadata to be kept for > each object. [objectId, revision, object]. > * We should have a basic server definition which supports CRUD and > keeps our revision numbers in check. This may not be a server product > but just a spec that can be implemented by anything at this point. > * We should have basic client code which keeps up with revisions, can > check the server for new revisions, and alert the user if there is a > sync conflict. > > > M2 - Sync Listener w/ Polling based sync listener, conflict management, > Serve user management > * We define on the client how callbacks will work for alerts when > remote data changes > * We implement a listener which polls a data source and delivers > changes to the user. > * We define how conflicts are managed > * The server should have a basic authentication and authorization plan > for controlling how data is synced > > M3 - Push based Sync Listener, Network Management, Serverside session > management when we say push here, are we talking about the 3rd party services such as GCM and APN's, if so, not sure that is a great idea > * We will build on our previous Listener work from M2 to include a > Push listener that the server can speak to. > * We will define in the client how network state and sync state > interact. IE how to handle errors in fetching new data when the > Listener is alerted. (Exponential back off, retry, etc) > * The server will need to have some mechanism for managing user > "sessions". This is what users are actively being synced. > > M4 - "Real Time" Sync Listener. Bidirectional automatic sync > * Instead of using push, Realtime Sync uses something like web > sockects. to automatically sync local and remote data. > * Previous Sync listeners may have to be upgraded to include "upload" > abilities. > * The server will need to support this as well. > > M5 - Conflict resolution, Error detection and support > * Provide a more comprehensive strategy for managing conflicts. > * Provide some automated conflict resolvers > * The server could get a larger set of conflict and errors messages > > M6 - Sync connection Upgrading > * The client and server will negotiate when it is appropriate to > switch between polling, push, and realtime sync strategies. > > M7 - Party > * We have a sync party. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From bsutter at redhat.com Wed Jan 29 11:32:40 2014 From: bsutter at redhat.com (Burr Sutter) Date: Wed, 29 Jan 2014 11:32:40 -0500 Subject: [aerogear-dev] Aerogear Cordova Push Plugin In-Reply-To: <0129A2CC-7F68-41BF-83CD-8B36EAEDE5D0@redhat.com> References: <31CB8979-F7A8-4A93-BBB6-1FFE309368DE@redhat.com> <0129A2CC-7F68-41BF-83CD-8B36EAEDE5D0@redhat.com> Message-ID: <1DF762F2-E787-4544-B9F8-6B88D46913E9@redhat.com> My next round of testing, when is onNotification called, please help me think through the scenarios 1) Android: when the app is up and in the foreground - yes 2) iOS: when the app is up and in the foreground - yes 3) Android: when the app is not on - yes (user killed the app) 4) iOS: when the app is not on - yes (user killed the app) 5) Android: when device is on its "lock screen"/screen off - yes - android vibrates 6) * iOS: when device is on its "lock screen"/screen off - sometimes - iOS displays message on lock screen 7) Android: when app is on but in the background - yes 8) ** iOS: when app is on but in the background - NO * seems to depend on how long the device has had its screen off ** this one seems to be a problem - as demonstrated in this video http://screencast.com/t/gtORCvRtNy It seems to me that the iOS app, in the background, should still have its onNotification method called to update its UI My sample project deployed across all devices https://github.com/burrsutter/hellopush On Jan 29, 2014, at 9:59 AM, Jay Balunas wrote: > Wow, this is a detailed investigation! Thanks a lot for digging in like this and the jiras! > > I think getting these addressed, and other UX items for getting started is a big priority for us going forward. As well as how to catch these issues sooner. > > On Jan 28, 2014, at 6:05 PM, Burr Sutter wrote: > >> OK, the real gotcha was... >> https://issues.jboss.org/browse/AGPUSH-525 >> >> There were some smaller issues: >> - I found the readme.md to be inaccurate >> - the video is incomplete http://www.youtube.com/watch?v=a7QVWfEkSpc >> i watched it several times last week, pausing, trying to tease out the commands needed to replicate the experience >> - I believe iOS also requires the console plugin be installed - as device ready was failing due to the console.log the sample app contains. >> - Hand editing the config.xml to provide the App Name and package/bundleID I wanted did not seem to "stick" - I was better off using the command line like so: >> cordova create hellopush com.burrsutter.hellopush "Hello Push" >> instead >> cordova create hellopush and editing the config.xml that was generated >> >> on Android 2.3, the app loads but blows up on launch >> https://issues.jboss.org/browse/AGPUSH-526 >> >> And there is inconsistency between iOS and Android >> https://issues.jboss.org/browse/AGPUSH-527 >> >> And can we "hide" the older UPS docs that focus on curl and bring the ones that focus on the web UI to the foreground? >> For instance, at the bottom of this page: >> http://aerogear.org/docs/guides/aerogear-push-android/google-setup/ >> it links to the curl version - curl is great, but more of an advanced topic >> this is the doc that needs more link love >> http://aerogear.org/docs/guides/AdminConsoleGuide/ >> >> >> I attempted to document the complete set of steps in my readme.txt >> https://github.com/burrsutter/hellopush >> >> I suspect I forgot something along the way >> >> >> On Jan 28, 2014, at 1:25 PM, Burr Sutter wrote: >> >>> https://github.com/aerogear/aerogear-pushplugin-cordova/ >>> My project/notes in the readme.md - it could be that I have missed a step, so I tried to describe my steps carefully in the readme, everything from the command line right now - I will attempt JBoss Tools once the command line steps seem to work. >>> https://github.com/burrsutter/hellopush >>> >>> I have also tested with >>> https://github.com/edewit/aerogear-pushplugin-cordova/tree/agdroid-195 >>> >>> It only works on Android 4.3, funny enough that was the first device I tried - perhaps there is some "affinity" for a single device? :-) >>> >>> It fails on: >>> Android 2.3.4 >>> Android 4.4.2 (two different devices) >>> iOS 6.1.5 >>> iOS 7.0.4 >>> >>> Let's define "fail": >>> - the app always deploys but... >>> - the additional devices never register a device token in the UPS console. I assume I will see "instances" for the various devices >>> - in the case of iOS, the deviceready does not even fire correctly >>> - in the case of Android (all versions), the onError handler is called with "no value for pushconfig" - including the 4.3 where things do work. >>> >>> >>> >>> _______________________________________________ >>> 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/20140129/393efceb/attachment.html From jbalunas at redhat.com Wed Jan 29 11:57:56 2014 From: jbalunas at redhat.com (Jay Balunas) Date: Wed, 29 Jan 2014 11:57:56 -0500 Subject: [aerogear-dev] Sync Day 2: All our cars are frozen in ice In-Reply-To: <52E92129.3070004@redhat.com> References: <52E92129.3070004@redhat.com> Message-ID: Finally got a chance to read through the whole sync thread :-) I'm a big fan keeping it simple, especially for initial releases. So limiting scope of our initial offering will be important imo. I really like the idea of defining the data model, protocol, client contract, etc... separate from a specific implementation. As several have said, those are impl. details that we can change as needed. For example Push - I like the idea of using it for notification of updates (optional, with fallback, & not required), but it should not be a 1.0 priority imo. It should also be something that requires no (or minimal) updates from the app developer when we implement it. At the end of the day it is just another way to let the app know something has changed :-) As for versioning, I'm concerned over having M1, M2, etc.... What do you think of sticking with semver 0.1, 0.2, etc...? On Jan 29, 2014, at 10:41 AM, Summers Pittman wrote: > I'm going to take some time to roll up yesterday's Sync Thread so we can > stop chasing down individual ideas. +1 and thanks > > Also I am going to propose a potential milestone conga line. I think > one of the things that keeps happening in these discussions is everyone > has an idea of what sync is but we don't really know what order things > should be done or released in. > > If everyone likes this I'll slice things into JIRA epics. > > # M1 - Basic revision Control, Data Model, Change Management, Server <-> > Client Contract > > * We seem to be in agreement on a basic set of metadata to be kept for > each object. [objectId, revision, object]. > * We should have a basic server definition which supports CRUD and > keeps our revision numbers in check. This may not be a server product > but just a spec that can be implemented by anything at this point. > * We should have basic client code which keeps up with revisions, can > check the server for new revisions, and alert the user if there is a > sync conflict. I would recommend at this point keep it free from implementation and/or have that implementation be as simple as possible. This way we can get through to the next stage quickly, without debating the specific impl. > > > M2 - Sync Listener w/ Polling based sync listener, conflict management, > Serve user management > * We define on the client how callbacks will work for alerts when > remote data changes > * We implement a listener which polls a data source and delivers > changes to the user. > * We define how conflicts are managed > * The server should have a basic authentication and authorization plan > for controlling how data is synced I agree we need to plan for the future with user management and security integration, but I might move that part to a later point release to keep this as simple as possible. Other than my comments above this looks like a good overall plan :-) Once we nail this down we'll want to talk about possible dates, and how we split time with other priorities as well (developer experience, getting started, examples, site, etc....) > > M3 - Push based Sync Listener, Network Management, Serverside session > management > * We will build on our previous Listener work from M2 to include a > Push listener that the server can speak to. > * We will define in the client how network state and sync state > interact. IE how to handle errors in fetching new data when the > Listener is alerted. (Exponential back off, retry, etc) > * The server will need to have some mechanism for managing user > "sessions". This is what users are actively being synced. > > M4 - "Real Time" Sync Listener. Bidirectional automatic sync > * Instead of using push, Realtime Sync uses something like web > sockects. to automatically sync local and remote data. > * Previous Sync listeners may have to be upgraded to include "upload" > abilities. > * The server will need to support this as well. > > M5 - Conflict resolution, Error detection and support > * Provide a more comprehensive strategy for managing conflicts. > * Provide some automated conflict resolvers > * The server could get a larger set of conflict and errors messages > > M6 - Sync connection Upgrading > * The client and server will negotiate when it is appropriate to > switch between polling, push, and realtime sync strategies. > > M7 - Party > * We have a sync party. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From lholmqui at redhat.com Wed Jan 29 12:00:26 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Wed, 29 Jan 2014 12:00:26 -0500 Subject: [aerogear-dev] Sync Day 2: All our cars are frozen in ice In-Reply-To: References: <52E92129.3070004@redhat.com> Message-ID: <56ECCBC9-B9E5-4A09-95C9-15C9D0D4F183@redhat.com> On Jan 29, 2014, at 11:57 AM, Jay Balunas wrote: > Finally got a chance to read through the whole sync thread :-) > > I'm a big fan keeping it simple, especially for initial releases. So limiting scope of our initial offering will be important imo. > > I really like the idea of defining the data model, protocol, client contract, etc... separate from a specific implementation. As several have said, those are impl. details that we can change as needed. For example Push - I like the idea of using it for notification of updates (optional, with fallback, & not required), but it should not be a 1.0 priority imo. It should also be something that requires no (or minimal) updates from the app developer when we implement it. At the end of the day it is just another way to let the app know something has changed :-) > > As for versioning, I'm concerned over having M1, M2, etc.... What do you think of sticking with semver 0.1, 0.2, etc?? +1 to semver > > On Jan 29, 2014, at 10:41 AM, Summers Pittman wrote: > >> I'm going to take some time to roll up yesterday's Sync Thread so we can >> stop chasing down individual ideas. > > +1 and thanks > >> >> Also I am going to propose a potential milestone conga line. I think >> one of the things that keeps happening in these discussions is everyone >> has an idea of what sync is but we don't really know what order things >> should be done or released in. >> >> If everyone likes this I'll slice things into JIRA epics. >> >> # M1 - Basic revision Control, Data Model, Change Management, Server <-> >> Client Contract >> >> * We seem to be in agreement on a basic set of metadata to be kept for >> each object. [objectId, revision, object]. >> * We should have a basic server definition which supports CRUD and >> keeps our revision numbers in check. This may not be a server product >> but just a spec that can be implemented by anything at this point. >> * We should have basic client code which keeps up with revisions, can >> check the server for new revisions, and alert the user if there is a >> sync conflict. > > I would recommend at this point keep it free from implementation and/or have that implementation be as simple as possible. This way we can get through to the next stage quickly, without debating the specific impl. > >> >> >> M2 - Sync Listener w/ Polling based sync listener, conflict management, >> Serve user management >> * We define on the client how callbacks will work for alerts when >> remote data changes >> * We implement a listener which polls a data source and delivers >> changes to the user. >> * We define how conflicts are managed >> * The server should have a basic authentication and authorization plan >> for controlling how data is synced > > I agree we need to plan for the future with user management and security integration, but I might move that part to a later point release to keep this as simple as possible. > > Other than my comments above this looks like a good overall plan :-) > > Once we nail this down we'll want to talk about possible dates, and how we split time with other priorities as well (developer experience, getting started, examples, site, etc....) > >> >> M3 - Push based Sync Listener, Network Management, Serverside session >> management >> * We will build on our previous Listener work from M2 to include a >> Push listener that the server can speak to. >> * We will define in the client how network state and sync state >> interact. IE how to handle errors in fetching new data when the >> Listener is alerted. (Exponential back off, retry, etc) >> * The server will need to have some mechanism for managing user >> "sessions". This is what users are actively being synced. >> >> M4 - "Real Time" Sync Listener. Bidirectional automatic sync >> * Instead of using push, Realtime Sync uses something like web >> sockects. to automatically sync local and remote data. >> * Previous Sync listeners may have to be upgraded to include "upload" >> abilities. >> * The server will need to support this as well. >> >> M5 - Conflict resolution, Error detection and support >> * Provide a more comprehensive strategy for managing conflicts. >> * Provide some automated conflict resolvers >> * The server could get a larger set of conflict and errors messages >> >> M6 - Sync connection Upgrading >> * The client and server will negotiate when it is appropriate to >> switch between polling, push, and realtime sync strategies. >> >> M7 - Party >> * We have a sync party. >> _______________________________________________ >> 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 Wed Jan 29 12:09:06 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 29 Jan 2014 12:09:06 -0500 Subject: [aerogear-dev] Sync Day 2: All our cars are frozen in ice In-Reply-To: <56ECCBC9-B9E5-4A09-95C9-15C9D0D4F183@redhat.com> References: <52E92129.3070004@redhat.com> <56ECCBC9-B9E5-4A09-95C9-15C9D0D4F183@redhat.com> Message-ID: <52E935B2.5000209@redhat.com> On Wed 29 Jan 2014 12:00:26 PM EST, Lucas Holmquist wrote: > > On Jan 29, 2014, at 11:57 AM, Jay Balunas wrote: > >> Finally got a chance to read through the whole sync thread :-) >> >> I'm a big fan keeping it simple, especially for initial releases. So limiting scope of our initial offering will be important imo. >> >> I really like the idea of defining the data model, protocol, client contract, etc... separate from a specific implementation. As several have said, those are impl. details that we can change as needed. For example Push - I like the idea of using it for notification of updates (optional, with fallback, & not required), but it should not be a 1.0 priority imo. It should also be something that requires no (or minimal) updates from the app developer when we implement it. At the end of the day it is just another way to let the app know something has changed :-) >> >> As for versioning, I'm concerned over having M1, M2, etc.... What do you think of sticking with semver 0.1, 0.2, etc?? > > +1 to semver Yeah, I didn't want to lead with version numbers because people tend to get hung up on numbers (seeing how we have two comments on that already). I'm more worried about ordering and grouping than numbers. By the time we make it into JIRAs and such we will have version numbers. >> >> On Jan 29, 2014, at 10:41 AM, Summers Pittman wrote: >> >>> I'm going to take some time to roll up yesterday's Sync Thread so we can >>> stop chasing down individual ideas. >> >> +1 and thanks >> >>> >>> Also I am going to propose a potential milestone conga line. I think >>> one of the things that keeps happening in these discussions is everyone >>> has an idea of what sync is but we don't really know what order things >>> should be done or released in. >>> >>> If everyone likes this I'll slice things into JIRA epics. >>> >>> # M1 - Basic revision Control, Data Model, Change Management, Server <-> >>> Client Contract >>> >>> * We seem to be in agreement on a basic set of metadata to be kept for >>> each object. [objectId, revision, object]. >>> * We should have a basic server definition which supports CRUD and >>> keeps our revision numbers in check. This may not be a server product >>> but just a spec that can be implemented by anything at this point. >>> * We should have basic client code which keeps up with revisions, can >>> check the server for new revisions, and alert the user if there is a >>> sync conflict. >> >> I would recommend at this point keep it free from implementation and/or have that implementation be as simple as possible. This way we can get through to the next stage quickly, without debating the specific impl. >> >>> >>> >>> M2 - Sync Listener w/ Polling based sync listener, conflict management, >>> Serve user management >>> * We define on the client how callbacks will work for alerts when >>> remote data changes >>> * We implement a listener which polls a data source and delivers >>> changes to the user. >>> * We define how conflicts are managed >>> * The server should have a basic authentication and authorization plan >>> for controlling how data is synced >> >> I agree we need to plan for the future with user management and security integration, but I might move that part to a later point release to keep this as simple as possible. >> >> Other than my comments above this looks like a good overall plan :-) >> >> Once we nail this down we'll want to talk about possible dates, and how we split time with other priorities as well (developer experience, getting started, examples, site, etc....) >> >>> >>> M3 - Push based Sync Listener, Network Management, Serverside session >>> management >>> * We will build on our previous Listener work from M2 to include a >>> Push listener that the server can speak to. >>> * We will define in the client how network state and sync state >>> interact. IE how to handle errors in fetching new data when the >>> Listener is alerted. (Exponential back off, retry, etc) >>> * The server will need to have some mechanism for managing user >>> "sessions". This is what users are actively being synced. >>> >>> M4 - "Real Time" Sync Listener. Bidirectional automatic sync >>> * Instead of using push, Realtime Sync uses something like web >>> sockects. to automatically sync local and remote data. >>> * Previous Sync listeners may have to be upgraded to include "upload" >>> abilities. >>> * The server will need to support this as well. >>> >>> M5 - Conflict resolution, Error detection and support >>> * Provide a more comprehensive strategy for managing conflicts. >>> * Provide some automated conflict resolvers >>> * The server could get a larger set of conflict and errors messages >>> >>> M6 - Sync connection Upgrading >>> * The client and server will negotiate when it is appropriate to >>> switch between polling, push, and realtime sync strategies. >>> >>> M7 - Party >>> * We have a sync party. >>> _______________________________________________ >>> 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 matzew at apache.org Wed Jan 29 12:11:24 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 29 Jan 2014 18:11:24 +0100 Subject: [aerogear-dev] Aerogear Cordova Push Plugin In-Reply-To: <1DF762F2-E787-4544-B9F8-6B88D46913E9@redhat.com> References: <31CB8979-F7A8-4A93-BBB6-1FFE309368DE@redhat.com> <0129A2CC-7F68-41BF-83CD-8B36EAEDE5D0@redhat.com> <1DF762F2-E787-4544-B9F8-6B88D46913E9@redhat.com> Message-ID: On Wed, Jan 29, 2014 at 5:32 PM, Burr Sutter wrote: > My next round of testing, when is onNotification called, please help me > think through the scenarios > 1) Android: when the app is up and in the foreground - yes > 2) iOS: when the app is up and in the foreground - yes > 3) Android: when the app is not on - yes (user killed the app) > not sure, but I *think* when the user used a 'task killer* to 'kill' the app, it's no longer receiving messages (at least at some point I did notice that behaviour w/ AeroDoc-Android) > 4) iOS: when the app is not on - yes (user killed the app) > 5) Android: when device is on its "lock screen"/screen off - yes - android > vibrates > 6) * iOS: when device is on its "lock screen"/screen off - sometimes - iOS > displays message on lock screen > hrm, sometimes ? Let me try that out > 7) Android: when app is on but in the background - yes > 8) ** iOS: when app is on but in the background - NO > hrm... are you on iOS7 ? > > * seems to depend on how long the device has had its screen off > ** this one seems to be a problem - as demonstrated in this video > http://screencast.com/t/gtORCvRtNy > It seems to me that the iOS app, in the background, should still have its > onNotification method called to update its UI > hrm. can't watch that video; will test the sometimes in a bit > > My sample project deployed across all devices > https://github.com/burrsutter/hellopush > > > > > On Jan 29, 2014, at 9:59 AM, Jay Balunas wrote: > > Wow, this is a detailed investigation! Thanks a lot for digging in like > this and the jiras! > > I think getting these addressed, and other UX items for getting started is > a big priority for us going forward. As well as how to catch these issues > sooner. > > On Jan 28, 2014, at 6:05 PM, Burr Sutter wrote: > > OK, the real gotcha was... > https://issues.jboss.org/browse/AGPUSH-525 > > There were some smaller issues: > - I found the readme.md to be inaccurate > - the video is incomplete http://www.youtube.com/watch?v=a7QVWfEkSpc > i watched it several times last week, pausing, trying to tease out the > commands needed to replicate the experience > - I believe iOS also requires the console plugin be installed - as device > ready was failing due to the console.log the sample app contains. > - Hand editing the config.xml to provide the App Name and package/bundleID > I wanted did not seem to "stick" - I was better off using the command line > like so: > cordova create hellopush com.burrsutter.hellopush "Hello Push" > instead > cordova create hellopush and editing the config.xml that was generated > > on Android 2.3, the app loads but blows up on launch > https://issues.jboss.org/browse/AGPUSH-526 > > And there is inconsistency between iOS and Android > https://issues.jboss.org/browse/AGPUSH-527 > > And can we "hide" the older UPS docs that focus on curl and bring the ones > that focus on the web UI to the foreground? > For instance, at the bottom of this page: > http://aerogear.org/docs/guides/aerogear-push-android/google-setup/ > it links to the curl version - curl is great, but more of an advanced topic > this is the doc that needs more link love > http://aerogear.org/docs/guides/AdminConsoleGuide/ > > > I attempted to document the complete set of steps in my readme.txt > https://github.com/burrsutter/hellopush > > I suspect I forgot something along the way > > > On Jan 28, 2014, at 1:25 PM, Burr Sutter wrote: > > https://github.com/aerogear/aerogear-pushplugin-cordova/ > My project/notes in the readme.md - it could be that I have missed a > step, so I tried to describe my steps carefully in the readme, everything > from the command line right now - I will attempt JBoss Tools once the > command line steps seem to work. > https://github.com/burrsutter/hellopush > > I have also tested with > https://github.com/edewit/aerogear-pushplugin-cordova/tree/agdroid-195 > > It only works on Android 4.3, funny enough that was the first device I > tried - perhaps there is some "affinity" for a single device? :-) > > It fails on: > Android 2.3.4 > Android 4.4.2 (two different devices) > iOS 6.1.5 > iOS 7.0.4 > > Let's define "fail": > - the app always deploys but... > - the additional devices never register a device token in the UPS console. > I assume I will see "instances" for the various devices > - in the case of iOS, the deviceready does not even fire correctly > - in the case of Android (all versions), the onError handler is called > with "no value for pushconfig" - including the 4.3 where things do work. > > > > _______________________________________________ > 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 > -- 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/20140129/6c3d9971/attachment.html From supittma at redhat.com Wed Jan 29 12:11:53 2014 From: supittma at redhat.com (Summers Pittman) Date: Wed, 29 Jan 2014 12:11:53 -0500 Subject: [aerogear-dev] Sync Day 2: All our cars are frozen in ice In-Reply-To: <3CFAEC87-A48E-4A23-85D1-8B8FB6BB087B@redhat.com> References: <52E92129.3070004@redhat.com> <3CFAEC87-A48E-4A23-85D1-8B8FB6BB087B@redhat.com> Message-ID: <52E93659.2010505@redhat.com> On 01/29/2014 11:18 AM, Lucas Holmquist wrote: > On Jan 29, 2014, at 10:41 AM, Summers Pittman wrote: > >> I'm going to take some time to roll up yesterday's Sync Thread so we can >> stop chasing down individual ideas. >> >> Also I am going to propose a potential milestone conga line. I think >> one of the things that keeps happening in these discussions is everyone >> has an idea of what sync is but we don't really know what order things >> should be done or released in. >> >> If everyone likes this I'll slice things into JIRA epics. >> >> # M1 - Basic revision Control, Data Model, Change Management, Server <-> >> Client Contract >> >> * We seem to be in agreement on a basic set of metadata to be kept for >> each object. [objectId, revision, object]. >> * We should have a basic server definition which supports CRUD and >> keeps our revision numbers in check. This may not be a server product >> but just a spec that can be implemented by anything at this point. >> * We should have basic client code which keeps up with revisions, can >> check the server for new revisions, and alert the user if there is a >> sync conflict. >> >> >> M2 - Sync Listener w/ Polling based sync listener, conflict management, >> Serve user management >> * We define on the client how callbacks will work for alerts when >> remote data changes >> * We implement a listener which polls a data source and delivers >> changes to the user. >> * We define how conflicts are managed >> * The server should have a basic authentication and authorization plan >> for controlling how data is synced >> >> M3 - Push based Sync Listener, Network Management, Serverside session >> management > when we say push here, are we talking about the 3rd party services such as GCM and APN's, if so, not sure that is a great idea A one way notification service which only guarantees eventual delivery. GCM and APN is an example of this type of service but I explicitly left it out and think we should target consuming messages from the unified push server. This may mean that we implement SimplePush on iOS and Android so we are "pure" and bundle the simple push server into the sync server contract. > >> * We will build on our previous Listener work from M2 to include a >> Push listener that the server can speak to. >> * We will define in the client how network state and sync state >> interact. IE how to handle errors in fetching new data when the >> Listener is alerted. (Exponential back off, retry, etc) >> * The server will need to have some mechanism for managing user >> "sessions". This is what users are actively being synced. >> >> M4 - "Real Time" Sync Listener. Bidirectional automatic sync >> * Instead of using push, Realtime Sync uses something like web >> sockects. to automatically sync local and remote data. >> * Previous Sync listeners may have to be upgraded to include "upload" >> abilities. >> * The server will need to support this as well. >> >> M5 - Conflict resolution, Error detection and support >> * Provide a more comprehensive strategy for managing conflicts. >> * Provide some automated conflict resolvers >> * The server could get a larger set of conflict and errors messages >> >> M6 - Sync connection Upgrading >> * The client and server will negotiate when it is appropriate to >> switch between polling, push, and realtime sync strategies. >> >> M7 - Party >> * We have a sync party. >> _______________________________________________ >> 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 Wed Jan 29 13:58:08 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Wed, 29 Jan 2014 19:58:08 +0100 Subject: [aerogear-dev] Aerogear Cordova Push Plugin In-Reply-To: References: <31CB8979-F7A8-4A93-BBB6-1FFE309368DE@redhat.com> <0129A2CC-7F68-41BF-83CD-8B36EAEDE5D0@redhat.com> <1DF762F2-E787-4544-B9F8-6B88D46913E9@redhat.com> Message-ID: On Wed, Jan 29, 2014 at 6:11 PM, Matthias Wessendorf wrote: > > > > On Wed, Jan 29, 2014 at 5:32 PM, Burr Sutter wrote: > >> My next round of testing, when is onNotification called, please help me >> think through the scenarios >> 1) Android: when the app is up and in the foreground - yes >> 2) iOS: when the app is up and in the foreground - yes >> 3) Android: when the app is not on - yes (user killed the app) >> > > not sure, but I *think* when the user used a 'task killer* to 'kill' the > app, it's no longer receiving messages > (at least at some point I did notice that behaviour w/ AeroDoc-Android) > > >> 4) iOS: when the app is not on - yes (user killed the app) >> 5) Android: when device is on its "lock screen"/screen off - yes - >> android vibrates >> 6) * iOS: when device is on its "lock screen"/screen off - sometimes - >> iOS displays message on lock screen >> > > hrm, sometimes ? > Let me try that out > > >> 7) Android: when app is on but in the background - yes >> 8) ** iOS: when app is on but in the background - NO >> > > hrm... are you on iOS7 ? > > https://issues.jboss.org/browse/AGPUSH-530 > > > >> >> * seems to depend on how long the device has had its screen off >> ** this one seems to be a problem - as demonstrated in this video >> http://screencast.com/t/gtORCvRtNy >> It seems to me that the iOS app, in the background, should still have its >> onNotification method called to update its UI >> > > hrm. can't watch that video; will test the sometimes in a bit > > >> >> My sample project deployed across all devices >> https://github.com/burrsutter/hellopush >> >> >> >> >> On Jan 29, 2014, at 9:59 AM, Jay Balunas wrote: >> >> Wow, this is a detailed investigation! Thanks a lot for digging in like >> this and the jiras! >> >> I think getting these addressed, and other UX items for getting started >> is a big priority for us going forward. As well as how to catch these >> issues sooner. >> >> On Jan 28, 2014, at 6:05 PM, Burr Sutter wrote: >> >> OK, the real gotcha was... >> https://issues.jboss.org/browse/AGPUSH-525 >> >> There were some smaller issues: >> - I found the readme.md to be inaccurate >> - the video is incomplete http://www.youtube.com/watch?v=a7QVWfEkSpc >> i watched it several times last week, pausing, trying to tease out the >> commands needed to replicate the experience >> - I believe iOS also requires the console plugin be installed - as device >> ready was failing due to the console.log the sample app contains. >> - Hand editing the config.xml to provide the App Name and >> package/bundleID I wanted did not seem to "stick" - I was better off using >> the command line like so: >> cordova create hellopush com.burrsutter.hellopush "Hello Push" >> instead >> cordova create hellopush and editing the config.xml that was generated >> >> on Android 2.3, the app loads but blows up on launch >> https://issues.jboss.org/browse/AGPUSH-526 >> >> And there is inconsistency between iOS and Android >> https://issues.jboss.org/browse/AGPUSH-527 >> >> And can we "hide" the older UPS docs that focus on curl and bring the >> ones that focus on the web UI to the foreground? >> For instance, at the bottom of this page: >> http://aerogear.org/docs/guides/aerogear-push-android/google-setup/ >> it links to the curl version - curl is great, but more of an advanced >> topic >> this is the doc that needs more link love >> http://aerogear.org/docs/guides/AdminConsoleGuide/ >> >> >> I attempted to document the complete set of steps in my readme.txt >> https://github.com/burrsutter/hellopush >> >> I suspect I forgot something along the way >> >> >> On Jan 28, 2014, at 1:25 PM, Burr Sutter wrote: >> >> https://github.com/aerogear/aerogear-pushplugin-cordova/ >> My project/notes in the readme.md - it could be that I have missed a >> step, so I tried to describe my steps carefully in the readme, everything >> from the command line right now - I will attempt JBoss Tools once the >> command line steps seem to work. >> https://github.com/burrsutter/hellopush >> >> I have also tested with >> https://github.com/edewit/aerogear-pushplugin-cordova/tree/agdroid-195 >> >> It only works on Android 4.3, funny enough that was the first device I >> tried - perhaps there is some "affinity" for a single device? :-) >> >> It fails on: >> Android 2.3.4 >> Android 4.4.2 (two different devices) >> iOS 6.1.5 >> iOS 7.0.4 >> >> Let's define "fail": >> - the app always deploys but... >> - the additional devices never register a device token in the UPS >> console. I assume I will see "instances" for the various devices >> - in the case of iOS, the deviceready does not even fire correctly >> - in the case of Android (all versions), the onError handler is called >> with "no value for pushconfig" - including the 4.3 where things do work. >> >> >> >> _______________________________________________ >> 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 >> > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > -- 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/20140129/89ad37e4/attachment.html From corinnekrych at gmail.com Wed Jan 29 14:31:12 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Wed, 29 Jan 2014 20:31:12 +0100 Subject: [aerogear-dev] Sync Day 2: All our cars are frozen in ice In-Reply-To: <52E93659.2010505@redhat.com> References: <52E92129.3070004@redhat.com> <3CFAEC87-A48E-4A23-85D1-8B8FB6BB087B@redhat.com> <52E93659.2010505@redhat.com> Message-ID: <61C5B345-45B9-4DB7-B033-093B378014AF@gmail.com> Hi All, #agreed Good to have a plan with associated JIRA to help keep the focus on sync. For v0.1, I?d like to have a demo app epic (recipe app). it would be nice to agree on same demo app (to make sure more or less same features are implemented). I?ve started with Buddies?Hobbies app from Luke[1], I?m planning to add to ios-cookbook for our initial sync. Ok to add a demo JIRA for that? or any better idea for demo app? To me v0.1 and v0.2 could be grouped together. v0.2 should be without auth and authz to stay focus on pluggable confilct mgt and sync/reconciliation trigger(or listener) v0.3 could be focus on auth/authz and then as you stated Another important thing to help collaborative work would be to agree on vocabulary. I like the terms used by Fabrice in its gist[2] like confict and data set reconciliation (in v0.1 we stick to wholesale transfert). In spec doc we should refine vocabulary, let?s have a JIRa for that too? While you?re at planning task summers (doing the Epics) maybe it could be a good idea to start a sync roadmap page in ag.org[3]? ++ Corinne [1] https://github.com/lholmquist/ag-js-ds-poc [2] https://gist.github.com/fabricematrat/8666682 [3] https://github.com/aerogear/aerogear.org/tree/master/docs/planning/roadmaps On 29 Jan 2014, at 18:11, Summers Pittman wrote: > On 01/29/2014 11:18 AM, Lucas Holmquist wrote: >> On Jan 29, 2014, at 10:41 AM, Summers Pittman wrote: >> >>> I'm going to take some time to roll up yesterday's Sync Thread so we can >>> stop chasing down individual ideas. >>> >>> Also I am going to propose a potential milestone conga line. I think >>> one of the things that keeps happening in these discussions is everyone >>> has an idea of what sync is but we don't really know what order things >>> should be done or released in. >>> >>> If everyone likes this I'll slice things into JIRA epics. >>> >>> # M1 - Basic revision Control, Data Model, Change Management, Server <-> >>> Client Contract >>> >>> * We seem to be in agreement on a basic set of metadata to be kept for >>> each object. [objectId, revision, object]. >>> * We should have a basic server definition which supports CRUD and >>> keeps our revision numbers in check. This may not be a server product >>> but just a spec that can be implemented by anything at this point. >>> * We should have basic client code which keeps up with revisions, can >>> check the server for new revisions, and alert the user if there is a >>> sync conflict. >>> >>> >>> M2 - Sync Listener w/ Polling based sync listener, conflict management, >>> Serve user management >>> * We define on the client how callbacks will work for alerts when >>> remote data changes >>> * We implement a listener which polls a data source and delivers >>> changes to the user. >>> * We define how conflicts are managed >>> * The server should have a basic authentication and authorization plan >>> for controlling how data is synced >>> >>> M3 - Push based Sync Listener, Network Management, Serverside session >>> management >> when we say push here, are we talking about the 3rd party services such as GCM and APN's, if so, not sure that is a great idea > A one way notification service which only guarantees eventual delivery. > GCM and APN is an example of this type of service but I explicitly left > it out and think we should target consuming messages from the unified > push server. This may mean that we implement SimplePush on iOS and > Android so we are "pure" and bundle the simple push server into the sync > server contract. >> >>> * We will build on our previous Listener work from M2 to include a >>> Push listener that the server can speak to. >>> * We will define in the client how network state and sync state >>> interact. IE how to handle errors in fetching new data when the >>> Listener is alerted. (Exponential back off, retry, etc) >>> * The server will need to have some mechanism for managing user >>> "sessions". This is what users are actively being synced. >>> >>> M4 - "Real Time" Sync Listener. Bidirectional automatic sync >>> * Instead of using push, Realtime Sync uses something like web >>> sockects. to automatically sync local and remote data. >>> * Previous Sync listeners may have to be upgraded to include "upload" >>> abilities. >>> * The server will need to support this as well. >>> >>> M5 - Conflict resolution, Error detection and support >>> * Provide a more comprehensive strategy for managing conflicts. >>> * Provide some automated conflict resolvers >>> * The server could get a larger set of conflict and errors messages >>> >>> M6 - Sync connection Upgrading >>> * The client and server will negotiate when it is appropriate to >>> switch between polling, push, and realtime sync strategies. >>> >>> M7 - Party >>> * We have a sync party. >>> _______________________________________________ >>> 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 matzew at apache.org Thu Jan 30 03:22:09 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 30 Jan 2014 09:22:09 +0100 Subject: [aerogear-dev] Sync Day 2: All our cars are frozen in ice In-Reply-To: <52E92129.3070004@redhat.com> References: <52E92129.3070004@redhat.com> Message-ID: On Wed, Jan 29, 2014 at 4:41 PM, Summers Pittman wrote: > I'm going to take some time to roll up yesterday's Sync Thread so we can > stop chasing down individual ideas. > > Also I am going to propose a potential milestone conga line. I think > one of the things that keeps happening in these discussions is everyone > has an idea of what sync is but we don't really know what order things > should be done or released in. > > If everyone likes this I'll slice things into JIRA epics. > > # M1 - Basic revision Control, Data Model, Change Management, Server <-> > Client Contract > > * We seem to be in agreement on a basic set of metadata to be kept for > each object. [objectId, revision, object]. > * We should have a basic server definition which supports CRUD and > keeps our revision numbers in check. This may not be a server product > but just a spec that can be implemented by anything at this point. > * We should have basic client code which keeps up with revisions, can > check the server for new revisions, and alert the user if there is a > sync conflict. > what about looking at local changes ? Is that implied here? > > > M2 - Sync Listener w/ Polling based sync listener, conflict management, > Serve user management > * We define on the client how callbacks will work for alerts when > remote data changes > * We implement a listener which polls a data source and delivers > changes to the user. > * We define how conflicts are managed > * The server should have a basic authentication and authorization plan > for controlling how data is synced > Not sure, but: could/should a user get the chance to kinda control that 'change' (e.g. veto) ? > > M3 - Push based Sync Listener, Network Management, Serverside session > management > * We will build on our previous Listener work from M2 to include a > Push listener that the server can speak to. > * We will define in the client how network state and sync state > interact. IE how to handle errors in fetching new data when the > Listener is alerted. (Exponential back off, retry, etc) > * The server will need to have some mechanism for managing user > "sessions". This is what users are actively being synced. > I still think this is optional :-) I think generally it's nice to have feature that the "sync-server" can send 'update requests' to the unifiedpush server; However IMO the clients should still mark this as optional (again a user (on iOS/FFOS) can decide she is not interested in push notification; Than all the offerings from M3 would just not work > > M4 - "Real Time" Sync Listener. Bidirectional automatic sync > * Instead of using push, Realtime Sync uses something like web > sockects. to automatically sync local and remote data. > Should be the default when an app is active and open (putting platform limits aside) > * Previous Sync listeners may have to be upgraded to include "upload" > abilities. > * The server will need to support this as well. > This step might allow us (*later*) to plug in some sort of OT (Operational Transform) implementation > > M5 - Conflict resolution, Error detection and support > * Provide a more comprehensive strategy for managing conflicts. > * Provide some automated conflict resolvers > * The server could get a larger set of conflict and errors messages > +1 > > M6 - Sync connection Upgrading > * The client and server will negotiate when it is appropriate to > switch between polling, push, and realtime sync strategies. > yeah, sounds good > > M7 - Party > * We have a sync party. > J?germeister and fine brews from Russian River -> yay! > _______________________________________________ > 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/20140130/68e82390/attachment-0001.html From matzew at apache.org Thu Jan 30 03:32:51 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 30 Jan 2014 09:32:51 +0100 Subject: [aerogear-dev] Sync Day 2: All our cars are frozen in ice In-Reply-To: References: <52E92129.3070004@redhat.com> Message-ID: On Wed, Jan 29, 2014 at 5:57 PM, Jay Balunas wrote: > Finally got a chance to read through the whole sync thread :-) > > I'm a big fan keeping it simple, especially for initial releases. So > limiting scope of our initial offering will be important imo. > > I really like the idea of defining the data model, protocol, client > contract, etc... separate from a specific implementation. As several have > said, those are impl. details that we can change as needed. For example > Push - I like the idea of using it for notification of updates (optional, > with fallback, & not required), but it should not be a 1.0 priority imo. > It should also be something that requires no (or minimal) updates from the > app developer when we implement it. At the end of the day it is just > another way to let the app know something has changed :-) > > As for versioning, I'm concerned over having M1, M2, etc.... What do you > think of sticking with semver 0.1, 0.2, etc...? > > On Jan 29, 2014, at 10:41 AM, Summers Pittman wrote: > > > I'm going to take some time to roll up yesterday's Sync Thread so we can > > stop chasing down individual ideas. > > +1 and thanks > > > > > Also I am going to propose a potential milestone conga line. I think > > one of the things that keeps happening in these discussions is everyone > > has an idea of what sync is but we don't really know what order things > > should be done or released in. > > > > If everyone likes this I'll slice things into JIRA epics. > > > > # M1 - Basic revision Control, Data Model, Change Management, Server <-> > > Client Contract > > > > * We seem to be in agreement on a basic set of metadata to be kept for > > each object. [objectId, revision, object]. > > * We should have a basic server definition which supports CRUD and > > keeps our revision numbers in check. This may not be a server product > > but just a spec that can be implemented by anything at this point. > > * We should have basic client code which keeps up with revisions, can > > check the server for new revisions, and alert the user if there is a > > sync conflict. > > I would recommend at this point keep it free from implementation and/or > have that implementation be as simple as possible. This way we can get > through to the next stage quickly, without debating the specific impl. > what do you mean ? Just specs and papers ? Not sure I follow on keeping it "free from implementation" > > > > > > > M2 - Sync Listener w/ Polling based sync listener, conflict management, > > Serve user management > > * We define on the client how callbacks will work for alerts when > > remote data changes > > * We implement a listener which polls a data source and delivers > > changes to the user. > > * We define how conflicts are managed > > * The server should have a basic authentication and authorization plan > > for controlling how data is synced > > I agree we need to plan for the future with user management and security > integration, but I might move that part to a later point release to keep > this as simple as possible. > user mgmt - keycloak :-) Ok, we should not really go there, yet :-)) > Other than my comments above this looks like a good overall plan :-) > > Once we nail this down we'll want to talk about possible dates, and how we > split time with other priorities as well (developer experience, getting > started, examples, site, etc....) > > > > > M3 - Push based Sync Listener, Network Management, Serverside session > > management > > * We will build on our previous Listener work from M2 to include a > > Push listener that the server can speak to. > > * We will define in the client how network state and sync state > > interact. IE how to handle errors in fetching new data when the > > Listener is alerted. (Exponential back off, retry, etc) > > * The server will need to have some mechanism for managing user > > "sessions". This is what users are actively being synced. > > > > M4 - "Real Time" Sync Listener. Bidirectional automatic sync > > * Instead of using push, Realtime Sync uses something like web > > sockects. to automatically sync local and remote data. > > * Previous Sync listeners may have to be upgraded to include "upload" > > abilities. > > * The server will need to support this as well. > > > > M5 - Conflict resolution, Error detection and support > > * Provide a more comprehensive strategy for managing conflicts. > > * Provide some automated conflict resolvers > > * The server could get a larger set of conflict and errors messages > > > > M6 - Sync connection Upgrading > > * The client and server will negotiate when it is appropriate to > > switch between polling, push, and realtime sync strategies. > > > > M7 - Party > > * We have a sync party. > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140130/c0a6ecbe/attachment.html From matzew at apache.org Thu Jan 30 03:33:10 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 30 Jan 2014 09:33:10 +0100 Subject: [aerogear-dev] Sync Day 2: All our cars are frozen in ice In-Reply-To: <56ECCBC9-B9E5-4A09-95C9-15C9D0D4F183@redhat.com> References: <52E92129.3070004@redhat.com> <56ECCBC9-B9E5-4A09-95C9-15C9D0D4F183@redhat.com> Message-ID: On Wed, Jan 29, 2014 at 6:00 PM, Lucas Holmquist wrote: > > On Jan 29, 2014, at 11:57 AM, Jay Balunas wrote: > > > Finally got a chance to read through the whole sync thread :-) > > > > I'm a big fan keeping it simple, especially for initial releases. So > limiting scope of our initial offering will be important imo. > > > > I really like the idea of defining the data model, protocol, client > contract, etc... separate from a specific implementation. As several have > said, those are impl. details that we can change as needed. For example > Push - I like the idea of using it for notification of updates (optional, > with fallback, & not required), but it should not be a 1.0 priority imo. > It should also be something that requires no (or minimal) updates from the > app developer when we implement it. At the end of the day it is just > another way to let the app know something has changed :-) > > > > As for versioning, I'm concerned over having M1, M2, etc.... What do > you think of sticking with semver 0.1, 0.2, etc...? > > +1 to semver > +1 -- 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/20140130/157440fd/attachment.html From matzew at apache.org Thu Jan 30 03:38:19 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 30 Jan 2014 09:38:19 +0100 Subject: [aerogear-dev] Sync Day 2: All our cars are frozen in ice In-Reply-To: <61C5B345-45B9-4DB7-B033-093B378014AF@gmail.com> References: <52E92129.3070004@redhat.com> <3CFAEC87-A48E-4A23-85D1-8B8FB6BB087B@redhat.com> <52E93659.2010505@redhat.com> <61C5B345-45B9-4DB7-B033-093B378014AF@gmail.com> Message-ID: On Wed, Jan 29, 2014 at 8:31 PM, Corinne Krych wrote: > Hi All, > > #agreed Good to have a plan with associated JIRA to help keep the focus on > sync. > +1 > For v0.1, I'd like to have a demo app epic (recipe app). it would be nice > to agree on same demo app (to make sure more or less same features are > implemented). I've started with Buddies'Hobbies app from Luke[1], I'm > planning to add to ios-cookbook for our initial sync. > Ok to add a demo JIRA for that? or any better idea for demo app? > You mean a demo app in addition, right? > > To me v0.1 and v0.2 could be grouped together. > v0.2 should be without auth and authz to stay focus on pluggable confilct > mgt and sync/reconciliation trigger(or listener) > hrm, not sure tbh > v0.3 could be focus on auth/authz > and then as you stated > > Another important thing to help collaborative work would be to agree on > vocabulary. I like the terms used by Fabrice in its gist[2] like confict > and data set reconciliation (in v0.1 we stick to wholesale transfert). > In spec doc we should refine vocabulary, let's have a JIRa for that too... > > While you're at planning task summers (doing the Epics) maybe it could be > a good idea to start a sync roadmap page in ag.org[3]? > > ++ > Corinne > [1] https://github.com/lholmquist/ag-js-ds-poc > [2] https://gist.github.com/fabricematrat/8666682 > [3] > https://github.com/aerogear/aerogear.org/tree/master/docs/planning/roadmaps > On 29 Jan 2014, at 18:11, Summers Pittman wrote: > > On 01/29/2014 11:18 AM, Lucas Holmquist wrote: > >> On Jan 29, 2014, at 10:41 AM, Summers Pittman > wrote: > >> > >>> I'm going to take some time to roll up yesterday's Sync Thread so we > can > >>> stop chasing down individual ideas. > >>> > >>> Also I am going to propose a potential milestone conga line. I think > >>> one of the things that keeps happening in these discussions is everyone > >>> has an idea of what sync is but we don't really know what order things > >>> should be done or released in. > >>> > >>> If everyone likes this I'll slice things into JIRA epics. > >>> > >>> # M1 - Basic revision Control, Data Model, Change Management, Server > <-> > >>> Client Contract > >>> > >>> * We seem to be in agreement on a basic set of metadata to be kept for > >>> each object. [objectId, revision, object]. > >>> * We should have a basic server definition which supports CRUD and > >>> keeps our revision numbers in check. This may not be a server product > >>> but just a spec that can be implemented by anything at this point. > >>> * We should have basic client code which keeps up with revisions, can > >>> check the server for new revisions, and alert the user if there is a > >>> sync conflict. > >>> > >>> > >>> M2 - Sync Listener w/ Polling based sync listener, conflict management, > >>> Serve user management > >>> * We define on the client how callbacks will work for alerts when > >>> remote data changes > >>> * We implement a listener which polls a data source and delivers > >>> changes to the user. > >>> * We define how conflicts are managed > >>> * The server should have a basic authentication and authorization plan > >>> for controlling how data is synced > >>> > >>> M3 - Push based Sync Listener, Network Management, Serverside session > >>> management > >> when we say push here, are we talking about the 3rd party services such > as GCM and APN's, if so, not sure that is a great idea > > A one way notification service which only guarantees eventual delivery. > > GCM and APN is an example of this type of service but I explicitly left > > it out and think we should target consuming messages from the unified > > push server. This may mean that we implement SimplePush on iOS and > > Android so we are "pure" and bundle the simple push server into the sync > > server contract. > >> > >>> * We will build on our previous Listener work from M2 to include a > >>> Push listener that the server can speak to. > >>> * We will define in the client how network state and sync state > >>> interact. IE how to handle errors in fetching new data when the > >>> Listener is alerted. (Exponential back off, retry, etc) > >>> * The server will need to have some mechanism for managing user > >>> "sessions". This is what users are actively being synced. > >>> > >>> M4 - "Real Time" Sync Listener. Bidirectional automatic sync > >>> * Instead of using push, Realtime Sync uses something like web > >>> sockects. to automatically sync local and remote data. > >>> * Previous Sync listeners may have to be upgraded to include "upload" > >>> abilities. > >>> * The server will need to support this as well. > >>> > >>> M5 - Conflict resolution, Error detection and support > >>> * Provide a more comprehensive strategy for managing conflicts. > >>> * Provide some automated conflict resolvers > >>> * The server could get a larger set of conflict and errors messages > >>> > >>> M6 - Sync connection Upgrading > >>> * The client and server will negotiate when it is appropriate to > >>> switch between polling, push, and realtime sync strategies. > >>> > >>> M7 - Party > >>> * We have a sync party. > >>> _______________________________________________ > >>> 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 > -- 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/20140130/0ec625c6/attachment-0001.html From matzew at apache.org Thu Jan 30 03:39:44 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 30 Jan 2014 09:39:44 +0100 Subject: [aerogear-dev] Sync Day 2: All our cars are frozen in ice In-Reply-To: <52E92129.3070004@redhat.com> References: <52E92129.3070004@redhat.com> Message-ID: Oh, did you get a chance to read the mail/gist from Fabrice? * http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Conflicts-amp-Reconciliation-td6026.html * https://gist.github.com/fabricematrat/8666682 -M On Wed, Jan 29, 2014 at 4:41 PM, Summers Pittman wrote: > I'm going to take some time to roll up yesterday's Sync Thread so we can > stop chasing down individual ideas. > > Also I am going to propose a potential milestone conga line. I think > one of the things that keeps happening in these discussions is everyone > has an idea of what sync is but we don't really know what order things > should be done or released in. > > If everyone likes this I'll slice things into JIRA epics. > > # M1 - Basic revision Control, Data Model, Change Management, Server <-> > Client Contract > > * We seem to be in agreement on a basic set of metadata to be kept for > each object. [objectId, revision, object]. > * We should have a basic server definition which supports CRUD and > keeps our revision numbers in check. This may not be a server product > but just a spec that can be implemented by anything at this point. > * We should have basic client code which keeps up with revisions, can > check the server for new revisions, and alert the user if there is a > sync conflict. > > > M2 - Sync Listener w/ Polling based sync listener, conflict management, > Serve user management > * We define on the client how callbacks will work for alerts when > remote data changes > * We implement a listener which polls a data source and delivers > changes to the user. > * We define how conflicts are managed > * The server should have a basic authentication and authorization plan > for controlling how data is synced > > M3 - Push based Sync Listener, Network Management, Serverside session > management > * We will build on our previous Listener work from M2 to include a > Push listener that the server can speak to. > * We will define in the client how network state and sync state > interact. IE how to handle errors in fetching new data when the > Listener is alerted. (Exponential back off, retry, etc) > * The server will need to have some mechanism for managing user > "sessions". This is what users are actively being synced. > > M4 - "Real Time" Sync Listener. Bidirectional automatic sync > * Instead of using push, Realtime Sync uses something like web > sockects. to automatically sync local and remote data. > * Previous Sync listeners may have to be upgraded to include "upload" > abilities. > * The server will need to support this as well. > > M5 - Conflict resolution, Error detection and support > * Provide a more comprehensive strategy for managing conflicts. > * Provide some automated conflict resolvers > * The server could get a larger set of conflict and errors messages > > M6 - Sync connection Upgrading > * The client and server will negotiate when it is appropriate to > switch between polling, push, and realtime sync strategies. > > M7 - Party > * We have a sync party. > _______________________________________________ > 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/20140130/110f755a/attachment.html From corinnekrych at gmail.com Thu Jan 30 03:40:51 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 30 Jan 2014 09:40:51 +0100 Subject: [aerogear-dev] Sync Day 2: All our cars are frozen in ice In-Reply-To: References: <52E92129.3070004@redhat.com> <3CFAEC87-A48E-4A23-85D1-8B8FB6BB087B@redhat.com> <52E93659.2010505@redhat.com> <61C5B345-45B9-4DB7-B033-093B378014AF@gmail.com> Message-ID: <632550AB-FEA1-4F80-9150-A7DFFCB84140@gmail.com> On 30 Jan 2014, at 09:38, Matthias Wessendorf wrote: > > > > On Wed, Jan 29, 2014 at 8:31 PM, Corinne Krych wrote: > Hi All, > > #agreed Good to have a plan with associated JIRA to help keep the focus on sync. > > +1 > > For v0.1, I?d like to have a demo app epic (recipe app). it would be nice to agree on same demo app (to make sure more or less same features are implemented). I?ve started with Buddies?Hobbies app from Luke[1], I?m planning to add to ios-cookbook for our initial sync. > Ok to add a demo JIRA for that? or any better idea for demo app? > > You mean a demo app in addition, right? Yes, a demo app to test our use cases for v0.1 keep it simple like Luke?s demo > > > To me v0.1 and v0.2 could be grouped together. > v0.2 should be without auth and authz to stay focus on pluggable confilct mgt and sync/reconciliation trigger(or listener) > > hrm, not sure tbh Not sure for what grouped 0.1/0.2 or v0.2 without Auth Authz? > > v0.3 could be focus on auth/authz > and then as you stated > > Another important thing to help collaborative work would be to agree on vocabulary. I like the terms used by Fabrice in its gist[2] like confict and data set reconciliation (in v0.1 we stick to wholesale transfert). > In spec doc we should refine vocabulary, let?s have a JIRa for that too? > > While you?re at planning task summers (doing the Epics) maybe it could be a good idea to start a sync roadmap page in ag.org[3]? > > ++ > Corinne > [1] https://github.com/lholmquist/ag-js-ds-poc > [2] https://gist.github.com/fabricematrat/8666682 > [3] https://github.com/aerogear/aerogear.org/tree/master/docs/planning/roadmaps > On 29 Jan 2014, at 18:11, Summers Pittman wrote: > > On 01/29/2014 11:18 AM, Lucas Holmquist wrote: > >> On Jan 29, 2014, at 10:41 AM, Summers Pittman wrote: > >> > >>> I'm going to take some time to roll up yesterday's Sync Thread so we can > >>> stop chasing down individual ideas. > >>> > >>> Also I am going to propose a potential milestone conga line. I think > >>> one of the things that keeps happening in these discussions is everyone > >>> has an idea of what sync is but we don't really know what order things > >>> should be done or released in. > >>> > >>> If everyone likes this I'll slice things into JIRA epics. > >>> > >>> # M1 - Basic revision Control, Data Model, Change Management, Server <-> > >>> Client Contract > >>> > >>> * We seem to be in agreement on a basic set of metadata to be kept for > >>> each object. [objectId, revision, object]. > >>> * We should have a basic server definition which supports CRUD and > >>> keeps our revision numbers in check. This may not be a server product > >>> but just a spec that can be implemented by anything at this point. > >>> * We should have basic client code which keeps up with revisions, can > >>> check the server for new revisions, and alert the user if there is a > >>> sync conflict. > >>> > >>> > >>> M2 - Sync Listener w/ Polling based sync listener, conflict management, > >>> Serve user management > >>> * We define on the client how callbacks will work for alerts when > >>> remote data changes > >>> * We implement a listener which polls a data source and delivers > >>> changes to the user. > >>> * We define how conflicts are managed > >>> * The server should have a basic authentication and authorization plan > >>> for controlling how data is synced > >>> > >>> M3 - Push based Sync Listener, Network Management, Serverside session > >>> management > >> when we say push here, are we talking about the 3rd party services such as GCM and APN's, if so, not sure that is a great idea > > A one way notification service which only guarantees eventual delivery. > > GCM and APN is an example of this type of service but I explicitly left > > it out and think we should target consuming messages from the unified > > push server. This may mean that we implement SimplePush on iOS and > > Android so we are "pure" and bundle the simple push server into the sync > > server contract. > >> > >>> * We will build on our previous Listener work from M2 to include a > >>> Push listener that the server can speak to. > >>> * We will define in the client how network state and sync state > >>> interact. IE how to handle errors in fetching new data when the > >>> Listener is alerted. (Exponential back off, retry, etc) > >>> * The server will need to have some mechanism for managing user > >>> "sessions". This is what users are actively being synced. > >>> > >>> M4 - "Real Time" Sync Listener. Bidirectional automatic sync > >>> * Instead of using push, Realtime Sync uses something like web > >>> sockects. to automatically sync local and remote data. > >>> * Previous Sync listeners may have to be upgraded to include "upload" > >>> abilities. > >>> * The server will need to support this as well. > >>> > >>> M5 - Conflict resolution, Error detection and support > >>> * Provide a more comprehensive strategy for managing conflicts. > >>> * Provide some automated conflict resolvers > >>> * The server could get a larger set of conflict and errors messages > >>> > >>> M6 - Sync connection Upgrading > >>> * The client and server will negotiate when it is appropriate to > >>> switch between polling, push, and realtime sync strategies. > >>> > >>> M7 - Party > >>> * We have a sync party. > >>> _______________________________________________ > >>> 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 > > > > -- > 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 From matzew at apache.org Thu Jan 30 03:48:03 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 30 Jan 2014 09:48:03 +0100 Subject: [aerogear-dev] Sync Day 2: All our cars are frozen in ice In-Reply-To: <632550AB-FEA1-4F80-9150-A7DFFCB84140@gmail.com> References: <52E92129.3070004@redhat.com> <3CFAEC87-A48E-4A23-85D1-8B8FB6BB087B@redhat.com> <52E93659.2010505@redhat.com> <61C5B345-45B9-4DB7-B033-093B378014AF@gmail.com> <632550AB-FEA1-4F80-9150-A7DFFCB84140@gmail.com> Message-ID: On Thu, Jan 30, 2014 at 9:40 AM, Corinne Krych wrote: > > On 30 Jan 2014, at 09:38, Matthias Wessendorf wrote: > > > > > > > > > On Wed, Jan 29, 2014 at 8:31 PM, Corinne Krych > wrote: > > Hi All, > > > > #agreed Good to have a plan with associated JIRA to help keep the focus > on sync. > > > > +1 > > > > For v0.1, I'd like to have a demo app epic (recipe app). it would be > nice to agree on same demo app (to make sure more or less same features are > implemented). I've started with Buddies'Hobbies app from Luke[1], I'm > planning to add to ios-cookbook for our initial sync. > > Ok to add a demo JIRA for that? or any better idea for demo app? > > > > You mean a demo app in addition, right? > > Yes, a demo app to test our use cases for v0.1 > keep it simple like Luke's demo > yeah :-) I agree > > > > > > > To me v0.1 and v0.2 could be grouped together. > > v0.2 should be without auth and authz to stay focus on pluggable > confilct mgt and sync/reconciliation trigger(or listener) > > > > hrm, not sure tbh > > Not sure for what grouped 0.1/0.2 or v0.2 without Auth Authz? > not sure on the grouping > > > > > v0.3 could be focus on auth/authz > > and then as you stated > > > > Another important thing to help collaborative work would be to agree on > vocabulary. I like the terms used by Fabrice in its gist[2] like confict > and data set reconciliation (in v0.1 we stick to wholesale transfert). > > In spec doc we should refine vocabulary, let's have a JIRa for that too... > > > > While you're at planning task summers (doing the Epics) maybe it could > be a good idea to start a sync roadmap page in ag.org[3]? > > > > ++ > > Corinne > > [1] https://github.com/lholmquist/ag-js-ds-poc > > [2] https://gist.github.com/fabricematrat/8666682 > > [3] > https://github.com/aerogear/aerogear.org/tree/master/docs/planning/roadmaps > > On 29 Jan 2014, at 18:11, Summers Pittman wrote: > > > On 01/29/2014 11:18 AM, Lucas Holmquist wrote: > > >> On Jan 29, 2014, at 10:41 AM, Summers Pittman > wrote: > > >> > > >>> I'm going to take some time to roll up yesterday's Sync Thread so we > can > > >>> stop chasing down individual ideas. > > >>> > > >>> Also I am going to propose a potential milestone conga line. I think > > >>> one of the things that keeps happening in these discussions is > everyone > > >>> has an idea of what sync is but we don't really know what order > things > > >>> should be done or released in. > > >>> > > >>> If everyone likes this I'll slice things into JIRA epics. > > >>> > > >>> # M1 - Basic revision Control, Data Model, Change Management, Server > <-> > > >>> Client Contract > > >>> > > >>> * We seem to be in agreement on a basic set of metadata to be kept > for > > >>> each object. [objectId, revision, object]. > > >>> * We should have a basic server definition which supports CRUD and > > >>> keeps our revision numbers in check. This may not be a server > product > > >>> but just a spec that can be implemented by anything at this point. > > >>> * We should have basic client code which keeps up with revisions, > can > > >>> check the server for new revisions, and alert the user if there is a > > >>> sync conflict. > > >>> > > >>> > > >>> M2 - Sync Listener w/ Polling based sync listener, conflict > management, > > >>> Serve user management > > >>> * We define on the client how callbacks will work for alerts when > > >>> remote data changes > > >>> * We implement a listener which polls a data source and delivers > > >>> changes to the user. > > >>> * We define how conflicts are managed > > >>> * The server should have a basic authentication and authorization > plan > > >>> for controlling how data is synced > > >>> > > >>> M3 - Push based Sync Listener, Network Management, Serverside session > > >>> management > > >> when we say push here, are we talking about the 3rd party services > such as GCM and APN's, if so, not sure that is a great idea > > > A one way notification service which only guarantees eventual delivery. > > > GCM and APN is an example of this type of service but I explicitly left > > > it out and think we should target consuming messages from the unified > > > push server. This may mean that we implement SimplePush on iOS and > > > Android so we are "pure" and bundle the simple push server into the > sync > > > server contract. > > >> > > >>> * We will build on our previous Listener work from M2 to include a > > >>> Push listener that the server can speak to. > > >>> * We will define in the client how network state and sync state > > >>> interact. IE how to handle errors in fetching new data when the > > >>> Listener is alerted. (Exponential back off, retry, etc) > > >>> * The server will need to have some mechanism for managing user > > >>> "sessions". This is what users are actively being synced. > > >>> > > >>> M4 - "Real Time" Sync Listener. Bidirectional automatic sync > > >>> * Instead of using push, Realtime Sync uses something like web > > >>> sockects. to automatically sync local and remote data. > > >>> * Previous Sync listeners may have to be upgraded to include > "upload" > > >>> abilities. > > >>> * The server will need to support this as well. > > >>> > > >>> M5 - Conflict resolution, Error detection and support > > >>> * Provide a more comprehensive strategy for managing conflicts. > > >>> * Provide some automated conflict resolvers > > >>> * The server could get a larger set of conflict and errors messages > > >>> > > >>> M6 - Sync connection Upgrading > > >>> * The client and server will negotiate when it is appropriate to > > >>> switch between polling, push, and realtime sync strategies. > > >>> > > >>> M7 - Party > > >>> * We have a sync party. > > >>> _______________________________________________ > > >>> 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 > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140130/601e8e9c/attachment-0001.html From corinnekrych at gmail.com Thu Jan 30 03:54:54 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 30 Jan 2014 09:54:54 +0100 Subject: [aerogear-dev] Sync Day 2: All our cars are frozen in ice In-Reply-To: References: <52E92129.3070004@redhat.com> <3CFAEC87-A48E-4A23-85D1-8B8FB6BB087B@redhat.com> <52E93659.2010505@redhat.com> <61C5B345-45B9-4DB7-B033-093B378014AF@gmail.com> <632550AB-FEA1-4F80-9150-A7DFFCB84140@gmail.com> Message-ID: <79B66FA7-D3F5-40B5-9229-66FFA646BB2F@gmail.com> On 30 Jan 2014, at 09:48, Matthias Wessendorf wrote: > > > > On Thu, Jan 30, 2014 at 9:40 AM, Corinne Krych wrote: > > On 30 Jan 2014, at 09:38, Matthias Wessendorf wrote: > > > > > > > > > On Wed, Jan 29, 2014 at 8:31 PM, Corinne Krych wrote: > > Hi All, > > > > #agreed Good to have a plan with associated JIRA to help keep the focus on sync. > > > > +1 > > > > For v0.1, I?d like to have a demo app epic (recipe app). it would be nice to agree on same demo app (to make sure more or less same features are implemented). I?ve started with Buddies?Hobbies app from Luke[1], I?m planning to add to ios-cookbook for our initial sync. > > Ok to add a demo JIRA for that? or any better idea for demo app? > > > > You mean a demo app in addition, right? > > Yes, a demo app to test our use cases for v0.1 > keep it simple like Luke?s demo > > yeah :-) I agree > > > > > > > > To me v0.1 and v0.2 could be grouped together. > > v0.2 should be without auth and authz to stay focus on pluggable confilct mgt and sync/reconciliation trigger(or listener) > > > > hrm, not sure tbh > > Not sure for what grouped 0.1/0.2 or v0.2 without Auth Authz? > > not sure on the grouping ok no grouping then 0.1 - set up demo, sync pipe (find a name), detect conflics 0.2 - pluggable conflict resolution 0.3 - Auth/authz ok like this? > > > > > > v0.3 could be focus on auth/authz > > and then as you stated > > > > Another important thing to help collaborative work would be to agree on vocabulary. I like the terms used by Fabrice in its gist[2] like confict and data set reconciliation (in v0.1 we stick to wholesale transfert). > > In spec doc we should refine vocabulary, let?s have a JIRa for that too? > > > > While you?re at planning task summers (doing the Epics) maybe it could be a good idea to start a sync roadmap page in ag.org[3]? > > > > ++ > > Corinne > > [1] https://github.com/lholmquist/ag-js-ds-poc > > [2] https://gist.github.com/fabricematrat/8666682 > > [3] https://github.com/aerogear/aerogear.org/tree/master/docs/planning/roadmaps > > On 29 Jan 2014, at 18:11, Summers Pittman wrote: > > > On 01/29/2014 11:18 AM, Lucas Holmquist wrote: > > >> On Jan 29, 2014, at 10:41 AM, Summers Pittman wrote: > > >> > > >>> I'm going to take some time to roll up yesterday's Sync Thread so we can > > >>> stop chasing down individual ideas. > > >>> > > >>> Also I am going to propose a potential milestone conga line. I think > > >>> one of the things that keeps happening in these discussions is everyone > > >>> has an idea of what sync is but we don't really know what order things > > >>> should be done or released in. > > >>> > > >>> If everyone likes this I'll slice things into JIRA epics. > > >>> > > >>> # M1 - Basic revision Control, Data Model, Change Management, Server <-> > > >>> Client Contract > > >>> > > >>> * We seem to be in agreement on a basic set of metadata to be kept for > > >>> each object. [objectId, revision, object]. > > >>> * We should have a basic server definition which supports CRUD and > > >>> keeps our revision numbers in check. This may not be a server product > > >>> but just a spec that can be implemented by anything at this point. > > >>> * We should have basic client code which keeps up with revisions, can > > >>> check the server for new revisions, and alert the user if there is a > > >>> sync conflict. > > >>> > > >>> > > >>> M2 - Sync Listener w/ Polling based sync listener, conflict management, > > >>> Serve user management > > >>> * We define on the client how callbacks will work for alerts when > > >>> remote data changes > > >>> * We implement a listener which polls a data source and delivers > > >>> changes to the user. > > >>> * We define how conflicts are managed > > >>> * The server should have a basic authentication and authorization plan > > >>> for controlling how data is synced > > >>> > > >>> M3 - Push based Sync Listener, Network Management, Serverside session > > >>> management > > >> when we say push here, are we talking about the 3rd party services such as GCM and APN's, if so, not sure that is a great idea > > > A one way notification service which only guarantees eventual delivery. > > > GCM and APN is an example of this type of service but I explicitly left > > > it out and think we should target consuming messages from the unified > > > push server. This may mean that we implement SimplePush on iOS and > > > Android so we are "pure" and bundle the simple push server into the sync > > > server contract. > > >> > > >>> * We will build on our previous Listener work from M2 to include a > > >>> Push listener that the server can speak to. > > >>> * We will define in the client how network state and sync state > > >>> interact. IE how to handle errors in fetching new data when the > > >>> Listener is alerted. (Exponential back off, retry, etc) > > >>> * The server will need to have some mechanism for managing user > > >>> "sessions". This is what users are actively being synced. > > >>> > > >>> M4 - "Real Time" Sync Listener. Bidirectional automatic sync > > >>> * Instead of using push, Realtime Sync uses something like web > > >>> sockects. to automatically sync local and remote data. > > >>> * Previous Sync listeners may have to be upgraded to include "upload" > > >>> abilities. > > >>> * The server will need to support this as well. > > >>> > > >>> M5 - Conflict resolution, Error detection and support > > >>> * Provide a more comprehensive strategy for managing conflicts. > > >>> * Provide some automated conflict resolvers > > >>> * The server could get a larger set of conflict and errors messages > > >>> > > >>> M6 - Sync connection Upgrading > > >>> * The client and server will negotiate when it is appropriate to > > >>> switch between polling, push, and realtime sync strategies. > > >>> > > >>> M7 - Party > > >>> * We have a sync party. > > >>> _______________________________________________ > > >>> 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 > > > > > > > > -- > > Matthias Wessendorf > > > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > twitter: http://twitter.com/mwessendorf > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From hbons at redhat.com Thu Jan 30 06:24:55 2014 From: hbons at redhat.com (Hylke Bons) Date: Thu, 30 Jan 2014 11:24:55 +0000 Subject: [aerogear-dev] Let's change the AeroGear Twitter account handle Message-ID: <52EA3687.2050601@redhat.com> "@AeroGears" can cause confusion about what the project name really is. Options to fix: - Ask the owner of @AeroGear if he or she want to give up the handle - Change the handle to "@AeroGearTeam" or "@AeroGearProject", or something else Thoughts? Hylke From matzew at apache.org Thu Jan 30 06:29:13 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 30 Jan 2014 12:29:13 +0100 Subject: [aerogear-dev] Let's change the AeroGear Twitter account handle In-Reply-To: <52EA3687.2050601@redhat.com> References: <52EA3687.2050601@redhat.com> Message-ID: On Thu, Jan 30, 2014 at 12:24 PM, Hylke Bons wrote: > "@AeroGears" can cause confusion about what the project name really is. > All the JUGs I presented at, and some conferences call the project already "AeroGears", due to the tiwtter handle :-) > > Options to fix: > - Ask the owner of @AeroGear if he or she want to give up the handle > are we also offering 50k ? :) > - Change the handle to "@AeroGearTeam" or "@AeroGearProject", or > something else > I think the 'concern' was that the name is too long, but on the other hand, there is some sort of confusion w/ our actual name :-0 If I had to pick one out of those that you suggested it would be 'AeroGearTeam', that's exactly just three chars longer than the current :) -M > > Thoughts? > > Hylke > _______________________________________________ > 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/20140130/9a51628f/attachment.html From hbons at redhat.com Thu Jan 30 06:38:46 2014 From: hbons at redhat.com (Hylke Bons) Date: Thu, 30 Jan 2014 11:38:46 +0000 Subject: [aerogear-dev] Let's change the AeroGear Twitter account handle In-Reply-To: References: <52EA3687.2050601@redhat.com> Message-ID: <52EA39C6.8020607@redhat.com> You are right that it may be a bit long for replies. "@AGTeam" or "@AGProject" could work too (if they weren't already taken but something amongst those line :). Hylke On 30/01/2014 11:29, Matthias Wessendorf wrote: > > > > On Thu, Jan 30, 2014 at 12:24 PM, Hylke Bons > wrote: > > "@AeroGears" can cause confusion about what the project name > really is. > > > All the JUGs I presented at, and some conferences call the project > already "AeroGears", due to the tiwtter handle :-) > > > Options to fix: > - Ask the owner of @AeroGear if he or she want to give up the handle > > > are we also offering 50k ? :) > > - Change the handle to "@AeroGearTeam" or "@AeroGearProject", or > something else > > > I think the 'concern' was that the name is too long, but on the other > hand, there is some sort of confusion w/ our actual name :-0 > > If I had to pick one out of those that you suggested it would be > 'AeroGearTeam', that's exactly just three chars longer than the current :) > > -M > > > > > Thoughts? > > Hylke > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140130/2136d347/attachment.html From matzew at apache.org Thu Jan 30 07:33:48 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 30 Jan 2014 13:33:48 +0100 Subject: [aerogear-dev] Let's change the AeroGear Twitter account handle In-Reply-To: <52EA39C6.8020607@redhat.com> References: <52EA3687.2050601@redhat.com> <52EA39C6.8020607@redhat.com> Message-ID: On Thu, Jan 30, 2014 at 12:38 PM, Hylke Bons wrote: > You are right that it may be a bit long for replies. > "@AGTeam" or "@AGProject" could work too (if they weren't already taken > but something amongst those line :). > not sure if AGTeam/Project is really 'cool' > > > Hylke > > > On 30/01/2014 11:29, Matthias Wessendorf wrote: > > > > > On Thu, Jan 30, 2014 at 12:24 PM, Hylke Bons wrote: > >> "@AeroGears" can cause confusion about what the project name really is. >> > > All the JUGs I presented at, and some conferences call the project > already "AeroGears", due to the tiwtter handle :-) > > >> >> Options to fix: >> - Ask the owner of @AeroGear if he or she want to give up the handle >> > > are we also offering 50k ? :) > > >> - Change the handle to "@AeroGearTeam" or "@AeroGearProject", or >> something else >> > > I think the 'concern' was that the name is too long, but on the other > hand, there is some sort of confusion w/ our actual name :-0 > > If I had to pick one out of those that you suggested it would be > 'AeroGearTeam', that's exactly just three chars longer than the current :) > > -M > > > > > >> >> Thoughts? >> >> Hylke >> _______________________________________________ >> 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 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 > -- 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/20140130/c89a711c/attachment-0001.html From matzew at apache.org Thu Jan 30 08:20:42 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 30 Jan 2014 14:20:42 +0100 Subject: [aerogear-dev] Security roadmap updates In-Reply-To: References: Message-ID: ship it ! On Wed, Jan 29, 2014 at 3:20 PM, Bruno Oliveira wrote: > Good morning peeps, a proposal was sent to change the security roadmap > https://github.com/aerogear/aerogear.org/pull/242. > > If you have any concern, let me know. > > -- > abstractj > > _______________________________________________ > 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/20140130/d14338d1/attachment.html From matzew at apache.org Thu Jan 30 08:31:13 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 30 Jan 2014 14:31:13 +0100 Subject: [aerogear-dev] Keycloak on AeroGear In-Reply-To: References: <1390738834902.6b58437e@Nodemailer> Message-ID: Follow up thread, on better integration: http://lists.jboss.org/pipermail/keycloak-dev/2014-January/001164.html Looks like we have several options... On Wed, Jan 29, 2014 at 4:02 PM, Matthias Wessendorf wrote: > > > > On Wed, Jan 29, 2014 at 3:57 PM, Bruno Oliveira wrote: > >> Sorry I just missed your e-mail during while the syncalipse was happening. >> >> What I meant was something like: admin, developers, regular users and how >> to deal with these roles. Maybe this is planned to the next steps, but at >> some point we need to test how KeyCloak could protect our endpoints and >> deal with multiple roles. >> > > yes, the 'ui part' (and the underlying endpoints) being protected by > keycloak; > On the next steps is also looking at different roles for this. I was never > speaking about a specific user/role - more generically protecting the > "Admin UI", which can be consumed by users w/ different roles > > -Matthias > > >> >> >> On Sun, Jan 26, 2014 at 10:41 AM, Matthias Wessendorf wrote: >> >>> Hello Bruno, >>> >>> >>> On Sun, Jan 26, 2014 at 1:20 PM, Bruno Oliveira wrote: >>> >>>> Any specific reason to limit the scope to admin page only? I'm thinking >>>> about login for regular users >>> >>> >>> Not sure I follow. What do you mean w/ "regular users"? >>> >>> >>> Before my change very thing was restricted by Keycloak (/*). I did not >>> really change there a lot, however I just removed the URLs for >>> 'device-registration' and 'sending': >>> >>> https://github.com/matzew/aerogear-unifiedpush-server/blob/keycloak/src/main/webapp/WEB-INF/web.xml#L42-L50 >>> >>> So, currently the following is protected by Keycloak: >>> * Admin UI (not speaking about a specific admin user) >>> * REST APIs that are accessed by the Admin UI, like: >>> - http://aerogear.org/docs/specs/aerogear-push-rest/PushApplication/ >>> - http://aerogear.org/docs/specs/aerogear-push-rest/Variants/ >>> >>> Perviously the 'device-registration' and 'sending' URL were protected as >>> well. Removing them from the 'keycloak protection' is really the only change >>> >>> Greetings, >>> Matthias >>> >>> >>> >>>> -- >>>> abstractj >>>> >>>> >>>> On Sun, Jan 26, 2014 at 9:11 AM, Matthias Wessendorf >>> > wrote: >>>> >>>>> Hello! >>>>> >>>>> I have a few more updates: >>>>> >>>>> On my branch (a fork from Bruno's branch), the URLs for the actual >>>>> sending and the device-registration (both 'protected' via HTTP-Basic), now >>>>> work again. I have 'limited' the scope of the Keycloak 'protection' to the >>>>> AdminUI. >>>>> >>>>> Greetings, >>>>> Matthias >>>>> >>>>> >>>>> >>>>> On Fri, Jan 24, 2014 at 6:05 PM, Matthias Wessendorf < >>>>> matzew at apache.org> wrote: >>>>> >>>>>> I have updated the branch w/ their recent changes from this weeks >>>>>> alpha-1 release, and submitted a PR against abstractj's repo: >>>>>> https://github.com/abstractj/aerogear-unifiedpush-server/pull/1 >>>>>> >>>>>> More to come >>>>>> >>>>>> Greetings, >>>>>> Matthias >>>>>> >>>>>> >>>>>> >>>>>> On Fri, Dec 20, 2013 at 1:11 PM, Bruno Oliveira wrote: >>>>>> >>>>>>> Good morning peeps, yesterday I started to replace AeroGear Security >>>>>>> on Unified Push server by Keycloak and you might be asking: "Why?". >>>>>>> Keycloak is a SSO with some handy features like TOTP, OAuth2, user >>>>>>> management support and I think we have too much to contribute, is the only >>>>>>> way to have some success with security, "divide to conquer" (at least for >>>>>>> authorization and authentication). >>>>>>> >>>>>>> So will ag-security be discontinued? No! Keycloak is still on Alpha >>>>>>> and we have to test it against our projects before fully replace >>>>>>> ag-security, but the only way to upstream our needs, is to using it. >>>>>>> >>>>>>> This replacement only applies to authentication/authorization >>>>>>> features, we still have a ton of projects which Keycloak is not able to >>>>>>> replace like: TOTP, crypto and OAuth2 on mobile, our focus. >>>>>>> >>>>>>> - PoC >>>>>>> >>>>>>> So let's talk about this replacement, any dependency on ag-security >>>>>>> was removed from the push server and replaced by Keycloak: >>>>>>> https://github.com/abstractj/aerogear-unifiedpush-server/tree/openshift >>>>>>> >>>>>>> Based on Keycloak examples, I just did copy & paste from one of the >>>>>>> demos (https://github.com/abstractj/auth-server/tree/openshift) to >>>>>>> create a server. Keycloak requires Resteasy 3.0.4, for this reason I had to >>>>>>> manually replace some modules on JBoss. >>>>>>> >>>>>>> To test it go to: http://push-abstractj.rhcloud.com/ag-push/ you >>>>>>> must be redirected to Keycloak, enter: >>>>>>> >>>>>>> username: john at doe.com >>>>>>> password: password >>>>>>> >>>>>>> You must be redirected to agpush console, keep in mind that I took >>>>>>> some shortcuts to get this demo working, so for example the create will >>>>>>> fail because I removed everything related into the ember interface. >>>>>>> >>>>>>> Is also possible to enable TOTP, user's registration and whatever >>>>>>> you want. >>>>>>> >>>>>>> So what do you think? >>>>>>> >>>>>>> -- >>>>>>> abstractj >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >>>> >>> >>> >>> >>> -- >>> 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 >>> >> >> >> >> -- >> >> -- >> "The measure of a man is what he does with power" - Plato >> - >> @abstractj >> - >> Volenti Nihil Difficile >> >> _______________________________________________ >> 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 > -- 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/20140130/8aca576b/attachment.html From lholmqui at redhat.com Thu Jan 30 08:37:07 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Thu, 30 Jan 2014 08:37:07 -0500 Subject: [aerogear-dev] Let's change the AeroGear Twitter account handle In-Reply-To: References: <52EA3687.2050601@redhat.com> <52EA39C6.8020607@redhat.com> Message-ID: <5C19C2C6-2F09-4659-A146-0B44AEE4445C@redhat.com> On Jan 30, 2014, at 7:33 AM, Matthias Wessendorf wrote: > > > > On Thu, Jan 30, 2014 at 12:38 PM, Hylke Bons wrote: > You are right that it may be a bit long for replies. > "@AGTeam" or "@AGProject" could work too (if they weren't already taken but something amongst those line :). > > not sure if AGTeam/Project is really 'cool' yea, if i was just a random person on twitter and saw "AGTeam", i'd be like WhoTF is that > > > Hylke > > > On 30/01/2014 11:29, Matthias Wessendorf wrote: >> >> >> >> On Thu, Jan 30, 2014 at 12:24 PM, Hylke Bons wrote: >> "@AeroGears" can cause confusion about what the project name really is. >> >> All the JUGs I presented at, and some conferences call the project already "AeroGears", due to the tiwtter handle :-) >> >> >> Options to fix: >> - Ask the owner of @AeroGear if he or she want to give up the handle >> >> are we also offering 50k ? :) >> >> - Change the handle to "@AeroGearTeam" or "@AeroGearProject", or >> something else >> >> I think the 'concern' was that the name is too long, but on the other hand, there is some sort of confusion w/ our actual name :-0 >> >> If I had to pick one out of those that you suggested it would be 'AeroGearTeam', that's exactly just three chars longer than the current :) >> >> -M >> >> >> >> >> >> Thoughts? >> >> Hylke >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140130/09b6d52f/attachment-0001.html From supittma at redhat.com Thu Jan 30 10:04:35 2014 From: supittma at redhat.com (Summers Pittman) Date: Thu, 30 Jan 2014 10:04:35 -0500 Subject: [aerogear-dev] Sync Day 2: All our cars are frozen in ice In-Reply-To: References: <52E92129.3070004@redhat.com> Message-ID: <52EA6A03.3050308@redhat.com> On 01/30/2014 03:32 AM, Matthias Wessendorf wrote: > > On Wed, Jan 29, 2014 at 5:57 PM, Jay Balunas > wrote: > > Finally got a chance to read through the whole sync thread :-) > > I'm a big fan keeping it simple, especially for initial releases. > So limiting scope of our initial offering will be important imo. > > I really like the idea of defining the data model, protocol, > client contract, etc... separate from a specific implementation. > As several have said, those are impl. details that we can change > as needed. For example Push - I like the idea of using it for > notification of updates (optional, with fallback, & not required), > but it should not be a 1.0 priority imo. It should also be > something that requires no (or minimal) updates from the app > developer when we implement it. At the end of the day it is just > another way to let the app know something has changed :-) > > As for versioning, I'm concerned over having M1, M2, etc.... What > do you think of sticking with semver 0.1, 0.2, etc...? > > On Jan 29, 2014, at 10:41 AM, Summers Pittman > wrote: > > > I'm going to take some time to roll up yesterday's Sync Thread > so we can > > stop chasing down individual ideas. > > +1 and thanks > > > > > Also I am going to propose a potential milestone conga line. I > think > > one of the things that keeps happening in these discussions is > everyone > > has an idea of what sync is but we don't really know what order > things > > should be done or released in. > > > > If everyone likes this I'll slice things into JIRA epics. > > > > # M1 - Basic revision Control, Data Model, Change Management, > Server <-> > > Client Contract > > > > * We seem to be in agreement on a basic set of metadata to be > kept for > > each object. [objectId, revision, object]. > > * We should have a basic server definition which supports CRUD and > > keeps our revision numbers in check. This may not be a server > product > > but just a spec that can be implemented by anything at this point. > > * We should have basic client code which keeps up with > revisions, can > > check the server for new revisions, and alert the user if there is a > > sync conflict. > > I would recommend at this point keep it free from implementation > and/or have that implementation be as simple as possible. This > way we can get through to the next stage quickly, without debating > the specific impl. > > > what do you mean ? Just specs and papers ? Not sure I follow on > keeping it "free from implementation" Bump. I'm also curious what you meant. > > > > > > > > M2 - Sync Listener w/ Polling based sync listener, conflict > management, > > Serve user management > > * We define on the client how callbacks will work for alerts when > > remote data changes > > * We implement a listener which polls a data source and delivers > > changes to the user. > > * We define how conflicts are managed > > * The server should have a basic authentication and > authorization plan > > for controlling how data is synced > > I agree we need to plan for the future with user management and > security integration, but I might move that part to a later point > release to keep this as simple as possible. > > > user mgmt - keycloak :-) > Ok, we should not really go there, yet :-)) > > > Other than my comments above this looks like a good overall plan :-) > > Once we nail this down we'll want to talk about possible dates, > and how we split time with other priorities as well (developer > experience, getting started, examples, site, etc....) > > > > > M3 - Push based Sync Listener, Network Management, Serverside > session > > management > > * We will build on our previous Listener work from M2 to include a > > Push listener that the server can speak to. > > * We will define in the client how network state and sync state > > interact. IE how to handle errors in fetching new data when the > > Listener is alerted. (Exponential back off, retry, etc) > > * The server will need to have some mechanism for managing user > > "sessions". This is what users are actively being synced. > > > > M4 - "Real Time" Sync Listener. Bidirectional automatic sync > > * Instead of using push, Realtime Sync uses something like web > > sockects. to automatically sync local and remote data. > > * Previous Sync listeners may have to be upgraded to include > "upload" > > abilities. > > * The server will need to support this as well. > > > > M5 - Conflict resolution, Error detection and support > > * Provide a more comprehensive strategy for managing conflicts. > > * Provide some automated conflict resolvers > > * The server could get a larger set of conflict and errors messages > > > > M6 - Sync connection Upgrading > > * The client and server will negotiate when it is appropriate to > > switch between polling, push, and realtime sync strategies. > > > > M7 - Party > > * We have a sync party. > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > > -- > Matthias Wessendorf > > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > twitter: http://twitter.com/mwessendorf > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140130/54e6ed45/attachment.html From supittma at redhat.com Thu Jan 30 10:13:30 2014 From: supittma at redhat.com (Summers Pittman) Date: Thu, 30 Jan 2014 10:13:30 -0500 Subject: [aerogear-dev] Sync Day 2: All our cars are frozen in ice In-Reply-To: References: <52E92129.3070004@redhat.com> Message-ID: <52EA6C1A.2010800@redhat.com> On 01/30/2014 03:22 AM, Matthias Wessendorf wrote: > > > > On Wed, Jan 29, 2014 at 4:41 PM, Summers Pittman > wrote: > > I'm going to take some time to roll up yesterday's Sync Thread so > we can > stop chasing down individual ideas. > > Also I am going to propose a potential milestone conga line. I think > one of the things that keeps happening in these discussions is > everyone > has an idea of what sync is but we don't really know what order things > should be done or released in. > > If everyone likes this I'll slice things into JIRA epics. > > # M1 - Basic revision Control, Data Model, Change Management, > Server <-> > Client Contract > > * We seem to be in agreement on a basic set of metadata to be > kept for > each object. [objectId, revision, object]. > * We should have a basic server definition which supports CRUD and > keeps our revision numbers in check. This may not be a server product > but just a spec that can be implemented by anything at this point. > * We should have basic client code which keeps up with > revisions, can > check the server for new revisions, and alert the user if there is a > sync conflict. > > > what about looking at local changes ? Is that implied here? Right. Basically the first thing we should have is some way of detecting if the local data and server data are out of sync with one another. I'll follow up later with a bit more indepth discussion on how we do that. (Diff-merge-patch and revision control are the two being worked on in the sync server right now). > > > M2 - Sync Listener w/ Polling based sync listener, conflict > management, > Serve user management > * We define on the client how callbacks will work for alerts when > remote data changes > * We implement a listener which polls a data source and delivers > changes to the user. > * We define how conflicts are managed > * The server should have a basic authentication and > authorization plan > for controlling how data is synced > > > Not sure, but: could/should a user get the chance to kinda control > that 'change' (e.g. veto) ? It depends on the architecture of the application. In a peer to peer system like say email then maybe. In a client/server system like mediawiki then that is probably a no. Something to think about on the JIRA. > > M3 - Push based Sync Listener, Network Management, Serverside session > management > * We will build on our previous Listener work from M2 to include a > Push listener that the server can speak to. > * We will define in the client how network state and sync state > interact. IE how to handle errors in fetching new data when the > Listener is alerted. (Exponential back off, retry, etc) > * The server will need to have some mechanism for managing user > "sessions". This is what users are actively being synced. > > > I still think this is optional :-) > > I think generally it's nice to have feature that the "sync-server" can > send 'update requests' > to the unifiedpush server; However IMO the clients should still mark > this as optional (again > a user (on iOS/FFOS) can decide she is not interested in push > notification; Than all the offerings > from M3 would just not work Yes a user on iOS and FFx can turn off parts of M3. However M3 builds the foundation for M4. Additionally network management and intermittent connectivity ARE problems for all platforms and they are also addressed in this bundle. > > M4 - "Real Time" Sync Listener. Bidirectional automatic sync > * Instead of using push, Realtime Sync uses something like web > sockects. to automatically sync local and remote data. > > > Should be the default when an app is active and open (putting platform > limits aside) Managing that is what M6 is about. > > * Previous Sync listeners may have to be upgraded to include "upload" > abilities. > * The server will need to support this as well. > > > This step might allow us (*later*) to plug in some sort of OT > (Operational Transform) implementation Well before this the way uploading was done was out of band with the sync channel. Before M4 this was one way sync (server -> client) with the application pushing changes to the server. Now the idea is that library will have support for pushing changes automatically. > > > M5 - Conflict resolution, Error detection and support > * Provide a more comprehensive strategy for managing conflicts. > * Provide some automated conflict resolvers > * The server could get a larger set of conflict and errors messages > > > +1 > > > M6 - Sync connection Upgrading > * The client and server will negotiate when it is appropriate to > switch between polling, push, and realtime sync strategies. > > > yeah, sounds good Maybe this should be moved to before automagic conflict resolution (M5) > > > M7 - Party > * We have a sync party. > > > J?germeister and fine brews from Russian River -> yay! :-D > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140130/6859e01c/attachment-0001.html From hbons at redhat.com Thu Jan 30 10:14:10 2014 From: hbons at redhat.com (Hylke Bons) Date: Thu, 30 Jan 2014 15:14:10 +0000 Subject: [aerogear-dev] Let's change the AeroGear Twitter account handle In-Reply-To: <5C19C2C6-2F09-4659-A146-0B44AEE4445C@redhat.com> References: <52EA3687.2050601@redhat.com> <52EA39C6.8020607@redhat.com> <5C19C2C6-2F09-4659-A146-0B44AEE4445C@redhat.com> Message-ID: <52EA6C42.605@redhat.com> On 30/01/2014 13:37, Lucas Holmquist wrote: > > On Jan 30, 2014, at 7:33 AM, Matthias Wessendorf > wrote: > >> >> >> >> On Thu, Jan 30, 2014 at 12:38 PM, Hylke Bons > > wrote: >> >> You are right that it may be a bit long for replies. >> "@AGTeam" or "@AGProject" could work too (if they weren't already >> taken but something amongst those line :). >> >> >> not sure if AGTeam/Project is really 'cool' > > yea, if i was just a random person on twitter and saw "AGTeam", i'd > be like WhoTF is that > Well, it's just a handle. Real names are shown in tweets too nowadays. It's better to have something that's a bit less related than something that is confusing. *team, *project and *tweets are pretty much convention too and people will figure out the name. Hylke >> >> >> Hylke >> >> >> On 30/01/2014 11:29, Matthias Wessendorf wrote: >>> >>> >>> >>> On Thu, Jan 30, 2014 at 12:24 PM, Hylke Bons >> > wrote: >>> >>> "@AeroGears" can cause confusion about what the project name >>> really is. >>> >>> >>> All the JUGs I presented at, and some conferences call the >>> project already "AeroGears", due to the tiwtter handle :-) >>> >>> >>> Options to fix: >>> - Ask the owner of @AeroGear if he or she want to give up >>> the handle >>> >>> >>> are we also offering 50k ? :) >>> >>> - Change the handle to "@AeroGearTeam" or "@AeroGearProject", or >>> something else >>> >>> >>> I think the 'concern' was that the name is too long, but on the >>> other hand, there is some sort of confusion w/ our actual name :-0 >>> >>> If I had to pick one out of those that you suggested it would be >>> 'AeroGearTeam', that's exactly just three chars longer than the >>> current :) >>> >>> -M >>> >>> >>> >>> >>> Thoughts? >>> >>> Hylke >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> >> -- >> Matthias Wessendorf >> >> blog: http://matthiaswessendorf.wordpress.com/ >> sessions: http://www.slideshare.net/mwessendorf >> twitter: http://twitter.com/mwessendorf >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140130/eacb309c/attachment.html From supittma at redhat.com Thu Jan 30 10:14:41 2014 From: supittma at redhat.com (Summers Pittman) Date: Thu, 30 Jan 2014 10:14:41 -0500 Subject: [aerogear-dev] Sync Day 2: All our cars are frozen in ice In-Reply-To: References: <52E92129.3070004@redhat.com> Message-ID: <52EA6C61.5000909@redhat.com> On 01/30/2014 03:39 AM, Matthias Wessendorf wrote: > Oh, > > did you get a chance to read the mail/gist from Fabrice? > > * > http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Conflicts-amp-Reconciliation-td6026.html > * https://gist.github.com/fabricematrat/8666682 > I've looked at it a couple of times but havn't written any code based on it so I'll hold off on any judgement. > -M > > > On Wed, Jan 29, 2014 at 4:41 PM, Summers Pittman > wrote: > > I'm going to take some time to roll up yesterday's Sync Thread so > we can > stop chasing down individual ideas. > > Also I am going to propose a potential milestone conga line. I think > one of the things that keeps happening in these discussions is > everyone > has an idea of what sync is but we don't really know what order things > should be done or released in. > > If everyone likes this I'll slice things into JIRA epics. > > # M1 - Basic revision Control, Data Model, Change Management, > Server <-> > Client Contract > > * We seem to be in agreement on a basic set of metadata to be > kept for > each object. [objectId, revision, object]. > * We should have a basic server definition which supports CRUD and > keeps our revision numbers in check. This may not be a server product > but just a spec that can be implemented by anything at this point. > * We should have basic client code which keeps up with > revisions, can > check the server for new revisions, and alert the user if there is a > sync conflict. > > > M2 - Sync Listener w/ Polling based sync listener, conflict > management, > Serve user management > * We define on the client how callbacks will work for alerts when > remote data changes > * We implement a listener which polls a data source and delivers > changes to the user. > * We define how conflicts are managed > * The server should have a basic authentication and > authorization plan > for controlling how data is synced > > M3 - Push based Sync Listener, Network Management, Serverside session > management > * We will build on our previous Listener work from M2 to include a > Push listener that the server can speak to. > * We will define in the client how network state and sync state > interact. IE how to handle errors in fetching new data when the > Listener is alerted. (Exponential back off, retry, etc) > * The server will need to have some mechanism for managing user > "sessions". This is what users are actively being synced. > > M4 - "Real Time" Sync Listener. Bidirectional automatic sync > * Instead of using push, Realtime Sync uses something like web > sockects. to automatically sync local and remote data. > * Previous Sync listeners may have to be upgraded to include > "upload" > abilities. > * The server will need to support this as well. > > M5 - Conflict resolution, Error detection and support > * Provide a more comprehensive strategy for managing conflicts. > * Provide some automated conflict resolvers > * The server could get a larger set of conflict and errors messages > > M6 - Sync connection Upgrading > * The client and server will negotiate when it is appropriate to > switch between polling, push, and realtime sync strategies. > > M7 - Party > * We have a sync party. > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140130/fb9886e1/attachment-0001.html From supittma at redhat.com Thu Jan 30 10:23:15 2014 From: supittma at redhat.com (Summers Pittman) Date: Thu, 30 Jan 2014 10:23:15 -0500 Subject: [aerogear-dev] Sync Day 3 Sync takes Manhattan Message-ID: <52EA6E63.5060505@redhat.com> I rolled up the feedback to the email I sent yesterday. One quick note, this is not a 0.1.0 plan nor a 1.0.0 plan. It is probably closer to a 1.5 or 2.0 plan in terms of scope. I tried to order things and break out big "chunks" which will need to be done and the approximate order they should be done in while also drawing a line around what features we have. This is why I have not placed ANY versions YET. By the end of today/tomorrow morning I hope that we will be in a good place to do that. Big changes from yesterday, User mgmt moved to M4. M6 (Sync Listener Upgrading)was merged into M3(Push Listeners) so that we can have optional push sooner. # M1 - Basic revision Control, Data Model, Change Management, Server <-> Client Contract * We seem to be in agreement on a basic set of metadata to be kept for each object. [objectId, revision, object]. * We should have a basic server definition which supports CRUD and keeps our revision numbers in check. This may not be a server product but just a spec that can be implemented by anything at this point. * We should have basic client code which keeps up with revisions, can check the server for new revisions, and alert the user if there is a sync conflict. M2 - Sync Listener w/ Polling based sync listener, conflict management, * We define on the client how callbacks will work for alerts when remote data changes * We implement a listener which polls a data source and delivers changes to the user. * We define how conflicts are managed M3 - Push based Sync Listener, Sync Listener Strategy Management * The client and server will negotiate when it is appropriate to switch between polling, push, and realtime sync strategies. * We will build on our previous Listener work from M2 to include a Push listener that the server can speak to. * We will support ways of automagically managing sync listeners based on the availability of Push. M4 - Server user management, Network Management, Server side session management * We will define in the client how network state and sync state interact. IE how to handle errors in fetching new data when the Listener is alerted. (Exponential back off, retry, etc) * The server will need to have some mechanism for managing user "sessions". This is what users are actively being synced. * The server should have a basic authentication and authorization plan for controlling how data is synced M5 - "Real Time" Sync Listener. Bidirectional automatic sync * Instead of using push, Realtime Sync uses something like web sockects. to automatically sync local and remote data. * Previous Sync listeners may have to be upgraded to include "upload" abilities. * We will also include the ability to switch between Realtime sync listeners, polling listeners, and push listeners * The server will need to support this as well. M6 - Conflict resolution, Error detection and support * Provide a more comprehensive strategy for managing conflicts. * Provide some automated conflict resolvers * The server could get a larger set of conflict and errors messages M8 - Party * We have a sync party. From corinnekrych at gmail.com Thu Jan 30 10:26:04 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 30 Jan 2014 16:26:04 +0100 Subject: [aerogear-dev] Sync Day 3 Sync takes Manhattan In-Reply-To: <52EA6E63.5060505@redhat.com> References: <52EA6E63.5060505@redhat.com> Message-ID: I like it. On 30 Jan 2014, at 16:23, Summers Pittman wrote: > I rolled up the feedback to the email I sent yesterday. > > One quick note, this is not a 0.1.0 plan nor a 1.0.0 plan. It is > probably closer to a 1.5 or 2.0 plan in terms of scope. I tried to > order things and break out big "chunks" which will need to be done and > the approximate order they should be done in while also drawing a line > around what features we have. This is why I have not placed ANY > versions YET. By the end of today/tomorrow morning I hope that we will > be in a good place to do that. > > Big changes from yesterday, User mgmt moved to M4. +1 > M6 (Sync Listener > Upgrading)was merged into M3(Push Listeners) so that we can have > optional push sooner. > > # M1 - Basic revision Control, Data Model, Change Management, Server <-> > Client Contract > > * We seem to be in agreement on a basic set of metadata to be kept for > each object. [objectId, revision, object]. > * We should have a basic server definition which supports CRUD and > keeps our revision numbers in check. This may not be a server product > but just a spec that can be implemented by anything at this point. > * We should have basic client code which keeps up with revisions, can > check the server for new revisions, and alert the user if there is a > sync conflict. > > > M2 - Sync Listener w/ Polling based sync listener, conflict management, > > * We define on the client how callbacks will work for alerts when > remote data changes > * We implement a listener which polls a data source and delivers > changes to the user. > * We define how conflicts are managed > > > M3 - Push based Sync Listener, Sync Listener Strategy Management > * The client and server will negotiate when it is appropriate to > switch between polling, push, and realtime sync strategies. > * We will build on our previous Listener work from M2 to include a > Push listener that the server can speak to. > * We will support ways of automagically managing sync listeners based > on the availability of Push. > > M4 - Server user management, Network Management, Server side session > management > * We will define in the client how network state and sync state > interact. IE how to handle errors in fetching new data when the > Listener is alerted. (Exponential back off, retry, etc) > * The server will need to have some mechanism for managing user > "sessions". This is what users are actively being synced. > * The server should have a basic authentication and authorization plan > for controlling how data is synced > > M5 - "Real Time" Sync Listener. Bidirectional automatic sync > * Instead of using push, Realtime Sync uses something like web > sockects. to automatically sync local and remote data. > * Previous Sync listeners may have to be upgraded to include "upload" > abilities. > * We will also include the ability to switch between Realtime sync > listeners, polling listeners, and push listeners > * The server will need to support this as well. > > M6 - Conflict resolution, Error detection and support > * Provide a more comprehensive strategy for managing conflicts. > * Provide some automated conflict resolvers > * The server could get a larger set of conflict and errors messages > > M8 - Party > * We have a sync party. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From corinnekrych at gmail.com Thu Jan 30 10:33:08 2014 From: corinnekrych at gmail.com (Corinne Krych) Date: Thu, 30 Jan 2014 16:33:08 +0100 Subject: [aerogear-dev] Sync Day 2: All our cars are frozen in ice In-Reply-To: <52EA6C61.5000909@redhat.com> References: <52E92129.3070004@redhat.com> <52EA6C61.5000909@redhat.com> Message-ID: <521A04E3-3C10-484F-8B85-AD9085A7F807@gmail.com> On 30 Jan 2014, at 16:14, Summers Pittman wrote: > On 01/30/2014 03:39 AM, Matthias Wessendorf wrote: >> Oh, >> >> did you get a chance to read the mail/gist from Fabrice? >> >> * http://aerogear-dev.1069024.n5.nabble.com/aerogear-dev-Conflicts-amp-Reconciliation-td6026.html >> * https://gist.github.com/fabricematrat/8666682 >> > I've looked at it a couple of times but havn't written any code based on it so I'll hold off on any judgement. Yep with some code samples it will make more sense. We need soem demo For reconciliation stuff, you can have a look to this lib: https://github.com/3musket33rs/mathsync (I?m planning to do iOS version) >> -M >> >> >> On Wed, Jan 29, 2014 at 4:41 PM, Summers Pittman wrote: >> I'm going to take some time to roll up yesterday's Sync Thread so we can >> stop chasing down individual ideas. >> >> Also I am going to propose a potential milestone conga line. I think >> one of the things that keeps happening in these discussions is everyone >> has an idea of what sync is but we don't really know what order things >> should be done or released in. >> >> If everyone likes this I'll slice things into JIRA epics. >> >> # M1 - Basic revision Control, Data Model, Change Management, Server <-> >> Client Contract >> >> * We seem to be in agreement on a basic set of metadata to be kept for >> each object. [objectId, revision, object]. >> * We should have a basic server definition which supports CRUD and >> keeps our revision numbers in check. This may not be a server product >> but just a spec that can be implemented by anything at this point. >> * We should have basic client code which keeps up with revisions, can >> check the server for new revisions, and alert the user if there is a >> sync conflict. >> >> >> M2 - Sync Listener w/ Polling based sync listener, conflict management, >> Serve user management >> * We define on the client how callbacks will work for alerts when >> remote data changes >> * We implement a listener which polls a data source and delivers >> changes to the user. >> * We define how conflicts are managed >> * The server should have a basic authentication and authorization plan >> for controlling how data is synced >> >> M3 - Push based Sync Listener, Network Management, Serverside session >> management >> * We will build on our previous Listener work from M2 to include a >> Push listener that the server can speak to. >> * We will define in the client how network state and sync state >> interact. IE how to handle errors in fetching new data when the >> Listener is alerted. (Exponential back off, retry, etc) >> * The server will need to have some mechanism for managing user >> "sessions". This is what users are actively being synced. >> >> M4 - "Real Time" Sync Listener. Bidirectional automatic sync >> * Instead of using push, Realtime Sync uses something like web >> sockects. to automatically sync local and remote data. >> * Previous Sync listeners may have to be upgraded to include "upload" >> abilities. >> * The server will need to support this as well. >> >> M5 - Conflict resolution, Error detection and support >> * Provide a more comprehensive strategy for managing conflicts. >> * Provide some automated conflict resolvers >> * The server could get a larger set of conflict and errors messages >> >> M6 - Sync connection Upgrading >> * The client and server will negotiate when it is appropriate to >> switch between polling, push, and realtime sync strategies. >> >> M7 - Party >> * We have a sync party. >> _______________________________________________ >> 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 From matzew at apache.org Thu Jan 30 11:03:05 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 30 Jan 2014 17:03:05 +0100 Subject: [aerogear-dev] Sync Day 3 Sync takes Manhattan In-Reply-To: <52EA6E63.5060505@redhat.com> References: <52EA6E63.5060505@redhat.com> Message-ID: On Thu, Jan 30, 2014 at 4:23 PM, Summers Pittman wrote: > I rolled up the feedback to the email I sent yesterday. > > One quick note, this is not a 0.1.0 plan nor a 1.0.0 plan. It is > probably closer to a 1.5 or 2.0 plan in terms of scope. ahm... thinking about 2.0.0 before we have a 1.0.0 ? Not sure I understand that > I tried to > order things and break out big "chunks" which will need to be done and > the approximate order they should be done in while also drawing a line > around what features we have. This is why I have not placed ANY > versions YET. By the end of today/tomorrow morning I hope that we will > be in a good place to do that. > > > Big changes from yesterday, User mgmt moved to M4. M6 (Sync Listener > Upgrading)was merged into M3(Push Listeners) so that we can have > optional push sooner. > > # M1 - Basic revision Control, Data Model, Change Management, Server <-> > Client Contract > > * We seem to be in agreement on a basic set of metadata to be kept for > each object. [objectId, revision, object]. > * We should have a basic server definition which supports CRUD and > keeps our revision numbers in check. This may not be a server product > but just a spec that can be implemented by anything at this point. > * We should have basic client code which keeps up with revisions, can > check the server for new revisions, and alert the user if there is a > sync conflict. > +1 > > > M2 - Sync Listener w/ Polling based sync listener, conflict management, > > * We define on the client how callbacks will work for alerts when > remote data changes > * We implement a listener which polls a data source and delivers > changes to the user. > * We define how conflicts are managed > +1 > > > M3 - Push based Sync Listener, Sync Listener Strategy Management > * The client and server will negotiate when it is appropriate to > switch between polling, push, and realtime sync strategies. > * We will build on our previous Listener work from M2 to include a > Push listener that the server can speak to. > * We will support ways of automagically managing sync listeners based > on the availability of Push. > overall, yes - the nasty details can be discussed at a later point, hence +1 > > M4 - Server user management, Network Management, Server side session > management > * We will define in the client how network state and sync state > interact. IE how to handle errors in fetching new data when the > Listener is alerted. (Exponential back off, retry, etc) > * The server will need to have some mechanism for managing user > "sessions". This is what users are actively being synced. > * The server should have a basic authentication and authorization plan > for controlling how data is synced > this assume we do have a server w/ pluggable adapters, no ? E.g. JPA/JavaEE/Hibernate adapters verus YetAnotherDatabaseThingy adapter > > M5 - "Real Time" Sync Listener. Bidirectional automatic sync > * Instead of using push, Realtime Sync uses something like web > sockects. to automatically sync local and remote data. > * Previous Sync listeners may have to be upgraded to include "upload" > abilities. > * We will also include the ability to switch between Realtime sync > listeners, polling listeners, and push listeners > * The server will need to support this as well. > Didn't M3 already include 'realtime' ? > > M6 - Conflict resolution, Error detection and support > * Provide a more comprehensive strategy for managing conflicts. > * Provide some automated conflict resolvers > * The server could get a larger set of conflict and errors messages > > M8 - Party > * We have a sync party. > what about M7? :) > _______________________________________________ > 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/20140130/b8d60abc/attachment.html From supittma at redhat.com Thu Jan 30 11:13:28 2014 From: supittma at redhat.com (Summers Pittman) Date: Thu, 30 Jan 2014 11:13:28 -0500 Subject: [aerogear-dev] Sync Day 3 Sync takes Manhattan In-Reply-To: References: <52EA6E63.5060505@redhat.com> Message-ID: <52EA7A28.1050404@redhat.com> On 01/30/2014 11:03 AM, Matthias Wessendorf wrote: > > > > On Thu, Jan 30, 2014 at 4:23 PM, Summers Pittman > wrote: > > I rolled up the feedback to the email I sent yesterday. > > One quick note, this is not a 0.1.0 plan nor a 1.0.0 plan. It is > probably closer to a 1.5 or 2.0 plan in terms of scope. > > > ahm... thinking about 2.0.0 before we have a 1.0.0 ? Not sure I > understand that The point I was trying to make is that I'm not expecting everything on here to get done quickly from top to bottom and slap 1.0 on it sometime in May. Also that I am expecting to have several releases made during the production of points on this list. > > I tried to > order things and break out big "chunks" which will need to be done and > the approximate order they should be done in while also drawing a line > around what features we have. This is why I have not placed ANY > versions YET. By the end of today/tomorrow morning I hope that we > will > be in a good place to do that. > > > > > Big changes from yesterday, User mgmt moved to M4. M6 (Sync Listener > Upgrading)was merged into M3(Push Listeners) so that we can have > optional push sooner. > > # M1 - Basic revision Control, Data Model, Change Management, > Server <-> > Client Contract > > * We seem to be in agreement on a basic set of metadata to be > kept for > each object. [objectId, revision, object]. > * We should have a basic server definition which supports CRUD and > keeps our revision numbers in check. This may not be a server product > but just a spec that can be implemented by anything at this point. > * We should have basic client code which keeps up with > revisions, can > check the server for new revisions, and alert the user if there is a > sync conflict. > > > +1 > > > > M2 - Sync Listener w/ Polling based sync listener, conflict > management, > > * We define on the client how callbacks will work for alerts when > remote data changes > * We implement a listener which polls a data source and delivers > changes to the user. > * We define how conflicts are managed > > > > +1 > > > > M3 - Push based Sync Listener, Sync Listener Strategy Management > * The client and server will negotiate when it is appropriate to > switch between polling, push, and realtime sync strategies. > * We will build on our previous Listener work from M2 to include a > Push listener that the server can speak to. > * We will support ways of automagically managing sync listeners > based > on the availability of Push. > > > > overall, yes - the nasty details can be discussed at a later point, hence > +1 > > > M4 - Server user management, Network Management, Server side session > management > * We will define in the client how network state and sync state > interact. IE how to handle errors in fetching new data when the > Listener is alerted. (Exponential back off, retry, etc) > * The server will need to have some mechanism for managing user > "sessions". This is what users are actively being synced. > * The server should have a basic authentication and > authorization plan > for controlling how data is synced > > > > this assume we do have a server w/ pluggable adapters, no ? > E.g. JPA/JavaEE/Hibernate adapters verus YetAnotherDatabaseThingy adapter Yeah, that is something we are lacking in this list is what the abilities of our server "are". For the most part I assumed that each step a server technology or spec was built up and kept up. > > M5 - "Real Time" Sync Listener. Bidirectional automatic sync > * Instead of using push, Realtime Sync uses something like web > sockects. to automatically sync local and remote data. > * Previous Sync listeners may have to be upgraded to include > "upload" > abilities. > * We will also include the ability to switch between Realtime sync > listeners, polling listeners, and push listeners > * The server will need to support this as well. > > > Didn't M3 already include 'realtime' ? For me real time means there is a persistent connection. If the client is offline the message fails and there is an error. Also realtime means that changes made to the client's data are automatically uploaded and propagated. M3 was only concerning itself with detecting changes of remote data and notifying the user and possible doing some merging if there wasn't a conflict. Also in this step is the ability for the server to send the changes themselves instead of sending a notification that something changed. I think of push technologies like a message queue. Deliveries are eventually made and trusted to get made at some random point in the future. > > M6 - Conflict resolution, Error detection and support > * Provide a more comprehensive strategy for managing conflicts. > * Provide some automated conflict resolvers > * The server could get a larger set of conflict and errors messages > > M8 - Party > * We have a sync party. > > > what about M7? :) M7 was scared of 8 so it is hiding. > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140130/5c424527/attachment-0001.html From matzew at apache.org Thu Jan 30 12:02:00 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 30 Jan 2014 18:02:00 +0100 Subject: [aerogear-dev] Sync Day 3 Sync takes Manhattan In-Reply-To: <52EA7A28.1050404@redhat.com> References: <52EA6E63.5060505@redhat.com> <52EA7A28.1050404@redhat.com> Message-ID: On Thu, Jan 30, 2014 at 5:13 PM, Summers Pittman wrote: > On 01/30/2014 11:03 AM, Matthias Wessendorf wrote: > > > > > On Thu, Jan 30, 2014 at 4:23 PM, Summers Pittman wrote: > >> I rolled up the feedback to the email I sent yesterday. >> >> One quick note, this is not a 0.1.0 plan nor a 1.0.0 plan. It is >> probably closer to a 1.5 or 2.0 plan in terms of scope. > > > ahm... thinking about 2.0.0 before we have a 1.0.0 ? Not sure I > understand that > > The point I was trying to make is that I'm not expecting everything on > here to get done quickly from top to bottom and slap 1.0 on it sometime in > May. > Oh, ok - yeah, I totally agree that we should _not_ say: 1.0 is in May and it contains all the bits from your M1 -> M8; > Also that I am expecting to have several releases made during the > production of points on this list. > yep! > > >> I tried to >> order things and break out big "chunks" which will need to be done and >> the approximate order they should be done in while also drawing a line >> around what features we have. This is why I have not placed ANY >> versions YET. By the end of today/tomorrow morning I hope that we will >> be in a good place to do that. >> > > > > >> >> Big changes from yesterday, User mgmt moved to M4. M6 (Sync Listener >> Upgrading)was merged into M3(Push Listeners) so that we can have >> optional push sooner. >> >> # M1 - Basic revision Control, Data Model, Change Management, Server <-> >> Client Contract >> >> * We seem to be in agreement on a basic set of metadata to be kept for >> each object. [objectId, revision, object]. >> * We should have a basic server definition which supports CRUD and >> keeps our revision numbers in check. This may not be a server product >> but just a spec that can be implemented by anything at this point. >> * We should have basic client code which keeps up with revisions, can >> check the server for new revisions, and alert the user if there is a >> sync conflict. >> > > +1 > > >> >> >> M2 - Sync Listener w/ Polling based sync listener, conflict management, >> >> * We define on the client how callbacks will work for alerts when >> remote data changes >> * We implement a listener which polls a data source and delivers >> changes to the user. >> * We define how conflicts are managed >> > > > +1 > > >> >> >> M3 - Push based Sync Listener, Sync Listener Strategy Management >> * The client and server will negotiate when it is appropriate to >> switch between polling, push, and realtime sync strategies. >> * We will build on our previous Listener work from M2 to include a >> Push listener that the server can speak to. >> * We will support ways of automagically managing sync listeners based >> on the availability of Push. >> > > > overall, yes - the nasty details can be discussed at a later point, hence > +1 > > >> >> M4 - Server user management, Network Management, Server side session >> management >> * We will define in the client how network state and sync state >> interact. IE how to handle errors in fetching new data when the >> Listener is alerted. (Exponential back off, retry, etc) >> * The server will need to have some mechanism for managing user >> "sessions". This is what users are actively being synced. >> * The server should have a basic authentication and authorization plan >> for controlling how data is synced >> > > > this assume we do have a server w/ pluggable adapters, no ? > E.g. JPA/JavaEE/Hibernate adapters verus YetAnotherDatabaseThingy adapter > > Yeah, that is something we are lacking in this list is what the abilities > of our server "are". > that was my thought as well > > For the most part I assumed that each step a server technology or spec was > built up and kept up. > I think a 'real' server (w/ adapters) might be needed at some point :-) > > > > >> >> M5 - "Real Time" Sync Listener. Bidirectional automatic sync >> * Instead of using push, Realtime Sync uses something like web >> sockects. to automatically sync local and remote data. >> * Previous Sync listeners may have to be upgraded to include "upload" >> abilities. >> * We will also include the ability to switch between Realtime sync >> listeners, polling listeners, and push listeners >> * The server will need to support this as well. >> > > Didn't M3 already include 'realtime' ? > > For me real time means there is a persistent connection. > same here - but that's listed (real-time) in M3 as well, right ? If the client is offline the message fails and there is an error. Also > realtime means that changes made to the client's data are automatically > uploaded and propagated. > +1 > M3 was only concerning itself with detecting changes of remote data and > notifying the user and possible doing some merging if there wasn't a > conflict. > Ah!! ok, did not get that from reading the list > > Also in this step is the ability for the server to send the changes > themselves instead of sending a notification that something changed. > agreed > > I think of push technologies like a message queue. Deliveries are > eventually made and trusted to get made at some random point in the future. > well, I have some thoughts on that, when we get there :) > > > > >> >> M6 - Conflict resolution, Error detection and support >> * Provide a more comprehensive strategy for managing conflicts. >> * Provide some automated conflict resolvers >> * The server could get a larger set of conflict and errors messages >> >> M8 - Party >> * We have a sync party. >> > > what about M7? :) > > > M7 was scared of 8 so it is hiding. > I hope it was not: buy all the booze for M8 :-) > > > > >> _______________________________________________ >> 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 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 > -- 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/20140130/b2c0befe/attachment.html From scm.blanc at gmail.com Thu Jan 30 12:09:08 2014 From: scm.blanc at gmail.com (=?utf-8?Q?S=C3=A9bastien_Blanc?=) Date: Thu, 30 Jan 2014 22:39:08 +0530 Subject: [aerogear-dev] Let's change the AeroGear Twitter account handle In-Reply-To: <52EA6C42.605@redhat.com> References: <52EA3687.2050601@redhat.com> <52EA39C6.8020607@redhat.com> <5C19C2C6-2F09-4659-A146-0B44AEE4445C@redhat.com> <52EA6C42.605@redhat.com> Message-ID: Another radical solution will be just to change the project name , it's huge but we are still young ... Envoy? de mon iPhone Le Jan 30, 2014 ? 20:44, Hylke Bons a ?crit : > On 30/01/2014 13:37, Lucas Holmquist wrote: >> >> On Jan 30, 2014, at 7:33 AM, Matthias Wessendorf wrote: >> >>> >>> >>> >>> On Thu, Jan 30, 2014 at 12:38 PM, Hylke Bons wrote: >>> You are right that it may be a bit long for replies. >>> "@AGTeam" or "@AGProject" could work too (if they weren't already taken but something amongst those line :). >>> >>> not sure if AGTeam/Project is really 'cool' >> >> yea, if i was just a random person on twitter and saw "AGTeam", i'd be like WhoTF is that >> > > Well, it's just a handle. Real names are shown in tweets too nowadays. It's better to have something that's a bit less related than something that is confusing. *team, *project and *tweets are pretty much convention too and people will figure out the name. > > Hylke > > >>> >>> >>> Hylke >>> >>> >>> On 30/01/2014 11:29, Matthias Wessendorf wrote: >>>> >>>> >>>> >>>> On Thu, Jan 30, 2014 at 12:24 PM, Hylke Bons wrote: >>>> "@AeroGears" can cause confusion about what the project name really is. >>>> >>>> All the JUGs I presented at, and some conferences call the project already "AeroGears", due to the tiwtter handle :-) >>>> >>>> >>>> Options to fix: >>>> - Ask the owner of @AeroGear if he or she want to give up the handle >>>> >>>> are we also offering 50k ? :) >>>> >>>> - Change the handle to "@AeroGearTeam" or "@AeroGearProject", or >>>> something else >>>> >>>> I think the 'concern' was that the name is too long, but on the other hand, there is some sort of confusion w/ our actual name :-0 >>>> >>>> If I had to pick one out of those that you suggested it would be 'AeroGearTeam', that's exactly just three chars longer than the current :) >>>> >>>> -M >>>> >>>> >>>> >>>> >>>> >>>> Thoughts? >>>> >>>> Hylke >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>>> >>>> >>>> >>>> -- >>>> Matthias Wessendorf >>>> >>>> blog: http://matthiaswessendorf.wordpress.com/ >>>> sessions: http://www.slideshare.net/mwessendorf >>>> twitter: http://twitter.com/mwessendorf >>>> >>>> >>>> _______________________________________________ >>>> aerogear-dev mailing list >>>> aerogear-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >>> >>> >>> >>> -- >>> Matthias Wessendorf >>> >>> blog: http://matthiaswessendorf.wordpress.com/ >>> sessions: http://www.slideshare.net/mwessendorf >>> twitter: http://twitter.com/mwessendorf >>> _______________________________________________ >>> aerogear-dev mailing list >>> aerogear-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > 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/20140130/b295abbd/attachment-0001.html From bruno at abstractj.org Thu Jan 30 13:44:42 2014 From: bruno at abstractj.org (Bruno Oliveira) Date: Thu, 30 Jan 2014 16:44:42 -0200 Subject: [aerogear-dev] Let's change the AeroGear Twitter account handle In-Reply-To: References: <52EA3687.2050601@redhat.com> <52EA39C6.8020607@redhat.com> <5C19C2C6-2F09-4659-A146-0B44AEE4445C@redhat.com> <52EA6C42.605@redhat.com> Message-ID: -10000 ? I don?t get what?s the problem, that was already decided. I can?t see any strong argument to change the name. -- abstractj On January 30, 2014 at 3:09:24 PM, S?bastien Blanc (scm.blanc at gmail.com) wrote: > > Another radical solution will be just to change the project > name , it's huge but we are still young ... > > Envoy? de mon iPhone From lholmqui at redhat.com Thu Jan 30 14:15:56 2014 From: lholmqui at redhat.com (Lucas Holmquist) Date: Thu, 30 Jan 2014 14:15:56 -0500 Subject: [aerogear-dev] Sync Day 3 Sync takes Manhattan In-Reply-To: References: <52EA6E63.5060505@redhat.com> Message-ID: On Jan 30, 2014, at 11:03 AM, Matthias Wessendorf wrote: > > > > On Thu, Jan 30, 2014 at 4:23 PM, Summers Pittman wrote: > I rolled up the feedback to the email I sent yesterday. > > One quick note, this is not a 0.1.0 plan nor a 1.0.0 plan. It is > probably closer to a 1.5 or 2.0 plan in terms of scope. > > ahm... thinking about 2.0.0 before we have a 1.0.0 ? Not sure I understand that > > I tried to > order things and break out big "chunks" which will need to be done and > the approximate order they should be done in while also drawing a line > around what features we have. This is why I have not placed ANY > versions YET. By the end of today/tomorrow morning I hope that we will > be in a good place to do that. > > > > > Big changes from yesterday, User mgmt moved to M4. M6 (Sync Listener > Upgrading)was merged into M3(Push Listeners) so that we can have > optional push sooner. > > # M1 - Basic revision Control, Data Model, Change Management, Server <-> > Client Contract > > * We seem to be in agreement on a basic set of metadata to be kept for > each object. [objectId, revision, object]. > * We should have a basic server definition which supports CRUD and > keeps our revision numbers in check. This may not be a server product > but just a spec that can be implemented by anything at this point. > * We should have basic client code which keeps up with revisions, can > check the server for new revisions, and alert the user if there is a > sync conflict. > > +1 > > > > M2 - Sync Listener w/ Polling based sync listener, conflict management, > > * We define on the client how callbacks will work for alerts when > remote data changes > * We implement a listener which polls a data source and delivers > changes to the user. > * We define how conflicts are managed > > > +1 somewhat related http://blog.lholmquist.org/img/ab_sync_conflict.jpg > > > > M3 - Push based Sync Listener, Sync Listener Strategy Management > * The client and server will negotiate when it is appropriate to > switch between polling, push, and realtime sync strategies. > * We will build on our previous Listener work from M2 to include a > Push listener that the server can speak to. > * We will support ways of automagically managing sync listeners based > on the availability of Push. > > > overall, yes - the nasty details can be discussed at a later point, hence > +1 > > > M4 - Server user management, Network Management, Server side session > management > * We will define in the client how network state and sync state > interact. IE how to handle errors in fetching new data when the > Listener is alerted. (Exponential back off, retry, etc) > * The server will need to have some mechanism for managing user > "sessions". This is what users are actively being synced. > * The server should have a basic authentication and authorization plan > for controlling how data is synced > > > this assume we do have a server w/ pluggable adapters, no ? > E.g. JPA/JavaEE/Hibernate adapters verus YetAnotherDatabaseThingy adapter > > > M5 - "Real Time" Sync Listener. Bidirectional automatic sync > * Instead of using push, Realtime Sync uses something like web > sockects. to automatically sync local and remote data. > * Previous Sync listeners may have to be upgraded to include "upload" > abilities. > * We will also include the ability to switch between Realtime sync > listeners, polling listeners, and push listeners > * The server will need to support this as well. > > Didn't M3 already include 'realtime' ? > > > M6 - Conflict resolution, Error detection and support > * Provide a more comprehensive strategy for managing conflicts. > * Provide some automated conflict resolvers > * The server could get a larger set of conflict and errors messages > > M8 - Party > * We have a sync party. > > what about M7? :) > > _______________________________________________ > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140130/ff98a7fb/attachment.html From supittma at redhat.com Thu Jan 30 15:24:02 2014 From: supittma at redhat.com (Summers Pittman) Date: Thu, 30 Jan 2014 15:24:02 -0500 Subject: [aerogear-dev] Sync Day 3 Sync takes Manhattan In-Reply-To: <52EA6E63.5060505@redhat.com> References: <52EA6E63.5060505@redhat.com> Message-ID: <52EAB4E2.7050904@redhat.com> I've turned M1 into a Jira https://issues.jboss.org/browse/AEROGEAR-1405 Is there any complain to turning each M into an Epic and each bullet into a subtask in that Epic? In theory from here we can group them into versions and releases. On 01/30/2014 10:23 AM, Summers Pittman wrote: > I rolled up the feedback to the email I sent yesterday. > > One quick note, this is not a 0.1.0 plan nor a 1.0.0 plan. It is > probably closer to a 1.5 or 2.0 plan in terms of scope. I tried to > order things and break out big "chunks" which will need to be done and > the approximate order they should be done in while also drawing a line > around what features we have. This is why I have not placed ANY > versions YET. By the end of today/tomorrow morning I hope that we will > be in a good place to do that. > > Big changes from yesterday, User mgmt moved to M4. M6 (Sync Listener > Upgrading)was merged into M3(Push Listeners) so that we can have > optional push sooner. > > # M1 - Basic revision Control, Data Model, Change Management, Server <-> > Client Contract > > * We seem to be in agreement on a basic set of metadata to be kept for > each object. [objectId, revision, object]. > * We should have a basic server definition which supports CRUD and > keeps our revision numbers in check. This may not be a server product > but just a spec that can be implemented by anything at this point. > * We should have basic client code which keeps up with revisions, can > check the server for new revisions, and alert the user if there is a > sync conflict. > > > M2 - Sync Listener w/ Polling based sync listener, conflict management, > > * We define on the client how callbacks will work for alerts when > remote data changes > * We implement a listener which polls a data source and delivers > changes to the user. > * We define how conflicts are managed > > > M3 - Push based Sync Listener, Sync Listener Strategy Management > * The client and server will negotiate when it is appropriate to > switch between polling, push, and realtime sync strategies. > * We will build on our previous Listener work from M2 to include a > Push listener that the server can speak to. > * We will support ways of automagically managing sync listeners based > on the availability of Push. > > M4 - Server user management, Network Management, Server side session > management > * We will define in the client how network state and sync state > interact. IE how to handle errors in fetching new data when the > Listener is alerted. (Exponential back off, retry, etc) > * The server will need to have some mechanism for managing user > "sessions". This is what users are actively being synced. > * The server should have a basic authentication and authorization plan > for controlling how data is synced > > M5 - "Real Time" Sync Listener. Bidirectional automatic sync > * Instead of using push, Realtime Sync uses something like web > sockects. to automatically sync local and remote data. > * Previous Sync listeners may have to be upgraded to include "upload" > abilities. > * We will also include the ability to switch between Realtime sync > listeners, polling listeners, and push listeners > * The server will need to support this as well. > > M6 - Conflict resolution, Error detection and support > * Provide a more comprehensive strategy for managing conflicts. > * Provide some automated conflict resolvers > * The server could get a larger set of conflict and errors messages > > M8 - Party > * We have a sync party. > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev From matzew at apache.org Thu Jan 30 16:43:29 2014 From: matzew at apache.org (Matthias Wessendorf) Date: Thu, 30 Jan 2014 22:43:29 +0100 Subject: [aerogear-dev] Sync Day 3 Sync takes Manhattan In-Reply-To: <52EAB4E2.7050904@redhat.com> References: <52EA6E63.5060505@redhat.com> <52EAB4E2.7050904@redhat.com> Message-ID: On Thu, Jan 30, 2014 at 9:24 PM, Summers Pittman wrote: > I've turned M1 into a Jira https://issues.jboss.org/browse/AEROGEAR-1405 yay! > > > Is there any complain to turning each M into an Epic and each bullet > into a subtask in that Epic? > Nope, that's perfect > > In theory from here we can group them into versions and releases. > +1 > > On 01/30/2014 10:23 AM, Summers Pittman wrote: > > I rolled up the feedback to the email I sent yesterday. > > > > One quick note, this is not a 0.1.0 plan nor a 1.0.0 plan. It is > > probably closer to a 1.5 or 2.0 plan in terms of scope. I tried to > > order things and break out big "chunks" which will need to be done and > > the approximate order they should be done in while also drawing a line > > around what features we have. This is why I have not placed ANY > > versions YET. By the end of today/tomorrow morning I hope that we will > > be in a good place to do that. > > > > Big changes from yesterday, User mgmt moved to M4. M6 (Sync Listener > > Upgrading)was merged into M3(Push Listeners) so that we can have > > optional push sooner. > > > > # M1 - Basic revision Control, Data Model, Change Management, Server <-> > > Client Contract > > > > * We seem to be in agreement on a basic set of metadata to be kept > for > > each object. [objectId, revision, object]. > > * We should have a basic server definition which supports CRUD and > > keeps our revision numbers in check. This may not be a server product > > but just a spec that can be implemented by anything at this point. > > * We should have basic client code which keeps up with revisions, can > > check the server for new revisions, and alert the user if there is a > > sync conflict. > > > > > > M2 - Sync Listener w/ Polling based sync listener, conflict management, > > > > * We define on the client how callbacks will work for alerts when > > remote data changes > > * We implement a listener which polls a data source and delivers > > changes to the user. > > * We define how conflicts are managed > > > > > > M3 - Push based Sync Listener, Sync Listener Strategy Management > > * The client and server will negotiate when it is appropriate to > > switch between polling, push, and realtime sync strategies. > > * We will build on our previous Listener work from M2 to include a > > Push listener that the server can speak to. > > * We will support ways of automagically managing sync listeners based > > on the availability of Push. > > > > M4 - Server user management, Network Management, Server side session > > management > > * We will define in the client how network state and sync state > > interact. IE how to handle errors in fetching new data when the > > Listener is alerted. (Exponential back off, retry, etc) > > * The server will need to have some mechanism for managing user > > "sessions". This is what users are actively being synced. > > * The server should have a basic authentication and authorization plan > > for controlling how data is synced > > > > M5 - "Real Time" Sync Listener. Bidirectional automatic sync > > * Instead of using push, Realtime Sync uses something like web > > sockects. to automatically sync local and remote data. > > * Previous Sync listeners may have to be upgraded to include "upload" > > abilities. > > * We will also include the ability to switch between Realtime sync > > listeners, polling listeners, and push listeners > > * The server will need to support this as well. > > > > M6 - Conflict resolution, Error detection and support > > * Provide a more comprehensive strategy for managing conflicts. > > * Provide some automated conflict resolvers > > * The server could get a larger set of conflict and errors messages > > > > M8 - Party > > * We have a sync party. > > _______________________________________________ > > aerogear-dev mailing list > > aerogear-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/aerogear-dev > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20140130/5e7f2b79/attachment-0001.html From qmx at qmx.me Fri Jan 31 15:42:02 2014 From: qmx at qmx.me (Douglas Campos) Date: Fri, 31 Jan 2014 18:42:02 -0200 Subject: [aerogear-dev] bower repos for custom builds In-Reply-To: References: <8B1AE989-453D-456E-8911-D1E4F31084D1@redhat.com> <20140128190852.GH20528@rohan.local> Message-ID: <20140131204202.GG61817@rohan.local> On Tue, Jan 28, 2014 at 02:13:05PM -0500, Lucas Holmquist wrote: > > On Jan 28, 2014, at 2:08 PM, Douglas Campos wrote: > > > On Tue, Jan 28, 2014 at 09:40:47AM -0500, Lucas Holmquist wrote: > >> so i created this JIRA https://issues.jboss.org/browse/AGJS-133 > >> > >> It would kind of neat if we offered some custom builds in bower, > >> > >> this way it could make it super easy for someone to pull in just data > >> manager for example > >> > >> $ bower install aerogear-datamanager One of the things we briefly talked on IRC that I promised to post here: I was (naively) thinking that this command would bring this to the app: - aerogear-datamanager.js +-- aerogear-core.js (as a dependency) So, what do we need to do to have something like this? Is AMD-ifying the project the only solution for having this? > at the moment we only have "official releases", but it would be > interesting to have the "development release" also available since > these are really just tags Hmm, but wouldn't this mean we just end up with a ton of tags? if people want to use development builds they can point to the repo, can't they? -- qmx