Hi Yakov > I'll start with TiddlyFox since it is still used by many users (with either > FireFox 56- or Pale Moon, WaterFox and other FF forks). One thing about it is > building the xpi: I've read about building it a little and the crucial > quesion is: is it still possible to create signed xpi, or updating TiddlyFox > is impossible in principle?
Mozilla was responsible for signing the extension as part of the process of uploading it; I don’t think there’s ever been a way for anyone else to sign it and have it accepted by recent versions of Firefox. But I don’t know much about it, it may be worth asking on the Mozilla dev mailing lists. > If it's not, I'd only like to ask Jeremy to add 2.x tags to the repo and > attach xpi files to the github releases; or add me to the repo and I'll do > that myself. Otherwise, I'd like to contribute a bit more and have some more > questions. No problem with adding you to the repo. > Next and the main point of this thread is: both TWC and TW5 have many > supporting solutions (native apps, servers, browser plugins etc) for saving > but I'm not aware of docs that describe how actually one supports saving (and > may be more functionality) of both TWC and TW5. For instance, > MainTiddlyServer <https://yakovl.github.io/MainTiddlyServer/> could be > extended a bit so that it fits the php server gap > <https://github.com/TiddlyWiki/php-server>, but I (as a developer of TWC > extensions, MTS and maintainer of the core) am not really aware of how to > support TW5 correctly; likewise, the aTW <https://github.com/TiddlyWiki/aTW> > saver for Android supports only TW5 (as far as I know), but I'd like to > participate and support TWC as well, yet I still didn't even get an answer > <https://github.com/TiddlyWiki/aTW/issues/1#issuecomment-459076550> about the > app status (and I suspect Simon may be reluctant to support TWC without nice > docs describing that). Finally, it seems every time one tries to support > saving in their software, they invent some new implementation which (this > diversity) is difficult to follow and the ecosystem is quite difficult to > maintain. TW5 supports saving in two completely different ways: saving the entire HTML file versus syncing individual tiddlers to a server. Syncing is the easier to explain of the two: TWC has plugins that let it sync changes to TiddlyWeb, a venerable Python-based TiddlyWiki serverside we developed at Osmosoft. I’ve not tested it recently, but those plugins should also enable TWC to save back to a TW5 server. In TW5, saving is modular: there are eleven built into the core: andtidwiki - for saving within the AndTidWiki Android app beaker - for saving within Beaker Browser download - for the fallback HTML5 compatible download saver fsosaver - for the Internet Explorer ActiveX saver manualdownload - a version of the download saver for older browsers that don’t support the necessary HTML5 features msdownload - a version of the download saver for older Microsoft browsers put - for saving to WebDav servers tiddlyfox - for saving under TiddlyFox tiddlyie - for saving to the Internet Explorer TiddlyIE extension twedit - for saving within TWEdit, an old iPad/iPhone app for TiddlyWiki upload - for saving to TiddlySpot, or a PHP server running the upload script The TiddlyFox saver talks to TiddlyFox via a hidden DIV and custom events. TiddlyFox itself has different handling for TW5 and TWC. For TW5, it uses the hidden DIV and custom events, and things are reasonably elegant. For TWC, TiddlyFox has to inject overrides to the saving functions which then set up the hidden DIV and handle the custom events. > Thus, it seems to me that we really need 2 things: > nice docs describing how to support saving of TWC, TW5 (and, in perpective, > more features like image uploading and more) > core libraries in different languages (js for browser plugins? js for node, > PHP, Java/Android, Swift/iOS, may be more) which one can use for developing > new solutions Do you mean docs for writing an app for handling saving of TiddlyWikis? Or for building a serverside for TiddlyWikis? Or do you mean docs for how the saving mechanisms work? > Now this thread is mostly about the first part, the docs (and by the way > saving is not the only thing which would be nice to document; think, for > example, of the .tid format which is not described anywhere, at least Jeremy > wrote so some months ago). > I think we are indeed missing docs for the .tid file format, but probably only because it’s so basic. Are you running into a problem with it? > My proposal consists of 2 parts: > > create a repo in the TiddlyWiki <https://github.com/TiddlyWiki/> org @github > (I'd like to be a member to contribute) > start building docs > For the second part, I now have a draft based on what I've learned from the > TiddlyFox sources, see it below the main post. I invite you to comment it, > correct where I'm wrong, fill the gaps, especially about TW5. > Good stuff. I think you’ve captured the behaviour of the TiddlyFox plugin. I’ve added comments to your questions. > This surely can give false positives which seems to be ok; this also doesn't > support "pure store" format. > I do remember the “pure store” format being discussed, but don’t recall the details. If it reduces the HTML file to the storeArea, then the heuristics above should work. > MainTiddlyServer injects JS bits into the TWC code before serving it and > strips those back when saves "the whole thing" (it can also send save > increments); some modifications (like support of incremental saving) are made > as hijacks which are done in loadPlugins > <https://github.com/YakovL/MainTiddlyServer/blob/master/index.php#L467> so > that the store is ready > server-side implementations (that inject JS into TW so that user doesn't have > to install a plugin into TW) also need to decide where to inject JS, see next > section I’m not familiar with the details of MTS, but it sounds like these modifications would be done on the HTML file, rather than in the DOM. Somewhat different techniques need to be used in those situations. > not sure whether TiddlyFox adds JS on load or eariler (probably the latter) I think that the code gets injected after the page has loaded: https://github.com/TiddlyWiki/TiddlyFox/blob/master/index.js#L30 <https://github.com/TiddlyWiki/TiddlyFox/blob/master/index.js#L30> > neither I am sure of the exact moment tiddly-node-saver uses > <https://github.com/fallwest/tiddly-node-saver/blob/master/server.js#L27> > although the approach looks interesting > same for TiddlyDesktop overwriting > <https://github.com/Jermolene/TiddlyDesktop/blob/ffd0c7be4d4220a67211e3b18ece208d11d305e4/source/js/utils/saving.js#L19> TiddlyDesktop just implements the TiddlyFox protocol of the hidden DIV and the custom events. > As for TW5, I'm not really sure about the exact stack, but it seems for > saving, a handler of the "tiddlywiki-save-file" custom event should be added. > The handler should expect the "event" (first argument) to have .path and > .content properties which should hold (local?) path to the file to save and > (UTF-8?) content string of the file. Not sure if some sort of > "file-save-success" event is supported to notify the core that the file was > actually saved (and TiddlyFox actually has a bug to always report that TW was > saved, even if it was on a USB storage which was removed before saving, > because the injected saver always returns true > <https://github.com/TiddlyWiki/TiddlyFox/blob/eb4c0d9822cf8beffe27a7cacb3b00c2d18e3771/data/inject.js#L26>). > As discussed above, TW5 has pluggable save handlers so the two approaches to implementing saving are to either re-use one of the existing core savers (e.g. as does TiddlyDesktop) or to add a brand new saver module (e.g. as we do for Beaker Browser). Best wishes Jeremy > > Further considerations > > There's a number of topics that should be covered as well, mostly after those > above are, but some of them will affect architecture and hence should be > considered anyway (can affect the core, especially in case of TWC; I'm ready > to adapt it to better architecture): > > sync vs async saving > full saving vs sending changes, shortcuts for backuping (sending full file to > backup vs sending "copy file A into B" message) > protocol layer (shouldn't necessarily be uniform, but recommendations can > facilitate development of new tools) > streaming changes via websockets and sync editing > security consideratinos > server logic (authorization & roles, ..) > federation (including content from other TWs, saving it back) > advanced features (image uploading, integration with git etc) > ==== > > Looks like that's all I've gathered for now. Again, contributions are very > much welcome. > > > -- > 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] > <mailto:[email protected]>. > To post to this group, send email to [email protected] > <mailto:[email protected]>. > Visit this group at https://groups.google.com/group/tiddlywikidev > <https://groups.google.com/group/tiddlywikidev>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/tiddlywikidev/e4526996-ad42-45fd-af38-caac660cc07c%40googlegroups.com > > <https://groups.google.com/d/msgid/tiddlywikidev/e4526996-ad42-45fd-af38-caac660cc07c%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- 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 https://groups.google.com/group/tiddlywikidev. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/6776ED8C-78AD-43F4-B31C-7F99BCD74759%40gmail.com. For more options, visit https://groups.google.com/d/optout.
