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 clantz@microsoft.com designates
 207.46.163.241 as permitted sender)
From: Chuck Lantz <clantz@microsoft.com>
To: "Treggiari, Leo" <leo.treggiari@intel.com>, "dev@cordova.apache.org"
	<dev@cordova.apache.org>
Subject: RE: cordova plugin save
Thread-Topic: cordova plugin save
Thread-Index: Ac+3O9ZTgzcjODhIS3+bTDNmF+eI3gACctaAAACGhQAAAlGzAAAFHngh
Date: Thu, 14 Aug 2014 02:14:32 +0000
Message-ID: 
 <8eff060366a445ad94162c2f1adfbdc7@BLUPR03MB065.namprd03.prod.outlook.com>
References: 
 <85A3E123BABF314D9D3656D0B418125643E0E4D8@FMSMSX103.amr.corp.intel.com>
 <CAEeF2Td9-=cvVO9i8r-nBhsvEdiDDhK25t02W8Mbp4zA9qVxrw@mail.gmail.com>
 <ef5d3079cb1942e9b95122cab20ca838@BLUPR03MB065.namprd03.prod.outlook.com>,<85A3E123BABF314D9D3656D0B418125643E0E886@FMSMSX103.amr.corp.intel.com>
In-Reply-To: 
 <85A3E123BABF314D9D3656D0B418125643E0E886@FMSMSX103.amr.corp.intel.com>
Accept-Language: en-US
Content-Language: en-US
Content-Type: multipart/alternative;
	boundary="_000_8eff060366a445ad94162c2f1adfbdc7BLUPR03MB065namprd03pro_"
MIME-Version: 1.0

--_000_8eff060366a445ad94162c2f1adfbdc7BLUPR03MB065namprd03pro_
Content-Type: text/plain; charset="windows-1256"
Content-Transfer-Encoding: quoted-printable

Yeah I guess what I'm getting at is it is more of an app descriptor. It des=
cribes things about the app that are immutable across the native underlying=
 projects used to build the app, different IDEs, or project structures. If =
there was a way to import and export Cordova apps across any number of IDEs=
 or products and services (PhoneGap Build, WorkLight, Intel, Telerik, etc) =
there are a set of things about the app that wouldn't change. A transformed=
 version of config.xml lands in underlying native projects in the platforms=
 folder as well.

Another example, lets say that Gulp becomes the build system instead of the=
 CLI (not saying that will happen - just jumping to an extreme). We need a =
place to keep the things that would not change.

Speaking for VS, I would never put typescript compilation settings, build c=
onfigs, and other IDE settings that pertain to the app project in config.xm=
l. That's specific to the VS world and belongs in the VS project. Similarly=
 I would not force a project structure on another IDE let alone someone han=
d editing config.xml in sublime text. Most likely will not change from the =
CLI structure anyway.

Now, how that is presented to the developer is a completely different story=
.

Whether config.xml is the right long term place for what I describe is anot=
her topic entirely.  It's pretty engrained. I do think it will be important=
 to easily separate the concepts, however.

On the other questions - hop on that thread. I didn't make the PR so I can =
only speak to the code verses the exact intent. :) The issue is that there =
is no single definitive list of plugins or platforms to install today (plug=
ins pull in dependencies for specific platforms so the contents of the plug=
ins folder is actually not the definitive list).  That's what it was trying=
 to fix.
________________________________
From: Treggiari, Leo<mailto:leo.treggiari@intel.com>
Sent: =FD8/=FD13/=FD2014 6:48 PM
To: Chuck Lantz<mailto:clantz@microsoft.com>; dev@cordova.apache.org<mailto=
:dev@cordova.apache.org>
Cc: Treggiari, Leo<mailto:leo.treggiari@intel.com>
Subject: RE: cordova plugin save

Hi Chuck,

Thanks for adding the other 'app metadata file' (like AndroidManifest.xml o=
r package.appxmanifest.xml.) to the conversation.  It's important to consid=
er that as well.  Those are somewhat different because they contain informa=
tion that is not built into the app executable, but rather handled by an in=
staller or loader.  Does that make those settings somehow different to the =
app developer?  I'm not sure.  But I'm sure you're right that items in the =
existing set of metadata files affect all of the app executable, the accomp=
anying app 'manifest' file, and the accompanying cordova.js file.

To start, I'm not sure that it makes sense to add any new metadata to the a=
pp config.xml file.  I'm not sure that, because of its history, it fits cle=
anly into any metadata category we might want to define.  Maybe a new file =
is needed.  Others than I are better suited to judge that since I don't hav=
e the Cordova history.

