Quantcast

[aerogear-dev] AeroGear.js Separation of Concerns

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[aerogear-dev] AeroGear.js Separation of Concerns

Kris Borchers
Now that AeroGear.js 1.0.0.Alpha is out, I want to get people's thoughts both on what they think of the library so far, and where they would like to see it go in the future. Please take a look at http://staging-aerogear.rhcloud.com/docs/planning/1.0.0/AeroGearJS/ and provide any feedback on the current roadmap that you may have.

Also, and more to the subject of this e-mail, I want to discuss the separation of concerns between the different pieces of AeroGear.js and what should be handled where. I bring this up because as I move forward with Pipeline and the other components of the library, I find myself implementing things where they may not belong. Specifically, I have started creating a filter method in the REST adapter for pipeline. I have started to think that this is not where that method belongs and in fact, the storage of data in the pipeline object at all I think was a mistake. I think Pipeline should be just that, a pipeline for data to move between the client and server and should not be a place where data is managed or manipulated.

This is where some sort of data management piece of the lib comes in - no clever name yet :). I would like to see Pipeline handle the transport of data, whether that be with REST, websockets or what ever, but then just hand the data off to the app to do what it wants. Then, we can support a connection between Pipeline and this data management piece so that if the user wants help with data management including storage in memory, session storage, local storage, web sql, IndexedDB, files, etc. they could pass an instance of the data manager to Pipeline and say put the data here when you get it or take it from here when you send it, etc.

I hope this novel I just wrote makes sense but please feel free to ask questions, make comments and suggestions, tell me I'm an idiot, what ever. If people seem on board with this, I would like to get a basic memory based storage system similar to what is in Pipeline now, moved out into it's on section of the library in conjunction with working on aerogear-auth.js for M6.

Thanks,
Kris

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

Re: [aerogear-dev] AeroGear.js Separation of Concerns

Luke
I agree with the separation.  Having it connect to a separate data layer makes sense.  Then they can use the data layer without pipeline if they wanted to get it another way.  

it seems that each Library(maybe not the right word) should do one thing and do it awesome! 

We don't want to just recreate backbone Models, or any other other Model part of a framework for that matter.  

I know in my development,  i just want to get the data from the backend and manipulate it on my own. 

The only question i have is how the separation would relate to the sync process?  Would the user then have to use both pipeline and data thing to keep front/back end in sync?

-Luke


On Tue, Aug 28, 2012 at 2:08 PM, Kris Borchers <[hidden email]> wrote:
Now that AeroGear.js 1.0.0.Alpha is out, I want to get people's thoughts both on what they think of the library so far, and where they would like to see it go in the future. Please take a look at http://staging-aerogear.rhcloud.com/docs/planning/1.0.0/AeroGearJS/ and provide any feedback on the current roadmap that you may have.

Also, and more to the subject of this e-mail, I want to discuss the separation of concerns between the different pieces of AeroGear.js and what should be handled where. I bring this up because as I move forward with Pipeline and the other components of the library, I find myself implementing things where they may not belong. Specifically, I have started creating a filter method in the REST adapter for pipeline. I have started to think that this is not where that method belongs and in fact, the storage of data in the pipeline object at all I think was a mistake. I think Pipeline should be just that, a pipeline for data to move between the client and server and should not be a place where data is managed or manipulated.

This is where some sort of data management piece of the lib comes in - no clever name yet :). I would like to see Pipeline handle the transport of data, whether that be with REST, websockets or what ever, but then just hand the data off to the app to do what it wants. Then, we can support a connection between Pipeline and this data management piece so that if the user wants help with data management including storage in memory, session storage, local storage, web sql, IndexedDB, files, etc. they could pass an instance of the data manager to Pipeline and say put the data here when you get it or take it from here when you send it, etc.

I hope this novel I just wrote makes sense but please feel free to ask questions, make comments and suggestions, tell me I'm an idiot, what ever. If people seem on board with this, I would like to get a basic memory based storage system similar to what is in Pipeline now, moved out into it's on section of the library in conjunction with working on aerogear-auth.js for M6.

Thanks,
Kris

_______________________________________________
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
|  
Report Content as Inappropriate

Re: [aerogear-dev] AeroGear.js Separation of Concerns

Kris Borchers

On Aug 28, 2012, at 3:34 PM, Lucas Holmquist <[hidden email]> wrote:

