incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: plugin tooling/specification
Date Tue, 11 Sep 2012 12:38:28 GMT
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
View raw message