Experimental Standards-Compliant File Saving for TiddlyWiki
Jeremy Ruston
able to use standards-compliant browser techniques to accomplish file
saving.
The motivation is that we're already seeing browsers (finally)
tightening up some of the security loopholes that have historically
allowed TiddlyWiki to function. Establishing a standards-compliant way
of operating, even if it's a bit clunky, would go a long way to give
us all confidence that TiddlyWiki can continue to function properly in
the long term.
The first approach I've been looking at is that of assembling the new
TiddlyWiki file as a data: URI, and then simulating clicking on a link
to it in order to force the browser to download it. You can see the
code here put together into a simple demo of a sort of plain text
single tiddler TiddlyWiki.
https://github.com/Jermolene/FileSavingDemo
On Chrome, the experience isn't entirely terrible: one just edits
away, clicking 'save' every so often. Then, after the editing session,
one retrieves the most recently downloaded file from the 'downloads'
folder. On other browsers, it's a bit worse - both Safari and Firefix
give no control over the name of the downloaded file, so it doesn't
even have an '.html' extension.
I'm imagining a future version of TiddlyWiki that adds a technique
like this as a fallback for when the browser hacks don't work.
This approach does actually have a couple of nice features: notably,
that it is possible to save the file locally even if the page has been
loaded over http. So, one could imagine a service like
http:///getmytiddlywiki.com/ that presents itself as a sort of
tear-off pad: you'd make your initial edits while at that URI, and
then click 'save' to download a local copy of your changes.
I'm interested to know what people think about this approach, and of
course any suggestions or help with figuring out how to improve it on
different browsers,
Best wishes
Jeremy
--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com
Eric Shulman
> that it is possible to save the file locally even if the page has been
> loaded over http. So, one could imagine a service like
> http:///getmytiddlywiki.com/ that presents itself as a sort of
> tear-off pad: you'd make your initial edits while at that URI, and
> then click 'save' to download a local copy of your changes.
-e
Jeremy Ruston
Hi Eric,
I remember this plugin. I'm not sure if I'm reading the source right
but it looks like it uses a PHP server script to force the download;
is that right? Does it also work without the server script?
Eric Shulman
> but it looks like it uses a PHP server script to force the download;
> is that right? Does it also work without the server script?
sent, but adds some HTTP headers:
Pragma: private
Cache-control: private, must-revalidate
Content-type: application/binary; charset="UTF-8"
Content-disposition: attachment; filename="targetfilename.ext"
The "Content-disposition" header is the most important. It tells the
receiving browser to start the normal 'download-and-save' dialog, so
the user is prompted to save the file (and can change the location/
name) without triggering any local file I/O permission alerts.
-e
Yakov
I wonder if this new idea (and/or usage of Eric's plugin) means that
all (most of) the browsers will be able to save changes, even if they
don't have ActiveX, or XPCOM or access to JVE? I mean, in Opera Mobile
in Windows Mobile for instance [1]?
[1] There were some ideas and their "states" mentioned in
http://groups.google.com/group/tiddlywikidev/browse_thread/thread/8a626ff5be7b8846
Eric Shulman
> I've been doing some experiments to explore how TiddlyWiki might be
> able to use standards-compliant browser techniques to accomplish file
> saving.
> TiddlyWiki file as a data: URI, and then simulating clicking on a link
> to it in order to force the browser to download it.
to the use of the data: URL scheme. According to the RFC for the
data URI (see http://www.ietf.org/rfc/rfc2397)
-----
The "data:" URL scheme is only useful for short values. Note that
some applications that use URLs may impose a length limit; for
example, URLs embedded within <A> anchors in HTML have a length limit
determined by the SGML declaration for HTML [RFC1866]. The LITLEN
(1024) limits the number of characters which can appear in a single
attribute value literal, the ATTSPLEN (2100) limits the sum of all
lengths of all attribute value specifications which appear in a tag,
and the TAGLEN (2100) limits the overall length of a tag.
-----
and, Mozilla's Developer info says (see https://developer.mozilla.org/en/data_URIs)
-----
Although Mozilla supports data URIs of essentially unlimited length,
browsers are not required to support any particular maximum length of
data. For example, the Opera 11 browser limits data URIs to around
65000 characters.
-----
and:
-----
Note: as of Firefox 6, fragments (anchors) are processed consistent
with other URI schemes, thus a bare "#" in the content needs to be
escaped as '%23'.
-----
and:
-----
The data scheme is supported by Opera 7.20 and above, as well as
Safari and Konqueror. Internet Explorer 7 and below, however, do not
currently support it. Internet Explorer 8 and above only supports data
URIs for images in CSS.
*sigh*... so many complications....
-e
Jeremy Ruston
and Firefox working OK with 1.5MB of text (thanks Gutenberg), and so
suspect that in practice these browsers are relaxed about data: URI
sizes.
None of this works at all for IE, of course, with its 32KB limit,
which I think is enforced. Anyhow, for old versions of IE we're
probably OK with the existing ActiveX code. I need to do some
investigation with IE9 and IE10.
Cheers
Jeremy
> --
> You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
> To post to this group, send email to tiddly...@googlegroups.com.
> To unsubscribe from this group, send email to tiddlywikide...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/tiddlywikidev?hl=en.
VJ
> I've been doing some experiments to explore how TiddlyWiki might be
> able to use standards-compliant browser techniques to accomplish file
any way be considered a serious TW developer. But I did want to ask
whether there's been any thought about working on this problem from
the other end: trying to get browser development (Mozilla being
perhaps the most tractable?) to become conscious of TiddlyWiki and
other in-browser applications that rely on the ability to carry out
"insecure" actions.
It seems that the Microsoft model of providing "security" by simply
prohibiting the user from interacting with the computer except in
specific pre-determined ways is being somewhat broadly embraced. I
would hate to see the major browsers lock down so tightly that even
existing innovative technologies like TW are excluded, to say nothing
of limiting the possibilities for future development. It seems to me
that TiddlyWiki has some standing in the Web community and might be
able to influence the course of development in the direction of secure
models to ALLOW file saving rather than in a more prohibitive
direction.
Just my $0.02.
--Jon
rakugo
> I'm hesitant to stick my nose into this discussion, as I could not in
> any way be considered a serious TW developer. But I did want to ask
> whether there's been any thought about working on this problem from
> the other end: trying to get browser development (Mozilla being
> perhaps the most tractable?) to become conscious of TiddlyWiki and
> other in-browser applications that rely on the ability to carry out
> "insecure" actions.
http://www.w3.org/TR/file-writer-api/ - although I'm not sure what the
status of this is. It certainly hasn't appeared in any browser yet.
The complimentary FileReader api does exist and seems to tackle the
problems associated with importing from local files (see
http://groups.google.com/group/tiddlywiki/browse_thread/thread/8c593e956e9f48cb)
Poul
(can) trust the server with your content- if not, read on...how about
a dedicated web service for editing your (locally kept) documents.You
would go to, say, edit.tiddlywiki.com, upload your document and start
editing. When you're done, you'd click the download button and get it
back.If you needed to collaborative editing, you could have a
temporary URL assigned for the document, that you could share.If you
reject either of the preconditions, you'd of course have to install
the (open-source) server on your own PC.
Extra advantages: All the services (like wysiwyg editor, auto-save,
etc.) that a server could offer.The Google App Engine/SDK would be a
perfect basis for a platform-neutral implementation.Heck, the service
could even be ad-sponsored.
:-) Poul