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.