On Wed, Aug 13, 2014 at 6:07 PM, Treggiari, Leo <leo.treggi...@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.treggi...@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 > > >
