Architecture flaws of TWc that were "fixed" in TW5

65 views
Skip to first unread message

Yakov

unread,
May 4, 2016, 7:56:54 AM5/4/16
to TiddlyWikiDev
Hello everyone,

recently I've looked through some unread posts here and found this interesting comment by Eric [1]:

Unfortunately, the TWC codebase relies upon older web tech, several aspects of which have changed over the years.  Most notably, handling for local file I/O and cross-origin resource sharing (CORS) have been severely restricted or eliminated.  In addition, TWC had some architectural limitations and performance issues due to the way it uses the DOM for *stateful* rendering.  TWC also has the potential for security exploits because it allows un-restricted injection of javascript code directly into tiddlers.

Can someone provide more details about this?

I understand file I/O and CORS issues, no need to explain this much (I personally am upgrading MicroTiddlyServer so that meanwhile I'll be able to do not only saving local and remote TWs [I'm still on TWc], but also make all the including/saveAs/upgrading/requesting RSS and other stuff using a server as a fallback, so this won't be that much of an issue in the future).

But what is stateful rendering? What alternatives are out there? (what is implemented in TW5?)

What's the idea in TW5 to fix those security issues? Strict separation of plugins (JavaScript-containing tiddlers) and content (no JavaScript, no ~macros that eval text)?

What other architectural limitations and performance issues are known?

Best regards,
Yakov.

[1] https://groups.google.com/d/msg/tiddlywikidev/TF6UyFR-xVA/NOEZgNQoCQAJ
Reply all
Reply to author
Forward
0 new messages