Right. The more we simply connect to real TW the better IMO.
Shirley, that is the point? 
TT
1 Like
Erm. Not so sure.
What can I say? I’d guess whichever method could be done it is always best to easily invoke a live TW. Otherwise why do it? Something like that.
Best, TT
I wanted to follow up on this. The whole “card” thing.
FYI @joshuafontany wrote an experimental plugin that hasn’t had the attention it deserves for TW “Oembeds” https://github.com/joshuafontany/TW5-Oembed. Unfortunately the demo doesn’t seem to be working ATM.
Best, TT
This is just thinking out loud. The recipes are apparently written in a Onebox “Gem” in Ruby (on Rails). Presuming that a headless browser driver exists for Ruby, then it might be able to fetch and parse the actual contents of an address to a single tiddler and set up a more responsive “card”. This would make setting up cards much easier because rather than using a special description field, there could be a default fall back that takes the first 100 characters or so of a tiddler as description.
Just throwing this out there in case there are any bored Ruby programmers hanging around.
1 Like
This is for embedding other things in TW, not the other way around.
2 Likes
Although the Other thing we embed in TW could be from a tiddlywiki !
- If we can make tiddlywiki objects Oembeddable in other sites or wikis, ideally also through and then interrogate them within tiddlywiki it would provide a form of interwiki communication.
- Tiddlers in wikis, static tiddlers or seperate .tid or .json files could be embeded?
- Sometimes only a few bytes are needed to make a big difference.
2 Likes
I remember @telumire invented an smart solution to use Tiddlywiki lively in a Talk post!
I could not find the thread!
Thanks for keeping this thread alive!
My point in the OP was that there is a “distance” (visually) between Discourse and TW.
I simply think TW would do better if we could integrate a “TW Look” into Discourse.
I did suggest that rather than having links to TW-wikis we embed them. BUT there was concern on it being too much—that it would cause problems on bandwidth & performance here. So I, basically agreeing, abandoned that idea.
However, I still think we could maybe do more to "narrow the gap between talking about TW & using it??" And visual appearance is a big part of that.
I hope this is clear!
TT
Thanks for the mention ! I believe that you are talking about this post : Intended feature or potential security issue ? How to embed an iframe in talk.tiddlywiki
I agree that it would be amazing to have talk.tiddlywiki support tiddlywiki files natively ! Maybe it could allow embedding of html files, in a similar way that codepen does ?
A tiddlywiki theme for discourse could also be good but I’m not sure if the features of this forum are similar enough to tiddlywiki to allow that (sidebar, tags, …?)
1 Like
It would do that easily. I shown that already. The issue is that there was concern on bandwidth & performance. That it would create problems for some users.
That iframes here on Discourse could cause problems.
That is why I did not push it further. But basic iframing looked well viable to me and easy.
TT
Right. It would be a Second Best. A “Cut Down” version! But maybe still useful?
But I am glad, @telumire, you really get the point of the OP!
Best, TT
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.
I thought you comments interesting.
I still believe that having a Discourse that can incorporate the look and feel of TW would help a lot.
As a second-best I did look at how to get control of the CSS for our Discourse. It is a bit beyond my skill level to actually do it.
What I can see is that it would definitely be possible to …
1 - write posts in a TW; (as normal)
2 - that can be directly posted to Discourse; (via a TW poster macro)
3 - that, in theory, on landing on Discourse, could be laid-out exactly the same as their origin in TW; (needs Discourse end CSS changes).
Just a comment, TT
800mb wow, envy on my part…
I upped my data from 2GB/mo to 4 a month ago. But then I am using a Mexican plan, roaming in the US, and using Google Maps constantly on the road…
1 Like
That’s 800mb total for the year! And, mb, not gb .
This is really handy for things like pointing out outdated tiddlers in documentation, explaining what text bodies mean, and helping newer users locate information.
Could this also be used with the static.tiddlywiki versions? I’d imagine so- ooo it would be cool to see what could be done with tiddlyhost as well.
2 Likes
Yes. Certainly embedding static pages would work and I think, not be so much of a problem for lower bandwidth users or those where full TW embed is not performative or costly?
An example of static embed …
<- Click to see ''Introduction To Filter Notation'' ...
This is the static version ... Introduction to filter notation
[UPDATE: One of the good things with the static TW is you can still click around; i.e. you click a link and it loads that item as a static page within the same iframe. That behaviour is very close to what I envisioned in the OP.]
[UPDATE Update: Though there are some items that aren’t rendered statically. Links to those give a 404. Nonetheless it is pretty useable on most linkage.]
I do think some of the ideas in this thread are worth pursuing into some kind of consensus & action.
Thoughts, TT
This is where I think an alternate template for generating static tiddlers would make all the links therein open the parent wiki.
I did create it here How to export static tiddlers who’s internal links will open the master wiki
2 Likes
Right. And that approach would match the OP I think on iframes?; i.e we’d iframe a static page for low overhead in a discussion group; but if a reader wanted to go further they would load TW Mother, knowing so.
Best, TT
1 Like