Hi,

I have recently come full circle, finding again TiddlyWiki, a technology I used intensively from 2005 to 2007 and I want to connect it with Fossil (which has become integral part of my workflow since 2011).

TiddlyWiki has Git saving support (see 1 and 2) and I wonder what needs to be done to have a similar experience but with the advantages of using Fossil. This is the scenario I imagine:

• The TiddlyWiki would be a single HTML file stored inside a Fossil repository and when you launch the Fossil UI and browse, let's say the trunk version of such file and hit save on it, a commit on the current branch would be done.

• A Tiddler is the minimal unit of information storage and functionality in TiddlyWiki. A Fossil configuration Tiddler would be the one saving the name and password of the current user in the repository (or the user can use Fossil's login UI). The important issue here is that TiddlyWiki user has a way to access commit functionality from its web interface by pressing save inside TiddlyWiki. A commit process is triggered in a similar way to Stephen's experiments on enabling Wiki editing and saving functionality.

• A single Fossil file repository containing the TiddlyWiki HTML file and its history could be launched (and even packaged) with a Fossil executable. This would provide an easy way to have a multiplatform portable wiki with saving, history and collaboration, that can be particularly useful in low/intermittent connectivity scenarios (that was what made me think of such combination), but also elsewhere, empowered by two simple and pretty self-contained and powerful tech stacks: Fossil and TiddlyWiki.

Where could I start such exploration? Any ideas, pointers, half prototypes, reading suggestions, are pretty appreciated.

Thanks,

The TiddlyWiki would be a single HTML file stored inside a Fossil repository and when you launch the Fossil UI and browse, let's say the trunk version of such file and hit save on it

That's effectively how the /fileedit page works. Hypothetically, of you set the project's home page to something like /fileedit?filename=tiddly.html&checkin=trunk, when you run fossil ui then you would land directly in the editor.

, a commit on the current branch would be done.

Noting that "current branch" means nothing without a checkout.

Where could I start such exploration? Any ideas, pointers, half prototypes, reading suggestions, are pretty appreciated.

It sounds like the above option would give you at least part of what you're looking for, with two very minor caveats:

First, you would also need to enable /fileedit by setting the (non-syncing) fileedit-glob setting:

fossil set fileedit-glob '*.html,...other wildcards'

Note that that setting, by design, does not sync to clones - it has to be explicitly set on any repository copy where it should be enabled. If that setting is empty, the /fileedit page does not work (and it only allows editing of files matching one of the given globs).

Secondly, /fileedit, for various reasons, explicitly does not permit adding a new file via the web interface. You would first need to commit an initial copy of the file into the repo before /fileedit can make use of it.

Hypothetically, of you set the project's home page to something like ... when you run fossil ui then you would land directly in the editor.

It turns out that that's not quite true. The default page when running in ui mode is the timeline, not the home page. In order to start at the tiddly page you'd need to do the following after configuring (via the /setup_config page) the home page as described in the post above this one:

fossil ui --page home

I had somehow missed /fileedit as a thing and thought we were only getting the new /wikiedit (which is great btw). /fileedit looks awesome/like it could be really useful. About to be away from my desk for a week for the first time in about 2 years and will be trying not to think about work-related stuff, but part of me will be wanting to get home and have a play with this feature :)

Back on topic, don't know anything about TiddlyWiki but just had a very quick look at savers to see what might be bodged together with copypasta/cribbing from /fileedit and noticed that 'empty.html' (the default TiddlyWiki file) seems to contain binary data, which causes /fileedit to bail - so am not sure how viable it might be.

If Offray can figure out what the binary elements are then there might be a workaround - and default-csp may also need editing so that TiddlyWiki is able to operate,. ..but that still wouldn't solve new files (which understandably can't be done from /fileedit) or other binary stuff (e.g. how are images/attachments managed in TW?). You could maybe make them attachments to a related wiki page in the fossil or something like that, but it seems like there could be multiple cans of worms to open if you want to use all of TW's features with Fossil and no third element (e.g. a browser plugin or online service that can talk to Fossil or have Fossil respond to activity in a given dir).

It would be worth having a look at how TiddlyDesktop works to get an idea of what sort of files/content would need to be supported.

I had somehow missed /fileedit as a thing and thought we were only getting the new /wikiedit...

The two are very similar in terms of UI and features. There was much re-use of ideas and code between the two.

