12:26 p.m.
On Feb 24, 2015, at 1:11 PM, Bruno Oliveira
<bruno(a)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(a)lists.jboss.org <mailto:aerogear-dev@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(a)lists.jboss.org <mailto:aerogear-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/aerogear-dev
<https://lists.jboss.org/mailman/listinfo/aerogear-dev>