-
Notifications
You must be signed in to change notification settings - Fork 762
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Promises #637
Comments
The file plugin is written to W3C specs with the idea that eventually the plugin won't be needed eventually (in fact most Apache plugins were written like this). They are as follows:
Given that the standard of this file plugin is based on is discontinued (with no known replacements as far as I know) I think we should be open to the idea of introducing Promise support where it makes sense. But we should not deviate from any active/working specifications, which means we should not make API changes to FileReader, FileWriter, Blob, etc... unless if the goal is to polyfill missing features. It would also be worth seeing if Promises can be implemented in such a way that it isn't a breaking change, which I believe your sample proposal shows. I suggest requesting a "buy-in" before starting any substantial work to see if other community members agree or disagree. (They don't always pay attention to GitHub notifications since they are quite noisy). To do this you'll need to subscribe to the Dev Mailing List and write to the list stating your intent. You an can reference this issue. If after 48-72 hours occurs with no response, then you can treat the lack of response as a lazy agreement. For what it's worth I think introducing promise support on the filesystem APIs would cut down on a lot of "callback hell" that the W3C specification has and I personally see no problem deviating from a standard that appears to be killed. I believe the only browser that had an actual implementation of it was Chrome. The devil's advocate here is that it's also easy to provide a Facade to provide the promise-based API without changing the underlying library API. |
Hi @breautek, thanks four thoughts and suggestions. So you think it's ok to change something on the filesystem api, but not on the file api, except to make a Facade for it or for everything. My intention was, to make it backward compatible. You can still use callbacks, but also promises, if no callbacks are given. What do you think how a facade could look like? It would be also ok, to change only the filesystem api to promises, this would, as you wrote, already cut down the callback hell. I will do it like you wrote with the mailing list. Regards |
@breautek Nobody reacted on this except you, is this a lazy agreement? |
I would send out a "final call" email which can read something to the effect of:
If no one else responds, then yes I would treat it as a lazy agreement. Given this is just to decide if it's worth starting the work, the final call isn't really necessary (because after the work is done, a PR needs to be approved and merged still) BUT this serves as a final reminder for someone to make constructive arguments against the plan, and something you can point to should someone tries to drastically change the path come PR review time after you've already done said work. If you're not already joined, you can use https://join.slack.com/t/cordova/shared_invite/zt-z70vy6tx-7VNulesO0Qz0Od9QV4tc1Q to join the slack workspace. It's more or less an unofficial channel for realtime chat regarding cordova development. Most development choices and official processes must use the mailing list, but slack is suitable to iron out thoughts or get advice regarding the Apache processes. |
Ok thanks, then I will do a final call. I'm registered in Slack, but the mailing list is ok for me. And as you wrote, the PR will be a discussion ground about the new integration. |
Hi @breautek, I found a W3C Community Group Draft Report of the Do we have to care about this? Greetings, Manuel |
I don't think so. The file plugin has a lot of really old code that obviously has been mangled and manipulated to not only keep up with standard changes previously but to make it work with the underlying android and ios filesystems. I think adopting any newer standard at this point should probably be done from a clean slate as a new plugin, which might be something that Apache would want to do in the future, but definitely out of scope for right now. |
Ok I understand. Another thing I noticed is that |
|
Ok I saw this also now. I formatted the readme regarding the specs, so it's clearer which specs are used, which are discontinued and which could be a replacement. |
Feature Request
I want to add Promise functionality to this plugin and have some questions.
From my point, Promises are save to add natively, because:
Here a sample of a conversion i would make.
Old code:
New code:
Would it be fine like this?
Regards
The text was updated successfully, but these errors were encountered: