cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: plugman + plugin spec final q's
Date Wed, 17 Apr 2013 19:24:21 GMT
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
View raw message