Would there be interest in producing an edition more basic than 'basic'?

[anicolao]

I'd like to have a core edition that contains nothing except the ability to execute plugins, and have all non-kernel functionality expressed as a plugin on top of core. To give a sense of how minimal this would be, core would not contain a user interface, plugins, editing facility, knowledge of the markdown language, or basically anything other than the kernel that can load a javascript tiddler to extend core. Initially it might be hard to subdivide the UI and. other parts into sufficiently small tiddlers but it ought to be possible to create a read-only view of a story river by loading only enough of core to display tiddlers, search tiddlers and re-order recents for example.

More or less every single feature would ultimately be broken out into its own tiddler so that it could be included or not as desired.

So to be clear what this discussion is about: it is not clear this is a good idea; and so let's discuss if it is. If it is a good idea, is there any appetite to take on patches?

[kookma]

Having a minimal TW has been a matter of discussion and interest in the past. This is a very useful idea.
Ability to add features/functionality as plugins/addons is great and allow to build different type of TiddlyWiki based on the final use.

So, I highly support your idea.

[anicolao]

The implementation path here would be to start with a core that is exactly the same as empty and then piece by piece pull funcitonality out of core into new system plugins that get added to empty as we go. In this way, the definition of an empty TW5 instance stays the same, while core becomes ever more minimal with each extracted feature.

[kookma]

A working demo will facilitate to grasp the idea better. I am not sure if you have made any minimal version yet.
I think breaking the current core plugin (it is distributed as plugin) into smaller piece would be a hard job!

[pmario]

I'd like to have a core edition that contains nothing except the ability to execute plugins, and have all non-kernel functionality expressed as a plugin on top of core.

That's pretty much the repository structure you describe. Have a look at the core/modules

Every js-module is a tiddler, that is activated at startup.
The TW core is a plugin tiddler already.
IMO it will not be possible to strip any js-tiddlers from the core, for backwards compatibility reasons.
It should be possible to remove all the UI related tiddlers, except for those which start the UI. That's 2 tiddlers.

The startup is done in boot/boot.js, which defines the minimally needed kernel code to import the module tiddlers from "core/modules" and to start them.

So every module-js file is "plugin-like" -- but we call them modules. So we do not get a naming conflict with user facing TW plugins.

A TW plugin combines several tiddlers into a new plugin-tiddler. So every plugin is a tiddler that contains "sub-tiddlers". Those subtiddlers
are expanded at startup into so called "shadow-tiddlers".

The UI gets started from the TW render.js module, which exports a .startup() function, which gets the UI handling going.

The UI itself is defined and started using the following tiddlers:

• $:/core/ui/RootTemplate, which starts the main layout. Can be seen in render.js
• The default layout is the : $:/core/ui/PageTemplate which starts the rest of the UI

That's basically all you need to start

To give a sense of how minimal this would be, core would not contain a user interface, plugins, editing facility, knowledge of the markdown language, or basically anything other than the kernel that can load a javascript tiddler to extend core.

Edit: That's done with boot.js

[pmario]

Have a closer look at the dev-edition, which describes the microkernel architecture and the startup process.

[anicolao]

Thanks. I thought I had read this, but I had only read pieces of it, and hadn't seen this version where the whole is presented in a logical sequence, so this link was very helpful.

To match the language of my idea better with the architecture, it turns out I am not really proposing a core edition, but actually a microkernel edition, where I wish to be able to control the system starting at the boot process and not bother loading components that my configuration doesn't need.

The documents aren't quite specific enough for me to be sure what works. For example, there are two ways to decide if a boot task should be executed in the system, tw.boot.doesTaskMatchPlatform and tw.boot.disabledStartupModules.indexOf. It isn't clear if I can write a new startup module as a regular plugin with a before field to run it first so that it could mutate disabledStartupModules and so control the boot process: this would be one way to boot whatever I want. This seems plausible at least. Modifying doesTaskMatchPlatform seems more difficult as it is currently essentially hardcoded to deal with just two cases, namely node and browser, and it doesn't seem super high value to the microkernel to fix it to use a tiddler to define the platforms and match against them.

So the specific question is, if I make a new startup plugin that is before everything, can it then disable whatever it wants to disable? If so, I think this is the path of least resistance for me to do what I want, as it requires no modification to TW5 itself.

[Jermolene]

It isn't clear if I can write a new startup module as a regular plugin with a before field to run it first so that it could mutate disabledStartupModules and so control the boot process:

Yes, I think that would be a reasonable approach.

[linonetwo]

Maybe with #7329 you can write your own startup logic.

[Jermolene]

Hi @anicolao the idea of making the core plugin smaller seems like an obvious no-brainer: everybody can start out with the smallest possible thing, and then just add the granular functionality that they need. It might feel like this would make things more efficient.

However, TiddlyWiki exists in a symbiotic relationship with the community that supports and sustains it. One role of the community is to help newcomers debug problems, or learn new techniques. In that context, there are enormous benefits of everyone in the community using the same thing. If everyone was using a slightly different variant of TiddlyWiki, with different features, then before we could answer support questions we'd have to establish which variants of TiddlyWiki they are using. That would add significantly to the friction of the support process. So, we try to establish a baseline of commonality between all users that makes support and backwards compatibility much easier to handle.

A further consideration is that TiddlyWiki's architecture means that one can't necessarily meaningfully separate features like "editing tiddlers". Architecturally, TiddlyWiki is comprised of a suite of primitives: operators, widgets, macros, etc. These primitives are combined through templates to create the features visible to end users. For example, there is an <$edit-text> widget that is the heart of the tiddler editing view. However, the same widget is also used for the sidebar search box, and so it wouldn't be possible to omit it from a putative read-only TiddlyWiki.

It's interesting to look at the composition of the core by measuring the size of the source folders:

• Entire /core folder - 1.8MB
• JS modules in /core/modules folder - 1.2MB
• Wikitext templates in /core/ui - 240KB

That means that there is very little to be gained by moving wikitext templates out of the core plugin, so this is really about rearranging the JS modules, where we have the problem discussed above that there isn't a clear correspondence between JS primitives and end-user functionality.

[anicolao]

Ah, I must have not explained the purpose at all well. I completely agree that for the purposes of having a personal web notebook, there should be one (or a very small number, but ideally one) TiddlyWiki edition that everyone is encouraged to use. In fact, the current state where the user arrives at the website and has to figure out what a "saver" is to get started is already a big hill to climb and I suspect the existing ecosystem loses a lot of potential users at that very first step. For that purpose, I have written a firestore syncer that makes it trivial to deploy a new personal, private tiddly wiki in the free tier of Google Firestore that should fill many user's needs: as simple as "give your wiki a name and click create" and you're up and running.

However my purpose here is completely different: I think quite different sofware can be built on top of the core, treating it as a kind of "web operating system" that could implement a game, or a blog, or a message board, or more or less anything. These new things wouldn't be recognizable as TiddyWiki descendants and wouldn't be part of the tiddlywiki ecosystem, any more than libreOffice is part of Linux. TiddlyWiki is an application; the 'core' edition is a platform on which one could build other applications.

[anicolao]

Perhaps a specific example would be helpful. I have recently implemented a firestore backend that stores the user's tiddlers in firestore and a serving mechanism that makes it easy enough to use the usual UI to edit tiddlers.

However, I'd like to be able to see the wiki as a filesystem tree rather than as a website. To that end, I hope to implement a 9p fileserver that serves <tiddlername>.tid files corresponding to all the tiddlers in the wiki. The user should be able to mount this filesystem and edit files, and the fileserver will write them in the appropriate way back to firestore. In this way, I can use tools of my choice to deal with the wiki whether for editing, searching, automatically creating tiddlers with scripts outside the scope of tw5, etc.

The 9p fileserver has no need of a UI; indeed no need to speak http or to do any of many things that the current core can do. However, being able to fire up a core that loads the 9p plugin and serves the protocol based on a 9p protocol plugin tiddler plus a core that can execute it and knows how to supply .tid files and how to consume .tid files would be convenient. This server could contain a larger core than needed, of course.

