incubator-callback-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Mueller <pmue...@gmail.com>
Subject Re: CommandLine Tooling Design
Date Tue, 10 Apr 2012 03:21:18 GMT
On Mon, Apr 9, 2012 at 18:24, Paul Beusterien <paul.beusterien@gmail.com>wrote:

>   - Any aspirations to have "cordova deploy" and "cordova run" or would
>   that be too hard on non-Android?
>

Sure.  I've been thinking more about the "build" side of the issues, but
"run"-ish commands should be available as well, as much as possible.


>   - It would be useful to support the concept of cordova version,
>   including querying, updating, and validation
>

Right.  Ideally, the "command" (cordova) can be logically separated from
the particular version of Cordova libraries in use.  Seems like you could -
in theory - support multiple versions of the Cordova runtime at the same
time; say, switch back and forth between 2.0 and 2.1, within a single
project, or something.  But, I don't think that's terribly useful, and
seems like a great vector for errors.  :-)

Long term, the version of the core Cordova runtime can be separated out
from the core plugins as well.  They can evolve and ship separately.

Beyond that is the "W3C version" issue.  When the a W3C spec changes, we
should really create a new implementation of the new version; I think this
should be baked into the "fully qualified" name of the plugin,
eg webaudio-20120315 vs webaudio-20111215 ( example from
http://www.w3.org/TR/webaudio/ ) , though the 'versioned' name would likely
just be used when installing the plugin - most of the time, you don't want
to see that.


>   - As you imply, the directory structure doesn't work in conjunction with
>   the Eclipse Android Development Tools where the www directory needs to be
>   part of the Android assets directory hierarchy and plugins in the src
>   directory.
>

Right.  Sorry.  The directory structure won't work for ANY of the
platforms, directly, as I've specified.  That's just where we lay down the
source, so the tools can find it.  What I'd like to see if we can get away
with - and realize that we might not be able to - is for us to augment the
existing platform-specific build bits so they COPY things like the www/
tree into the platform specific directories, if required.  The www/
directory is just the tip of the iceberg.  As I've drawn it out, there will
be native code in
plugins/KewlioPlugin/platform/android/native/KewlioPlugin.java (or some
such) that will also need to be compiled.  Again, thinking - copy it before
a build.  You have it easy with Eclipse/Android, compared to the "fun" that
will be had with Xcode.  :-)

-- 
Patrick Mueller
http://muellerware.org

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