Thank you Eric for taking the time to thoughtfully lay out the detailed history. I really appreciate it.
By way of reply I'd like to divide between two things. Its just a way of talking, though perhaps brings a bit from a slightly different perspective. Two broad points ... 1 - INNOCENT LANDING. 2 - PEOPLE WHO SHOULD BE WISER ALREADY I'd like to start with (2). BACKUP is essential whatever you are doing. Depending of your level of paranoia / experience of PAST oversight. This is not really a TW issue. WHY? Because its a sensible empirical convention that you can't rely on one system to protect you. And browsers are very prone to fuck-ups. EXTERNAL backup is pretty reliable. Personally I do automated redundant backups whenever a TW file is changed. To say again, this is NOT a TW issue. * It's a basic attitude. The need for EXTERNAL backup*. *BUT: your approach seems to FOG that up with native saving.* SO I question the added value of YOUR scenario: which is, basically, a via-browser backup system. *I'd RATHER talk about EXTERNAL BACKUP on that rather than what reads like a series of complex EXTRA steps.* On (1). Idiots like me arrive everyday. Used to conventions on saving on a click. I think this is maybe my big point. Its an entirely different one than (2). On this issue it seems that "we" may need to "educate" "them"? My question on this is this is simply whether its a viable approach to even entertain file save? Jeremy in his note #2 in the starting post seems to incline to on-line services as the easiest way forward for "the masses". I'm convinced I'm slightly incoherent on all this. Lets stab in the dark together. Best wishes Josiah On Monday, 13 March 2017 21:46:18 UTC+1, Eric Shulman wrote: > > 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/a5ef5ee4-11bb-459d-b570-b11c1144b7d7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
