incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Lunny <>
Subject Re: CommandLine Tooling Design
Date Wed, 11 Apr 2012 18:37:37 GMT
On 10 April 2012 16:27, Patrick Mueller <> wrote:

> 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?

Well from a high-level perspective, I think your commands are too
low-level. :)

The issue is that there isn't such a thing as a Cordova app. There are two
separate things:

(a) a native (iOS, Android, etc) app, using the Cordova framework to serve
content; and
(b) some higher abstraction (like a PhoneGap Build app) that transforms
down in multiple apps of type (a)

>From anecdotal experience, I think most developers are building type-a
apps, then running into difficulties when they try to create a second
type-a app that uses the same www content (porting from iOS to Android or

Some things CLI tools can do:

1. improve the experience of building a type-a app (like generating an
xcodeproj that doesn't explode, or adding new capabilities through plugins)
2. improve the experience of building multiple type-a apps (generate an
Android project from your iOS project, keep them in sync)
3. create/enhance a type-b experience (which your proposed commands do) and
abstract away the type-a projects

I think we do need CLI tools to solve the #1 and #2 problem sets*.

I don't think we're at a place where we can reliably abstract away those
type-a projects, so that every interaction a user has is through a type-b
project and the associated CLI commands. In some of the problems you
mention above, the type-b concept gets even stronger, affecting the actual
JS runtime of the created app. The issue is whether we *want* to create and
encourage this kind of holistic developer experience.

PhoneGap/Cordova has historically stayed away from this stuff - we haven't
determined or enforced how developers build apps using the framework. I
think this is a feature, not a bug; web developers can easily come in and
build to a browser, rather than to our particular conventions.

Personally, I would like to see this kind of
type-b/holistic/I've-been-typing-too-long developed outside of cordova (as
Brian's old Cordova project was) - if it becomes mature and viable enough,
we can bring it into the project as a whole, and start determining changes
to the framework to accomodate it.

Hope some of that makes sense,

* sorry, this is getting increasingly convoluted

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