cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anis KADRI <anis.ka...@gmail.com>
Subject Re: plugman + plugin spec final q's
Date Wed, 17 Apr 2013 21:21:02 GMT
On Wed, Apr 17, 2013 at 2:07 PM, Michal Mocny <mmocny@chromium.org> wrote:

> To add a few more thoughts RE: URL to find plugin universe:
>
> - We could also support an apt style model where the user has a personal
> global list of repositories specified, and the tools use that list to find
> plugins referenced by name, starting with a single default (or a
> cordova-core universe and a wild-west).  Note: a plugin can still be
> explicit with the URL, but this is a bit more flexible when referring to
> just a name.
>

I started working on this a while when Brian LeRoux requested and then
reverted because some problems arose:
- Two plugins have the same name, same version but different repository
URLs/zips etc (or different metadata)... Which one do you pick when one
asks to install it or when you need it as dependency ? You could prompt the
user when they have 2 or 3 universes but what happens when they have n
universes. APT deals with this by picking the highest version I believe but
APT also has the package stored server side and we don't (at the moment).


> - I would also like to be able to support local directories as a universe.
>

This is a good-to-have.


> - Alternatively to the above would be the ability to lookup plugin
> dependancies relative to the URL of the current one being added, so if I
> manually add a plugin from some local/remote URL and it depends on plugins
> by name only, look in that same location first.  Especially useful combined
> with --link.
>

That is what I initially envisioned but Braden had a good counterargument
that plugins (or their metadata) can all be in different remote sources
(core, 3rd party, google, ...).


