cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <mmo...@google.com>
Subject Re: cordova plugin save
Date Wed, 13 Aug 2014 22:26:31 GMT
On Wed, Aug 13, 2014 at 6:07 PM, Treggiari, Leo <leo.treggiari@intel.com>
wrote:

>  Hi Michal,
>
>
>
> Thanks for your answers.  They were quite helpful.  I have a few
> follow-ups.
>
>
>
> With your answers, and references, and I found
> https://wiki.apache.org/cordova/ConfigurationFiles,
>
> I have a better understanding of the existing metadata files.
>
>
>
> However there seem to be quite a few of them  and I’m not yet sure about
> where different types of information should go.
>
>
>
> https://wiki.apache.org/cordova/ConfigurationFiles goes into the answers
> I’m looking for, except it just seems to be documenting the current
> situation.
>
> -  What types of metadata are there?
>
> -  Where is each type saved?
>
> -  Who owns each type and can change it?
>
I think we are figuring this out ourselves.  There are differing opinions.
 Thanks for speaking up and voicing yours.

>
>
> Here are my thoughts:
>
>
>
> - “App” (or “Project”) metadata defines everything about the “app” that
> should be shared by all developers who want to develop/build the app.  In
> the case of Cordova CLI, this is primarily a “build recipe”.  I.e. with
> this metadata (plus given proper “workspace” (or “environment”) setup),
> anyone can build the same app.  Tooling (e.g. Cordova CLI) or IDEs would
> normally be used to maintain some/all of this metadata.  For example,
> Cordova CLI may handle the plugins and platforms but document how to add
> icons and splash screens to the app using this metadata file.  An IDE might
> manage all of that inside the IDE itself.  The newly proposed metadata for
> specifying project directory structure would be part of this metadata.
>
Personally, this is exactly my mental model as well.  But its


>
>
> - “Workspace” (or “Environment” or “Project specific user settings”)
> metadata describe the settings that a user (or tools on the user’s behalf)
> have to make to set up an environment for developing/building the app.
> E.g. the location of native SDKs.
>
Ditto.

>
>
> In general, different tooling/IDEs could have different rules regarding
> who creates these metadata files and who is allowed to edit them and how.
>
>
>
> Is app config.xml intended to be the “App” metadata file?
>
Yes.  Though it should be noted that most everyone would rather there was a
different file for this.

config.xml is based on a deprecated proposal for app metadata (widget
spec).  There are several new app manifest formats roaming around, most
based on json.  However, I think we will likely use what we already have
for the foreseeable future since we're already spending way too much time
on tooling and changing this is not worthwhile bang-for-buck.

>  Is .cordova/config.json intended to be the “Workspace” metadata file?
>
I think so.  I'm less sure about how everyone feels about this file, but
its likely that we will stick with what we have.  Its also possible that
IDE's/downstream tooling can just use some internal settings representation
since most the the config.json values can be passed in to the CLI through
the command line or node interface.

>
>
> > - Aside from the initial create script that sets name etc, the
>
> > plugin/platform save command is the first tooling command to edit the
> file
>
> > directly (I think?).
>
>
>
> I don’t understand why ‘cordova plugin/platform add/remove’ would not
> modify app config.xml, but now ‘cordova plugin/platform save’ would.  Or is
> that really the distinction between the 2?  And how does that list of
> plugins interact with what the user may have added themselves to config.xml?
>
I think this was Andrew's point and Gorkems original intention.  We agree
that `plugin add/remove` should update the list.  The save/restore was just
a non-intrusive way to experiment for now.

>
>
> Thanks,
>
All good questions raised, with few definitive answers.  It sounds like
you're all caught up to the rest of us, though!

>  Leo
>
>
>
> > A few answers:
>
> > - There is no spec, since this is an "experimental" feature we aren't
>
> >  ourselves sure yet how it will look when complete.  That was the point
> of
>
> >  recent threads.
>
> > - The file belongs to the app / user, not to the workspace / tooling.
>
> > - Aside from the initial create script that sets name etc, the
>
> > plugin/platform save command is the first tooling command to edit the
> file
>
> > directly (I think?).
>
> > - You can read more here:
>
> > https://cordova.apache.org/docs/en/edge/config_ref_index.md.html
>
> > - The top level "app" config.xml is not platform specific, but you can
> have
>
> > platform specific settings in there by using the <platform> tag
>
> > - It is specific to cordova CLI.  Each platform has another, different
>
> > config.xml (we usually call it the "platform" config.xml) which is
> created
>
> > during cordova prepare, and thats what edited with non cli workflow.
>
> > - Phonegap workflow (also chrome cordova (cca) and likely others) is
>
> > compatible with cordova config.xml, but those often also add extensions
> to
>
> > the options
>
> > - "project-level" (I call this "workspace") metadata should *not* go into
>
> > app config.xml. We already have another file, .cordova/config.json for
>
> > those.  However, the list of plugins that your app needs is arguably not
> a
>
> > property of a workspace, but truly a property of your application.  Ditto
>
> > for platforms (to a lesser extent).
>
> >
>
> > I'm not so sure what the proposal is for removing plugins/ directory, I
>
> > don't think there is anything concrete for that, it was just ramblings of
>
> > various contributors ;)
>
> >
>
> > -Michal
>
> >
>
> >
>
> > On Wed, Aug 13, 2014 at 2:41 PM, Treggiari, Leo <leo.treggiari@intel.com
> >
>
> > wrote:
>
> >
>
> >> I'm new to this mailing list.  I work on the Intel(r) XDK which is
> another
>
> >> IDE which supports the creation of hybrid apps using Cordova plugins.
>
> >>
>
> >> I'm having trouble figuring out what the proposed 'cordova plugin save'
>
> >> command does.  Is there an up-to-date 'spec' that explains the goals of
> the
>
> >> command and the implementation?
>
> >>
>
> >> A couple of things that I have read in the mailing list concern me.
>
> >>
>
> >> There is mention of saving information in config.xml.  The usage of
>
> >> config.xml is somewhat of a mystery to me:
>
> >> -  Who owns the file?  Does the user own and edit it?  Do certain
> Cordova
>
> >> CLI commands edit it?  What are the valid entries?
>
> >> -  Is it treated differently by different platform builds - e.g. iOS vs.
>
> >> Android?  Is it treated differently by Cordova CLI vs. other Cordova
> IDEs
>
> >> which directly use Cordova CLI or not - e.g. PhoneGap build?
>
> >> -  If Cordova CLI wants to store 'project-level' metadata, is this a
> good
>
> >> place to put it?  If the answer to the first question above is not well
>
> >> defined, or the answer to the second question is that different 'things'
>
> >> are using it differently, then config.xml may not be a good place to be
>
> >> putting new metadata.
>
> >>
>
> >> There is a mention of plugin "restoring" and making the plugins
> directory
>
> >> optional.  This relates to the issue of plugin 'versions'.  Now, when a
>
> >> user executes 'cordova plugin add', plugin sources are fetched and the
>
> >> version of the plugin that was added is fixed until the user explicitly
>
> >> removes and re-adds it.  Is 'cordova plugin save' & 'restore'
> suggesting a
>
> >> new version management model?  E.g. if I add a plugin without a specific
>
> >> version suffix and 'restore' it later, I may not get the same version,
>
> >> right?
>
> >>
>
> >> If there is a 'spec', I should be able to answer these questions myself.
>
> >>
>
> >> Thanks,
>
> >> Leo Treggiari
>
>
>

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