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

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Sebastien Blanc
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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Kris Borchers
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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Sebastien Blanc
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Kris Borchers
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Sebastien Blanc
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Corinne Krych
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. 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.
Looking at your TODO app I think it would be nice to decouple the view

2. Not sure how you're thinking on introducing Sync in your code, is it going to be another adapters of DataManager?

3. Are you going to provide multi-user synch?

Tell me your views...
++
Corinne.

On 26 October 2012 16:03, Sebastien Blanc <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Kris Borchers
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Corinne Krych
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/ 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

Inline images 1



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?
Do you plan to implement another adapter of DataManager to deal with localStorage permanent store?

Cheers
Corinne

On 29 October 2012 12:46, Kris Borchers <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Kris Borchers

On Oct 29, 2012, at 8:03 AM, Corinne Krych <[hidden email]> 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/ 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Corinne Krych
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 <[hidden email]> wrote:

On Oct 29, 2012, at 8:03 AM, Corinne Krych <[hidden email]> 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/ 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|

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

Kris Borchers
No problem and please do stay tuned. Feel free to get involved too. :D We would appreciate any input you might have and feel free to say hi in IRC too on #aerogear on freenode.

Thanks!


On Oct 29, 2012, at 8:26 AM, Corinne Krych <[hidden email]> wrote:

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 <[hidden email]> wrote:

On Oct 29, 2012, at 8:03 AM, Corinne Krych <[hidden email]> 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/ 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev



_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev