alt. local storage backends in TiddlyWiki5?
Eric Drechsel
documents writing to the filesystem?
I hope the new generation of TW clientsides will support loading/
saving Tiddlers in multiple local backends (LocalStorage, Flash..).
See [1] for a wrapper around different local keystores. Perhaps just
serialize the contents of a tiddler container, using a unique key for
each document (embedded in the TW.html file?).
[1] http://plugins.jquery.com/project/jStore
Has anyone had success in implementing this in the original TW without
breaking most plugins?
Jeremy Ruston
> documents writing to the filesystem?
As with the classic TiddlyWiki, it will be possible for a plugin to
override the file saving code so as to target some other way of
persisting content.
> I hope the new generation of TW clientsides will support loading/
> saving Tiddlers in multiple local backends (LocalStorage, Flash..).
> See [1] for a wrapper around different local keystores.
I'm interested in the scenario of using HTML 5 Client-side Database
Storage API as a temporary cache for storing modified content prior to
syncing it back to a server.
I've also thought about using the the Database Storage API as the
"working store" of tiddlers (ie, the implementation of the "store"
object in classic TiddlyWiki).
Generally, all these technologies take the form of a client-side
accessible data cache. My conceptual problem with using them for
tiddler storage is that the modified tiddlers end up being stored in a
somewhat ephemeral way, living in the browser, and the user loses the
usual TiddlyWiki comfort of being able to reach out and inspect their
data at any time. However, there are clearly some interesting
situations (like Safari on the iPhone) where these are the only
available techniques for persistent storage.
Cheers
Jeremy
> Perhaps just
> serialize the contents of a tiddler container, using a unique key for
> each document (embedded in the TW.html file?).
>
> [1] http://plugins.jquery.com/project/jStore
>
> Has anyone had success in implementing this in the original TW without
> breaking most plugins?
>
> --
> 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.
>
>
--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com
Paul Downey
>> How does TiddlyWiki5 support newer browsers which don't allow local
>> documents writing to the filesystem?
>
> As with the classic TiddlyWiki, it will be possible for a plugin to
> override the file saving code so as to target some other way of
> persisting content.
I'm hoping that "following the microkernel approach" means it will be
possible to cook a TiddlyWiki which doesn't include the local
filesystem saving, rather than having to add code to 'override'
redundant core code, as at present.
> Generally, all these technologies take the form of a client-side
> accessible data cache. My conceptual problem with using them for
> tiddler storage is that the modified tiddlers end up being stored in a
> somewhat ephemeral way, living in the browser, and the user loses the
> usual TiddlyWiki comfort of being able to reach out and inspect their
> data at any time. However, there are clearly some interesting
> situations (like Safari on the iPhone) where these are the only
> available techniques for persistent storage.
That's true, but that might change, and Eric's point that we should
embrace HTML 5 techniques as they become available is a good one. For
example the W3C File API currently has no provision to save files
locally, but may be extended to in the future.
--
Paul (psd)
http://blog.whatfettle.com
Jeremy Ruston
> possible to cook a TiddlyWiki which doesn't include the local
> filesystem saving, rather than having to add code to 'override'
> redundant core code, as at present.
Yup, that's correct.
With reference to the microkernelness, there's some trade-offs to be
explored. The current code splits up the core into multiple distinct
plugins, and so allows that kind of substitution of plugins, but we
may want to save a few KBs by collapsing them into a single plugin for
ordinary use.
Cheers
Jeremy
FND
In that case, registering a new "driver" should be easy. (Obviously,
such drivers still have to be written. I second what's been said so far,
but share Jeremy's concerns about browser-specific storage.)
> With reference to the microkernelness, there's some trade-offs to be
> explored. [...] we may want to save a few KBs by collapsing them into
> a single plugin for ordinary use.
Generally speaking, if we're /really/ worried about filesize, I believe
we should pursue non-invasive approaches like minification before
sacrificing modularity.
-- F.