From callback-dev-return-4800-apmail-incubator-callback-dev-archive=incubator.apache.org@incubator.apache.org Wed Apr 11 18:38:06 2012 Return-Path: X-Original-To: apmail-incubator-callback-dev-archive@minotaur.apache.org Delivered-To: apmail-incubator-callback-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4DA789912 for ; Wed, 11 Apr 2012 18:38:06 +0000 (UTC) Received: (qmail 97105 invoked by uid 500); 11 Apr 2012 18:38:06 -0000 Delivered-To: apmail-incubator-callback-dev-archive@incubator.apache.org Received: (qmail 97081 invoked by uid 500); 11 Apr 2012 18:38:06 -0000 Mailing-List: contact callback-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: callback-dev@incubator.apache.org Delivered-To: mailing list callback-dev@incubator.apache.org Received: (qmail 97073 invoked by uid 99); 11 Apr 2012 18:38:06 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Apr 2012 18:38:06 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of alunny@gmail.com designates 74.125.82.43 as permitted sender) Received: from [74.125.82.43] (HELO mail-wg0-f43.google.com) (74.125.82.43) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Apr 2012 18:37:58 +0000 Received: by wgbdr12 with SMTP id dr12so979554wgb.0 for ; Wed, 11 Apr 2012 11:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=0vMRw+BHy/1YVTIzXWVQIBZ/keG8pC0j2wuBb2iAohM=; b=qvyAw0+Uye9V989hDC2ySYaQDU5vytoLHyDmZSv9LLohPuNb1G6OeL7goejR4gYJbY utvX73WzUKYgz+k2bLNXIdRL3Wb+yAxMyvpIozVChS0xHFdPAuwDy3FKh1CLUFjhlEIp B3h9cQl9HbzLJkqN0JrW3+C13YntoLujdjxJ5rRj89s0WJ4GYJEwV/29hQT+6UKFyQRf OzGvqGxD1XyyT4VeEVALgR2/CRaos4/QLYtvOlgjBQrPzIVFBuecx1n/2wETFdCMhYH+ Qy+OZqZKysLfwvH5VXCsF2OLDPJinWnO6bWuO9vkIYhfFV89HYBm0MTu+Bfquwvk1lod 5PJA== MIME-Version: 1.0 Received: by 10.180.102.129 with SMTP id fo1mr18572260wib.6.1334169457862; Wed, 11 Apr 2012 11:37:37 -0700 (PDT) Received: by 10.216.200.11 with HTTP; Wed, 11 Apr 2012 11:37:37 -0700 (PDT) Reply-To: alunny@gmail.com In-Reply-To: References: Date: Wed, 11 Apr 2012 11:37:37 -0700 Message-ID: Subject: Re: CommandLine Tooling Design From: Andrew Lunny To: Patrick Mueller Cc: callback-dev@incubator.apache.org Content-Type: multipart/alternative; boundary=f46d044481499b286f04bd6b8804 --f46d044481499b286f04bd6b8804 Content-Type: text/plain; charset=ISO-8859-1 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 whatever). 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, Andrew * sorry, this is getting increasingly convoluted --f46d044481499b286f04bd6b8804--