I agree with the separation.  Having it connect to a separate data layer makes sense.  Then they can use the data layer without pipeline if they wanted to get it another way.  

Exactly

it seems that each Library(maybe not the right word) should do one thing and do it awesome! 

We don't want to just recreate backbone Models, or any other other Model part of a framework for that matter.  

I know in my development,  i just want to get the data from the backend and manipulate it on my own. 

The only question i have is how the separation would relate to the sync process?  Would the user then have to use both pipeline and data thing to keep front/back end in sync?

That's a good question. In order to keep them separate, yes they would need both to have AeroGear handle the syncing or they would have to do sync on their own.

On a side note, I am planning on adding different build options into the grunt build so that people can pick and choose what pieces they want and create a custom build. Eventually, it would be nice to have a little web app that did that for them by checking a few boxes and clicking download as well but this is all future stuff.

-Luke


On Tue, Aug 28, 2012 at 2:08 PM, Kris Borchers <[hidden email]> wrote:
Now that AeroGear.js 1.0.0.Alpha is out, I want to get people's thoughts both on what they think of the library so far, and where they would like to see it go in the future. Please take a look at http://staging-aerogear.rhcloud.com/docs/planning/1.0.0/AeroGearJS/ and provide any feedback on the current roadmap that you may have.

Also, and more to the subject of this e-mail, I want to discuss the separation of concerns between the different pieces of AeroGear.js and what should be handled where. I bring this up because as I move forward with Pipeline and the other components of the library, I find myself implementing things where they may not belong. Specifically, I have started creating a filter method in the REST adapter for pipeline. I have started to think that this is not where that method belongs and in fact, the storage of data in the pipeline object at all I think was a mistake. I think Pipeline should be just that, a pipeline for data to move between the client and server and should not be a place where data is managed or manipulated.

This is where some sort of data management piece of the lib comes in - no clever name yet :). I would like to see Pipeline handle the transport of data, whether that be with REST, websockets or what ever, but then just hand the data off to the app to do what it wants. Then, we can support a connection between Pipeline and this data management piece so that if the user wants help with data management including storage in memory, session storage, local storage, web sql, IndexedDB, files, etc. they could pass an instance of the data manager to Pipeline and say put the data here when you get it or take it from here when you send it, etc.

I hope this novel I just wrote makes sense but please feel free to ask questions, make comments and suggestions, tell me I'm an idiot, what ever. If people seem on board with this, I would like to get a basic memory based storage system similar to what is in Pipeline now, moved out into it's on section of the library in conjunction with working on aerogear-auth.js for M6.

Thanks,
Kris

_______________________________________________
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
|  
Report Content as Inappropriate

Re: [aerogear-dev] AeroGear.js Separation of Concerns

Matthias Wessendorf
In reply to this post by Kris Borchers
Howdy Kris!

thanks for brining it up - should apply to all 'client offerings' :)

More inline!

On Tue, Aug 28, 2012 at 8:08 PM, Kris Borchers <[hidden email]> wrote:

> Now that AeroGear.js 1.0.0.Alpha is out, I want to get people's thoughts
> both on what they think of the library so far, and where they would like to
> see it go in the future. Please take a look at
> http://staging-aerogear.rhcloud.com/docs/planning/1.0.0/AeroGearJS/ and
> provide any feedback on the current roadmap that you may have.
>
> Also, and more to the subject of this e-mail, I want to discuss the
> separation of concerns between the different pieces of AeroGear.js and what
> should be handled where. I bring this up because as I move forward with
> Pipeline and the other components of the library, I find myself implementing
> things where they may not belong. Specifically, I have started creating a
> filter method in the REST adapter for pipeline. I have started to think that
> this is not where that method belongs and in fact, the storage of data in
> the pipeline object at all I think was a mistake. I think Pipeline should be
> just that, a pipeline for data to move between the client and server and
> should not be a place where data is managed or manipulated.

+1 storing the data on a 'handler' object (like the pipeline) is wrong.
They should have (almost) no state!

(Honestly, when seeing your commit/push msgs on IRC, I thought
the 'filter' is a 'filtered read', BUT yeah... that's already
implemented on read itself :))

