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 <f...@adobe.com> wrote:
> Good call, sound rule of thumb
>
> On 4/17/13 12:03 PM, "Jesse" <purplecabb...@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
> ><jheif...@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" <jheif...@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" <bra...@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 <f...@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" <jheif...@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" <f...@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
> >> >>> >>><bra...@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 <f...@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" <m...@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 <f...@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.
> >>
>
>
