Skip to content
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

Consider a procedural API for a future iteration #18

Open
raymeskhoury opened this issue May 16, 2019 · 1 comment
Open

Consider a procedural API for a future iteration #18

raymeskhoury opened this issue May 16, 2019 · 1 comment

Comments

@raymeskhoury
Copy link
Collaborator

Thomas Steiner:

Could file_handler be dynamically extended, without pushing a new manifest? Conceived-ish example: you have a freeium app that initially handles just .foo files, you install it, love it, unlock the premium version, and now it can also handle .foopremium files.

Good thought. I think we should add that as something to explore for V2. The same idea has been raised for the proposed Shortcuts API and it's also relevant for web share target - ideally these "handler" APIs should have declarative and procedural versions

@fallaciousreasoning
Copy link
Collaborator

Interesting idea. You could achieve something similar by pushing an update to the manifest (based on cookies or sessions or something).

Do you think in this kind of situation, the app would want to be associated with .foopremium files anyway (so they can prompt the user for the upgrade)? This is what Word, Visual Studio, Intellij and the like do when you don't have a valid license.

But its definitely a neat idea to explore for V2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants