[MWS] Questions about Bags and Recipes

Working on the materials for my History Class (which is mainly working on a tiddlywiki) I have a question towards the new organization of TW in bags and recipies. (So I do not know, whether this is the right place to post these in this thread)
I have a number of subjects (Tiddlers) I would not include to the Course-TW but make it reachable from that point.

  • On the one hand, these are materials which would make the wiki too big (like for example the material I made in my art-history wiki on Expressionism).
  • On the other hand, this would be solutions to questions, the upcoming exam etc.
    Will there be a mechanism to load tiddlers or entire bags after loading the wiki?

MWS is beta, work in progress and not ready for prime time yet

Bags and recipes are “connected”.

A recipe is a configuration that allows us to configure the content of wikis.
A bag is representation of a datastore that combines tiddlers that belong together.

A more detailed description can be found at: Announcing the MultiWikiServer Plugin - #83 by pmario

So for a theoretical wiki of yours you could have the following configuration:

  • recipe: Art-history
    • bag: plugins
    • bag: general info about art

If tiddler titles are duplicated in different bags the lower bag will win. So it is the same mechanism as we
have with “shadow” tiddlers.

So the first recipe contains the general info. The next recipe contains the same bags are recipe 1 but it also contains the “too big” stuff, that would be needed for an upcoming exam.

  • recipe: Art-history on Expressionism
    • bag: plugins
    • bag: general info about art
    • bag: details about expressionism

As you can see. This mechanism allows you to reuse content in different wikis. So for example every user could use recipe 1 and add their own notes eg:

  • recipe: Art-history with user Notes
    • bag: plugins
    • bag: general info about art
    • bag: user notes

In this case the last bag “user notes” will be writeable by the owner only.


Missing features

  • We do not have a visual indication yet, in which bag the content is located
  • There is no easy way in the UI to move tiddlers from one bag to an other bag
  • The ACL (access control list) is not finished yet
    • That means access control is in flux
    • We did not even start to discuss it
  • The database structure is still in flux
  • … And probably more
1 Like

Everything pmario said is basically correct. It’s not production ready yet.

Now to answer your actual question. You can put the same bag in as many recipes as you want. But only the first bag (first position in the list in the admin UI) is actually writable. So you can make a separate recipe to edit the bag at each level, plus read the bags below that. For now you need to manually create all the recipes, but it’s fairly obvious that we’re going to have to make this bag+recipe cascade a little easier to manage.

The bag stack doesn’t use the client shadow tiddler feature, so you won’t see a plugin for lower bags. But it’s the same idea, where tiddlers with the same title cover over tiddlers below them in the list of bags.

1 Like

Hi @Arlen22
Thanks for your reply. Can you postload bags on demand?

I don’t think so but @Arlen22 may know better.

I’m not sure what you mean by postload. Currently you can load a tiddlywiki core plugin or an arbitrary data folder into a bag from the command line. If you need additional options I’m definitely looking for suggestions.

As far as I did understand it, he wants to load a wiki and then dynamically add a bag, so the content of that bag will be loaded later.

Ok, yes that is available. It’s used to preload the docs folders that show up by default in MWS, but you can use the command to import any wiki folder.

Load a TiddlyWiki folder into a bag

Usage:  --load-wiki-folder <path> <bag-name> <bag-description> <recipe-name> <recipe-description> 

Arguments:
  path                Path to the TiddlyWiki5 plugins folder
  bag-name            Name of the bag to load tiddlers into
  bag-description     Description of the bag
  recipe-name         Name of the recipe to create
  recipe-description  Description of the recipe
1 Like

Yea, but the request is, to do this from within TiddlyWiki.

1 Like

Oh, interesting. Do we need to access a folder on the file system, or is this just a request to load an entire single-file wiki or json export? All of these are fairly easy to implement, and we can probably even do a folder import from the user’s computer using modern browser features that let us open an entire folder.

What would be the security implications of accessing a folder on the server file system? If the folder needs to be refreshed often, I think the best I can do is provide a way in the CLI to add the folder, and then provide a button in the browser to rerun the import from the folder that’s already been specified from the CLI.

Basically, I can do anything besides letting the browser specify an arbitrary path on the server. The path has to be specified via CLI, but then a user with sufficient privileges can do the rest.

I could allow creating a “synced bag” via cli which has the file path attached to it, and the browser would detect this and give the user an option to refresh the bag. The bag should also be read-only in that case so you don’t have to worry about losing changes every time you resync the bag.

2 Likes

I think this is what I want: A button (or better an action-widget - that would be more flexible) to add content that is not present in the basic version of the wiki.

@Arlen22 – What your write about seems to be a security nightmare. I think none of this is needed. Especially accessing arbitrary paths on the server IMO is an absolute no-go.

It is OK, if users can open client-local paths to import JSON files, or wikis into their wikis. – But that’s already part of the TW core UI.