> This is where some sort of data management piece of the lib comes in - no
> clever name yet :). I would like to see Pipeline handle the transport of
> data, whether that be with REST, websockets or what ever, but then just hand
> the data off to the app to do what it wants.

+1 on separation :)

That's actually how the 'pipeline' is currently implemented on aerogear-ios.
It (the 'restful pipeline' (see [1]) reads the data and makes it
available, via blocks/closure.
The AGRestAdapter does not store any of that - if the app _wants_ -> fine ;)

See: https://gist.github.com/3508647


> Then, we can support a
> connection between Pipeline and this data management piece so that if the
> user wants help with data management including storage in memory, session
> storage, local storage, web sql, IndexedDB, files, etc. they could pass an
> instance of the data manager to Pipeline and say put the data here when you
> get it or take it from here when you send it, etc.

Exactly !

>
> I hope this novel I just wrote makes sense but please feel free to ask
> questions, make comments and suggestions, tell me I'm an idiot, what ever.
> If people seem on board with this, I would like to get a basic memory based
> storage system similar to what is in Pipeline now, moved out into it's on
> section of the library in conjunction with working on aerogear-auth.js for
> M6.

totally makes sense, and yes - please go for the isolation :)

-M

[1] https://github.com/aerogear/aerogear-ios/blob/master/AeroGear-iOS/AeroGear-iOS/AGRestAdapter.m

> Thanks,
> Kris
>
> _______________________________________________
> aerogear-dev mailing list
> [hidden email]
> 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
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [aerogear-dev] AeroGear.js Separation of Concerns

Matthias Wessendorf
In reply to this post by Luke
Hi Lucas,

On Tue, Aug 28, 2012 at 10:34 PM, Lucas Holmquist
<[hidden email]> wrote:
> I agree with the separation.  Having it connect to a separate data layer
> makes sense.

*any* data layer :)

>  Then they can use the data layer without pipeline if they
> wanted to get it another way.
>
> it seems that each Library(maybe not the right word) should do one thing and
> do it awesome!
>
> We don't want to just recreate backbone Models, or any other other Model
> part of a framework for that matter.


can you explain what you mean with that statement ?

>
> I know in my development,  i just want to get the data from the backend and
> manipulate it on my own.
>
> The only question i have is how the separation would relate to the sync
> process?  Would the user then have to use both pipeline and data thing to
> keep front/back end in sync?
>
> -Luke
>
>
> On Tue, Aug 28, 2012 at 2:08 PM, Kris Borchers <[hidden email]> wrote:
>>
>> Now that AeroGear.js 1.0.0.Alpha is out, I want to get people's thoughts
>> both on what they think of the library so far, and where they would like to
>> see it go in the future. Please take a look at
>> http://staging-aerogear.rhcloud.com/docs/planning/1.0.0/AeroGearJS/ and
>> provide any feedback on the current roadmap that you may have.
>>
>> Also, and more to the subject of this e-mail, I want to discuss the
>> separation of concerns between the different pieces of AeroGear.js and what
>> should be handled where. I bring this up because as I move forward with
>> Pipeline and the other components of the library, I find myself implementing
>> things where they may not belong. Specifically, I have started creating a
>> filter method in the REST adapter for pipeline. I have started to think that
>> this is not where that method belongs and in fact, the storage of data in
>> the pipeline object at all I think was a mistake. I think Pipeline should be
>> just that, a pipeline for data to move between the client and server and
>> should not be a place where data is managed or manipulated.
>>
>> This is where some sort of data management piece of the lib comes in - no
>> clever name yet :). I would like to see Pipeline handle the transport of
>> data, whether that be with REST, websockets or what ever, but then just hand
>> the data off to the app to do what it wants. Then, we can support a
>> connection between Pipeline and this data management piece so that if the
>> user wants help with data management including storage in memory, session
>> storage, local storage, web sql, IndexedDB, files, etc. they could pass an
>> instance of the data manager to Pipeline and say put the data here when you
>> get it or take it from here when you send it, etc.
>>
>> I hope this novel I just wrote makes sense but please feel free to ask
>> questions, make comments and suggestions, tell me I'm an idiot, what ever.
>> If people seem on board with this, I would like to get a basic memory based
>> storage system similar to what is in Pipeline now, moved out into it's on
>> section of the library in conjunction with working on aerogear-auth.js for
>> M6.
>>
>> Thanks,
>> Kris
>>
>> _______________________________________________
>> 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
>



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [aerogear-dev] AeroGear.js Separation of Concerns

