cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Grieve <agri...@chromium.org>
Subject Re: Plugin / Platform mismatch problems
Date Mon, 29 Jul 2013 19:10:16 GMT
Great summary Fil.

Sounds to me like what we should do is use the id for the npm "name".
For the lazy, we could special-case core plugins, so that if you leave off
the fqn, plugman will prepend "org.apache.cordova.core".


On Mon, Jul 29, 2013 at 3:02 PM, Filip Maj <fil@adobe.com> wrote:

> I'll try to summarize where we were before and where we are at currently.
>
> In The Beginning:
> - we spec'ed an `id` attribute to the plugin manifest under the pretense
> of having a unique identifier (generally a good idea), and a preemptive
> approach at easing a situation where we have a multi-registry universe
> (For example: BlackBerry, Apache, Google all hosting plugin registries)
> - the <name> element was to be a human-readable, "pretty" label. It can
> have spaces, apostrophes, etc. just like the <name> element in config.xml
>
> In The Present:
> - we are at the point where we are using an existing system (npm) that has
> different constraints on uniquely identifying a project. Npm uses a name,
> with no spaces, no underscores, and some other char constraints.
> - which leads us to our current conundrum: which field do we use to
> uniquely identify a plugin, and which solution should we employ to map
> between our plugin specification for naming / id'ing packages vs. Npm's.
>
> There are many different ways to solve this problem, each with varying
> degrees of difficulty to implement and each having a different answer to
> the question of "how much will we need to diverge from npm to support it":
>
> - using a plugin id as the npm "name"
> - using a plugin's "cleaned up" <name> contents (no spaces or funny
> characters) as the npm name
>
> Finally, discovery is the last use case that needs to be addressed here.
> What is npm's current strategy and what do we want to support?
>
> On 7/26/13 11:21 AM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
>
> >Exactly! Only the ones we need too! We're already doing this for
> >name/version/description so it would just be a few more.
> >
> >On Fri, Jul 26, 2013 at 11:19 AM, Filip Maj <fil@adobe.com> wrote:
> >> Ahh yeah. Some kind of at-publish-time conversion of certain plugin.xml
> >> fields to json fields?
> >>
> >> On 7/26/13 10:27 AM, "Anis KADRI" <anis.kadri@gmail.com> wrote:
> >>
> >>>I think XML is not a query friendly language. I suggest we add an
> >>>engine field initially and then add fields as we need them. I suspect
> >>>we won't be needing the bulk of plugin.xml in the registry. I have to
> >>>experiment with custom fields still but it seems possible. I will
> >>>report back sometime today.
> >>>
> >>>On Fri, Jul 26, 2013 at 9:23 AM, Filip Maj <fil@adobe.com> wrote:
> >>>> I think this was brought up before, but why not store the plugin xml
> >>>>in
> >>>> its entirety? I can us needing more bits down the road, such as
> >>>> dependencies and platform version requirements.
> >>>>
> >>>>
> >>>> On 7/26/13 7:32 AM, "Andrew Grieve" <agrieve@chromium.org> wrote:
> >>>>
> >>>>>That all sounds good, but let's talk more about the git ref part:
> >>>>>
> >>>>>It looks like our npm-based directory system is going to host the
.tgz
> >>>>>of
> >>>>>the plugins, so it won't matter what git ref the .tgz maps back to
> >>>>>unless
> >>>>>we think that a lot of people are not going to use our directory
> >>>>>service.
> >>>>>
> >>>>>One thing that would be useful though, is a way to list plugins
> >>>>>compatible
> >>>>>with your version of cordova (e.g. query for the latest version of
> >>>>>cordova-plugin-file that is compatible with 3.0.0). I think all that's
> >>>>>required here is to store the engine tag in the couchdb metadata
> >>>>>alongside
> >>>>>the tgz.
> >>>>>
> >>>>>
> >>>>>On Thu, Jul 25, 2013 at 6:38 PM, Benn Mapes <benn.mapes@gmail.com>
> >>>>>wrote:
> >>>>>
> >>>>>> +1 to brett's comments.
> >>>>>> Name - Human Readable name of the plugin to be used in the context
> >>>>>>of
> >>>>>>  plugin
> >>>>>> discovery.
> >>>>>> ID - unique id used by tools to reference the plugin
> >>>>>> Description - sentence+ about the plugin (optional?)
> >>>>>>
> >>>>>> As for how plugins should be loaded I liked Braden's suggestion
that
> >>>>>>plugin
> >>>>>> authors decide what the default ref is for their plugin. Default
> >>>>>>should
> >>>>>>be
> >>>>>> master if no ref is provided.
> >>>>>>
> >>>>>>
> >>>>>> On Thu, Jul 25, 2013 at 1:27 PM, Steven Gill
> >>>>>><stevengill97@gmail.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>> > I am going to hold off on testing + deploying+ merging
this back
> >>>>>>in
> >>>>>>until
> >>>>>> > we get some sort of consensus on naming
> >>>>>> >
> >>>>>> >
> >>>>>> > On Thu, Jul 25, 2013 at 12:10 PM, RUDD, Brett
> >>>>>><brettrudd@gmail.com>
> >>>>>> wrote:
> >>>>>> >
> >>>>>> > > name is human readable and should be retained for
plugin
> >>>>>>discovery
> >>>>>> tools
> >>>>>> > > etc. (such as build.phonegap.com)
> >>>>>> > >
> >>>>>> > > in the wild, i find description is anything from a
sentence to a
> >>>>>>small
> >>>>>> > > paragraph, so a smaller human readable field as a
name is
> >>>>>>valuable.
> >>>>>> > >
> >>>>>> > > as for using id instead of name for plugman, i transfer
my
> >>>>>>voting
> >>>>>>power
> >>>>>> > to
> >>>>>> > > anis.
> >>>>>> > >
> >>>>>> > > -brett
> >>>>>> > >
> >>>>>> > > On 25 Jul 2013, at 11:59, Shazron <shazron@gmail.com>
wrote:
> >>>>>> > >
> >>>>>> > > > Maybe "name" is the "human" readable name as
opposed to id
> >>>>>>which
> >>>>>>is
> >>>>>> for
> >>>>>> > > > tools
> >>>>>> > > >
> >>>>>> > > >
> >>>>>> > > > On Thu, Jul 25, 2013 at 11:45 AM, Andrew Grieve
<
> >>>>>> agrieve@chromium.org
> >>>>>> > > >wrote:
> >>>>>> > > >
> >>>>>> > > >> Anis - can we make it use id instead? I think
that's more
> >>>>>>inline
> >>>>>> with
> >>>>>> > > the
> >>>>>> > > >> purpose of the field.
> >>>>>> > > >>
> >>>>>> > > >> Maybe we should remove the name field? I
can't think of a
> >>>>>>meaningful
> >>>>>> > > >> distinction between name and id given that
we already have a
> >>>>>> > description
> >>>>>> > > >> field.
> >>>>>> > > >>
> >>>>>> > > >>
> >>>>>> > > >> On Thu, Jul 25, 2013 at 2:35 PM, Steven Gill
<
> >>>>>> stevengill97@gmail.com>
> >>>>>> > > >> wrote:
> >>>>>> > > >>
> >>>>>> > > >>> Thanks for the advice Shaz and Andrew.
> >>>>>> > > >>>
> >>>>>> > > >>> I will make sure to mention the issue
in the commit so the
> >>>>>>bot
> >>>>>> picks
> >>>>>> > it
> >>>>>> > > >> up.
> >>>>>> > > >>>
> >>>>>> > > >>> Just talked to Anis and he says it is
the name tag and not
> >>>>>>the
> >>>>>>ID.
> >>>>>> I
> >>>>>> > > >> could
> >>>>>> > > >>> go and rename all of the core plugins
to start with 'core-'
> >>>>>>if
> >>>>>>that
> >>>>>> > > makes
> >>>>>> > > >>> more sense to people. I like it. Distinguishes
core plugins
> >>>>>>from
> >>>>>> > > >> community
> >>>>>> > > >>> ones.
> >>>>>> > > >>>
> >>>>>> > > >>> I will make sure to do a release bug
once ready. Mobile-spec
> >>>>>>tests
> >>>>>> > for
> >>>>>> > > >> sure
> >>>>>> > > >>> and I will upload to registry (gotta
do it eventually :P)
> >>>>>> > > >>>
> >>>>>> > > >>> -Steve
> >>>>>> > > >>>
> >>>>>> > > >>>
> >>>>>> > > >>>
> >>>>>> > > >>>
> >>>>>> > > >>> On Thu, Jul 25, 2013 at 6:21 AM, Andrew
Grieve <
> >>>>>> agrieve@chromium.org
> >>>>>> > >
> >>>>>> > > >>> wrote:
> >>>>>> > > >>>
> >>>>>> > > >>>> Steve - If you mention the CB-XXXX
in the commit
> >>>>>>description
> >>>>>>then
> >>>>>> a
> >>>>>> > > bot
> >>>>>> > > >>>> will automatically add a comment
to the issue with the
> >>>>>>commit
> >>>>>> link.
> >>>>>> > > The
> >>>>>> > > >>>> issues aren't very useful if they
don't point to the
> >>>>>>commits
> >>>>>>that
> >>>>>> > fix
> >>>>>> > > >>> them.
> >>>>>> > > >>>>
> >>>>>> > > >>>> For the names - just wanted to verify
whether it was the
> >>>>>>name
> >>>>>> field
> >>>>>> > or
> >>>>>> > > >>> the
> >>>>>> > > >>>> id field that can't have caps/spaces?
If it's the name,
> >>>>>>then
> >>>>>>ID
> >>>>>> > seems
> >>>>>> > > a
> >>>>>> > > >>> bit
> >>>>>> > > >>>> redundant. Either way - I think it's
important to have some
> >>>>>>sort
> >>>>>> of
> >>>>>> > > >>> common
> >>>>>> > > >>>> prefix for cordova-core plugins.
E.g. core-vibration, or
> >>>>>> > > >>>> org.apache.cordova.vibration.
> >>>>>> > > >>>>
> >>>>>> > > >>>> I think any merge into master is
worthy of a release bug.
> >>>>>>That
> >>>>>>way
> >>>>>> > you
> >>>>>> > > >>> can
> >>>>>> > > >>>> link it with the commit that bumps
the package.json
> >>>>>>version.
> >>>>>> > Probably
> >>>>>> > > >> one
> >>>>>> > > >>>> bug for all the plugins being released
is fine though. In
> >>>>>>the
> >>>>>> > release
> >>>>>> > > >>> bug,
> >>>>>> > > >>>> I think you should state what you
tested, mobile-spec is
> >>>>>>the
> >>>>>>goto,
> >>>>>> > but
> >>>>>> > > >> in
> >>>>>> > > >>>> this case, you may want to say that
you tested uploading to
> >>>>>>the
> >>>>>> > > plugins
> >>>>>> > > >>>> registry.
> >>>>>> > > >>>>
> >>>>>> > > >>>>
> >>>>>> > > >>>> On Wed, Jul 24, 2013 at 6:26 PM,
Shazron
> >>>>>><shazron@gmail.com>
> >>>>>> wrote:
> >>>>>> > > >>>>
> >>>>>> > > >>>>> plugin.xml changes only correct?
IMO bump the version and
> >>>>>>run
> >>>>>>the
> >>>>>> > > >> steps
> >>>>>> > > >>>>> here to test plugin add:
> >>>>>> > > >>> http://wiki.apache.org/cordova/WorkingWithThree
> >>>>>> > > >>>>>
> >>>>>> > > >>>>>
> >>>>>> > > >>>>>
> >>>>>> > > >>>>>
> >>>>>> > > >>>>> On Wed, Jul 24, 2013 at 3:03
PM, Steven Gill <
> >>>>>> > stevengill97@gmail.com
> >>>>>> > > >>>
> >>>>>> > > >>>>> wrote:
> >>>>>> > > >>>>>
> >>>>>> > > >>>>>> So I just added a dev branch
for all of the plugins and
> >>>>>>finished
> >>>>>> > > >> the
> >>>>>> > > >>>>> issues
> >>>>>> > > >>>>>> [1] [2] [3]. All three of
these were minor fixes and I
> >>>>>>don't
> >>>>>> > > >> believe
> >>>>>> > > >>>>>> require retesting all of
the plugins on every platform.
> >>>>>>What
> >>>>>> > should
> >>>>>> > > >>> my
> >>>>>> > > >>>>> next
> >>>>>> > > >>>>>> steps be? I know if I merge
into master, I should bump
> >>>>>>the
> >>>>>> version
> >>>>>> > > >>> for
> >>>>>> > > >>>>> all
> >>>>>> > > >>>>>> of them to 0.1.1. Is this
something I should create a
> >>>>>>release
> >>>>>> bug
> >>>>>> > > >> for
> >>>>>> > > >>>> and
> >>>>>> > > >>>>>> get tested before merging
into master?
> >>>>>> > > >>>>>>
> >>>>>> > > >>>>>>
> >>>>>> > > >>>>>> [1] https://issues.apache.org/jira/browse/CB-4371
> >>>>>> > > >>>>>> [2] https://issues.apache.org/jira/browse/CB-4370
> >>>>>> > > >>>>>> [3] https://issues.apache.org/jira/browse/CB-4338
> >>>>>> > > >>>>>>
> >>>>>> > > >>>>>>
> >>>>>> > > >>>>>> On Mon, Jul 22, 2013 at 12:41
PM, Brian LeRoux
> >>>>>><b@brian.io>
> >>>>>> > wrote:
> >>>>>> > > >>>>>>
> >>>>>> > > >>>>>>> Like that
> >>>>>> > > >>>>>>>
> >>>>>> > > >>>>>>> On Mon, Jul 22, 2013
at 3:33 PM, Andrew Grieve <
> >>>>>> > > >>> agrieve@chromium.org
> >>>>>> > > >>>>>
> >>>>>> > > >>>>>>> wrote:
> >>>>>> > > >>>>>>>> Oh! Oh! Perhaps have
multiple definitions based on CDV
> >>>>>> version.
> >>>>>> > > >>>> e.g.:
> >>>>>> > > >>>>>>>>
> >>>>>> > > >>>>>>>> <engine min-cdv-version="2.8"
max-cdv-version="2.8">
> >>>>>> > > >>>>>>>>  <default-git-ref>refs/head/2.8.x</default-git-ref>
> >>>>>> > > >>>>>>>> </engine>
> >>>>>> > > >>>>>>>> <engine min-cdv-version="2.9">
> >>>>>> > > >>>>>>>>  <default-git-ref>refs/tags/stable</default-git-ref>
> >>>>>> > > >>>>>>>> </engine>
> >>>>>> > > >>>>>>>>
> >>>>>> > > >>>>>>>>
> >>>>>> > > >>>>>>>> Then, when someone
plugman installs the git URL, it can
> >>>>>>fetch
> >>>>>> > > >> it
> >>>>>> > > >>>> and
> >>>>>> > > >>>>>>>> checkout a version
that best matches your cordova
> >>>>>>version.
> >>>>>> > > >>>>>>>> Then, when you update
your cordova version, it can go
> >>>>>>through
> >>>>>> > > >>> your
> >>>>>> > > >>>>>>> plugins
> >>>>>> > > >>>>>>>> and update them to
different branches (unless you glue
> >>>>>>them to
> >>>>>> > > >> a
> >>>>>> > > >>>> ref
> >>>>>> > > >>>>>> as a
> >>>>>> > > >>>>>>>> part of your install
URL)
> >>>>>> > > >>>>>>>>
> >>>>>> > > >>>>>>>>
> >>>>>> > > >>>>>>>>
> >>>>>> > > >>>>>>>> On Mon, Jul 22, 2013
at 2:44 PM, Braden Shepherdson <
> >>>>>> > > >>>>>> braden@chromium.org
> >>>>>> > > >>>>>>>> wrote:
> >>>>>> > > >>>>>>>>
> >>>>>> > > >>>>>>>>> The model I had
always imagined was that we would do
> >>>>>> something
> >>>>>> > > >>>>> similar
> >>>>>> > > >>>>>>> to
> >>>>>> > > >>>>>>>>> npm: Plugin authors
decide what the default ref is for
> >>>>>>their
> >>>>>> > > >>>> plugin.
> >>>>>> > > >>>>>>> Could
> >>>>>> > > >>>>>>>>> be master, some
other branch, a tag, a hash. That's
> >>>>>>what
> >>>>>>the
> >>>>>> > > >>>>> discovery
> >>>>>> > > >>>>>>> tool
> >>>>>> > > >>>>>>>>> will return when
a user asks to add that plugin
> >>>>>>without
> >>>>>> > > >>> explicitly
> >>>>>> > > >>>>>>>>> specifying a
version. I think this is a good idea we
> >>>>>>should
> >>>>>> > > >>>>> implement
> >>>>>> > > >>>>>>> too.
> >>>>>> > > >>>>>>>>>
> >>>>>> > > >>>>>>>>> Braden
> >>>>>> > > >>>>>>>>>
> >>>>>> > > >>>>>>>>>
> >>>>>> > > >>>>>>>>> On Fri, Jul 19,
2013 at 10:16 AM, Andrew Grieve <
> >>>>>> > > >>>>> agrieve@chromium.org
> >>>>>> > > >>>>>>>>>> wrote:
> >>>>>> > > >>>>>>>>>
> >>>>>> > > >>>>>>>>>> I think it's
true that:
> >>>>>> > > >>>>>>>>>>
> >>>>>> > > >>>>>>>>>> 1. CLI downloads
tagged versions of platforms
> >>>>>> > > >>>>>>>>>> 2. Plugman
downloads plugins from "master" branch
> >>>>>> > > >>>>>>>>>>
> >>>>>> > > >>>>>>>>>> This means
that we can't check any code into plugin
> >>>>>>master
> >>>>>> > > >>>>> branches
> >>>>>> > > >>>>>>>>> without
> >>>>>> > > >>>>>>>>>> them going
live immediately.
> >>>>>> > > >>>>>>>>>>
> >>>>>> > > >>>>>>>>>> Best solution
would be to change plugman to download
> >>>>>>from a
> >>>>>> > > >>> tag
> >>>>>> > > >>>> by
> >>>>>> > > >>>>>>>>> default,
> >>>>>> > > >>>>>>>>>> but a bit
late for that now...
> >>>>>> > > >>>>>>>>>>
> >>>>>> > > >>>>>>>>>> Instead,
I think we should change all development on
> >>>>>> > > >> plugins:
> >>>>>> > > >>>>>>>>>> - Commit
only to "dev" branch.
> >>>>>> > > >>>>>>>>>> - When we
want to push an update, we should file a
> >>>>>>release
> >>>>>> > > >> bug
> >>>>>> > > >>>> for
> >>>>>> > > >>>>>> the
> >>>>>> > > >>>>>>>>>> plugin, test
on all platforms
> >>>>>> > > >>>>>>>>>> Case 1: The
changes work with 3.0 cordova: then merge
> >>>>>>into
> >>>>>> > > >>>> master
> >>>>>> > > >>>>>>> (only
> >>>>>> > > >>>>>>>>> if
> >>>>>> > > >>>>>>>>>> it works
of course)
> >>>>>> > > >>>>>>>>>> Case 2: The
changes require a platform API that
> >>>>>>hasn't
> >>>>>>been
> >>>>>> > > >>>>> release
> >>>>>> > > >>>>>>> yet:
> >>>>>> > > >>>>>>>>>> Wait and
release after the next cordova core release.
> >>>>>> > > >>>>>>>>>>
> >>>>>> > > >>>>>>>>>>
> >>>>>> > > >>>>>>>>>> Any other
ideas?
> >>>>>> > > >>>>>>>>>>
> >>>>>> > > >>>>>>>>>
> >>>>>> > > >>>>>>>
> >>>>>> > > >>>>>>
> >>>>>> > > >>>>>
> >>>>>> > > >>>>
> >>>>>> > > >>>
> >>>>>> > > >>
> >>>>>> > >
> >>>>>> > >
> >>>>>> >
> >>>>>>
> >>>>
> >>
>
>

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