From: "Jay Balunas" <tech4j@gmail.com>
To: "AeroGear Developer Mailing List" <aerogear-dev@lists.jboss.org>
Cc: "Matt Carrano" <mcarrano@redhat.com>
Sent: Monday, February 24, 2014 9:16:38 AM
Subject: Re: [aerogear-dev] AeroGear project structure and the website


On Feb 20, 2014, at 12:06 PM, Bruno Oliveira <bruno@abstractj.org> wrote:

Hylke amazing work, I can’t wait to see it in production.

+1 Hylke - good stuff, and a lot to get through!
+1 this is great!

--  
abstractj

On February 20, 2014 at 11:06:34 AM, Hylke Bons (hbons@redhat.com) wrote:

TL;DR: The most important questions that we need to answer are  
these:
- "If I download a library on one platform, what must I download  
to use
the same features on an other platform?"

I like this approach.  I'd rather be feature driven than library driven.  I think most yours will be looking for what we can do for them before looking at what native libs we provide.

Lets get this breakdown together for Hylke - using the eitherpad or a gist seems the best approach here.

As the noob to the group... perhaps another way to think of this could be by platform -> type of resource needed -> then desired feature?

So If I'm a Cordova developer and I want to learn how-to setup UnifiedPush Server and integrate Push within my hybrid app I don't care about the native Android & iOS libraries, guides, etc.. I just want everything that is relevant to hybrid apps. I actually ran into this exact issue this last weekend when I created my first push notification app. Its hard to keep track of what guides and sample code I needed. This may solve that. I kind of like the way http://devcenter.kinvey.com/ does this. When I first go there it allows me to select my dev platform and it sets a cookie so when I come back its still on that platform. I can swap at any time, but as a developer I really liked the Kinvey experience because I could find what I needed. Nothing more nothing less.


-"Is this a part I use on the client, or on the server side?”

Not sure if I understood your question correctly, but to get the full solution, you need to download both

I think he means for each feature is there a client and a server part and if so how do we offer them.  Then we can get the info and links for the solution in one place.  Hylke - is that it or something else?


-"What do we mean when talking about different AeroGear
subprojects/modules?”

By subprojects I understand as exactly like you did at https://raw2.github.com/hbons/aerogear-design/master/website-restructure/aerogear-modules.png.


One solution might be:
https://raw2.github.com/hbons/aerogear-design/master/website-restructure/aerogear-modules.png
I've made a lot of assumptions here, and it might not work, but  
I'd like
to hear your thoughts on it.

It would clarify a lot if we could harmonise the different downloads  
across platforms, either by providing single download solutions  
or
splitting everything up and naming all the parts consistently.  
I'm
interested in what the technical issues might be, as I wasn't  
around
when most of these decisions were made, or I simply missed them.  

Thoughts or other ideas? :)

I don’t have any idea, because I liked the way how it was organized. No disagreement here.

+1 keep up the good work!



Thanks,

Hylke
_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev 


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev