On Tue, Apr 10, 2012 at 18:21, Andrew Lunny <[email protected]> wrote:
> I think the best way for us to approach command-line tooling is to be > laser-focused on individual problems. Partially agree. That's the "bottom up" approach. I'm curious what our "top down" story looks like. The easiest way for me to imagine what that looks like, is to start sketching out the highest-level "commands" that you'll be using to do stuff. Bottom up is great for solving the "how do I do surgery on .xcodeproject files, or those android manifests - THEY ARE STINKY!" Tough sticky problems to work on, we will likely need them once we figure out what the high level story is. I think we need to do both. At least, I think we do, because, again, I have no idea what our "top down" story looks like. None at all. So I made one up - the commands. Is there another "top down" story out there I missed? One of the biggest problem I've seen on the mailing list and > community.phonegap.com (which has a lot of Cordova questions, not just > PGB) > is getting an iOS project started - the www directory going missing, and > the weirdo ARC checkbox that makes everything break, and so forth. It might > be best to bite off a small problem like that - how do we make creating > Cordova iOS projects super easy? - rather than going after everything at > once. > Those are certainly problems today. But, since I have no idea what the top level story is, I have no idea if this will even BE a problem in the new world. Maybe ... we don't ship fricken Xcode project templates since Apple has underpowered them, maybe we actually create Xcode project files that are shaped the way we need them, when the user does "cordova platform add ios". Figuring out how to turn fricken ARC on and off, in the Xcode project file, and how to point the Xcode project file to the user's www directory (so we don't have to copy-on-build) are great low-level problems we need to work on. Here are some of the high-level problems I'm laser-focused on - in my head anyway: What is a plugin? Is there a manifest? (surely yes) How do I specify which files in the plugin are native source? I guess I can just guess the language of the native source from file extensions? Do we need to be able to handle .jars in Android, .xcodeproj's, .libs, .frameworks in Xcode? Those are in the plugin? Is the plugin packaged in an archive? How do the tools find a plugin? Once we have the plugin "installed", how does the plugin JS get into the user's HTML file? Do we do a "build" and build it into a cordova-MyApp-ios.js file? Or will the user have to <script src=> a .js file for the plugin? How will they know the name to use? Is the .js in a plugin a "module" or a plain old "script" or can we do both? etc, etc -- Patrick Mueller http://muellerware.org
