I have been thinking about the overall architecture of my gun wiki. As the guns are located in the various states in Australia and the target user is a dad in the street with son who spots a gun and wants more information about it, it seems a waste of time and bandwidth to have all guns in a single wiki as dad is unlikely to want info on a gun across the country. So, I have created a number of sub-wikis, one for each state, mainly for data conversion at present but maybe as a delivery architecture as well.
Now it would be great if we could have functions that action across all states. For example, if I am looking for all guns of a type, it would be preferable to have a single search interface that searches across all wikis, rather than having dad have to search each stateâs wiki separately. The returned list of applicable tiddlers could have complete URLâs rather than just tiddler titles.
So, has anyone thought about using the parameter attributes of a URL to pass, for example, the search request to the search tiddler in each wiki and have it perform the required search. I am thinking of something like http://wikiurl#search?"25 pounder" where the term âsearchâ is the title of a tiddler in the wiki whose action is to parse out the search text and perform the search.
I know it is possible to display tiddlers that way directly http://wikiurl/ArtilleryRegisterPilot202605013_SA.html#New%20South%20Wales will open up the SA wiki at the New South Wales tiddler.
This is a great idea if it can (or rather âmayâ) be done.
My second-best alternative to this idea is to have a way to isolate any combination of zones at will, in a single wiki.
Itâs the opposite of your idea, in that you combine topics in one wiki, but you create a way to treat them one at a time when you want to, rather than having separate wikis, and then making them act as one at will. (This might obviously be a deal breaker depending on the usersâ intended uses.)
First, this would mean that you would combine information from multiple wikis into one single wiki.
The way I thought to accomplish this was to have a way of isolating different groups of tiddlers in the wiki.
MediaWiki for example has ânamespacesâ which are higher-level than regular categories or tags.
Wiki articles can belong to multiple namespaces.
Perhaps âsystemâ and âshadowâ would each be namespaces to maintain compatibility
Changing the namespace can change what you see.
ticking namespace boxes over searchbar might control which namespaces are active in search, more like in advanced search
requires creating namespace filter operators
Another possibility would be to be able to change what tags the system recognizes for certain purposes.
This accomplishes the possibility of instantly altering what actions apply to different tiddlers. The buttons and elements do not change - just which tiddlers have which tags - and tag relationships.
Settings config shows a list of all the system tags that are recognized by the wiki by design.
Users can alter these tags in realtime through actions, so that the wiki can drastically change form according to which tags are recognized for what purposes.
Custom tags can also be swapped out for others
Tag relationships can be changed, drastically changing the wiki
This would probably require features where tag relationships are more prevalent as well, although tag relationships can already be accomplished via lists.
The second idea for altering system tags in realtime could have many, many possible applications, but it could be used in order to effectively accomplish many of the purposes that namespaces could serve - just in a more round-a-bout way.
Both of these things could be used to effectively create single wikis that can either include, or exclude what content is actively searchable and convenient and recognized by regular features like:
Another idea, now I have my thinking cap on, a way to have a âmasterâ wiki with all the code and slave wikis with all the data. So a single code base shared between multiple âslavesâ.
One alternative thought, a mechanism to load a data set into a master wiki at run time and to be able to reload another data set at any time.
However the above could be in a master wiki to search when the state is unknown, and each wiki could have a menu bar with a drop down link to every state.
If you have an internet facing node install you can have multiple wikis published including subwikis
It is possible to search via the wiki url, I believe it after the ? see the https://tiddlywiki.com/#InfoMechanism but right now I cant find the documentation on this right now. I get lots of false hits.
If you want more details I am sure the community can assist. As is common people have taken this path before, and tiddlywiki has usually addressed it already.
This is very similar to the architecture I use for Lithic (https://lithic.uk).
It uses a TiddlyStow-based launcher that dynamically injects data-only wikis into an âemptyâ Lithic core at runtime. When you hit save, it extracts and saves only the data tiddlers back out, keeping the core codebase completely isolated from the user data.
At some point Iâm going to modularize and generalize the launcher to work with arbitrary wiki editions but for the time being itâs hard coded to work just with lithic.
It also creates caches of the wikis in browser storage so you can do cross-wiki text searches from the launcher, even before you have granted file access permissions to the browser
Been thinking more about how we might implement a central master wiki with slave data wikis.
In my case, the slaves have the data for guns for a state, eg. South Australia. This data could be help as a simple JSON file as you might use for importing bulk tiddlers. All the tiddler code would only be stored in the master.
The master would have function to âopenâ the guns for a selected state. This would cause an import of the json file representing that state, possibly removing current data or maybe leaving it cause it would all be lost on wiki closing anyway.
This would only work for the case where the gunsâ data does not change through user interaction. I would envisage having a separate wiki for each state to allow editing of that states data followed by a JSON export of the data tiddlers.
This has one difficulty (or at least 1 that I can think of). What about those data tiddlers shared between states, for example, details of ships, forts, manufacturers, etc. These could be held in external wiki also I guess but I am not sure about this.
This would only work by using inter-wiki links and having the ability to intercept such a link to load the target tiddlers.
Iâm curious: did you test whether this is necessary at all? I know that youâve had a few performance issues, but I thought those had been solved.
So, assuming you externalize your images, do you still have enough content to make the wiki uncomfortably slow to load? If not, then there are only problems of proper presentation to not overwhelm Dad and Son. There could be real challenges in there, but they do sound eminently solvable.