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

Reenable local-uri support when deprecating RelativeSource #148

Open
simonbuehler opened this issue Jun 16, 2020 · 6 comments
Open

Reenable local-uri support when deprecating RelativeSource #148

simonbuehler opened this issue Jun 16, 2020 · 6 comments

Comments

@simonbuehler
Copy link
Contributor

simonbuehler commented Jun 16, 2020

hi,

in my usecase the app should allow to easily replace assets ( pngs / html text/ ...) by the end user and therefore the html/asset files should not be hidden inside the Application.
When RelativeSource will be removed there is no easy way to provide this possibility to the users or did i miss something?

@simonbuehler
Copy link
Contributor Author

hi,

actually i found that up to commit b2a4a8f there was a pack-uri and local-uri scheme handler.
The advantage of the local-uri scheme is that js modules can be loaded as the mimetype etc is set correctly.
When deprecating RelativeSource, why did the local-uri support get dropped? So the issue is rather about re-activating the local-uri handler than keeping relative source, any comments on this please?

@simonbuehler simonbuehler changed the title Reconsider deprecating RelativeSource Reenable local-uri support when deprecating RelativeSource Jul 3, 2020
@David-Desmaisons
Copy link
Member

Hello @simonbuehler , sorry for the late answer.

I am trying to remember why I remove the local uri scheme.
I remember that there were issues with scheme security and ultimatelly as an internal hack I kind of hijack https protocol for pack url. Doing this, I removed the local scheme.

I guess that I could reintroduce-it using the same hack as pack url. Maybe the new API will accept an absolute path and let the application figure out how to build it.

That said, in any case, I will drop relative source support without addressing this point,

Could you explain better your use case? And why embedded resources are not a good solution for you?

@simonbuehler
Copy link
Contributor Author

The use case is a application that runs in a kiosk mode and the customers should be able to replace dynamic content like their logos / images in sliders / css styles by replacing files in a folder on the desktop.
This is to make it easy for non technical people to customize the appearance of the kiosk gui as well as implementing a content distribution system where stuff is pushed to the devices duing runtime without having to create a individual exe for each customer

@simonbuehler
Copy link
Contributor Author

simonbuehler commented Sep 3, 2020

hi @David-Desmaisons

could you still find some time for this isse, would be awesome!

@David-Desmaisons
Copy link
Member

hi @simonbuehler , with the current solution do you have any limitation for the scenario you are targeting?
Currently I have no date to deprecate local-uri and I will provide an alternative when I do.

@simonbuehler
Copy link
Contributor Author

sorry for the delay -

the limit is that i can't use filesystem content as the relative source doesn't set the mime type and the last implemention of LocalUriResourceHandler did.

It would be perfect if one could chosoe from useing pack:// ( internal) resoures or local:// ( filesystem) resources with those customized CfxResponse headers and MimeTypes

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