Matthias Wessendorf
In reply to this post by Kris Borchers
On Tue, Aug 28, 2012 at 10:55 PM, Kris Borchers <[hidden email]> wrote:

>
> On Aug 28, 2012, at 3:34 PM, Lucas Holmquist <[hidden email]>
> wrote:
>
> I agree with the separation.  Having it connect to a separate data layer
> makes sense.  Then they can use the data layer without pipeline if they
> wanted to get it another way.
>
>
> Exactly
>
>
> it seems that each Library(maybe not the right word) should do one thing and
> do it awesome!
>
> We don't want to just recreate backbone Models, or any other other Model
> part of a framework for that matter.
>
> I know in my development,  i just want to get the data from the backend and
> manipulate it on my own.
>
> The only question i have is how the separation would relate to the sync
> process?  Would the user then have to use both pipeline and data thing to
> keep front/back end in sync?
>
>
> That's a good question. In order to keep them separate, yes they would need
> both to have AeroGear handle the syncing or they would have to do sync on
> their own.

Hey Kris,

right now the 'sync' would be 'polling' based, right ? E.g. haven the
app using the 'client library'
to ask for new/modified data, right?

With a WebSocket adapter, there are other options - but that's future :)

> On a side note, I am planning on adding different build options into the
> grunt build so that people can pick and choose what pieces they want and
> create a custom build. Eventually, it would be nice to have a little web app
> that did that for them by checking a few boxes and clicking download as well
> but this is all future stuff.

I have seen this somewhere before .... :-) :)

Cheers!
Matthias

>
>
> -Luke
>
>
> On Tue, Aug 28, 2012 at 2:08 PM, Kris Borchers <[hidden email]> wrote:
>>
>> Now that AeroGear.js 1.0.0.Alpha is out, I want to get people's thoughts
>> both on what they think of the library so far, and where they would like to
>> see it go in the future. Please take a look at
>> http://staging-aerogear.rhcloud.com/docs/planning/1.0.0/AeroGearJS/ and
>> provide any feedback on the current roadmap that you may have.
>>
>> Also, and more to the subject of this e-mail, I want to discuss the
>> separation of concerns between the different pieces of AeroGear.js and what
>> should be handled where. I bring this up because as I move forward with
>> Pipeline and the other components of the library, I find myself implementing
>> things where they may not belong. Specifically, I have started creating a
>> filter method in the REST adapter for pipeline. I have started to think that
>> this is not where that method belongs and in fact, the storage of data in
>> the pipeline object at all I think was a mistake. I think Pipeline should be
>> just that, a pipeline for data to move between the client and server and
>> should not be a place where data is managed or manipulated.
>>
>> This is where some sort of data management piece of the lib comes in - no
>> clever name yet :). I would like to see Pipeline handle the transport of
>> data, whether that be with REST, websockets or what ever, but then just hand
>> the data off to the app to do what it wants. Then, we can support a
>> connection between Pipeline and this data management piece so that if the
>> user wants help with data management including storage in memory, session
>> storage, local storage, web sql, IndexedDB, files, etc. they could pass an
>> instance of the data manager to Pipeline and say put the data here when you
>> get it or take it from here when you send it, etc.
>>
>> I hope this novel I just wrote makes sense but please feel free to ask
>> questions, make comments and suggestions, tell me I'm an idiot, what ever.
>> If people seem on board with this, I would like to get a basic memory based
>> storage system similar to what is in Pipeline now, moved out into it's on
>> section of the library in conjunction with working on aerogear-auth.js for
>> M6.
>>
>> Thanks,
>> Kris
>>
>> _______________________________________________
>> 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
>



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [aerogear-dev] AeroGear.js Separation of Concerns

Kris Borchers

On Aug 29, 2012, at 3:50 AM, Matthias Wessendorf <[hidden email]> wrote:

