Plugin Libraries: Is there a standard format?

#1

Is there a standard format for plugin libraries that TiddlyWiki uses to access the list of plugins, or does each plugin library exist as its own plugin that can be used to load other plugins?

The reason I’m asking is because I want to allow users to add plugin libraries to MWS (a server system we’re working on) so users (or at least admins) can choose plugins from them.

If that’s not feasible we can always do drag-and-drop install like normal people.

#2

I Publish Plugin Libraries I have found here https://plugins.tiddlyhost.com/, tell me if I have missed one, however these just point to a repository, made up of multiple files.

  • I did research this in the past.

One could capture the tiddlers required to add libraries to a wiki and package these as a plugin.

Search talk.tiddlywiki for my user id and “Library” and you will find related content including this How to create a plugin library with one click (tiddlyhost)

While libraries can be generated from the command line (from memory) we don’t yet have a generator of them, like we do wikis (innerwiki plugin) and plugin generators (Gatha?).

  • This should be possible using the zip plugin to generate files as needed and store them in a zip, download and extract on a HTML host.
  • It seems to me the node is a html host so we have no reason why we can’t publish libraries directly from a server version of tiddlywiki like MWS, bypassing the download and host step. Use node as the host.

To add features to MWS I recall that other node servers could publish all tiddlers at an independent html address eg static tiddlers, This could be enhanced to make the available files for the source library available to those with access to the MWS server or one of its wikis.

However one of the difficulties is I could not find a document that outlines the Library mechanism in a way you could read and replicate a library, it seems only the source code in the node servers documents this.

  • See Make library command
  • You could generate a library from the command line, then observe the result and use this to reverse engineer the library generation mechanisium to;
    • Generate a zip file to place on a html host
    • To publish the same files on a node server such as MWS allowing a library definition to be shared that points to that server.

Do ask more questions if I can help :nerd_face:

#3

WIth MWS you should use a different approach. Plugin libraries do have a special format. Using them with MWS makes everything more complex. For admins and users.

MWS already has a bag-system. So if admins want to use 3rd party libraries,

  • They should install them with the normal drag & drop or import mechanism into an eg: my-libs bag.
  • Then they should tell their users to include this bag into their recipe

Done

That’s simple for admins and it also includes the possibility to install several related and preconfigured plugins into one bag. – If that’s needed.

It also makes maintenance easier. Since an admin can update and test newer plugins. So users do not have to test new plugins for compatibility individually.

We did use this mechanism extensively with TiddlySpace. Where every plugin had it’s own recipe with documentation. This recipe also used the plugin-bag. So the docs can be separated from the plugin. So user only include the plugin bag with minimal documentation. Or if they want they can also include the documentation bag. It’s their decision.

If users want to install plugins that are not prepared they can do so in the same ways as they do now. So no additional maintenance work for admins necessary.

More experienced users can manage their own plugin-bags as described above. So the mechanism for users and admins is the same.

The recipe and bag system was designed to be used that way. The single file plugin-library handling is much more complex, due to browser CORS restrictions.

Using bags to include libraries into user recipes also has the advantage, that the MWS authentication system can be used.

#4

Hi @Arlen22

TiddlyWiki’s plugin library mechanism is rather elaborate in order to get around the limitations with performing xmlhttprequests from pages loaded from a file: URI. The client TiddlyWiki loads the plugin library HTML entry point into an iframe. TiddlyWiki then uses window.postMessage to talk to the JavaScript within the plugin library. The format for the messages is essentially HTTP tunnelled over window.postMessage.

We don’t really need any of that complexity in the context of MWS unless we want to support clients of the plugin library that are loaded from file: URIs. It would be much simpler to implement the plugin library as a plain, ordinary bag containing the JSON plugins with an appropriate naming convention. I don’t think the server should need to be aware that the bag is anything special; it’s just another dumb storage array.

One of the principles that we found useful was to think of the server as a big dumb shelving system in the sky, with as much of the logic as possible residing in the client. The motivation was to build a platform that others could hack upon in ways that we could not anticipate in advance. Almost everyone in the TiddlyWiki ecosystem can hack things together in the browser, while the skills required for serverside hacking are much demanding.

2 Likes