[aerogear-dev] AeroGear.js

[Matthias Wessendorf]

On Tuesday, February 24, 2015, Lucas Holmquist <lholmqui at redhat.com> wrote:

> While i was getting things together for the 2.1.0 release, I started to
> think about the structure of AeroGear.js.
>
> Lets take DataManager as an example.
>
> var dataManager = new AeroGear.DataManager();
>
> Basically, the resulting datamanger object is a fancy array. We can add
> new stores to it:
>
> dataManager.add('memoryStoreThing');
>
> dataManager.add({{
>     name: "indexDBStore",
>     type: "IndexedDB"
> }});
>
> I'm not sure what the reason for this was historically. I think this
> concept was initally created when we were doing Pipeline.
>
> But sticking to this example, i'm wondering if it adds any value though.
> would someone create a Datamanager that has more than one store in it? It's
> possible i guess if someone wanted to store the same info in a IndexedDB
> and WebSQL database at the same, for example, but there is currently no way
> to sync data between the two
>
> With the next release, 2.1.0, we will be deprecating Notifier, which uses
> this pattern.
>
> So Datamanager and Sync would be the only things using this pattern. Which
> i'm not sure makes sense anymore.
>
>
I agree



>
>
The remaining parts of the Library, Crypto, UnifiedPush, and to some extent
> SimplePush(currenlty coupled with Notifier) don't do this.
>
> I am leaning toward proposing we get rid of this pattern and just make a
> DataManager object hold 1 store/adapter( sync woud follow suit )
>
> This change though would be a 3.0 thing since it would be changing the way
> the API works.
>

yeah, lets do that for 3.0



> I'm also wondering if it would make sense to separate the differnt parts
> of the library into different repo's.
>
worth to evaluate this



> I think one of the main reasons this wasn't done in the past was because
> AeroGear.Core was shared across many pieces of the library and it would
> be a lot of code duplication.
>
but we could get it via dependency, right?


> But something like the UnifiedPush Client SDK, might make sense in a
> separate repo.
>
I like this approach


> For distribution, i've actually created a AeroGear Component GH
> organization, that has pieces of the library,
> https://github.com/orgs/AeroGear-Components/dashboard
>
> I think i've started to ramble, so i'll stop here and look for comments
>


-- 
Sent from Gmail Mobile
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150224/cfd0ed13/attachment-0001.html