[tw5] If I wanted to start a discussion ...

I’d probably do something like this:

What is the sweet spot of how much should be core TiddlyWiki and how much should be plugin?

If there were no plugins needed because everything anybody would ever need would be in the core. Would it make core TiddlyWiki too heavy?

And if we were to make TiddlyWiki as light as possible, and make everything a plugin, would that be too unwieldy?

Is there such a thing as one sweet spot, or would it make more sense to have a handful of sweet spots available?

To have a handful of sweet spots, they should be easy to create and maintain. Probably makes sense to have a slimmest bare bones TiddlyWiki core, with “big plugins” to easily create each alternative “sweet spot”.

What do you think?

If I wanted to get into that kind of discussion, I think that’s how I’d kick things off.

2 Likes

At minimum, having apt, nano, curl, and ssh installed is pretty much a no brainer. But you don’t need the dev tools, you don’t need the docker runtime or VMs, you don’t need a graphical environment (many choices, none perfect), but you do need the basic bash scripting tools.

My current philosophy for Tiddlywiki is “if you can do it with a plugin, do it”. Core doesn’t really need more user comforts but extensibility is an ever expanding work in progress. There are certain features that I always add to every single wiki, like certain macros that I find useful, and if you find yourself always doing that, that can indicate it’s a feature that could be useful in core. Macros and small style tweaks are especially good candidates for that. Also, if you’re good at coloring a UI, palettes need more diversity. If someone makes a really good theme that answers ALL the scenarios perfectly, that would be a candidate for an official plugin.

This is something that I’ve related to a lot in working with TiddlyWiki. I made TiddlyServer, for instance, (https://arlen22.github.io/tiddlyserver/), and I made it entirely based on code that was already existing in TW5, mostly just using standard features in boot and core. The core is intentionally built to be extended, and it was the core code that actually gave me the idea for how to write TiddlyServer. I didn’t come up with it, I just saw the pattern and used it.

That being said, the thing I have made more pull requests for than anything else is the boot folder loading code. After four or five different PRs trying different ways of approaching the situation, I finally came up with the rather simple solution of dividing the startup function out into three separate functions which would allow the init and exec portions to remain the same while being able to change the load portion to use async calls. That PR was accepted and I can now happily override the data loading with any async adapter I want without worrying about maintaining the init and exec portions every time they change. The main use case for this would be “TW5 in the cloud” and other “NodeJS TiddlyWiki5” scenarios where blocking is undesirable or impossible.

https://github.com/Jermolene/TiddlyWiki5/blob/master/boot/boot.js#L2491-L2497

$tw.boot.startup = function(options){
options = options || {}; // Get the URL hash and check for safe mode $tw.boot.initStartup(options); $tw.boot.loadStartup(options); $tw.boot.execStartup(options); };

So my two cents is: do what you can as a plugin, and think of the most generic and useful ways to make improvements to core that retain existing compatibility and keep things organized and performant.

1 Like

Well, I am a Damn Small Linux, Puppy Linux, and Linux From Scratch fan.

If you know Linux, you can imagine I’m on a totally opposite spectrum.

Kind of unrelated, kind of not. My device of choice at home: Chromebook.

I guess I am immediately drawn to light and agile, and quickly get miserable as soon as I sense “weight”. But I’ve got sensory hypersensitivity along with cognitive disorders, so I am almost always in a solo school of thought.

All of that aside: that was a pretty awesome post. Thanks for taking the time !