On Sunday, March 12, 2017 at 7:01:50 AM UTC-7, @TiddlyTweeter wrote: > > The fallback behaviour of save(1) save(2) is not viable, IMO, for most > folk. >
First... a bit of history to provide a bit of perspective on how we came to be here... Many years ago, browsers permitted "privileged file I/O" operations from Javascript simply by making a call to "request permissions". This would display a dialog box that would ask the user to allow direct file I/O. Once permitted, that choice could be remembered, so that further saving would happen without showing the dialog again. This enabled seamless manual saving (via "save changes" menu item) and autosaving while editing (after a set number of keystrokes) as well as autosaving on a timed basis. Unfortunately, this method of gaining permission for file I/O was prone to some hacking. There were ways of spoofing the dialog... for example, by having it appear off-screen and showing an alternative on-screen message box with a simple OK button to trick the user into giving permission to access the file system without realizing it. In addition, once permission was granted, access to the file system was *unrestricted*. You could navigate to ANY folder, programmatically, and read/write the directory and file contents at will from within TiddlyWiki. Of course, this presented a HUGE security hole, since tiddlers containing embedded inline javascript could be easily copied from remote sources and, if permission to access the file system had *ever* been granted, then file I/O could occur silently, without requiring any user interaction or even awareness that file I/O was taking place. Of course, TiddlyWiki also benefited immensely from this ability, as it allowed the kind of smooth, "just save it" behavior that most people have come to expect from an application, as well as the ability to provide plugins to provide more sophisticated file-related interactions, such as Import, Export, and SaveAs and automatic backup strategies that used timestamps in filenames to preserve previous revisions on minute, hour, daily, and weekly basis. Inevitably, however, the browser makers came to the conclusion that file I/O was too dangerous to be allowed directly from insecure Javascript, and they attempted to limit the impact by restricting file I/O to "the current working folder and below" and then gradually phased out and then completely removed support for access to "privileged I/O functions" except when they are defined as part of curated browser-based addon code that must be explicitly installed on each platform and instance of the browser that you intend to use with TiddlyWiki... and thus, gave rise to clever bits of code like TiddlyFox and TiddlyDesktop. When Jeremy began work on TiddlyWiki5, one of the major advances in architecture that he innovated is the use of FileSaver modules. This allows a much more consistent internal API for TiddlyWiki to work in a variety of environments and configurations, including stand-alone files, locally-served folders (via nodejs), remotely-hosted stand-alone files (via upload to store.php... e.g., TiddlySpot.com), and full server-side hosting. Independent of these core-included abilities, other people in the TW community have created FileSaver modules for using various databases (either locally-hosted or remote). There's also browser-based LocalStorage I/O... which uses a "sandboxed" private file space that is allocated within the browser's local cache, without exposing the rest of the file system. Regrettably, all of these solutions, regardless of their benefits also have their peculiarities and drawbacks, including platform, environment, and browser-specific limitations as well as various multi-step installation/configuration issues. Currently, there is only ONE file I/O method included in the TW5 core code that can be considered to have ANY chance of being "universal"... and that is the so-called "fallback download saver" method. Every browser that permits downloading a file provides some kind of secure, interactive process to allow the user to transfer files onto their local file system while reducing the risk of being struck by some kind of malicious exploit. So... this leads to back to your statement that I quoted above: > The fallback behaviour of save(1) save(2) is not viable, IMO, for most > folk. To which I respond: I respectfully disagree... and here's why: First, the "download a file" behavior is already familiar to nearly all users. Sure, there are some system-specific differences between the various browsers and platforms, but for the most part, they all work nearly the same way when a download is initiated. For example, some browsers will immediately ask for a 'destination folder' for the download, but others are configured by default to simply place downloaded content into a "Downloads" folder, without asking the user. Most browsers allow the user to change this setting so that downloads will always request a destination folder. IMO, the effort to change this setting is MUCH less than that required to install and configure a browser-specific addon. Second, once the browser has been configured to ask for a location, the automatic "collision handling" of save(1), save(2), etc. can actually be a HUGE benefit to TiddlyWiki's "edit-save-reload" workflow cycle. For example, consider the following workflow scenario (that I actually use myself) 1) go to a folder on my desktop that contains "index.html" and open it to start working 2) make some changes that you want to keep and press "save changes" 3) browser download dialog appears. If needed, navigate to the "current working folder" (the one containing index.html) 4) the default suggested filename should be something like "index (1).html" 5) press save and resume working on the current document without reloading 6) repeat as desired, creating incremental "checkpoint" saves "index (2).html", "index (3).html", etc. Then... suppose that as you continue to work, you realize that you "messed something up", and can't figure out what broke. So, you go back to the folder on your desktop, and open the most recent "checkpoint" save and see if the problem existed in the previous revision. If it did, then you keep working backwards, until the bug disappears. Then, you can carefully compare the two revisions to determine exactly what changed, and hopefully find the error quickly. This "checkpoint" revision methodology also lends itself to making small experimental changes without immediately committing those changes by always overwriting the base "index.html". This is especially useful if the changes require a reload of the TiddlyWiki to be tested. After saving to index(1).html, just load that saved file in another browser tab or window.. If it fails to load, or otherwise has some bad bug that make it inoperable, you still have the current index.html loaded in the first tab, so you can go back and fix things there. 7) if you are satisfied that all changes are good, save again (from either tab)... and select the base "index.html" file as the destination 8) when the system asks, confirm "replace this file" (or "allow overwrite".. .or whatever the wording is) 9) continue working (with or without reloading) 10) finally, when you are completely finished with your work session, you can go back to the folder on your desktop and delete all the checkpoint files, leaving just the final updated base "index.html"... just as you would expect. Personally, I quite like the 'safety' provided by the automatic addition of "(n)" to the filenames. It ensure that I don't accidentally overwrite the base file without a deliberate decision that I am ready to make my changes permanent. It also makes hunting for bugs easier since I can use external tools (e.g., "diff") to compare the saved files and quickly find all the differences. One last interesting scenario.... sometimes, especially when researching the answer to a question posted online, I will open http://tiddlywiki.com/empty.html, and start creating a few test/example tiddlers from scratch. Once I have a good working example, I can just use "save changes" to trigger the usual download saver, which provides *exactly* the same local file saving experience to me, regardless of whether I am working online or locally. In conclusion: While solutions like TiddlyFox and TiddlyDesktop do provide a 'smoother' process for local file saving and we should clearly continue efforts to implement a wide variety of FileSaver modules and other file-saving solutions, the "fallback download saver" process is actually quite useful and remarkably consistent and reliable across nearly all platforms and does not require ANY extra steps to install/configure, making it the likely experience for most 'novice' TiddlyWiki users. IMO, the best strategy for assisting novice users with the file saving experience is to first help them to understand the default download saving process while also introducing them to the more advanced solutions provided by various plugins, addons, and external apps. your thoughts? -e Eric Shulman TiddlyTools: "Small Tools for Big Ideas" (tm) InsideTiddlyWiki: The Missing Manuals -- 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 post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/tiddlywiki. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/fcc8a4bc-b0e4-4dc0-afe7-9ebd6cdb8236%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
