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 14:52:33 GMT
> Subcommand argument formats still look off a bit
Fixed

> I think the $ is unneeded. All the other shell code
> examples don't include the leading shell character.

Actually, the opposite. Every example did have leading $ except for the
first usage, which was inconsistent. But I agree $ is essentially just
noise and have removed all instances from the doc. :)

It would be nice to clean up the Random notes section. I think there may be
some context associated with those chat discussion snippets that were
copy/pasted in, so expanding on those points would be helpful for everyone
else (including me.)



On Tue, Sep 11, 2012 at 10:41 AM, Michal Mocny <mmocny@chromium.org> wrote:

> Subcommand argument formats still look off a bit, I think they should look
> as follows:
>
> create <directory> [<id> [<name>]]
> platform ls
> platform add <platform>
> platform remove <platform>
> plugin ls
> plugin add <path-to-plugin>   (NOTE: why use "path-to-" here? Seems
> inconsistant with the other examples of add/remove)
> plugin remove <plugin>
> build
> emulate
>
>
>
> Also, in the line "you can access the tool via $ cordova"  I think the $ is
> unneeded.  All the other shell code examples don't include the leading
> shell character.  Alternatively we can add shell character to all the other
> shell command examples.
>
>
> On Tue, Sep 11, 2012 at 10:24 AM, Mike Reinstein
> <reinstein.mike@gmail.com>wrote:
>
> > I've updated my copy of the README.md, pulling changes from Filip,
> Michal,
> > and Brian:
> > https://github.com/mreinstein/incubator-cordova-labs/tree/cordova-client
> >
> > If I've missed anything please let me know.
> >
> > -Mike
> >
> > On Tue, Sep 11, 2012 at 10:22 AM, Michal Mocny <mmocny@chromium.org>
> > wrote:
> >
> > > I'm still unsure what a "baked in" plugin/platform would be, in that
> > > context.  Anyway, its not super important as the actual argument types
> > may
> > > change over time.  The gist of it is just that you can reference a
> > > plugin/platform using various typical methods and I think that point
> gets
> > > across well enough.
> > >
> > >
> > > On Tue, Sep 11, 2012 at 8:38 AM, Brian LeRoux <b@brian.io> wrote:
> > >
> > > > Considering the source I'd say 'baked' was intentional.
> > > >
> > > >
> > > > On Tue, Sep 11, 2012 at 5:29 AM, Mike Reinstein
> > > > <reinstein.mike@gmail.com> wrote:
> > > > >> 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