>
> -Michal
>
>
> On Wed, Apr 17, 2013 at 4:22 PM, Don Coleman <don.coleman@gmail.com>
> wrote:
>
> > On Windows Phone the permission required to access NFC is
> ID_CAP_PROXIMITY.
> >
> > The ID_REQ_NFC restricts the application to running on only devices that
> > have NFC.
> >
> > This would be equivalent to setting android:required to true for a
> feature
> >
> >     <uses-feature android:name="android.hardware.nfc"
> > android:required="true" />
> >
> > AFAIK android:required="true" only effects Google Play listings.
> >
> > Plugman should set the features and permissions.  I think adding hardware
> > restrictions is a decision that needs to be made by the app developer.
> >
> >
> > On Wed, Apr 17, 2013 at 3:41 PM, Jesse <purplecabbage@gmail.com> wrote:
> >
> > > I could, or it could just be an ignored tag for other platforms. It
> will
> > > sit inside the platform tag anyway.
> > > could also just add an optional attrib to the permission tag :
> > > <permission type='requirement'  name='ID_REQ_NFC' />
> > >
> > > The names already do contain enough info to easily parse, ID_CAP_*
> > ID_REQ_*
> > > not to mention ID_RESOLUTION_*
> > >
> > > I am down with whatever.
> > >
> > >
> > > @purplecabbage
> > > risingj.com
> > >
> > >
> > > On Wed, Apr 17, 2013 at 12:24 PM, Filip Maj <fil@adobe.com> wrote:
> > >
> > > > Hmm, this could be an implementation detail for windows phone.
> > > >
> > > > Requirement vs permission isn't syntactically different. Could we
> > > > encapsulate Windows Phone requirements as <permission> elements
in
> > > > plugin.xml, and have tooling be smart enough to parse wp7 + wp8
> > > <platform>
> > > > <permission> elements and drop them into the Windows Phone manifest
> as
> > > > whatever elements they need to be?
> > > >
> > > > On 4/17/13 12:16 PM, "Jesse" <purplecabbage@gmail.com> wrote:
> > > >
> > > > >While we are there, we may want to add an optional requirements tag.
> > > > >Requirements let the app specify what device features it must have,
> > for
> > > > >example NFC. [1]
> > > > >Logically this would just fall right under platform, and be
> optional :
> > > > >
> > > > > <platform name="wp8">
> > > > >        <requirement name="ID_REQ_NFC" />
> > > > >  </platform>
> > > > >
> > > > >Does it make sense for us to group these?
> > > > >ie.
> > > > >
> > > > ><platform>
> > > > >  <permissions>
> > > > >     <permission/>
> > > > >      ...
> > > > >  </permissions>
> > > > >  <requirements>
> > > > >     <requirement/>
> > > > >      ...
> > > > >  </requirements>
> > > > ></platform>
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >[1]
> > > > >
> > > >
> > >
> >
> http://blogs.windows.com/windows_phone/b/wpdev/archive/2013/04/17/defining
> > > > >-your-app-s-requirements-for-a-great-customer-experience.aspx
> > > > >
> > > > >
> > > > >
> > > > >@purplecabbage
> > > > >risingj.com
> > > > >
> > > > >
> > > > >On Wed, Apr 17, 2013 at 12:04 PM, Filip Maj <fil@adobe.com>
wrote:
> > > > >
> > > > >> Good call, sound rule of thumb
> > > > >>
> > > > >> On 4/17/13 12:03 PM, "Jesse" <purplecabbage@gmail.com>
wrote:
> > > > >>
> > > > >> >RE: the permission element
> > > > >> >Looks good for wp7 + wp8
> > > > >> >I assume if some platform requires extra data in the permission
> tag
> > > it
> > > > >>can
> > > > >> >have it, the same way that the blackberry version has the
system
> > > > >> >attribute.
> > > > >> >
> > > > >> >@purplecabbage
> > > > >> >risingj.com
> > > > >> >
> > > > >> >
> > > > >> >On Wed, Apr 17, 2013 at 11:48 AM, Jeffrey Heifetz
> > > > >> ><jheifetz@blackberry.com>wrote:
> > > > >> >
> > > > >> >> Makes sense to me.
> > > > >> >>
> > > > >> >> Sent from my BlackBerry 10 smartphone on the Rogers
network.
> > > > >> >> From: Filip Maj
> > > > >> >> Sent: Wednesday, April 17, 2013 2:43 PM
> > > > >> >> To: dev@cordova.apache.org
> > > > >> >> Reply To: dev@cordova.apache.org
> > > > >> >> Subject: Re: plugman + plugin spec final q's
> > > > >> >>
> > > > >> >>
> > > > >> >> K one more update: <permission> element that will
be a child of
> > > > >> >><platform>
> > > > >> >> elements.
> > > > >> >>
> > > > >> >> Examples:
> > > > >> >> <platform name="android">
> > > > >> >> <permission name="android.permission.INTERNET" />
> > > > >> >> </platform>
> > > > >> >> <platform name="blackberry">
> > > > >> >> <permission name="_sys_use_consumer_push" system="true"
/>
> > > > >> >> </platform>
> > > > >> >> <platform name="wp7">
> > > > >> >> <permission name="ID_CAP_CONTACTS" />
> > > > >> >> </platform>
> > > > >> >>
> > > > >> >>
> > > > >> >> `name` attribute is mandatory, mapping to native strings
> > > representing
> > > > >> >> specific features/permissions.
> > > > >> >>
> > > > >> >> `system` attribute is optional and false by default.
Only used
> by
> > > > >> >> BlackBerry for certain system-level permissions.
> > > > >> >>
> > > > >> >> I think this satisfies our use cases.
> > > > >> >>
> > > > >> >> Thoughts/comments welcome.
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >> On 4/17/13 11:07 AM, "Jeffrey Heifetz" <
> jheifetz@blackberry.com>
> > > > >>wrote:
> > > > >> >>
> > > > >> >> >I was thinking exactly along the same lines as Braden.
> Whatever
> > > > >> >>universe
> > > > >> >> >the cordova core plugins live in will likely be
default, with
> > the
> > > > >>wild
> > > > >> >> >west following it. SO long as plugman is explicit
about where
> it
> > > is
> > > > >> >> >fetching from, a dev shouldn't have to find the
URL and hope
> it
> > > > >>never
> > > > >> >> >changes.
> > > > >> >> >
> > > > >> >> >On 13-04-17 2:01 PM, "Braden Shepherdson" <
> braden@chromium.org>
> > > > >>wrote:
> > > > >> >> >
> > > > >> >> >>I think there will be a common repo, where the
Cordova core
> > > plugins
> > > > >> >>and
> > > > >> >> >>some others live. See the spec for the remotes.js
file; I
> think
> > > it
> > > > >> >>should
> > > > >> >> >>search for plugins with the given name in each
of those
> > > universes.
> > > > >> >> >>Specifying a url in the <dependency> would
then only be
> > necessary
> > > > >>for
> > > > >> >> >>other
> > > > >> >> >>universes.
> > > > >> >> >>
> > > > >> >> >>Braden
> > > > >> >> >>
> > > > >> >> >>
> > > > >> >> >>On Wed, Apr 17, 2013 at 1:56 PM, Filip Maj <fil@adobe.com>
> > > wrote:
> > > > >> >> >>
> > > > >> >> >>> But then we'd need to be able to discover
the different
> > > > >>universes..
> > > > >> >> >>>Unless
> > > > >> >> >>> we all agree on a "default", don't think
this is optional..
> > > > >> >> >>>
> > > > >> >> >>> On 4/17/13 10:53 AM, "Jeffrey Heifetz"
<
> > > jheifetz@blackberry.com>
> > > > >> >> wrote:
> > > > >> >> >>>
> > > > >> >> >>> >Coming back to Braden's suggestion
of specifying a url and
> > id
> > > > >>for
> > > > >> >> >>>plugin
> > > > >> >> >>> >dependency, I think this is the correct
route, and would
> go
> > > > >> >>further to
> > > > >> >> >>> >suggest the url is optional. I do not
believe we should
> > > > >>inherently
> > > > >> >>tie
> > > > >> >> >>> >plugin dependency to the exact source.
Thats why we have a
> > > > >> >>discovery
> > > > >> >> >>> >system and multiple places to get a
plugin from.
> > > > >> >> >>> >
> > > > >> >> >>> >On 13-04-17 1:37 PM, "Filip Maj" <fil@adobe.com>
wrote:
> > > > >> >> >>> >
> > > > >> >> >>> >>Braden and I had a little chat
on IRC about
> > install/uninstall
> > > > >>and
> > > > >> >> >>>calling
> > > > >> >> >>> >>prepare. We've agreed that having
prepare as a separate
> > > > >>command is
> > > > >> >> >>>useful
> > > > >> >> >>> >>(you tweak some plugin JS files,
add more JS files, and
> > want
> > > > >>that
> > > > >> >> >>> >>reflected in your app), but also
calling prepare
> > > automatically
> > > > >> >>after
> > > > >> >> >>>an
> > > > >> >> >>> >>install and uninstall makes sense
too (otherwise people
> > using
> > > > >> >>plugman
> > > > >> >> >>> >>will
> > > > >> >> >>> >>have to call prepare manually after
calling install or
> > > > >>uninstall).
> > > > >> >> >>> >>
> > > > >> >> >>> >>FTR, --prepare composes the cordova_plugins.json
object
> > that
> > > is
> > > > >> >>read
> > > > >> >> >>>by
> > > > >> >> >>> >>cordova.js and handles injecting
plugin JS into the app.
> It
> > > > >>will
> > > > >> >>also
> > > > >> >> >>>be
> > > > >> >> >>> >>responsible for handling permissions
that plugins require
> > and
> > > > >> >>setting
> > > > >> >> >>>up
> > > > >> >> >>> >>platform manifests appropriately
based on all installed
> > > > >>plugins.
> > > > >> >> >>> >>
> > > > >> >> >>> >>On 4/17/13 10:25 AM, "Brian LeRoux"
<b@brian.io> wrote:
> > > > >> >> >>> >>
> > > > >> >> >>> >>>Braden: you thinking that the
config is canonical and
> then
> > > > >> >>prepare
> > > > >> >> >>> >>>quietly
> > > > >> >> >>> >>>does the right thing based
on that?
> > > > >> >> >>> >>>
> > > > >> >> >>> >>>(Agree less steps is exactly
what we're going for here.)
> > > > >> >> >>> >>>
> > > > >> >> >>> >>>
> > > > >> >> >>> >>>On Wed, Apr 17, 2013 at 10:16
AM, Braden Shepherdson
> > > > >> >> >>> >>><braden@chromium.org>wrote:
> > > > >> >> >>> >>>
> > > > >> >> >>> >>>> Re: --install calling
--prepare: no. It could,
> though, I
> > > > >> >>suppose.
> > > > >> >> >>> >>>>
> > > > >> >> >>> >>>> Why not have --prepare
handle the plugins rather than
> > > > >> >> >>>install/remove.
> > > > >> >> >>> >>>>We're
> > > > >> >> >>> >>>> trying to make less, not
more, happen at install time.
> > > > >>Someday
> > > > >> >>I
> > > > >> >> >>>hope
> > > > >> >> >>> >>>> --install ceases to exist.
> > > > >> >> >>> >>>>
> > > > >> >> >>> >>>>
> > > > >> >> >>> >>>> On Wed, Apr 17, 2013 at
12:59 PM, Filip Maj <
> > > fil@adobe.com>
> > > > >> >> wrote:
> > > > >> >> >>> >>>>
> > > > >> >> >>> >>>> > Max, yeah, at the
top of the plugman readme (in both
> > > > >>future
> > > > >> >>and
> > > > >> >> >>> >>>>master I
> > > > >> >> >>> >>>> > believe), the usage
docs don't specify --install or
> > > > >> >>--uninstall
> > > > >> >> >>>as
> > > > >> >> >>> >>>>an
> > > > >> >> >>> >>>> > available command,
but those commands are referenced
> > > right
> > > > >> >>after
> > > > >> >> >>>the
> > > > >> >> >>> >>>> usage
> > > > >> >> >>> >>>> > section. I'd be in
favor of using --fetch for the
> > > > >>RETRIEVAL
> > > > >> >>of
> > > > >> >> >>> >>>>plugins,
> > > > >> >> >>> >>>> > --remove for the
removal of plugins from the local
> > > plugins
> > > > >> >> >>>cache,
> > > > >> >> >>> >>>>and
> > > > >> >> >>> >>>> > --install and --uninstall
for the relevant actions.
> > > > >> >> >>> >>>> >
> > > > >> >> >>> >>>> > Max, re (2): correct.
> > > > >> >> >>> >>>> >
> > > > >> >> >>> >>>> > To Braden's points:
> > > > >> >> >>> >>>> >
> > > > >> >> >>> >>>> > - I'm fine with url
+ name attributes for
> <dependency>
> > > > >> >> >>>elements.
> > > > >> >> >>> >>>>Will
> > > > >> >> >>> >>>> > update the spec/README
shortly.
> > > > >> >> >>> >>>> > - Re <clobbers>
I will add a note about that to the
> > spec
> > > > >>as
> > > > >> >> >>>well.
> > > > >> >> >>> >>>> > - Re parsing package
Ids, fair enough.
> > > > >> >> >>> >>>> > - About "namespacing"
iOS source files, this sounds
> > > like a
> > > > >> >>good
> > > > >> >> >>> >>>>idea.
> > > > >> >> >>> >>>> > This is something
that plugman can handle as well,
> > yes?
> > > > >>That
> > > > >> >>is,
> > > > >> >> >>> >>>> > management of the
plist and pointing to the right
> > > > >>location.
> > > > >> >> >>> >>>> > - Re config munging
and permissions. I vote in favor
> > of
> > > > >> >> >>>removing
> > > > >> >> >>> >>>>all
> > > > >> >> >>> >>>> > permissions and re-adding
all of them with every
> > change
> > > in
> > > > >> >> >>>plugins
> > > > >> >> >>> >>>>(add
> > > > >> >> >>> >>>> or
> > > > >> >> >>> >>>> > remove), with a de-duping
pass. Brute force approach
> > but
> > > > >> >>it'll
> > > > >> >> >>>work
> > > > >> >> >>> >>>>and
> > > > >> >> >>> >>>> is
> > > > >> >> >>> >>>> > simple. However spec
wise we need a separate element
> > for
> > > > >>this
> > > > >> >> >>>ya?
> > > > >> >> >>> >>>> > <permission>
or something? Then based on what
> > <platform>
> > > > >>tag
> > > > >> >> >>>houses
> > > > >> >> >>> >>>>a
> > > > >> >> >>> >>>> > <permissions>
tag we can deduce where and how to set
> > up
> > > > >>the
> > > > >> >> >>> >>>>appropriate
> > > > >> >> >>> >>>> > native permissions.
> > > > >> >> >>> >>>> > - Re the different
<*-file> elements. I believe
> > behavior
> > > > >>in
> > > > >> >>how
> > > > >> >> >>> >>>>header
> > > > >> >> >>> >>>> > and source files
are handled on iOS are identical,
> so
> > > > >> >> >>>consolidating
> > > > >> >> >>> >>>>those
> > > > >> >> >>> >>>> > is an easy simplification.
I will update the spec
> with
> > > > >>that.
> > > > >> >> >>>I'll
> > > > >> >> >>> >>>>leave
> > > > >> >> >>> >>>> > resource-file in
there for now.
> > > > >> >> >>> >>>> >
> > > > >> >> >>> >>>> > One more question
that came up: does a plugman
> > --install
> > > > >>call
> > > > >> >> >>> >>>>implicitly
> > > > >> >> >>> >>>> > call plugman --prepare
?
> > > > >> >> >>> >>>> >
> > > > >> >> >>> >>>> > On 4/17/13 9:31 AM,
"Max Woghiren" <
> maxw@chromium.org
> > >
> > > > >> wrote:
> > > > >> >> >>> >>>> >
> > > > >> >> >>> >>>> > >(1) On line 25
of the cordova-plugman readme, is
> the
> > > > >>command
> > > > >> >> >>> >>>>missing
> > > > >> >> >>> >>>> (ie.
> > > > >> >> >>> >>>> > >--add or --install
or whatever)?
> > > > >> >> >>> >>>> > >
> > > > >> >> >>> >>>> > >(2) Though two
versions of a plugin are not
> allowed,
> > I
> > > > >>just
> > > > >> >> >>>want to
> > > > >> >> >>> >>>>make
> > > > >> >> >>> >>>> > >sure: there will
be some kind of detection that
> it's
> > > > >>okay if
> > > > >> >> >>>the
> > > > >> >> >>> >>>> > >*same*version
of a plugin has already been
> installed
> > > by a
> > > > >> >> >>>previous
> > > > >> >> >>> >>>> > >dependency,
> > > > >> >> >>> >>>> > >right? (For example,
plugins A and B both depend
> on C
> > > > >>v1.0,
> > > > >> >>so
> > > > >> >> >>> >>>>plugman
> > > > >> >> >>> >>>> > >will determine
that this is okay, whereas if A
> > depends
> > > > >>on C
> > > > >> >> >>>v1.0
> > > > >> >> >>> >>>>and
> > > > >> >> >>> >>>>B
> > > > >> >> >>> >>>> > >depends on C
v1.1, there'll be an error).
> > > > >> >> >>> >>>> > >
> > > > >> >> >>> >>>> > >
> > > > >> >> >>> >>>> > >On Wed, Apr 17,
2013 at 3:08 AM, Filip Maj
> > > > >><fil@adobe.com>
> > > > >> >> >>>wrote:
> > > > >> >> >>> >>>> > >
> > > > >> >> >>> >>>> > >> Hey all,
> > > > >> >> >>> >>>> > >>
> > > > >> >> >>> >>>> > >> I've done
a review of the spec and updated it.
> > Check
> > > it
> > > > >> >>out
> > > > >> >> >>>at
> > > > >> >> >>> >>>>the
> > > > >> >> >>> >>>> > >>README
> > > > >> >> >>> >>>> > >> in the plugman
repo's future branch [1]. I've
> added
> > > the
> > > > >> >>last
> > > > >> >> >>>bit
> > > > >> >> >>> >>>>to
> > > > >> >> >>> >>>> it:
> > > > >> >> >>> >>>> > >> <dependencies>
and <dependency> elements. Here is
> > an
> > > > >> >>example:
> > > > >> >> >>> >>>> > >>
> > > > >> >> >>> >>>> > >> <dependencies>
> > > > >> >> >>> >>>> > >> <dependency
> > > > >> >> >>> >>>> > >>
> > > > >> >> >>>url="
> http://plugins.cordova.io/com.facebook.plugin/plugin.xml
> > "
> > > > >> >> >>> />
> > > > >> >> >>> >>>> > >> <dependency
> > > > >> >> >>> >>>> > >>
> > > > >> >> >>>url="
> > http://plugins.phonegap.com/com.adobe.omniture/plugin.xml"
> > > > >> >> >>> >>>> > >> version="1.0.0"
/>
> > > > >> >> >>> >>>> > >> </dependencies>
> > > > >> >> >>> >>>> > >>
> > > > >> >> >>> >>>> > >>
> > > > >> >> >>> >>>> > >> Dependencies
are specified by providing a url and
> > > > >> >>optionally
> > > > >> >> >>>some
> > > > >> >> >>> >>>>way
> > > > >> >> >>> >>>> of
> > > > >> >> >>> >>>> > >> describing
what version of the plugin you want.
> The
> > > > >>only
> > > > >> >> >>> >>>>constraint
> > > > >> >> >>> >>>> > >> imposed
on plugin dependencies right now is only
> a
> > > > >>single
> > > > >> >> >>>version
> > > > >> >> >>> >>>>of a
> > > > >> >> >>> >>>> > >> plugin can
be installed in an app at the same
> > time. I
> > > > >> >>think
> > > > >> >> >>>this
> > > > >> >> >>> >>>>is
> > > > >> >> >>> >>>> good
> > > > >> >> >>> >>>> > >> enough,
but wanted to let everyone know and give
> > > people
> > > > >> >>time
> > > > >> >> >>>to
> > > > >> >> >>> >>>> comment.
> > > > >> >> >>> >>>> > >>
> > > > >> >> >>> >>>> > >> Also did
a bunch of updates/tweaks to the
> > plugin.xml
> > > > >>spec,
> > > > >> >> >>>made
> > > > >> >> >>> >>>> explicit
> > > > >> >> >>> >>>> > >> some failures
(if there are file conflicts, error
> > > > >>noisily,
> > > > >> >> >>>that
> > > > >> >> >>> >>>>kind
> > > > >> >> >>> >>>> of
> > > > >> >> >>> >>>> > >> stuff).
I have a PluginTooling [2] wiki article
> up
> > > > >>where
> > > > >> >>I am
> > > > >> >> >>> >>>>doing my
> > > > >> >> >>> >>>> > >> best to
summarize these various reqs/use cases
> > > floating
> > > > >> >> >>>around
> > > > >> >> >>> >>>>the
> > > > >> >> >>> >>>> list,
> > > > >> >> >>> >>>> > >> IRC, hangout
discussions regarding plugin tooling
> > > > >> >> >>>development. If
> > > > >> >> >>> >>>>you
> > > > >> >> >>> >>>> > >>have
> > > > >> >> >>> >>>> > >> anything
to add there please do so!
> > > > >> >> >>> >>>> > >>
> > > > >> >> >>> >>>> > >> Next, I
have a few questions came up when I was
> > going
> > > > >> >>through
> > > > >> >> >>>the
> > > > >> >> >>> >>>> spec:
> > > > >> >> >>> >>>> > >>
> > > > >> >> >>> >>>> > >> - does <clobbers>
and <merges> (specified in the
> JS
> > > > >>symbol
> > > > >> >> >>> >>>>mapping
> > > > >> >> >>> >>>> > >> section
of the plugin spec) create the objects on
> > > > >>window
> > > > >> >>if
> > > > >> >> >>>they
> > > > >> >> >>> >>>>do
> > > > >> >> >>> >>>> not
> > > > >> >> >>> >>>> > >> exist? I
suppose this is more of a cordova.js
> > > question
> > > > >> >>than a
> > > > >> >> >>> >>>>spec
> > > > >> >> >>> >>>> > >> question,
but that behavior should be explicit in
> > the
> > > > >> >>spec.
> > > > >> >> >>> >>>> > >> - native
code <source-file> elements have a
> > `target`
> > > > >> >> >>>attribute
> > > > >> >> >>> >>>>where
> > > > >> >> >>> >>>> > >>you
> > > > >> >> >>> >>>> > >> specify
where within the native project the
> native
> > > code
> > > > >> >> >>>should be
> > > > >> >> >>> >>>> copied
> > > > >> >> >>> >>>> > >> into. Is
this necessary? For Java files, we could
> > > look
> > > > >>at
> > > > >> >>the
> > > > >> >> >>> >>>>package
> > > > >> >> >>> >>>> > >> declaration
at the top to determine where to put
> > it.
> > > If
> > > > >> >>I'm
> > > > >> >> >>>not
> > > > >> >> >>> >>>> > >>mistaken,
> > > > >> >> >>> >>>> > >> on iOS it
doesn't matter where within the
> directory
> > > > >> >>structure
> > > > >> >> >>>of
> > > > >> >> >>> >>>>a
> > > > >> >> >>> >>>> > >> cordova-ios
project you put native code in. What
> is
> > > the
> > > > >> >> >>>situation
> > > > >> >> >>> >>>>for
> > > > >> >> >>> >>>> > >>the
> > > > >> >> >>> >>>> > >> Windows
(Phone) platforms, and for cordova-osx?
> > > > >> >> >>> >>>> > >> - the spec
currently only accounts for appending
> > XML
> > > to
> > > > >> >> >>>specific
> > > > >> >> >>> >>>> parts
> > > > >> >> >>> >>>> > >>of
> > > > >> >> >>> >>>> > >> XML-based
configuration documents. Does anyone
> > > foresee
> > > > >>an
> > > > >> >> >>> >>>>instance
> > > > >> >> >>> >>>> where
> > > > >> >> >>> >>>> > >> some manner
of native or cordova-specific config
> > > > >>munging
> > > > >> >> >>>OTHER
> > > > >> >> >>> >>>>than
> > > > >> >> >>> >>>> > >> appending
would be necessary?
> Removal/modification
> > of
> > > > >> >> >>>existing
> > > > >> >> >>> >>>> elements?
> > > > >> >> >>> >>>> > >> - iOS specific:
Do we need separate elements for
> > > > >> >> >>><source-file>,
> > > > >> >> >>> >>>> > >> <resource-file>
and <header-file>? Can we
> > consolidate
> > > > >>into
> > > > >> >> >>>one?
> > > > >> >> >>> >>>>The
> > > > >> >> >>> >>>> > >> current
draft of the spec mentions that this may
> be
> > > an
> > > > >> >> >>> >>>>implementation
> > > > >> >> >>> >>>> > >> detail.
> > > > >> >> >>> >>>> > >>
> > > > >> >> >>> >>>> > >> Finally,
I have two questions/concerns about the
> > > > >>command
> > > > >> >>line
> > > > >> >> >>> >>>> interface
> > > > >> >> >>> >>>> > >> for plugman.
> > > > >> >> >>> >>>> > >>
> > > > >> >> >>> >>>> > >> 1. The --fetch
operation seems to need a
> redundant
> > > > >> >>--plugin
> > > > >> >> >>>flag,
> > > > >> >> >>> >>>>e.g.
> > > > >> >> >>> >>>> > >> plugman
--fetch --plugin <url>. Shouldn't we just
> > axe
> > > > >> >> >>>--plugin in
> > > > >> >> >>> >>>>this
> > > > >> >> >>> >>>> > >> case?
> > > > >> >> >>> >>>> > >> 2. The API
readme mentions --install and
> > --uninstall
> > > > >>flags
> > > > >> >> >>>but
> > > > >> >> >>> >>>>the
> > > > >> >> >>> >>>> docs
> > > > >> >> >>> >>>> > >> only show
--fetch and --remove. Can we clarify
> > this?
> > > > >> >> >>> >>>> > >>
> > > > >> >> >>> >>>> > >> Thanks for
everyone's input. I feel we're getting
> > > > >>closer
> > > > >> >>to
> > > > >> >> >>> >>>>shipping
> > > > >> >> >>> >>>> > >>this
> > > > >> >> >>> >>>> > >> thing!
> > > > >> >> >>> >>>> > >>
> > > > >> >> >>> >>>> > >> [1]
> > > > >> >> >>> >>>> > >>
> > > > >> >> >>> >>>> > >>
> > > > >> >> >>> >>>>
> > > > >> >> >>> >>>>
> > > > >> >> >>>
> > > > >> >>
> > > > >>
> > >
> https://git-wip-us.apache.org/repos/asf?p=cordova-plugman.git;a=shortlo
> > > > >> >> >>> >>>>g
> > > > >> >> >>> >>>> > ;
> > > > >> >> >>> >>>> > >>h=
> > > > >> >> >>> >>>> > >> refs/heads/future
> > > > >> >> >>> >>>> > >> [2] http://wiki.apache.org/cordova/PluginTooling
> > > > >> >> >>> >>>> > >>
> > > > >> >> >>> >>>> > >>
> > > > >> >> >>> >>>> >
> > > > >> >> >>> >>>> >
> > > > >> >> >>> >>>>
> > > > >> >> >>> >>
> > > > >> >> >>> >
> > > > >> >> >>> >
> > > > >> >> >>>
> > > > >>
> > >
> >>>---------------------------------------------------------------------
> > > > >> >> >>> >This transmission (including any attachments)
may contain
> > > > >> >>confidential
> > > > >> >> >>> >information, privileged material (including
material
> > protected
> > > > >>by
> > > > >> >>the
> > > > >> >> >>> >solicitor-client or other applicable
privileges), or
> > > constitute
> > > > >> >> >>> >non-public information. Any use of
this information by
> > anyone
> > > > >>other
> > > > >> >> >>>than
> > > > >> >> >>> >the intended recipient is prohibited.
If you have received
> > > this
> > > > >> >> >>> >transmission in error, please immediately
reply to the
> > sender
> > > > >>and
> > > > >> >> >>>delete
> > > > >> >> >>> >this information from your system.
Use, dissemination,
> > > > >> >>distribution,
> > > > >> >> >>>or
> > > > >> >> >>> >reproduction of this transmission by
unintended recipients
> > is
> > > > >>not
> > > > >> >> >>> >authorized and may be unlawful.
> > > > >> >> >>>
> > > > >> >> >>>
> > > > >> >> >
> > > > >> >> >
> > > > >> >>
> > > >
> > >>>---------------------------------------------------------------------
> > > > >> >> >This transmission (including any attachments) may
contain
> > > > >>confidential
> > > > >> >> >information, privileged material (including material
protected
> > by
> > > > >>the
> > > > >> >> >solicitor-client or other applicable privileges),
or
> constitute
> > > > >> >> >non-public information. Any use of this information
by anyone
> > > other
> > > > >> >>than
> > > > >> >> >the intended recipient is prohibited. If you have
received
> this
> > > > >> >> >transmission in error, please immediately reply
to the sender
> > and
> > > > >> >>delete
> > > > >> >> >this information from your system. Use, dissemination,
> > > > >>distribution, or
> > > > >> >> >reproduction of this transmission by unintended
recipients is
> > not
> > > > >> >> >authorized and may be unlawful.
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > ---------------------------------------------------------------------
> > > > >> >> This transmission (including any attachments) may contain
> > > > >>confidential
> > > > >> >> information, privileged material (including material
protected
> by
> > > the
> > > > >> >> solicitor-client or other applicable privileges), or
constitute
> > > > >> >>non-public
> > > > >> >> information. Any use of this information by anyone other
than
> the
> > > > >> >>intended
> > > > >> >> recipient is prohibited. If you have received this transmission
> > in
> > > > >> >>error,
> > > > >> >> please immediately reply to the sender and delete this
> > information
> > > > >>from
> > > > >> >> your system. Use, dissemination, distribution, or reproduction
> of
> > > > >>this
> > > > >> >> transmission by unintended recipients is not authorized
and may
> > be
> > > > >> >>unlawful.
> > > > >> >>
> > > > >>
> > > > >>
> > > >
> > > >
> > >
> >
>

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