3:44 a.m.
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(a)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/AeroGea...
Thanks,
Kris
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)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