In the OP @JanJo mentioned 2 problems

As I understand it:

Add 1) The wiki containing all the material would make the “class-” / “working-wiki” too big. So it would be inconvenient.

Add 2) The wiki that contains all the info will be needed for “upcoming” exams.

So my suggested workflow is easy:

  • There is a small read-only class-wiki, which can be used by users to create their “user-wiki”.
    • This one is used during the lessons
  • The user-wiki contains a writeable bag, which can only be accessed by that user (and admins)
    • So they can add their notes
    • They can add all their links to external personal material there
  • There is a read-only wiki, that contains all the extra material @JanJo considers important to pass the exam.
    • The link to that wiki is only made visible to the class, when needed.

That’s it.

What will be needed, is an admin interface, that would make that workflow easy and convenient.
I think it will be worth to thing about this workflow and forget about the hacks.

It would be nice to know where it gets a security nightmare and what can be done against that.
In principle any wiki is read-only until a username and correct password are entered. If this wasn’t the case that would be a security-issue.
Why would the possibility to add further materials with a click be a security-problem?

Where is this content being stored? Is it being stored on the server, and clicking the button sends a message to the server to import it? Or is it being stored on the client and clicking a button opens a folder picker so you can manually select a folder or file on your local computer to import into the wiki?

I do not have such a setup yet. But I think it would be a bag/folder on the server.

Would it not be enough to just import a folder via the browser from your local computer? And then every so often import it again to keep it up to date? Are files being added automatically or would you be adding them manually? If the folder connection could happen via the browser, that would be vastly preferred.

As a result of this discussion, I have added several warnings about not using MWS for anything important yet at this point. Please download everything as single file wikis if you don’t want to lose it. I’m doing my best to not cause data loss, but the feature set is still very early and a breaking change is being planned currently.

1 Like

Thank you for considering this. I hope this does not slow up this eagerly awaited development. I could imagine adding other tiddlers like adding a pure wikitext plugin from the library.

1 Like

I have been working on a prototype wiki application that uses MWS (the earlier beta built by Jeremy) to process “place” data (geolocation + address + other related info).

I have a bag/wiki that contains my “application” code, and another bag/wiki that just contains “data” for that application. The data wiki currently has about 70,000 tiddlers! As a result, that data wiki loads and runs VERY slowly. If I were to directly include the data bag in my application wiki, it would also load very slowly and run even slower (due to the additional application-level logic operating on those 70k tiddlers).

To work around this, I have built a utility tiddler that runs in the data wiki to let me apply a filter to the 70k tiddlers and then construct compact indexed JSON tiddlers, each containing a selected subset of the 70k tiddlers, like this:

tiddlerA: { "field1":"value1", "field2":"value2", etc. }
tiddlerB: { "field1":"value1", "field2":"value2", etc. }
... etc

Then, in the application wiki, I have an interface that uses tm-http-request to fetch just the desired JSON index tiddler using a URL that points to https://domain-name/bags/datawiki/tiddlers/sometiddler. This allows me to load the compact indexed data “on-the-fly” only when actually needed by the application logic.

The received JSON index tiddler can then be further processed by the application code using a combination of indexes[], getindex[...], jsonextract[...], and jsonget[...] to either A) “unpack” the data to construct separate tiddlers or B) access the desired field values directly from the JSON index tiddler.

Using this approach, I can avoid the slow startup time (since it is not directly loading the bag with 70k tiddlers), and the application logic is also MUCH more efficient (around 5 times faster!) since it is now processing a single JSON tiddler containing the desired data rather than a huge set of separate tiddlers.

While this method currently works, more and more place data is being added to the big data wiki on a weekly basis so it does require me to periodically load the big data wiki and use the utility to manually prepare each of the desired indexed JSON tiddlers. Eventually, there may be hundreds of thousands of individual place tiddlers and perhaps dozens of indexed JSON tiddlers. As a result, this manual process gets slower and slower and I expect it will eventually “collapse under its own weight”, or at least become a severe maintainance headache.

What might be useful would be if there were an MWS server-side handler that would allow me to use tm-http-request to submit a bag URL, some kind of tiddler filter syntax, and a list of desired tiddler fieldnames, and have it automatically construct and return a JSON index tiddler containing just the matching tiddlers and the data from the indicated fieldnames. Because it would be processed server-side, it could hopefully use much more efficient SQL-based filtering (rather than browser-based client-side TWCore wiki filter syntax).

Your thoughts?

-e

1 Like

I think that Eric’s attempt is a quintessential Use Case of how MWS could make TiddlyWiki the best of the two worlds: serverless functionality and serverbased storage for loads of data. It would be perfect if there was a filtersyntax (or even better a translation for the TW-Filtersyntax to use the MySQL-DataBase to produce to filter the tiddlers for the http-request.