cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Filip Maj <...@adobe.com>
Subject Re: Plugin / Platform mismatch problems
Date Mon, 29 Jul 2013 19:02:29 GMT
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
View raw message