Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of braden@google.com designates
 209.85.214.43 as permitted sender)
MIME-Version: 1.0
Sender: braden@google.com
In-Reply-To: <CD93989B.1D1E1%fil@adobe.com>
References: <CD93989B.1D1E1%fil@adobe.com>
Date: Wed, 17 Apr 2013 12:19:56 -0400
Message-ID: 
 <CAMk5LLkzWTd+n-up5SoL7LuRYoF+dkxUUHDx_2GVaS7rLu9MWA@mail.gmail.com>
Subject: Re: plugman + plugin spec final q's
From: Braden Shepherdson <braden@chromium.org>
To: dev@cordova.apache.org
Content-Type: multipart/alternative; boundary=485b3970d5ce4f92f004da90db36

--485b3970d5ce4f92f004da90db36
Content-Type: text/plain; charset=ISO-8859-1

Responses inline.


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>
>
>
I was imagining that the plugin would be specified in two parts, a URL for
the universe generally, and a plugin name, for example:

<dependency name="com.facebook.plugin" url="http://plugins.cordova.io/" />

And then the flow for fetching a plugin dependency would be:
1. HTTP GET url + '/' + name:
http://plugins.cordova.io/com.facebook.pluginand expect to get back
the plugin data whose format is described elsewhere.
2. Find the newest version of the plugin that satisfies the local Cordova
version and the constraints given in any version="..." attribute.
3. Download it from the URL given in the metadata (Github, etc.)
4. Recursively install it.

Specifying the full URL also works, though I would at least leave off the
/plugin.xml, since it's not really fetching that file.


>
> 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.
>

Yes, they do.


>  - 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?
>

- We really don't want to be trying to parse package lines out of the tops
of Java files. It's not the end of the world to specify this.

- On iOS it doesn't matter, but it does. As discussed elsewhere, the paths
on the filesystem don't matter, but any #includes using relative paths
depend on the "paths" given in the project plist file. Currently both are
flat in Plugins/, which risks collisions and breaks the relative include
paths. I think we should be putting each plugin's files into
Plugins/com.foo.myplugin/some/path/File.h and maintaining the relative
paths in the plist.


>  - 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?
>

Android permissions is the obvious standout. We might want to handle them
with a custom tag, since they have different semantics from adding/removing
and we want to be careful. On the other hand, maybe on every --prepare we
empty that tag and let the currently-installed plugins add their
permissions, with de-duping? Then we wouldn't have to worry about removing
them.


>  - 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.
>

<resource-file> may need to be separate, but we could probably get away
with combining <header-file> and <source-file>.


>
> 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?
>

It fits with the other commands, most of which expect a --plugin. I'm okay
with leaving it.


> 2. The API readme mentions --install and --uninstall flags but the docs
> only show --fetch and --remove. Can we clarify this?
>
>
Really? I thought they were all specified. The docs where, on master?
--fetch and --remove were added in the future branch and have not been
merged back.

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=shortlog;h=
> refs/heads/future
> [2] http://wiki.apache.org/cordova/PluginTooling
>
>

--485b3970d5ce4f92f004da90db36--