[Jermolene]

Hi @anicolao using 9p is very interesting. I have thought about doing something similar over WebDAV.

[anicolao]

Do you have a design for what the exposed filesystem would look like? For example, one organization could involve having /tags/tag1/tag2, another possible organization could involve being able to have a path like /filters/tag[tag1]/tag[tag2] where in these examples the resulting directory would of course contain the same content, but the first one is easier to type/think about and of course they are not mutually exclusive.

Thinking about what the right way(tm) is to expose the wiki to the filesystem so that the user can bring their sense of how their wiki works to either environment is probably important to getting the file server correct, whether it speaks 9p or WebDAV. If we have more than one network protocol it would be desirable to have some sort of fileserver plugin that defines the file system in normal filesystem tree terms, and layers on top that then serve the various protocols you might want to use to access the files.

[anicolao]

(Perhaps I took it without saying that you'd like to have a /tiddlers/ with all user tiddlers, and probably a /$:/ or /system/ with all system tiddlers and perhaps a /all/ or /universe/ with everything in it. But these folders aren't convenient to work in because they contain too much of the wiki at once.)

[Jermolene]

To add further that @pmario is correct to point out the similarities between the existing design and the one you outline. We have the boot kernel in boot.js that boots up enough of the infrastructure to be able to load the JS modules from tiddlers.

[dubiouscript]

Would there be interest in producing an edition more basic than 'basic'?

+1 much interest in this i have , testing i can do ...

However, I'd like to be able to see the wiki as a filesystem tree rather than as a website.

+10
excited to hear some other minds groc's this potential

vaguely (perhaps/hopefully) related ramble hear : #7347

The 9p fileserver has no need of a UI; indeed no need to speak http or to do any of many things that the current core can do. However, being able to fire up a core that loads the 9p plugin and serves the protocol based on a 9p protocol plugin tiddler plus a core that can execute it and knows how to supply .tid files and how to consume .tid files would be convenient. This server could contain a larger core than needed, of course.

this sounds interesting
plz link to this repo!! (if it currently exists)
the description above reminds me of this 'lynx knowledge navigator' - #1733

[dubiouscript]

Hi @anicolao using 9p is very interesting. I have thought about doing something similar over WebDAV.

one perhaps related point about comparison with file systems or file system like thing's eg WebDAV

is the support of features like symlinks for example
iv read WebDAV( filesystem like interface over http) has inconsistent handling of symlinks , which depend on afair dav server configuration options , this realy sticks in my mind after spending some time trying to config webdav on Owrt router's =[

i would hope that the nature/history of p9 would bring symlink support out of the box !!

-- edit --
ftr searching on the themes of this topic i found that
http://9p.cat-v.org/implementations there appear to be 5 or so p9 implementations in js !!

• https://github.com/rsbohn/9pJSON

... https://github.com/roobie/9p.js

-- edit --
🤕 wtf 😱

it appears (i read / heard stated) plan 9 has no support for symlinks =0

[dubiouscript]

It's interesting to look at the composition of the core by measuring the size of the source folders:

* Entire /core folder - 1.8MB

* JS modules in /core/modules folder - 1.2MB

* Wikitext templates in /core/ui - 240KB

imho the reduction of required source is less about size in bytes more about cognitive load

having methods (even if adhoc) of partitioning / filtering
#1733 (comment)

in which seance the key is knowing what you can ignore / dis-guard , and what is essential-functionality (for whatever intended use)

[dubiouscript]

wrt

producing an edition more basic than 'basic'?

i think iv given abit of thought to &...
my view is that the dev tools console should be considered as a commandline for the browser

and that "producing an edition more basic" wiki should be able to be used via browser console as UI
( perhaps this could/should be considered tw.basic.cli module/plugin )
via calling 'core' functions store retrieve content from tw . install modules/plugins ect
🤔

...
#6590 (reply in thread) - Headless mode for browser

[anicolao]