> On Tue, Aug 28, 2012 at 10:55 PM, Kris Borchers <[hidden email]> wrote:
>>
>> On Aug 28, 2012, at 3:34 PM, Lucas Holmquist <[hidden email]>
>> wrote:
>>
>> I agree with the separation.  Having it connect to a separate data layer
>> makes sense.  Then they can use the data layer without pipeline if they
>> wanted to get it another way.
>>
>>
>> Exactly
>>
>>
>> it seems that each Library(maybe not the right word) should do one thing and
>> do it awesome!
>>
>> We don't want to just recreate backbone Models, or any other other Model
>> part of a framework for that matter.
>>
>> I know in my development,  i just want to get the data from the backend and
>> manipulate it on my own.
>>
>> The only question i have is how the separation would relate to the sync
>> process?  Would the user then have to use both pipeline and data thing to
>> keep front/back end in sync?
>>
>>
>> That's a good question. In order to keep them separate, yes they would need
>> both to have AeroGear handle the syncing or they would have to do sync on
>> their own.
>
> Hey Kris,
>
> right now the 'sync' would be 'polling' based, right ? E.g. haven the
> app using the 'client library'
> to ask for new/modified data, right?

Honestly, I haven't gotten that far yet. The initial implementation would not incorporate any sort of automatic sync, instead it would be up to the user to tell pipeline to update the data from the server or push new data to the server. When we get to sync, then we will need to probably do some sort of polling if we are using REST and then yes, WebSockets will be something else.

>
> With a WebSocket adapter, there are other options - but that's future :)
>
>> On a side note, I am planning on adding different build options into the
>> grunt build so that people can pick and choose what pieces they want and
>> create a custom build. Eventually, it would be nice to have a little web app
>> that did that for them by checking a few boxes and clicking download as well
>> but this is all future stuff.
>
> I have seen this somewhere before .... :-) :)
>
> Cheers!
> Matthias
>
>>
>>
>> -Luke
>>
>>
>> On Tue, Aug 28, 2012 at 2:08 PM, Kris Borchers <[hidden email]> wrote:
>>>
>>> Now that AeroGear.js 1.0.0.Alpha is out, I want to get people's thoughts
>>> both on what they think of the library so far, and where they would like to
>>> see it go in the future. Please take a look at
>>> http://staging-aerogear.rhcloud.com/docs/planning/1.0.0/AeroGearJS/ and
>>> provide any feedback on the current roadmap that you may have.
>>>
>>> Also, and more to the subject of this e-mail, I want to discuss the
>>> separation of concerns between the different pieces of AeroGear.js and what
>>> should be handled where. I bring this up because as I move forward with
>>> Pipeline and the other components of the library, I find myself implementing
>>> things where they may not belong. Specifically, I have started creating a
>>> filter method in the REST adapter for pipeline. I have started to think that
>>> this is not where that method belongs and in fact, the storage of data in
>>> the pipeline object at all I think was a mistake. I think Pipeline should be
>>> just that, a pipeline for data to move between the client and server and
>>> should not be a place where data is managed or manipulated.
>>>
>>> This is where some sort of data management piece of the lib comes in - no
>>> clever name yet :). I would like to see Pipeline handle the transport of
>>> data, whether that be with REST, websockets or what ever, but then just hand
>>> the data off to the app to do what it wants. Then, we can support a
>>> connection between Pipeline and this data management piece so that if the
>>> user wants help with data management including storage in memory, session
>>> storage, local storage, web sql, IndexedDB, files, etc. they could pass an
>>> instance of the data manager to Pipeline and say put the data here when you
>>> get it or take it from here when you send it, etc.
>>>
>>> I hope this novel I just wrote makes sense but please feel free to ask
>>> questions, make comments and suggestions, tell me I'm an idiot, what ever.
>>> If people seem on board with this, I would like to get a basic memory based
>>> storage system similar to what is in Pipeline now, moved out into it's on
>>> section of the library in conjunction with working on aerogear-auth.js for
>>> M6.
>>>
>>> Thanks,
>>> Kris
>>>
>>> _______________________________________________
>>> 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
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
> _______________________________________________
> 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
|  
Report Content as Inappropriate

Re: [aerogear-dev] AeroGear.js Separation of Concerns

Matthias Wessendorf
On Wed, Aug 29, 2012 at 1:43 PM, Kris Borchers <[hidden email]> wrote:

