[aerogear-dev] Big picture questions around the PipeManager and the DatastoreManager

Mon Oct 29 09:26:29 EDT 2012

Thks Kris

I'll stay tuned then.

I was thinking the same when implementing multi-users synchro, I'll take
advantage of Grails which already implements version attribute on all
domain object to provide a first draft of server side conflict merger.

Corinne.

On 29 October 2012 14:16, Kris Borchers <kris at redhat.com> wrote:

>
> On Oct 29, 2012, at 8:03 AM, Corinne Krych <corinnekrych at gmail.com> wrote:
>
> Hi Kris
>
> when talking about MVC, I actually meant MVC on client side.
>
> In my tagmyfriends exemple that I'm going to present to http://jseverywhere.eu/
> <http://jseverywhere.eu/%20>conf, I decouple the view and I've
> implemented a first draft of SyncManager for single user. Still not
> complete though.
>
> Here a picture of how client side look like in my ex.
> oops my picture has an error: it's syncmgr that sends ajax call not the
> store...
> But the code never lies, have a look to my Sync
>
> https://github.com/corinnekrych/tagmyfriends/blob/master/web-app/js/grails/mobile/sync/syncmanager.js
>
> <image.png>
>
>
>
>
> I had a look at your branch, I'm wondering the list of conductors will be
> the recorded journal of all offline events, right? Any link to your
> DataManager stores?
>
> The SyncManager will only orchestrate, thus the conductor name :), the
> interactions between pipes and stores. The DataManager maintains the record
> of offline data modifications and then based on that record, when a sync is
> done, it knows what needs to be sent. It will be up to the specific server
> implementation to manage how to merge that data though I would imagine we
> would implement 1 particular server impl for users to try but it should be
> pluggable to any impl.
>
> Do you plan to implement another adapter of DataManager to deal with
> localStorage permanent store?
>
> Yes, I actually have a sessionStorage/localStorage adapter for DataManager
> here on my machine I just haven't had time to update it to the latest
> DataManager changes. It is due to be included in our next milestone release.
>
>
> Cheers
> Corinne
>
> On 29 October 2012 12:46, Kris Borchers <kris at redhat.com> wrote:
>
>> Corinne,
>>
>> Thanks for your input. Please see my responses inline. I will be speaking
>> from a JS point of view. The others that work on our Android or iOS libs
>> may have different thoughts but what I'm working on is more relevant to
>> your questions.
>>
>> On Oct 29, 2012, at 4:17 AM, Corinne Krych <corinnekrych at gmail.com>
>> wrote:
>>
>> Hello Guys
>>
>> I jumped into the discussion because I'm working on similar topic for
>> 3musket33rs html-grails-plugin. And I would like to share my thoughts with
>> you.
>>
>> See code for Grails plugin here
>> https://github.com/3musket33rs/html5-mobile-scaffolding
>> or an example of implementation (if you just wan tto se the js)
>> https://github.com/corinnekrych/tagmyfriends/tree/master/web-app/js
>>
>> My design is similar I called Feed what you have named Pipeline.Feed can
>> be online or offline and I've implemented a first draft of synchronization.
>> Model is more or less equivalent to your StoreManager.
>>
>> Main differences I see is:
>>
>> 1. I've chosen to decouple with MVC pattern as I needed to identify what
>> need to be generated by Grails plugin.
>>
>> We are trying to keep the client libraries as decoupled from the server
>> as possible and only depend on a server implementation when necessary for
>> things like specific security adapters or syncing.
>>
>> For ex, in my example app the generated part is
>>
>> https://github.com/corinnekrych/tagmyfriends/tree/master/web-app/js/tagmyfriends
>> There is a bunch of js libraries (backbone, angular etc...) to do this
>> and I might propose an easy way to plug the chosen fwk.
>>
>>  The goal is that eventually AeroGear could work in tandem with client
>> side MV* libs like Backbone. That way, AeroGear could be used in place of
>> that library's persistence or sync method to be able to do things like use
>> Backbone with offline access and sync and use WebSockets as the server
>> connection.
>>
>> Looking at your TODO app I think it would be nice to decouple the view
>>
>> Totally agree. I have plans to rework/rebuild that app to do just that.
>> It started very simple but has grown quickly to obviously need the benefits
>> of something like Backbone.
>>
>>
>> 2. Not sure how you're thinking on introducing Sync in your code, is it
>> going to be another adapters of DataManager?
>>
>> I am working on completely decoupling Pipeline and DataManager and then
>> introducing a new module called SyncManager that will handle all syncing
>> between local and server side data. You can see the very early start and
>> monitor the progress of this code in the SyncManager branch
>> https://github.com/aerogear/aerogear-js/tree/SyncManager
>>
>>
>> 3. Are you going to provide multi-user synch?
>>
>> Yes, that is the goal. That would be one of those situations where a
>> specific server implementation would be used to manage things like
>> simultaneous connections, conflicts between two clients modifying the same
>> data offline, etc. This is all still very young though and hasn't been
>> worked out yet.
>>
>>
>> Tell me your views...
>> ++
>> Corinne.
>>
>> On 26 October 2012 16:03, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>>
>>> Very clear ;-)
>>> The question is how much flexibility/facilities/abstraction do we give
>>> to the app dev ? But some very interesting challenges to come ...
>>> Seb
>>>
>>>
>>> On Fri, Oct 26, 2012 at 3:21 PM, Kris Borchers <kris at redhat.com> wrote:
>>>
>>>> But a pipe only deals with moving data between the client and server. A
>>>> store handles client side data manipulation. We purposefully separated
>>>> them. Then the app dev can either manage when and how they use each or they
>>>> can use SyncManager to handle a lot of it for them. I don't see the benefit
>>>> of duplicating functionality of DataManager in Pipeline or vice versa.
>>>>
>>>> On Oct 26, 2012, at 8:13 AM, Sebastien Blanc <scm.blanc at gmail.com>
>>>> wrote:
>>>>
>>>> Hi,
>>>> I agree the "localPipe" seems like a bit strange weird, and it's
>>>> implementation will be very simple and "dumb" but there will be situation
>>>> maybe where we want to stay on the Pipe API, rather than shortcut to the
>>>> datamanager,  even if this Pipe just do a local loop, not sure I'm clear on
>>>> this point but it is the idea of consistency ...
>>>> Seb
>>>>
>>>>
>>>> On Fri, Oct 26, 2012 at 3:03 PM, Kris Borchers <kris at redhat.com> wrote:
>>>>
>>>>> We are on the same page for the most part. :)  Not sure what you mean
>>>>> by a "local pipe" though. I think that is what DataManager does. As for the
>>>>> event driven model for connecting and syncing a pipe to a store, I am
>>>>> already working on that on the JS side. Check out SyncManager in
>>>>> https://github.com/aerogear/aerogear-js/tree/SyncManager. There is
>>>>> still a lot to do and I have more code locally but it's a start.
>>>>>
>>>>> On Oct 26, 2012, at 7:56 AM, Sebastien Blanc <scm.blanc at gmail.com>
>>>>> wrote:
>>>>>
>>>>> Hi all !
>>>>> I was looking at the all different documentation pages and FAQ,  and
>>>>> some questions and ideas araise :
>>>>>
>>>>> 1)  A PipeManager can contains 'n' pipes, is there any plan to be able
>>>>> to chain pipes together (i.e : "localPipe -> restPipe") ? Even nicer, would
>>>>> it be possible to make conditional the pipe "route" (i.e ; "no connection
>>>>> then use the localPipe" etc …)
>>>>>
>>>>>
>>>>> 2)  The dataStore concept is clear but are there any plans to create
>>>>> some sort of association (one-to-one, one-to-many, etc ...) between a pipe
>>>>> and a datastore instance ?
>>>>>
>>>>>
>>>>> 3)  One idea should be that a pipe produce events ("entering
>>>>> pipe","exiting pipe", with some useful callback  data) and then any other
>>>>> component should be able to register to the pipe's events, same could be
>>>>> implemented for the other components (datastore events , security events)
>>>>> ...
>>>>>
>>>>> The main idea is how we will consolidate all this different
>>>>> components together (pipe and datamanager mainly) onces we will have to
>>>>> deal with data sync for example.
>>>>>
>>>>> I'm just throwing some ideas after a brainstorming with myself ;-) but
>>>>> please share your comments on this !
>>>>>
>>>>> Best Regards,
>>>>> Seb
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> aerogear-dev mailing list
>>>>> aerogear-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>>
>>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> aerogear-dev mailing list
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.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/20121029/141d4590/attachment-0001.html 