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 mmocny@google.com designates
 209.85.213.175 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <85A3E123BABF314D9D3656D0B418125643E0E4D8@FMSMSX103.amr.corp.intel.com>
References: 
 <85A3E123BABF314D9D3656D0B418125643E0E4D8@FMSMSX103.amr.corp.intel.com>
From: Michal Mocny <mmocny@google.com>
Date: Wed, 13 Aug 2014 18:26:31 -0400
Message-ID: 
 <CAEeF2Td9-=cvVO9i8r-nBhsvEdiDDhK25t02W8Mbp4zA9qVxrw@mail.gmail.com>
Subject: Re: cordova plugin save
To: "Treggiari, Leo" <leo.treggiari@intel.com>
Cc: "dev@cordova.apache.org" <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=001a11338c28f3cfa605008a4830

--001a11338c28f3cfa605008a4830
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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=E2=80=99m not yet sur=
e about
> where different types of information should go.
>
>
>
> https://wiki.apache.org/cordova/ConfigurationFiles goes into the answers
> I=E2=80=99m looking for, except it just seems to be documenting the curre=
nt
> 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:
>
>
>
> - =E2=80=9CApp=E2=80=9D (or =E2=80=9CProject=E2=80=9D) metadata defines e=
verything about the =E2=80=9Capp=E2=80=9D that
> should be shared by all developers who want to develop/build the app.  In
> the case of Cordova CLI, this is primarily a =E2=80=9Cbuild recipe=E2=80=
=9D.  I.e. with
> this metadata (plus given proper =E2=80=9Cworkspace=E2=80=9D (or =E2=80=
=9Cenvironment=E2=80=9D) 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 mig=
ht
> manage all of that inside the IDE itself.  The newly proposed metadata fo=
r
> specifying project directory structure would be part of this metadata.
>
Personally, this is exactly my mental model as well.  But its


>
>
> - =E2=80=9CWorkspace=E2=80=9D (or =E2=80=9CEnvironment=E2=80=9D or =E2=80=
=9CProject specific user settings=E2=80=9D)
> metadata describe the settings that a user (or tools on the user=E2=80=99=
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 =E2=80=9CApp=E2=80=9D 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 =E2=80=9CWorkspace=E2=80=9D m=
etadata 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=E2=80=99t understand why =E2=80=98cordova plugin/platform add/remov=
e=E2=80=99 would not
> modify app config.xml, but now =E2=80=98cordova plugin/platform save=E2=
=80=99 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.x=
ml?
>
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 in=
to
>
> > app config.xml. We already have another file, .cordova/config.json for
>
> > those.  However, the list of plugins that your app needs is arguably no=
t
> a
>
> > property of a workspace, but truly a property of your application.  Dit=
to
>
> > 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.co=
m
> >
>
> > 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 o=
f
> 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 v=
s.
>
> >> 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 wel=
l
>
> >> defined, or the answer to the second question is that different 'thing=
s'
>
> >> are using it differently, then config.xml may not be a good place to b=
e
>
> >> 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 explicitl=
y
>
> >> 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 specif=
ic
>
> >> 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 mysel=
f.
>
> >>
>
> >> Thanks,
>
> >> Leo Treggiari
>
>
>

--001a11338c28f3cfa605008a4830--