On Sunday, August 2, 2015 at 5:57:30 AM UTC-7, Anton Aylward wrote: > > "Bloat" doesn't always mean "size", sometimes it means "unwarranted > complexity and distraction". >
Your use of the word "unwarranted" is... ummm... unwarranted. This word generally means "not justified". However, in the case of TiddlyWiki file I/O, the "complexity and distraction" is virtually unavoidable because TiddlyWiki can only invoke functionality that is provided by the browser in which it is running. Modern browsers go to great lengths to ensure that they do not permit web pages to invoke *direct* file I/O operations, which would be a major security hole. Of course, all browsers do have the ability to do their own file I/O (i.e., download and save a file, read/write local cache, update config files, etc.). However, the only way a web page can access these internal file functions is by writing a browser-specific privileged add-on along with some custom scripting in the web page to invoke the add-on's functionality. This is what TiddlyFox and TiddlyChrome do. TiddlyWiki does the best it can within a restrictive browser environment. By default, without any add-on/plugin additions, it uses the browser's "download and save" handling to save a file. This works across nearly all browsers. In an ideal world, there would be one universal local file I/O solution that works for all browsers... but this is simply not the case. Note that HTML5 *does* have a "FileWriter" API, but it only writes to a "sandbox" area that the browser manages and the files in the "sandbox" are NOT really local files at all, they are merely data blobs managed by the browser. Further, the sandboxed files are tied to that specific browser. In this sense, they are more like giant cookies than actual files. But the real kicker is the number of different browsers that might be > used. Well, Ok a couple are for testing to make sure things always look > acceptable. > But having to replicate the likes of this for half a dozen or more > browsers ... things get complicated. > It gets complicated for support as well if some ancillary file needs to be > on the portable device, or -shock/horror - at a particular location on the > portable device. Not all <strike>salesmen</strike> end users are > technically sophisticated enough to manage that. The complication is somewhat intentional on the part of the browser makers. If working around their restrictions on file I/O was easy, it would defeat the purpose of restricting file I/O in the first place. Requiring installation of browser-specifc add-on code ensures that each user (or IT support person) makes a conscious choice to bypass these security measures. -e -- 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 http://groups.google.com/group/tiddlywiki. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/a284dcb3-9db2-47ee-bf72-f96d9a922fdf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
