Testing the Multi Wiki Server Plugin

[well-noted]

I have been noticing something recently that suggests to me I may have a misunderstanding of MWS – discrepancies between the same tiddler when it is represented in different recipes.

For example, my TODO items are in one bag that is shared between two recipes – in one recipe, I tag an item as “Done” and am surprised to find that it is not also tagged as done in the context of the other recipe.

After some investigating, I discover that by changing the tag in one context, it creates a new tiddler in the top bag of the recipe to be used in the place of the same tiddler in the bag of lower items in the recipe.

Is this expected/desired behavior?

It was my sense that modifying a tiddler that is in one bag should preserve its place in that bag if modified, rather than creating a new tiddler in the first bag of the recipe in which it is being viewed

[pmario]

@well-noted

Is this expected/desired behavior?

It was my sense that modifying a tiddler that is in one bag should preserve its place in that bag if modified, rather than creating a new tiddler in the first bag of the recipe in which it is being viewed

That’s desired behaviour.

You may have a closer look at a reply at an other thread, where I do point out some “gotchas” for new users.

Low-cost multi-wiki solution for D&D game?

From my point of view, that multi-wiki-server MWS plugin still is highly experimental. Especially the access handling is still in flux and subject to change in backwards incompatible ways. I think your usecase can be solved with MWS, but you would be an early adopter.Which means there will be breaking changes in the code, which may set you back several steps, or even to “sqare one”. The access control list (ACL) configurations in TW is “role” based. But at the moment this system only knows how…

Cloning content into “higher level” bags has an advantage in the long run. – The main problem at the moment is, that we do not have any visual indication, what’s going on.

If you would have had the possibility to move the “new tiddler” and “overwrite” the “lower level” one in a convenient and visible way, it would have been an obvious feature.

Because we are still in early stages, it is an issue.

[JanJo]

Could this be cured with an overwritten tiddlers table where the overwritten tiddlers are listed per bag perhaps with a sort of automatized temporary renaming mechanism.

(Zut alors ! It sounded easy in the beginning….)

[well-noted]

Interesting. I will need to get my head around this somewhat.

In my case, I would like to have a general TODO list that stores all the TODOs from all my various wikis – it has access to all the bags of TODOs from the relevant recipes, and I had expected that I could interact with the TODO list and have those changes reflected across all the other recipes: instead, checking off a TODO item only generates a clone in the TODO List page template bag, which is not as useful to me, especially in the context of tracking projects.

@pmario

If you would have had the possibility to move the “new tiddler” and “overwrite” the “lower level” one in a convenient and visible way, it would have been an obvious feature.

I would propose going a step further and say allowing users to select from multiple handling depending on filter conditions would be most helpful.

For example, I don’t mind if my TODOs get shuffled into other bags, but ultimately I do want them to all aggregate toward the TODO-items bag.

Likewise, I want all my Index and Idea tiddlers to end up in my KnowledgeBase and my Sources to end up in my References.

@pmario

Cloning content into “higher level” bags has an advantage in the long run

State tiddlers are the only obvious example I can think of, in my case, for this, but perhaps I’ve overlooked something.

[well-noted]

Any input on how realistic some kind of contextual filter for recipes would be?

I’m thinking “If this tiddler is being reviewed in the context of this recipe, then reveal this content”

This may actually link back to this previous thought:

@well-noted

Thoughts (anybody?) on introducing the bag field to tiddlers when they are created moved into MWS bags? The architecture is already there to keep the field hidden, and it would be simple to instruct that the the database update the bag-field when tiddlers are created or moved.

[jeremyruston]

@well-noted

It was my sense that modifying a tiddler that is in one bag should preserve its place in that bag if modified, rather than creating a new tiddler in the first bag of the recipe in which it is being viewed

This is the behaviour of the original TiddlyWeb design back in 2008 - see https://tiddlyweb.com/. We saw several advantages with this approach:

• Simplicity. End users do not have to be aware of the bag and recipe mechanism
• Flexibility. An advantage of routing all changes to the top bag is the ability to later explicitly push those changes down to the intended bag, giving a process akin to pull requests

There were similar discussions about whether recipes should be nestable, so that a recipe would be a list of intermingled subrecipes and bags. Our conclusion was that this additional complexity wasn’t worth it, and users could achieve the same effect by dynamically (re)building the recipe list, for which there was a simple API. Our biggest concern was again making the platform too complex. Programmers are used to dealing concepts like hierarchical nesting and indirection, but they can be unfamiliar and confusing for end users. Our belief was that the server should be as dumb as possible, with a preference for implementing flexibility and hackability within the TiddlyWiki client.

[well-noted]

Nice to hear from you, @jeremyruston

I agree with the decision about not having sub-recipes, for the reasons you state.

I have modified my working-edition so that, if a tiddler already exists and is saved, it gets saved back to the bag from which is already was.

For me, this has some major and obvious advantages:

1. I can sort from my existing wiki all tiddlers that match my Idea and Index tags and sort them into my knowledge database, for example
2. I can then know that in any context I want to see and interact with my knowledge-database tiddlers, I just have to include that bag in my recipe

3. I can
   a. Access and do data entry on my (much smaller and faster) knowledge database recipe and still
   b. View and modify those tiddlers in any other context they appear, knowing that those changes will be consistently reflected across all spaces.

Another context in which this is useful: Todo Lists:

Since making this change, I have been able to have all my todo items, calendar items, and projects in individual bags, which are all included in a recipe exclusively for accessing and interacting with scheduling/planning/itemizing.

This allows me to have an extremely small, simple, lightweight wiki that I am able to interact with in a way that allows me to replace, for example, google tasks/calendar. I can run that in my sidebar, or as a PWA on Android, alongside navigating my daily life and other wikis, without all the bloat of all of the context that I get from mixing together more complex recipes.

When attempting to do this with the core version, marking items as done in one context would essentially make a copy of it without updating the original context. This obviously does not work.

The idea of pushing changes down to other bags is interesting. Since the only mechanism I’ve seen for shuffling between bags is my improvised method, there may be some conceptualized form of this that would appeal to me. Would love to hear more about what the vision for that would be… Though I would hope it would include some controls for “Always sync changes from this context”

[joshuafontany]

@well-noted

The idea of pushing changes down to other bags is interesting. Since the only mechanism I’ve seen for shuffling between bags is my improvised method, there may be some conceptualized form of this that would appeal to me. Would love to hear more about what the vision for that would be… Though I would hope it would include some controls for “Always sync changes from this context”

Imagine 2 wiki/recipes

MyCoolRPG-Dev
Description: Draft mode of RPG rules (v0.1.3, private)
Recipe (last bag wins):
MyPlugins-bag
MyCoolRPG-bag
MyCoolRPG-Dev-bag

MyCoolRPG
Description: Published RPG rules (v0.1.2, public)
Recipe (last bag wins):
MyPlugins-bag
MyCoolRPG-bag

From the MyCoolRPG-Dev wiki interface, you have full access to the current “published rules”, but then any changes/updates to existing tiddlers from the published edition only exist in the Dev wiki. Until you “commit and publish” (change the bag for all “committed” tiddlers). One of these could be the “version” tiddler, so that publishing it auto-updates the version " in prod" to (for example) v0.1.3, and then bump the “dev” version automatically to v0.1.4.

I also see cases where updated tiddlers should be “auto committed” back to the bag they started from - especially for ToDos, etc.

[well-noted]

Interesting. But to take a step back, what does the actual interface for this look like? Does it take place from within the wiki or from within the MWS Index UI?

Like I said, there’s currently no form of bag shuffling I know of other than my hacky solution