@dubiouscript Quick summary: I haven't written the 9p server yet but it is next on my list of tiddlywiki related items. The 9p server will expose the same tiddler in multiple locations, more like hard links than symlinks, but at the end of the day sufficient for all the uses I can think of. @Jermolene has yet to comment on what the filesystem should look like so I might just go my own way when I build it and we can see if people like it or want it done differently.

A probable ETA for actually having something you could use to edit your tiddlywiki with shell tools seems like no earlier than November, but probably this calendar year.

[dubiouscript]

any ... links / research / perspectives wrt plan 9 protocol / fs

....
--edit--
https://en.wikipedia.org/wiki/9P_(protocol)#Server_applications - wikifs: a wiki editing tool that presents a remote wiki as files in the local namespace
https://9p.io/wiki/plan9/replace_language_for_wikifs/index.html - "The wikifs(4) in both Plan 9 and Inferno understand a very small set of cues when generating HTML. That set can be limiting. It should be replaced with something better,...."

https://plan9.io/magic/man2html/4/wikifs - wikifs man page has details about metadata/format and various "views" (read as files files) of the "page"/data

https://docs.kernel.org/filesystems/9p.html
https://ericvh.github.io/9p-rfc/ - RFC and standards documents relating the 9P protocol (and its extensions and applications).

https://github.com/ozaki-r/arm-js/wiki/References#9p
Manual Section 9 - Plan 9 from User Space

https://9fans.github.io/plan9port/man/man9/intro.html - introduction to the Plan 9 File Protocol, 9P

https://9p.io/wiki/plan9/unix_to_plan_9_command_translation/ (not directly relevant but it adds (prefix text with con))

https://9p.io/sys/doc/fs/fs.html # The 64-bit Standalone Plan 9 File Server

[dubiouscript]

this (oridb/git9) potentially seams (on a bit of tangent) related conceptually , wrt p9fs abstractions over some kind of db/storage 🤨

https://github.com/oridb/git9 - Git implementation for plan 9

Git/fs implements a git client for plan 9. The intent is to support
working with git repositories, without cloning the git interface
directly.

🎄 hope y'all had enjoyable Yaksmas festivities xD

[dubiouscript]

#7772 (reply in thread)

However, I'd like to be able to see the wiki as a filesystem tree rather than as a website. To that end, I hope to implement a 9p fileserver that serves <tiddlername>.tid files corresponding to all the tiddlers in the wiki.

@anicolao
if you have gawk/awk in your environment this server written in awk
mentioned hear #6110 (comment)
will list directory and files
eg =]
echo "$request_text" | gawk -f ./webserver.awk

eg request https://pastebin.com/raw/cS3DMsUj#http-request.txt

or https://github.com/msoap/shell2http as an alternative to svr.awk
...
empty.html / store.json contained tiddlers can be (de/?re?)composed / accessed (mapped to paths / views )
#1733 (comment)
using method similar to

cat ./empty.html  | \ 
pup -p '#storeArea :first-child pre text{}' | \
jq -cr '.tiddlers as $t | ($t|keys) as $k | .[]|.[]|keys  ' | \
tr -d '[]"' | tr ',' $'\n' | sort | uniq -c

or ./gron.awk could replace jq

imho these methods are interesting , while its not exactly p9fs server or whatever
( they offer the potential create view's to access the wiki plain text , in various likely out of the ordinary / unusual ways )
perhaps
some potential exists using such methods for (quickly) test/prototyp-ing some of the concepts/ideas mentioned in this thread ? 🕶️

[linonetwo]

I'm producing template that is more advanced than "advanced"

TidGi mobile now load template list from a wiki with filter expression ( from tag https://tidgi.fun/#WikiTemplates , so anyone can PR to add new template to https://github.com/tiddly-gittly/TidGi-Official-Website ).

The default template will have 71 plugins, so it works like Obsidian (but still less than it). But I hope there can be a more powerful template that works like Notion, so people won't say "Tiddlywik is difficult to use because you need to take days to setup before you can use it like Obsidian out of box)

[linonetwo]

I think a "Tiddlywiki-lib" is necessary for #6590