Deprecated plugins

[brodycj]

A decision was made in Apache JIRA CB-12708 ([1]), back in 2017. At this point we would like to deprecate the following plugins and archive them on GitHub:

• apache/cordova-plugin-contacts
  - [ ] apache/cordova-plugin-device-motion (development resumed, required for iOS 13+)
  - [ ] apache/cordova-plugin-device-orientation (development resumed, required for iOS 13+)
  - [ ] apache/cordova-plugin-file-transfer (development resumed)
• apache/cordova-plugin-globalization
• apache/cordova-plugin-media

Plugins that can be integrated into the affected platforms and archived:

• apache/cordova-plugin-splashscreen
• apache/cordova-plugin-whitelist

Further discussion is needed on these plugins:

• apache/cordova-plugin-camera - should be replaced by use of standard HTML media capture or getUserMedia() call; need to check for proper support on all platforms
• apache/cordova-plugin-file - see Apache JIRA CB-12715 & Apache JIRA CB-13044
• apache/cordova-plugin-media-capture
  • ideally superseded by web APIs
  • some other ideas in Apache JIRA CB-13049, could be superseded by phonegap/phonegap-plugin-media-stream
• apache/cordova-plugin-statusbar - possibly integrate, possibly get viewport-fit and theme-color values from HTML meta tag such as <meta name="theme-color"> ref:
  • https://html.spec.whatwg.org/multipage/semantics.html#meta-theme-color
  • https://issues.apache.org/jira/browse/CB-12717

In case we decide to sunset any other plugins within this issue, let's please add them to the appropriate checklist.

Process to follow is documented in [2].

I think it is extremely important that we archive all deprecated plugins in order to avoid the burden of issues and PRs that could come up on GitHub, as I had already said in issue #60.

Additional & related TODO item(s):

