[aerogear-dev] AeroGear.js Separation of Concerns

Wed Aug 29 07:50:29 EDT 2012

On Wed, Aug 29, 2012 at 1:43 PM, Kris Borchers <kris at redhat.com> wrote:
>
> On Aug 29, 2012, at 3:50 AM, Matthias Wessendorf <matzew at apache.org> wrote:
>
>> On Tue, Aug 28, 2012 at 10:55 PM, Kris Borchers <kris at redhat.com> wrote:
>>>
>>> On Aug 28, 2012, at 3:34 PM, Lucas Holmquist <lucas.holmquist at gmail.com>
>>> 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 <kris at redhat.com> 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
>>>> aerogear-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>>
>> --
>> Matthias Wessendorf
>>
>> blog: http://matthiaswessendorf.wordpress.com/
>> sessions: http://www.slideshare.net/mwessendorf
>> twitter: http://twitter.com/mwessendorf
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev


-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf