[aerogear-dev] AeroGear.js

[Sebastien Blanc]

Jaja , sorry ! I should read answers before answering :)

On Tue, Feb 24, 2015 at 7:34 PM, Lucas Holmquist <lholmqui at redhat.com>
wrote:

> not sure if it came through, yet,  but my after thinking about the
> separate repo thing,
>
> “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”
>
>
> On Feb 24, 2015, at 1:31 PM, Sebastien Blanc <scm.blanc at gmail.com> wrote:
>
>
>
> On Tue, Feb 24, 2015 at 6:26 PM, 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.
>>
>> 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.
>>
>> I'm also wondering if it would make sense to separate the differnt parts
>> of the library into different repo's.
>>
> That would make Bower distribution easier right  ?
>
>> 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.
>>
>> 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
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> 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/e4d87a84/attachment.html