• deprecation process ([2]) does not seem to be published on cordova.apache.org (deprecation page not found from cordova-contribute cordova-docs#1046)
• check if any other plugins could (eventually) be deprecated and archiving, as superseded by Web APIs known to be working properly on all platforms
• ensure and double-check that we keep the list of deprecated and archived plugins in README.md in sync with the plugins that are actually deprecated and archive
• check if any plugins should be removed from the cordova-mobile-spec (see also issue [Plugins] Improve plugin tests #37 - improve plugin tests)
• review issues directly and indirectly linked from [1] (JIRA CB-12708)
• close out issues linked directly and indirectly from [1] (JIRA CB-12708) with comments as appropriate
• close out [1] (JIRA CB-12708) with comments as appropriate

[1] https://issues.apache.org/jira/browse/CB-12708
[2] https://github.com/apache/cordova-contribute/blob/master/deprecation.md

[brodycj]

I think the following plugins should be moved into the list for further discussion:

• apache/cordova-plugin-file-transfer - this plugin may still be needed due to some possible issues with fetch & XHR on iOS, at least
• apache/cordova-plugin-globalization - seems to be still useful for the user community, as discussed in Do NOT deprecate this plugin cordova-plugin-globalization#79
• apache/cordova-plugin-media - I think we should check more carefully that this plugin can really be superseded by working Web API implementations. There seems tobe some interesting information in CB-12714 & CB-13095.

[brodycj]

Some more thoughts on my part:

I would personally downvote integrating plugin functionality into the platforms due to increased complexity and potentially less flexibility. I would make an exception for console which is very basic universal functionality.

The whitelist functionality seems to be a challenging beast since it evidently works differently on Android, iOS, and maybe some other platforms. It would be ideal if we could find a way to abstract it somehow. And the newer iOS WKWebView seems to make this even worse.

I would personally not really mind if the functionality of some of our core plugins would eventually be superseded by some third-party plugins that some members are involved with to a certain extent. For example:

• Ionic WKWebView
• https://github.com/EddyVerbruggen/cordova-plugin-safariviewcontroller - provides some specific improvements over the InAppBrowser on iOS and Android, though with some major limitations
• SQLite storage plugin - Android implementation was originally extracted from PhoneGap 1.x

I am fine if we split some of the tasks into separate issues, would like to see the list of deprecated plugins in a pinned issue to help give the user community plenty of warning and opportunity to comment.

[tryhardest]

To be clear I presume you are only suggesting sunsetting when newer versions of plugins are available aka close-to drop in replacement plugins?

Often new webAPIs that have core plugin functionality fully supported but cannot alone do the extended things some of those listed plugins can. At least not without months of work all told, or a huge amount of additional build out and refactor (maybe enough to kill businesses) which could honestly accompany this decision on next Cordova upgrade cycle, when these would all possibly become unusable. If for some reason (there often are) projects forced into an upgrade cycle and they find half their app no longer functions.

The whole model of Cordova was and is plugin extendability. Certainly hasn't been easy doing so with the complexity of version control, maintainers falling off, conflicts, etc. However, these are all critical plugins for many people who spent massive amounts of time and resources integrating them fully, and as mentioned the extended functionality and use cases in many of the listed plugins is critical to apps functioning correctly.

Wouldn't it make more sense seeing as Capacitor functions also on Cordova plugins, to promote upgrading and ongoing development of them by respective maintainers? Or suggesting the plugins reach out for some help and make the appropriate changes to be current? Users always have the option to opt for webAPIs anyway, so why not take that approach without actively promoting the depreciation of so many complex plugins.

the depreciation suggestion of these;
apache/cordova-plugin-contacts
apache/cordova-plugin-device-motion
apache/cordova-plugin-device-orientation
apache/cordova-plugin-file-transfer
apache/cordova-plugin-media
apache/cordova-plugin-media-capture
apache/cordova-plugin-camera
apache/cordova-plugin-file
All of which we use, seems like untold headaches.
For a small team that could potentially kill us. Took long enough to get all the plugins working correctly.

We also additionally use
Splashscreen
Whitelist
but personally we have no issue for those to be integrated, I've always felt that they should be.

Further we also use;
WKwebview (Ionic version)
Whitelist
SQLite storage
But you have not suggested those to be depreciated, only to superseed core plugins.

So I guess I am trying to get a better understanding of how this depreciation is being approached without potentially devistating consequences for thousands of projects moving fwd. Maybe my understanding of stopping active support, development and matenaince on them is elevated due to knowing there is an enevitable dead end with this approach whereby the continuing advancement of the platform will eventually collide with their use at all, rending all the code surrounding each to be unusable. I know (and am grateful) that you maintain many plugins and for your work on Cordova proper. I personally feel if we all took one or two of them under our wings (with webAPI optionality) it's a better approach. Aren't plugin maintainers the ones to decide if they want to continue updating and maintenance on a plugin anyway?

In summary; sorry I'm not fully understanding your posts. I am understanding this as either devastating ultimately to our project moving fwd or enough new work that it will destroy our small team because we depend on so much of what you have mentioned.

Thanks you.

[brodycj]

Thanks @tryhardest, your comments are definitely valuable. Please accept my apologies for not responding anytime sooner.

Our Apache Cordova maintenance team is mostly if not 100% unpaid volunteers, generally with busy jobs in other companies or busy with freelance work. Volunteers with busy jobs cannot afford to either quit or go part-time, and freelancers like myself cannot afford to put too much work on hold. (I have made some sacrifices on my own in the past and do continue to give as much as I can to help keep maintenance going.) I think a major root cause is that 2 major companies had stopped sponsoring maintenance work.

As a member of Apache Cordova, it makes me extremely unhappy to see things such as:

• issues and PRs sitting there with no response
• bug fixes take too long to be published
• Cordova falls too far behind platform API and SDK updates.

Definitely a stressful situation for myself and for others involved, including the user community.

I am sure people can understand that the burden of supporting such a large number of old plugins would only add to the unfortunate amount of the existing stress.

I think it would be ideal if we could see more and more plugins would be supported by user community members that we know, that we can keep documented, just like a number of plugins are famously supported by @EddyVerbruggen and SQLite storage is supported by myself.

[timbru31]

For transparency:
We've voted and agreed to resume/revive/un-deprecate the following plugins:

• apache/cordova-plugin-device-motion
• apache/cordova-plugin-device-orientation
• apache/cordova-plugin-file-transfer