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 18:06:14 GMT
Kay ill update the spec

On 4/17/13 11:01 AM, "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.
>>
>>


Mime
View raw message