incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Mueller <>
Subject Re: CommandLine Tooling Design
Date Tue, 10 Apr 2012 23:27:40 GMT
On Tue, Apr 10, 2012 at 18:21, Andrew Lunny <> 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
> (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

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

Here are some of the high-level problems I'm laser-focused on - in my head

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message