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