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.
