On Friday, May 14, 2021 at 1:56:08 AM UTC+2 [email protected] wrote: > I think the biggest advantage is that you can run any old static webserver > rather than one specific to TiddlyWiki. This enables things like more > easily handling multiple wikis (just stick them all in a common directory > and serve that directory, no config necessary). On Linux, no extra software > has to be installed, just download the wiki file and python is already > installed which has a webserver. >
OK. I'm running IIS on windows with a WebDav server and a nodejs at localhost on port 80. So no port is needed in the URL. I personally consider this as simple as running a python static server on linux. ... Anyway, that's a different topic. > The plugin doesn't require a webserver to work though, you just have to > pick the file in the filesaver once per reload. > Yea, and exactly that seems to be a "convenience" problem. > Personally, I don't refresh my wiki page very often so for me this is > probably once every couple hours at most unless I'm installing new JS > plugins or something. Once Chromium fixes their SOP policy for file://, > these can be safely stored in IndexedDB and have parity with running it > from a webserver. > OK. We will see, with what they come up with. > Another possibility is if FireFox implements the File System Access API > since they have a more restrictive origin policy for file:// domains. > IMO not really. They have the same problem, that file:// is only 1 domain for any of the local storage variants. ... I'm following the FireFox "file API" discussion very closely. ... IMO at the moment they don't intend to implement anything similar, to what chrome does. ... There is an open "bug", for a file API for web-extensions, that also has a "permission dialogue" for the first time you access a directory or a file. ... But then the setting should be permanent as long as the user doesn't revoke it. ... The advantage is, that a webpage has no access to any data store, that is available for a browser AddOn. ... So there shouldn't be a security problem with file:// URLs. On the other hand, there is a high chance, that the web-extension API for file:// URLs will be crippled. ... I don't hope so, but "We will see" :) -mario -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/18a467e4-73f2-48d3-872e-f8b8f2146325n%40googlegroups.com.
