breautek commented on issue #555: URL: https://github.com/apache/cordova-plugin-file/issues/555#issuecomment-1399035788
> But don't you agree that these abstraction layers serve exactly to maintain the API stable over the time as W3C spec change, since the end user would be faced only with a readFile(path) function? This is before my involvement with Apache Cordova but from what I understand, all the Apache plugins were built to "cease to exists" which is why they were created as closely to W3C spec as possible. Many of these plugins were deprecated/discontinued because the webview caught up and these APIs were available. So adding any API that is not part of the spec would mean giving the user opportunity to rely on something potentially won't be replaced by a native webview implementation. As a result, adding "custom" APIs goes against the "cease to exist" mantra that Apache Cordova/PhoneGap had. This is why I said abstractions or providing an alternate API probably belongs in the third-party community space. To be clear, I'm not an authoritative figure here. I'm just simply stating what the Apache Cordova community used to do and describing how adding custom APIs doesn't fit in that mantra. To get a broader feel for whether the community supports deviating from W3C spec APIs, for the purposes of adding utility methods, a vote thread could be raised in the [mailing list](https://cordova.apache.org/contact/). Personally, I'd probably vote +1. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
