cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeffrey Heifetz <jheif...@blackberry.com>
Subject Re: plugman + plugin spec final q's
Date Wed, 17 Apr 2013 18:07:31 GMT
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.

Mime
View raw message