[aerogear-dev] LiveOak SDK

[Burr Sutter]

At a minimum, the same HTTP error codes used to indicate "sync errors" via JAX-RS + JPA should be the same for LiveOak's REST APIs - therefore the client-code can be reusable across the two endpoints.   We should come up with sync strategies - levels 1, 2 and 3 - where 1 is simply the clever use of HTTP error codes and level 3 is real-time/off-line/auto-conflict resolution.   Perhaps there are 4 levels :-)

Anyone care to articulate the possible strategies?


On Jul 8, 2014, at 9:02 AM, Summers Pittman <supittma at redhat.com> wrote:

> On Mon 07 Jul 2014 12:14:17 PM EDT, Matt Wringe wrote:
>> 
>> Initial email to get some discussion going around the LiveOak SDK and
>> AeroGear collaboration.
>> 
>> Essentially in LiveOak we are going to need a few different SDK types
>> 
>> - Client Application SDK
>> This is the code which will run on the users device. Initial targets
>> here are javascript (+ cordova support), iOS, Android. This type of SDK
>> will handle things like getting and sending resources to and from the
>> server, handling login/logout/registration, etc. Probably some other
>> things like device registration would be needed as well.
>> 
>> Not sure if we want to provide support for some other things outside of
>> communicating with the server or not (eg access to device components (eg
>> camera, location, etc)) or if these would be best handled by using the
>> native environment's SDK instead.
>> 
>> - Server Side SDK
>> This is code that runs on the server side, written in JavaScript by the
>> application developer. This will need to be familiar to the client
>> application's JavaScript SDK, but may not be exactly the same. This type
>> of SDK will be able to access the same resources as the client side
>> JavaScript, as well as other internal resources and libraries.
>> 
>> 
>> I am not sure how to collaborate between the LiveOak and AeroGear teams
>> here. AeroGear makes really awesome SDKs for various mobile platforms,
>> but with LiveOak we are dealing with a specific type of application. The
>> AeroGear SDKs tend to handle the more generic case, which I don't
>> necessarily think makes sense for a LiveOak SDK.
>> 
>> I do think it makes sense that the LiveOak SDK uses the AeroGear SDK
>> internally, but I don't know if we want to expose these AeroGear
>> components to a LiveOak developer or not.
>> 
>> 
>> For me, I envision something like the admin setting up their application
>> in the LiveOak console which then generates a json configuration file
>> (url locations, resources available, KeyCloak settings, UPS settings,
>> etc). The application developer then drops this json file in to their
>> application, the LiveOak SDK reads the json file to set it self up and
>> then its really easy for the developer to start using it.
>> 
>> [there are also some really cool things we could be doing here as well
>> if we can get awesome data sync support for AeroGear. It might be
>> interesting to be able to fetch a resource from the server and
>> automatically sync its state across between the client and server. This
>> way the object appears as a local object: if the resource changes on the
>> server, it changes locally as well, if it changes locally, that change
>> is pushed to the server. This way you are just dealing with an object,
>> and not having to fetch and then push object back and forth between the
>> server manually]
>> 
>> Anyone have any thoughts on this?
> 
> One of the things which may be useful is aerogear-ios and 
> aerogear-android are both modularizing their libraries.  IN theory this 
> means that the liveOAK SDK's could be extensions of those modules 
> instead of a single monolothic thing.
> 
> Sync is still an ongoing discussion in AeroGear, but I think right now 
> the current group thought is that we will focus on 409 Conflict events 
> (JPA versioning on server side and utilities on the client side) and not 
> worrying about realtime sync.
> 
> 
> Some notes from out last meeting on the topic :
> Client API Strawman :
> https://github.com/secondsun/aerogear-android-sync/tree/master/android
> Client/Server workflow :
> https://docs.google.com/drawings/d/1E4NDEh3NQCdoEHNNHba4TR2akNrppvV5zDlk5nfzz08/edit 
> 
> 
> Also we are looking at doing something with diff merge patch as well as 
> adding in push based data changed notifications later.
> 
> 
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> 
> 
> 
> -- 
> Summers Pittman
>>> Phone:404 941 4698
>>> Java is my crack.
> 
> _______________________________________________
> 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/20140708/c839ceae/attachment.html