Re: [aerogear-dev] AeroGear project structure and the website
On 24/02/2014 14:16, Jay Balunas 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.
Yep, please feel free to edit the document:
http://oksoclap.com/p/AeroGearModuleUntangling
The solutions part of it is mostly brainstorming on my side. I'd love to
hear which bits are ok and which aren't and why (technical reasons, or
something constraints).
I saw in the "Small libs" thread started by Corinne that one of the
reasons why most libraries were split up was because of space savings
when building the mobile app. This could drive the decision on this as
well. The most important thing is that we get more consistency around
the downloads whichever solution we might pick.
>> -"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?
Yes, exactly. We should make it instantly clear which part of the
project a developer is dealing (Core/Push/Security/Sync and
Client/Server) with just by looking the component name. I've provided
some examples in the above document on how this could be done.
Thanks, and good to know that it's a step in the right direction!
Hylke
Attachments:
- attachment.html (text/html — 3.9 KB)