>
> On Aug 29, 2012, at 3:50 AM, Matthias Wessendorf <[hidden email]> wrote:
>
>> On Tue, Aug 28, 2012 at 10:55 PM, Kris Borchers <[hidden email]> wrote:
>>>
>>> On Aug 28, 2012, at 3:34 PM, Lucas Holmquist <[hidden email]>
>>> wrote:
>>>
>>> I agree with the separation.  Having it connect to a separate data layer
>>> makes sense.  Then they can use the data layer without pipeline if they
>>> wanted to get it another way.
>>>
>>>
>>> Exactly
>>>
>>>
>>> it seems that each Library(maybe not the right word) should do one thing and
>>> do it awesome!
>>>
>>> We don't want to just recreate backbone Models, or any other other Model
>>> part of a framework for that matter.
>>>
>>> I know in my development,  i just want to get the data from the backend and
>>> manipulate it on my own.
>>>
>>> The only question i have is how the separation would relate to the sync
>>> process?  Would the user then have to use both pipeline and data thing to
>>> keep front/back end in sync?
>>>
>>>
>>> That's a good question. In order to keep them separate, yes they would need
>>> both to have AeroGear handle the syncing or they would have to do sync on
>>> their own.
>>
>> Hey Kris,
>>
>> right now the 'sync' would be 'polling' based, right ? E.g. haven the
>> app using the 'client library'
>> to ask for new/modified data, right?
>
> Honestly, I haven't gotten that far yet. The initial implementation would not incorporate any sort of automatic sync, instead it
> would be up to the user to tell pipeline to update the data from the server or push new data to the server. When we get to sync,
> then we will need to probably do some sort of polling if we are using REST and then yes, WebSockets will be something else.
>

looks like we are on the same page here :)

-M

>>
>> With a WebSocket adapter, there are other options - but that's future :)
>>
>>> On a side note, I am planning on adding different build options into the
>>> grunt build so that people can pick and choose what pieces they want and
>>> create a custom build. Eventually, it would be nice to have a little web app
>>> that did that for them by checking a few boxes and clicking download as well
>>> but this is all future stuff.
>>
>> I have seen this somewhere before .... :-) :)
>>
>> Cheers!
>> Matthias
>>
>>>
>>>
>>> -Luke
>>>
>>>
>>> On Tue, Aug 28, 2012 at 2:08 PM, Kris Borchers <[hidden email]> wrote:
>>>>
>>>> Now that AeroGear.js 1.0.0.Alpha is out, I want to get people's thoughts
>>>> both on what they think of the library so far, and where they would like to
>>>> see it go in the future. Please take a look at
>>>> http://staging-aerogear.rhcloud.com/docs/planning/1.0.0/AeroGearJS/ and
>>>> provide any feedback on the current roadmap that you may have.
>>>>
>>>> Also, and more to the subject of this e-mail, I want to discuss the
>>>> separation of concerns between the different pieces of AeroGear.js and what
>>>> should be handled where. I bring this up because as I move forward with
>>>> Pipeline and the other components of the library, I find myself implementing
>>>> things where they may not belong. Specifically, I have started creating a
>>>> filter method in the REST adapter for pipeline. I have started to think that
>>>> this is not where that method belongs and in fact, the storage of data in
>>>> the pipeline object at all I think was a mistake. I think Pipeline should be
>>>> just that, a pipeline for data to move between the client and server and
>>>> should not be a place where data is managed or manipulated.
>>>>
>>>> This is where some sort of data management piece of the lib comes in - no
>>>> clever name yet :). I would like to see Pipeline handle the transport of
>>>> data, whether that be with REST, websockets or what ever, but then just hand
>>>> the data off to the app to do what it wants. Then, we can support a
>>>> connection between Pipeline and this data management piece so that if the
>>>> user wants help with data management including storage in memory, session
>>>> storage, local storage, web sql, IndexedDB, files, etc. they could pass an
>>>> instance of the data manager to Pipeline and say put the data here when you
>>>> get it or take it from here when you send it, etc.
>>>>
>>>> I hope this novel I just wrote makes sense but please feel free to ask
>>>> questions, make comments and suggestions, tell me I'm an idiot, what ever.
>>>> If people seem on board with this, I would like to get a basic memory based
>>>> storage system similar to what is in Pipeline now, moved out into it's on
>>>> section of the library in conjunction with working on aerogear-auth.js for
>>>> M6.
>>>>
>>>> Thanks,
>>>> Kris
>>>>
>>>> _______________________________________________
>>>> 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
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>> _______________________________________________
>> 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



--
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Loading...