cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jesse <purplecabb...@gmail.com>
Subject Re: plugman + plugin spec final q's
Date Wed, 17 Apr 2013 19:03:29 GMT
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