[aerogear-dev] [iOS] Simple draft of HTTP API to talk to ag-sync server

[Matthias Wessendorf]

On Tue, Jan 21, 2014 at 2:45 PM, Lucas Holmquist <lholmqui at redhat.com>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 <lholmqui at redhat.com> 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 <matzew at apache.org>
> 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