Unify TiddlyWiki extension interface for file access

[Jermolene]

The single file configuration of TiddlyWiki cannot directly access files. In response to a request to save changes it just uses standard HTML5 features to download a fresh copy of the file. The new file will not overwrite the existing file without manual intervention.

A variety of extensions exist on different platforms to give TiddlyWiki the capability of accessing the file system directly:

• TiddlyFox, an extension for Firefox
• TiddlyDesktop, a desktop app for Windows/Linux/OS X
• TWEdit, an app for iOS
• TiddlySaver, a cross-platform Java applet

The goal is to unify these disparate extensions so that:

• Extensions have the same JavaScript programming interface. The interface should be designed to resemble existing HTML5 APIs, with a possible view to standardisation in the future
  • The extensions that tunnel the API through the DOM should do so in the same way
• Extensions handle whitelisting and/or blacklisting in the same way
• Extensions provide the same facilities for backup retention

[pmario]

I'd like to add:

• unify basic backup handling

[PVHL]

I'll add some notes on TiddlySaver soon, but am wondering: HTML5 file APIs are currently asynchronous (there is a synchronous definition but current browsers don't implement it). TiddlySaver is currently inherently synchronous as is the TWC code. Should we imagine a future for TiddlySaver (in terms of whitelisting) that has both a synchronous and an asynchronous version? (That is: separate TWC and TW5 versions.) If so we can leave things much as they are for a TWC TiddlySaver version except for adding a whitelist feature.

[Jermolene]

The new JavaScript APIs should be async. We'll need to use several techniques to work with the existing synchronous TWC API:

• TiddlyFox handles loadFile() synchronously using the synchronous option of XMLHttpRequest; safeFile() is handled asynchronously, which means that TWC never sees the callback. But that works OK because TiddlyFox provides a UI if there is an error during saving
• TiddlySaver could also handle loadFile() with XMLHttpRequest, or it could keep around a synchronous interface for backwards compatibility.

To answer your implied question, as to whether we're talking about a refactoring of the existing TiddlySaver code, or a completely new beast: I'd really like to retain compatbility with TWC.

[PVHL]

If I'm reading you correctly TiddlyFox will change to an async loadFile() for the future HTML5-like API and keep a sync interface for backward compatibility, and TiddlySaver should do the same.

I've only been able to get local XMLHttpRequest file loading working with Firefox; the others restrict local file loading according to everything I've read and tried (though I just found something I'll try out some time). I imagine FF will restrict access at some point too, though this won't affect TiddlyFox's elevated privileges. (I don't see the need to implement XMLHttpRequest in Java if that's what you meant; the current methods could be implemented both ways, I think.)

[Jermolene]

If I'm reading you correctly TiddlyFox will change to an async loadFile() for the future HTML5-like API and keep a sync interface for backward compatibility, and TiddlySaver should do the same.

Unlike TWC, TW5 doesn't need to load the file before saving it; TW5 can generate the entire source file (it's a true quine!). So the new interface can focus on saving (and handling backups etc).

So, it probably makes sense to just keep the loadFile() call in TiddlySaver for TWC.

[PVHL]

Thanks Jeremy -- I had to remind myself what a quine was (I so miss university days!). Once again I look forward to getting a chance to go through the code for TW5.