[aerogear-dev] AeroGear.js

[Lucas Holmquist]

> On Feb 24, 2015, at 1:11 PM, Bruno Oliveira <bruno at abstractj.org> wrote:
> 
> On 2015-02-24, Lucas Holmquist 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.
> 
> Agreed with you, it doesn't make sense to me either.
> 
>> 
>> So Datamanager and Sync would be the only things using this pattern. Which i'm not sure makes sense anymore.
>> 
>> 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 )
> 
> +1 go ahead
> 
>> 
>> This change though would be a 3.0 thing since it would be changing the way the API works.
>> 
>> I'm also wondering if it would make sense to separate the differnt parts of the library into different repo's.
> 
> Do you mean separate all the libraries? How our libraries would make use
> of AeroGear.Core? Bower?
I think AeroGear.Core would essentially go away since it is only providing, the “add” and “remove” methods for the “Fancy Arrays”, if we stop doing that pattern,  then i don’t think this would be needed.

Thinking a little bit more,  we don’t need separte repo’s for each feature.  Thats what we can use AeroGear-Components thingy to distribute via bower.   We can script that shizzell,  to create custom feature builds


> 
>> 
>> 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 something like the UnifiedPush Client SDK, might make sense in a separate repo.
> 
> I couldn't see the real need of a separated repo, but probably I'm
> missing the context.

>> 
>> For distribution, i've actually created a AeroGear Component GH organization, that has pieces of the library, https://github.com/orgs/AeroGear-Components/dashboard <https://github.com/orgs/AeroGear-Components/dashboard> <https://github.com/orgs/AeroGear-Components/dashboard <https://github.com/orgs/AeroGear-Components/dashboard>>
>> I think i've started to ramble, so i'll stop here and look for comments
> 
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev <https://lists.jboss.org/mailman/listinfo/aerogear-dev>
> 
> 
> --
> 
> abstractj
> PGP: 0x84DC9914
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/aerogear-dev <https://lists.jboss.org/mailman/listinfo/aerogear-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150224/f4cb5eb9/attachment.html