cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: plugman + plugin spec final q's
Date Wed, 17 Apr 2013 22:25:02 GMT
This is a good point. Might be better to warn about unused permissions.
(And offer an audit command for cleanup/release purposes.)

On Wed, Apr 17, 2013 at 3:13 PM, Jesse <purplecabbage@gmail.com> wrote:

> I think we do have consensus on <permission>, you can ignore the entire
> discussion of <requirements> as it is up to the app developer to 'require'
> and not the plugin developer.
>
> However, I do not think that removing permissions will end well.  Looking
> at the bigger picture, I can think of many cases where a permission is
> required by the app itself, and should remain regardless of any plugin.
>  This needs to be decided by the app developer themselves imho.
>
>
>
>
> @purplecabbage
> risingj.com
>
>
> On Wed, Apr 17, 2013 at 2:31 PM, Filip Maj <fil@adobe.com> wrote:
>
> > K I will hold off on <permission> until we come to a consensus. You're
> > right in that we could put it in as a child to <config-file>..
> Duplication
> > can be easily prevented (check if permission exists already before adding
> > it).
> >
> > Removing config-file stuff during a plugin uninstall is trickier.. If two
> > plugins depend on the same permission (or library, or whatever
> config-file
> > modification), but you only uninstall one of them, we have to make sure
> > that it is still there. The naïve first-pass solution to --uninstall
> > testPlugin:
> >
> > 1. Uninstall all the things
> > 2. Re-install all the things not named testPlugin
> >
> > Net result being: testPlugin is uninstalled.
> >
> > On 4/17/13 2:12 PM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
> >
> > >On Wed, Apr 17, 2013 at 9:59 AM, 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.
> > >>
> > >
> > >+1
> > >
> > >
> > >>  - 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.
> > >>
> > >
> > >+1. looks like the issue is assigned to me.
> > >
> > >
> > >>  - 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.
> > >>
> > >
> > >I don't think we need a separate element for this. Right now permissions
> > >are XML fragments that are added to configuration files and
> > >adding/removing
> > >works just fine EXCEPT when the XML fragments have variables in them
> > >(example PACKAGE_ID, API_KEY etc...). Brett is working on fixing it.
> > >
> > >
> > >>  - 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.
> > >>
> > >
> > >As I said on IRC. Header, Source and Resource files are all placed in
> > >different sections of the iOS pbxproject so they need to be separated.
> > >
> > >
> > >>
> > >> One more question that came up: does a plugman --install call
> implicitly
> > >> call plugman --prepare ?
> > >>
> > >
> > >It looks like it does now but needs to be tested :-)
> > >
> > >
> > >>
> > >> 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
> > >> >>
> > >> >>
> > >>
> > >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message