incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Reinstein <reinstein.m...@gmail.com>
Subject Re: plugin tooling/specification
Date Tue, 11 Sep 2012 12:29:19 GMT
> assumed to be a 'backed in' platform/plugin

This must be a typo, eh? 'baked' was intended?

On Tue, Sep 11, 2012 at 4:15 AM, Brian LeRoux <b@brian.io> wrote:

> > * You will be able to access the client interface via: $ ./bin/cordova
> > * * suggest replacing ./ with $(CORDOVA_CLIENT_DIR)/
>
> Agree...tho the npm install should be global (in /usr/local/bin)
> ....maybe we say as much?
>
>
> > * Subcommands section
> > * * Typical unix manpage style is to use [] to surround optional
> arguments
> > <> to surround explanations and nothing for keywords.  Examples that need
> > fixing include:
> > * * * create <directory> [<id>] [<name>]
> > * * * platform ls
> > * * * platform add <platform>
> > * * * etc
> > * * even if we aren't aiming for manpage style here, there
> > are inconsistencies
>
> Sure
>
>
> > * * File and Directory Structure ascii tree diagram
> > * * * suggest appending / after directory names
>
> +1
>
>
> > * * ... it's assumed to be a 'backed in' platform/plugin. Otherwise, it's
> > assumed to be a URL to a gzipped tar archive...
> > * * * Not sure what 'backed in' means here, nor how to identify something
> > as not being backed in so as to fallback to gzipped tar
> > * * * Also wording sounds more like "else .. else" instead of "else if ..
> > else" (if that makes sense) :P
>
> Ya not sure what this is about?
>
>
> > * * KewlApp directory structure ascii tree diagram
> > * * * based on my understanding of the text, the ios/android platforms
> > should be subdirs of platforms/ and there should also be a subdir listed
> in
> > plugins/
>
> Yes.
>
>
> > * * Running tests warning
> > * * * Perhaps explain how to bootstrap so as not to have failing tests
> > instead of assuming the reverse?
>
> Yes.
>
>
> > Also, I will look into bash completions in some spare cycles and if it
> > looks reasonable I may volunteer for the task.  I've been curious to
> learn
> > how those work :)
>
> That'd be awesome...but I'm thinking in a future iteration once the
> actual CLI API is more solid. (But knock yourself out!)
>

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