[aerogear-dev] [iOS] Simple draft of HTTP API to talk to ag-sync server
Lucas Holmquist
lholmqui at redhat.com
Tue Jan 21 09:02:13 EST 2014
On Jan 21, 2014, at 8:57 AM, Matthias Wessendorf <matzew at apache.org> wrote:
>
>
>
> 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
yea, it is pretty nice when comparing/diffing objects and arrays
>
> -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
> _______________________________________________
> 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
More information about the aerogear-dev
mailing list