A lot of water went under the bridge on this topic, I just reread the whole thing. There are plenty of great ideas and examples and many are 90% towards some useful outcomes.
- Let us see if we can cross the “last mile” on this.
With tiddlywiki.com not undergoing too many changes every day surely more often than not peoples browsers load it from the browser cache?
- If not I think we can set some values in the html headers to keep a single file wiki in the browser cache longer
Also as I suggested earlier Static tiddlers could
- Have open graph or rich card code within them
- Rather than simply link to other static tiddlers link back to the “mother wiki”, so any attempt at interacting loads the mother wiki
- Allow iframing that specific static tiddler
As I understand is depending on how it is implemented the embed process queries the content at the end of the link when you attempt to view that link, so it only does so when you need to see that content. Some forums do it once and save the result of retrieving the card in their database.
The aforementioned data share method, demands a plugin to be installed on the host wiki, at present it is left to us to provision this, wiki.
- Surely we should publish an empty + share plugin under tiddlywik.com that we all use to publish stand alone data tiddlers. Lets call this the “data share wiki”.
- At the same time we should provide the tools to create or import a tiddler onto the “data share wiki” from which we extract the data url to paste into discourse.
- As soon as this is in place and regularly used most users will have this smaller “data share wiki” in their browser cache.
Performance, whilst for some would be an issue if you decide to load discourse and browse content then you are tacitly deciding to use bandwidth to read content. Even tiddlywiki.com is smaller than many images or audio out there.