However, I don't agree with some of the categorizations you've made.  I don=
't see why the list of plugins your app uses is a different kind of metadat=
a than the directories where you would find portable sources, plugins, merg=
e sources, etc.  Both are required to fully define how to build the app bas=
ed upon a set of sources pulled from a repository.  Thinking in terms of a =
Visual Studio example, wouldn't both be defined in a single project file?  =
More files just leads to more things to maintain and accidentally overlook.

> The idea behind  save/restore is to make it easier to share a project and=
 reduce the amount of redundant code that you'd check in to a source repo. =
 (You could omit the plugins and platforms folders from source control and =
then "restore".)

So is that the primary use case for the new commands?  I didn't realize tha=
t from the discussion I had read, but now I understand.  I  thought it was =
specifically recommended to not put the platforms folder under source code =
control.  So, the savings could come with the plugins folder.  There are, a=
t least, a couple of issues/questions with this that have already been ment=
ioned (just adding them here to keep them in one place...):
-  Where does 'save' find the definitive list of plugins that it should sav=
e?  There may be some plugins specified in config.xml and there are other m=
etadata (<platform>.json)  files that believe they know the list.
-  What does it save and where?  Does it save the argument that was passed =
to 'corodva platform add xxx'?  Does it save the id, (and possibly addition=
al information) from the sources that were actually fetched?
-  Can 'restore' be guaranteed to fetch the same exact sources that were in=
 the project that was 'save'd?  Does it need to?

Thanks,
Leo

-----Original Message-----
From: Chuck Lantz [mailto:clantz@microsoft.com]
Sent: Wednesday, August 13, 2014 3:58 PM
To: dev@cordova.apache.org; Treggiari, Leo
Subject: RE: cordova plugin save

My two cents - there are three things here:

1. App metadata
2. Project metadata
3. Workspace metadata

$project/.cordova/config.json is probably the closest thing to an IDE proje=
ct file. The closest thing to workspace level settings is $home/.cordova/co=
nfig.json.

Given config.xml's roots, it's more of an app metadata file like AndroidMan=
ifest.xml or package.appxmanifest.xml.  Its contents should describe the ap=
p intendant of IDE or build system (as far as that is possible). So, regard=
ing, "The newly proposed metadata for specifying project directory structur=
e would be part of this metadata," I don't think config.xml is the right pl=
ace for that. It's build system config - which I believe belongs in config.=
json. Plugins in many ways equate to capabilities or intents which is why t=
hat makes sense to exist in config.xml.  The platforms that the app is desi=
gned to target also by extension appear to make sense (though admittedly le=
ss cleanly since there isn't a native platform equivalent).

On the plugin operations - Question is whether that would annoy developers =
that prefer to edit by hand (vs IDE use). The idea behind save/restore is t=
o make it easier to share a project and reduce the amount of redundant code=
 that you'd check in to a source repo.  (You could omit the plugins and pla=
tforms folders from source control and then "restore".)

-Chuck

-----Original Message-----
From: Michal Mocny [mailto:mmocny@google.com]
Sent: Wednesday, August 13, 2014 3:27 PM
To: Treggiari, Leo
Cc: dev@cordova.apache.org
Subject: Re: cordova plugin save

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=92m not yet sure
> about where different types of information should go.
>
>
>
> https://wiki.apache.org/cordova/ConfigurationFiles goes into the
> answers I=92m 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:
>
>
>
> - =93App=94 (or =93Project=94) metadata defines everything about the =93a=
pp=94
> that should be shared by all developers who want to develop/build the
> app.  In the case of Cordova CLI, this is primarily a =93build recipe=94.
> I.e. with this metadata (plus given proper =93workspace=94 (or
> =93environment=94) 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


>
>
> - =93Workspace=94 (or =93Environment=94 or =93Project specific user setti=
ngs=94)
> metadata describe the settings that a user (or tools on the user=92s
> 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 the=
m and how.
>
>
>
> Is app config.xml intended to be the =93App=94 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 fo=
reseeable 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 =93Workspace=94 metadata file=
?
>
I think so.  I'm less sure about how everyone feels about this file, but it=
s likely that we will stick with what we have.  Its also possible that IDE'=
s/downstream tooling can just use some internal settings representation sin=
ce 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=92t understand why =91cordova plugin/platform add/remove=92 would n=
ot
> modify app config.xml, but now =91cordova plugin/platform save=92 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 t=
hat `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 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
> >> well
>
> >> 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 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 mysel=
f.
>
> >>
>
> >> Thanks,
>
> >> Leo Treggiari
>
>
>

--_000_8eff060366a445ad94162c2f1adfbdc7BLUPR03MB065namprd03pro_--