and noticed that 'empty.html' (the default TiddlyWiki file) seems to contain binary data, which causes /fileedit to bail - so am not sure how viable it might be.

/fileedit specifically cannot edit binary data. It uses an HTML textarea for all editing. It has a hook which allows the client to replace the textarea with a custom widget, but it's an all-or-nothing replacement, not per file type, so any plug-in replacement would need to be suitable for all types of files the user might want to edit. The editor-replacement API "could" hypothetically be extended to support per-mimetype swapping-out of the editor, but binary, in particular mixed-mode binary/text would be an ugly hurdle.

You could maybe make them attachments to a related wiki page in the fossil or something like that, but it seems like there could be multiple cans of worms to open if you want to use all of TW's features with Fossil and no third element (e.g. a browser plugin or online service that can talk to Fossil or have Fossil respond to activity in a given dir).

Indeed, "cans of worms" sounds like an apt description. i underestimated Offray's needs as basically just wanting to edit an HTML file. If it's more advanced than that then fileedit may well not be a good starting point.

TidlyWiki is a SPA that uses javascript to make an html file into a fully editable/searchable/viewable wiki. Viewing the file as html with javascript turned on provides editing, viewing etc of all the 'tiddlers' (think wiki page) in the html file.

E.g. I used it many years ago as the manual for a class on the simple event correlator. The tiddlywiki had:

• all the class slide presentations (with the ability for the students to annotate the slides)
• a reference manual/textbook for the class (again students could add notes to the pages)
• exercises/quizzes for the class
• the ability to remotely sync from my master tiddlywiki to pick up errata before/during/after class

Using /fileedit for editing is not a good idea as the contents are encoded to make them safe to store in the html file without breaking the file.

However the save mechanism used by fileedit may be useful. Tiddlywiki could post itself to fossil to add a new version of itself.

Thanks John, I think that you expressed my original question intend better. I was wondering about the save mechanism behind fileedit as I want to use TiddyWiki UI for adding and editing the wiki, but being able to store it inside Fossil, triggering the same events that fileedit uses when you save on it, but using the save button provided by TiddlyWiki and I wonder if there could be any API that allows to send events to the Fossil backend from a Single Page Application stored inside Fossil.

LiteStore was also in the radar, but I think that I will follow Marcelo's reminder and start there, as it could provide me a better overview of what I want to do with Fossil and is particularly suited to package and store SPA's.

... but using the save button provided by TiddlyWiki and I wonder if there could be any API that allows to send events to the Fossil backend from a Single Page Application stored inside Fossil.

There's no "officially exposed" API for doing checkins. The fileedit page of course has one which it uses, but that API is intentionally not documented and is explicitly subject to change at any time for any reason on any day in any weather. The closest thing to a public API for that is the wiki JSON API, which is semantically a very close match but wiki saving is handled much differently (and simpler) than a checkin.

i would be "cautiously reluctant" to expose something like fileedit's checkin interface to the general-purpose JSON API. For one, that particular API is limited to checking in a single file (text only: JSON has no native/built-in way to deal with binary data), which makes it of very limited use outside of such an editor app. For another, it offers plenty of opportunities to shoot oneself in the foot, e.g. via case-difference-only mismatches of file names, causing new files with the same names but different cases to be added, or creating an arbitrary number of unintentional forks (noting that there is no web interface for merging - that has to be done via the CLI).

That's not to flat-out rule out that as an eventual option, but my highest TODO priority in fossil is (still) to ajaxify the forum, but life is keeping me busy enough that i cannot yet dive head-first into that.

I understand your reluctancy and there is no rush ATM for such feature, as I will start my explorations with LiteStore and that could give me a better picture of what would be needed in Fossil (or I could use Nim to create some hooks between LiteStore and Fossil).

Just out of curiosity, I wonder how Git based storage mechanisms for TiddlyWiki are exposing their commit functionality to the SPA application to made it one click available from a web form...

Anyway I'll come back on this topic once my LiteStore + TiddlyWiki advances are more mature.

Thanks,

Shooting from the hip here: maybe LiteStore (based on SQLite) could be of help?

BTW, fossil treads tiddlywiki html as binary for me. Any way to force text?

Any way to force text?

Nope. IIRC, the determination of whether it's binary-ish is largely based on how long the lines are. Since diffs of files with extraordinarily long lines are essentially unreadable, such files are effectively binary for purposes of fossil's UI.