[aerogear-dev] AeroGear.js Separation of Concerns

[Matthias Wessendorf]

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 <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.

+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
> 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