I do understand that post-apocalypse iframes got segregated and treated as suspicious characters.
What is my point? It is a great shame we currently (as far as I can see) can’t embed iframes of target TW here, right, in the Discourse interface. IF we could it would likely rocket (
) understanding of TW …
I am wondering what the best alternative approach, if any, is …
Thoughts
TT
Just yesterday I pondered over the Share plugin (found in TWs official plugin library). If it could be made to work properly and installed on tiddlywiki.com then anyone could (remotely) create temporary tiddlers that interact with the wiki so it should be much easier to demo stuff and explain things.
We could allow iframes from certain domains, including TW-dot-com.
But it’s a security risk to allow for embedding of arbitrary domains (that might fall under the control of someone else etc etc)
Let’s see:
Thanks! Let’s see. I will do a few tests over next few days to see if it works well for the aim of the OP. Fingers-crossed.
Right!
Though I’m wondering if https://tiddlyhost.com/ wikis would also pass the security needs? It is a major way users display their TWs. It is a vast resource.
FYI, personally I do not currently use that service (as I own my own domains). But I would copy to it if it were kosher for Iframing examples safely for readers.
Laters, TT
This is an early test on layout on D. for Iframes. Hiding at first so as not to swamp the D. interface …
This is am embed of: Introduction to filter notation
I personally like a link to https://tiddlywiki.com/#HelloThere much more than an embedded iframe in the forum. Especially on mobile, where “screen space” and data-roaming is a general concern.
If we want a better static preview of links within the forum, IMO it would be worth to explore the possibility with additional meta data to show “cards”, that are used by other pages. eg. GitHub links
Those “cards” would be usefull for links in every social media, that is capable of using them.
I share that concern. Embedding tiddlers via loading a TW in an iframe is horribly inefficient, and a poor experience for people who don’t want to load the content.
That was what I thought till I tested it. Maybe it is luck that in remote provincial Italy it works fine… In particular, TW is pretty good on mobiles by default …
Screenshot from my ancient Android … !
Right! So I put the iframe inside a <details> so it is not visually rendered in D. until explicitly wanted. What is the issue?
Both you and @pmario are concerned not to expose discourse to iframes of TW’s.
I do understand the concern.
I’m just not so sure such worry is needed now.
My OP is fundamentally about bridging the gap from here to actual TW.
IMO the better we can co-integrate Discourse & TW the better.
This place is for TW.
The more TW we show live the better IMO.
Of course, if you two are convinced it is ineffectual to do that head-on I’ll shut up.
But my experience here in Italy is it can work pretty good live.
Best wishes
TT
I would wonder if the frame is pulling the data even though it is not rendering it. So it would apply to your mobile data charges even if you don’t look at it. Since the base TW is now 2m, that could add up quickly in some cases.
Possibly if you insert specific tiddlers from the static tw site it would reduce both dangers and data usage.
OK. Got it. Cost could be high. Something I don’t think about enough as mainly my phone uses my network for data, not phonelines. Even so, if I use bare bone phone here, the throughput of TWs never broke my limit.
Result: I agree it is an issue. Just very unclear how much of an issue it is in practice?
Best, TT
I try to limit my phone data to 800mb per year. Admittedly I might be an outlier.
Likely :-).
Regarding the issue here I’m unclear without facts on how impoverished the normal active user is.
I assumed that bandwidth is no issue for most everyone visiting here?
The OP is about access to TW live. @jeremyruston & @pmario have objections to that on grounds, partly bandwidthy, it isn’t viable. But I’m just not yet so sure what the baseline actually is now is on that?
Integrate TW as much as possible into interfaces live still seems best to me. Something like that.
A probe, TT
The concern is particularly on phone. Bandwidth is probably not an issue for most people visiting from a desktop. Some people spend much of the day on their phones. For them, the issue would be speed of rendering.
One does have to ask, why do you need to embed an entire 6mb file just to illustrate a point? Wouldn’t a screenshot do? Or one of the static tiddlers? What exactly is the use case?
Whoa. On mine, just loading a local version of TW made it choke and throw “Wait?” messages. It takes about a minute to flick between tabs on the Wizard. I’m guessing that the problem is that TiddlyWiki.com isn’t the intended usage.
Can you explain what the Share plugin accomplishes beyond the existing permalink technology? The “readme” is very terse. Since all the filtering happens on the wiki side, not the client side, it’s hard to understand the utility. If the filtering happened on the visiting client side, I’d get how it was useful.
Thanks!
Case, the actual TW is live. Case: see it working, interact.
Right. My phone gets its data from the wifi at home. Bandwidth is not an issue. Outside I just use it for calls; no wifi, no data drain.
An issue in this thread does seem to be data usage?
TT
Sounds like it needs a review. It performed well before but there was some bug in that URLs weren’t properly interpreted in all cases. Space characters became % or some such, not the problems you mention. BUT it is not installed on tw .com and in order to install it there it has to be saved and reloaded so if you try it then it can’t be tried there.
Yea, it is a super cool thing: It uses the method described (and demoed) with itty.bitty I don’t know how/why they succeed with proper character encoding but we don’t…
Anyway, with the Share plugin, you can create virtual tiddlers directly in the URL. These can interact with the other tiddlers. It would be very useful if it could work properly because it would be very easy to create “living examples” when e.g guiding someone or demoing smaller stuff.
But you’re only seeing the same TW that you could see by clicking on a link. The difference is that the choice is yours (that of the user). If you could iframe other TW’s, that would be a different issue. But as was mentioned, that would be a security issue. I guess you could ask @boris to white-list particular sites as they came up.
Some people are away from their home wifi most of the day. For example, their workplace may not allow personal access to the work wifi system. So they have to depend on their data, which is likely to be both slower and costlier than a direct connection. Or they’re on the road most of the day and seldom near a wifi connection.
So to use it with tiddlywiki, the serving host would need to have the share plugin installed? Which is unlikely to ever come installed on TW. So we would need some alternately hosted TW file (perhaps on TH) that has the share plugin installed?
Right, it unfortunately has to be on the serving side. Here are some old gg discussion that also discusses the problem:
Making it easier to share demos/snippets in Google Groups (by Jeremy)
My main concern is more about “Do one thing and do it well”.
So Discourse should drive discussion, linking and should keep the readers focus at the topic
The TiddlyWiki main page should be an interactive test bed and the home of the reference documentation
I think TW shouldn’t be embedded, because it limits its possibilities.
