incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Beusterien <paul.beuster...@gmail.com>
Subject Re: CommandLine Tooling Design
Date Wed, 11 Apr 2012 18:58:55 GMT
Who is the primary intended audience for the CLI? Patrick's comments seem
to indicate add-on tools providers to grow the PhoneGap eco-system.
Andrew's seem to indicate developers. It could be both, but while the needs
overlap, they are somewhat different.

Paul

On Wed, Apr 11, 2012 at 11:50 AM, Brian LeRoux <b@brian.io> wrote:

> after my cordova proj experience I think having tools for each
> project, using a common nomenclature, is the way to go
>
> the good news: most of those tools are in some form already in place
> for each proj
>
> wrapping those tools into a master cli project should be easy, and
> won't force the hands of devs
>
> On Wed, Apr 11, 2012 at 2:37 PM, Andrew Lunny <alunny@gmail.com> wrote:
> > On 10 April 2012 16:27, Patrick Mueller <pmuellr@gmail.com> wrote:
> >
> >> On Tue, Apr 10, 2012 at 18:21, Andrew Lunny <alunny@gmail.com> 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
>



-- 
Paul Beusterien
1-650-918-7074
skype:paul.beusterien
http://www.mobiledevelopersolutions.com

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