Hi Jeremy, My current plugin version is here for the moment: >> https://github.com/andreasabeck/TW5-syncIndexedDb >> > > Great. I noticed one small thing - there seems to be two copies of the > plugin, one in a tiddlywiki/syncIndexedDb subdirectory. >
Sorry, didn't notice that, I guess my IDE messed that up a bit. I am working on a forked repository now which is available here: https://github.com/andreasabeck/TiddlyWiki5-syncIndexedDb > For the pull request I'd put everything in >> plugins/tiddlywiki/syncIndexedDb - right? >> > > I think for consistency we'd call the > plugin "plugins/tiddlywiki/indexed-db" or "plugins/tiddlywiki/indexeddb". > We'd also need a demo edition, along the lines of the other core plugins. > Changed it to "indexeddb", the output of a demo edition (indexeddbdemo) is uploaded here, still need to improve the layout a bit: http://tw5-dev.cibm.de/ > I had two suggestions, which you may well have thought of too. > > Firstly, I wondered about hashing the URL of the TiddlyWiki file into the > database name, to make it easier to work with multiple file:// wikis at > once. Perhaps we'd need some clever trick to cope with files being renamed > or moved. > Absolutely, I already thought about that as well. I would go for adding different object stores, which is the layer just below database, because there currently doesn't seem to be a standard way to enumerate databases, whereas there is one to enumerate object stores within a database. I think we could also build one additional object store which acts like a catalogue, meaning it lists all the hashes and filenames etc. So to cope with renaming the not-so-clever way could be to ask the user to pick the right hash by displaying a list of the previous URLs in a config tiddler, so we can move the DB to the new hash. Well, I'd prefer something more clever, but the problem is we would need to keep some information within the html file and we can't rely on that in my opinion. Perhaps an option would be to hash the whole DOM or something like that, but that wouldn't work well when starting from the same files, as they would produce the same hash and wouldn't be changed as everything is synced to IndexedDB. What's your opinion on that? I think in any case we would need the not-so-clever approach as a robust alternative to whatever could be a clever trick. > Secondly, I wondered whether at startup the plugin might delete any > tiddlers in the indexedDB store that precisely match tiddlers that were > loaded from the HTML file at startup. That way, during repeated saves and > reloads we'd avoid building up unneeded tiddlers in the indexedDB database. > I didn't think about that yet. IndexedDB is supposed to be able to hold a huge amount of objects, on the other hand there are quotas, which are unfortunately inconsistent across the different browser. I liked the idea to take an empty file and have all my tiddlers displayed back from indexedDB. On the other hand you are right, if we have them already in a backup-file, which we open, there is no need to store them in indexedDB any longer. So indexedDB would serve as an intermediary storage and the manual backups would be the durable storage. I would have to dig through some core code I guess, cause I did just pay attention to syncer.js and the plugin system so far, if you had a hint where to start to get a list of all tiddlers from the file I'd appreciate that. Would be to bad if I deleted the wrong tiddlers ;-) Cheers Andreas -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" 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/tiddlywikidev. For more options, visit https://groups.google.com/d/optout.
