I have a plan to fix this, but I am uncertain whether it will be practical.
The idea is that when you click “edit” on a _canonical_uri image tiddler then in the background the draft tiddler will be synced to the server. When the server receives the draft via the sync process, it can inspect it and see that it is a _canonical_uri tiddler and then, if possible, it can replace it with the embedded version of the image tiddler.
The effect would be that after clicking the “edit” button on a _canonical_uri image tiddler there would be a brief delay where the _canonical_uri would be shown, and then it would be replaced by the full image for editing.
I kinda figuired you would be moving the loading process to the tiddlywiki.info file at some point. Thanks! can now use MWS out-of-the-box, no code changes required! Will set that up - got about 10 ‘server’ edition wikis that are loaded into the database for testing.
The mischief I have been up to:
The database is shared between MWS and my server by having my server boot up a tiddlywiki multiwikiserver edition which returns a reference to $tw. Thus both systems are using the same database via $tw.mws.store. So techically - there is only a single process accessing the database. Attempts to have two separate processes use the database did not go well.
Two of the TiddlyWikis are multi-user classics - a chat system and a dice game. My server handles the login, bearer token, and session controls (interface to clients via socket.io ). It manages ‘room’ tiddlers for chat and current state tiddlers for each user playing the dice game. Most of which is stored on the database in recipes/bags - got a few tiddlers left to move to it.
Concurrently, MWS is used on a different port to update the client side wikis during development. Was using ‘server’ edition but had to reload the wiki for the changes to take effect. With MWS the changes are live and immediate.
Setting up a reverse proxy so can finally have a demo facing the web. Turns out that is not as simple as it sounds.
Something to the effect of ‘tiddlywiki --mws-load ./mws/store --savewikifolder ./mywikifolder’ would be super handy. Which I am sure is in the works.
MWS is an awesome design and excellent system - works great and is not even finished yet! Having a lot of fun with it.
Attachments are a new feature and I already have found that some type of special handling is needed. Some way for the author to specify a tiddler is to be stored as an attachment regardless of size or type; or specify the tiddler is not to be an attachment.
A checkbox on import should be able to handle that. A default can be automated, but the author is really the one to make the decision. For large media files indicate that due to size it will be saved as an attachment. The attachment checkbox would only be available on the MWS edition (or editions that use MWS).
A similar scenario is how images are handled by server edition. If I wish the image to be in the wiki (which is usually based on if I am going to distribute the wiki as a single file) I drop the image and import it - and the image is in the wiki. If the wiki is going to always be a Node.js wiki, I place the image in the ‘files’ sub-directory and use _canonical_uri. The important thing being - it is my choice.
Attachments should have their own field. _canonical_uri can exist anywhere and the author enters them, messes with them; exist on your machine, on the web, they can change if moved to a different host, etc. _attachment only exists on MWS, the uri is generated by and uniquely handled by MWS, they are special. For example, the author would almost never specify the uri. _attachment should for the most part be totally automatic. Best advise to an author would be to leave it alone - the only thing you can do is break it.
Attachments are a new and substantial addition to TiddlyWiki. The SQLite database has definite advantages but for the most part is transparent - is another tiddler store. But the attachments will be the unsung heroes of the MWS release (well, unless you got a song about them - if so, put it in an attachment). Would not be surprised to see attachments added as a ‘server’ edition feature at some point.
Now is the time to give some thought on how and where to integrate attachments into the TiddlyWiki Architecture; before the release.
From a recent 20 year anniversary meetup Jeremy presented an overview of MWS, during which I possibly had a epiphany,
That the MWS server can host multiple-wikis where a wiki is effectively a recipe, and a recipe contains bags, that the server must have access to all recipes and bags.
Can I ask if someone who understands the direction of MWS can confirm or deny what I am saying and/or consider the necessary features to permit this approach?
I understand it is possible for example for the Sever to “share a set of tiddlers” to all wikis within it, allowing a server distributed set of config settings or content, to all wikis. We may call this a one (server) to many (wikis) relationship.
That each wiki can maintain its own bags, it is possible for a given wiki to share that bag with others or the server in a one to one relationship, or one to many relationship.
What I realized is if in a given (sub)wiki, access is limited to a single user, then it may as well be a private single user wiki, yet because the server can access it, it can define a wiki consisting of multiple single user wikis, the server wiki is in effect able to be a multi-user and multi-wiki tiddlywiki.
Sure each participating wiki needs the logic and tools to deal with what it receives, what it owns and what it shares, but ultimately it can represent a single authorized user of a somewhat “federated wiki”, or multi-user wiki
Thus if we have a multi-wiki server where its wikies are allocated to specific users then we have a multi-user wiki.
The designer will need to design this so the individual users of individual wikis are able to understand what they own and the scope of their influence on the greater wiki. Public, private and shared bags?
It is a correct that a wiki is made from a recipe, and that a recipe consists of a list of bags.
I don’t understand what you mean by “the server must have access to all recipes and bags”; recipes and bags are part of the server and so by definition the server has access to the recipes and bags that it contains.
The terminology isn’t quite right here. The server doesn’t exactly “share” anything; it would be more correct to say that recipes and bags can be setup so that a set of standard config settings or content can be shared between multiple wikis.
Wikis do not necessarily maintain their own bags. Bags are independent entities. A bag may be included in more than one recipe.
The idea at the moment is that access controls will apply to bags, not to wikis themselves. I don’t understand the rest of this section. It doesn’t make sense to say “the server can access it” because of the point above: bags and recipes are contained within servers, and so by definition the server can access all the bags and recipes that it contains.
There’s quite a bit more that I don’t fully understand: for example, the idea of a wiki being “allocated” to specific users, and the idea of a wiki “receiving” something. These are new terms without an established meaning and so might need to be explained to give context to others.
This is the way I am conceptualising it, for the argument I am putting. So yes.
Yes that is the challenge for me to understanding MWS
Or only one recipe that maps to a particular user or wiki?
Yes, I have read this multiple times, and in fact I suppose why am asking is a question of terminology.
Clearly the discussion so far is about multiple wikis, one could even say a server perspective.
I am trying to look at it from the perspective of one of the multiple wikis and or a wiki for a given user.
I am trying to answer two things;
Can we effectively build multiuser wikis where each user can only see or edit particular content and we can design which content is visible or editable elsewhere with appropriate permissions.
The method and MWS terminology we may use to describe this kind of implementation.
Background
It has being a long standing interest of mine to prepare multi-user wikis so teams can work together on tiddlywiki without risks of overwriting or contention, and some rudimentary permissions.
It appears this may be possible with MWS
TiddlyBob went a long way to doing this however is not reliabily maintained or supported, and I dont expect it to be, MWS supported by the core team may prove to be the best solution.
I would [humbly] add on the general topic of MWS that single-user, local solutions which do not require knowing an IP URL have an immediate benefit as well.
There might be some lack of clarity on the plans for such a scenario.
So to be specific: much like running a local TiddlyWiki empty.html file, could an MWS wiki have an emptyMWS.html URL to be used locally by the 1-generation “child” wikis?
(I would assume that this is also greatly possible with a corresponding local sqlite file.)
(If this is possible right now, then please let me know how to do this.)
And then a very related point of clarity: Bags can be drag-and-dropped to another (independent) wiki in a single act of importing a group of Tiddlers. When performing this identical action subsequently, does this mean that the bag still has enough definition in the receiving wiki, as to replace all old/altered locations of Tiddlers in the bag? I guess treating a bag like a plugin?
This would (desirably) mean that Tiddlers’ paths that are changed in the “upstream” bag - and Tiddlers that are deleted in the “upstream” bag - are also changed in the receiving local wiki after a new import of the bag. Note that this is different than a typical Tiddler export/import.
In this way, users could choose between a typical import and a bag import technique. Sometimes users want to import deletions and absent Tiddlers, but other times not.
MWS is a not primarily a file server. If you see a file:// URL in a browser, it means that the browser did load the file directly from your local drive. There is no intermediate server with the configuration you describe.
As soon as there is a client / server configuration you will have an http(s):// URL protocol and a localhost domain name.
So an empty MWS wiki would look like this: http://localhost:8080/empty.html
Loading a file:// TWs is possible right now without MWS.
You will need to define your **Download Settings**, if you want to overwrite your file
I’m using Edge for the screenshots to show the browser default save mechanism.
Browser Settings → Downloads → Ask me what to do with each download and
Browser Settings → Downloads → Show downloads menu when a download starts
No – Bags can not be dragged and dropp imported into other wikis. A bag is a configuration file.
Bags are no plugins. Plugins are tiddlers with a type:application/json, that contain several other tiddlers, which are activated at wiki-startup.
A bag is an abstract configuration element, that contains meta data that defines which tiddlers should be requested from the database. This can be content tiddlers and could also be plugin tiddlers.
A recipe is a second configuration, that defines, which bags should be used to create a wiki. eg:
recipe - myPersonalWiki
bag: system … could contain the TW core, themes, palettes
bag: sharedPlugins … could contain plugins that I want to use with several wikis
bag: personalContent … Would contain some personal but public tiddlers
recipe - myWorkWiki
bag: system … could contain the TW core, themes, palettes
bag: sharedPlugins … could contain plugins that I want to use with several wikis
bag: workRelatedPlugins … could contain other plugins only needed fro work related stuff
bag: myWorkContent … Work related content
If the recipe myPersonalWiki is opened all the tiddlers in the bags, which are listed in the recipe will be loaded. The principle is: The last one wins
So tiddlers in the personalContent bag are loaded last and will overwrite everything from bags which are listed prior to personalContent.
eg: sharedPlugins may contain plugin-A – If you import a newer version of plugin-A into your personalContent bag, those plugins will be activated. Overwriting the plugin from sharedPlugins.
Everything in workRelatedPlugins will overwrite tiddlers from system and sharedPlugins – If and only if, there are tiddlers with the same title.
So the user is in full control of their content
Changes in every bag should be dynamically updated. But if plugins which contain javascript code are updated a browser-tab reload will probably be needed.
I do not know, how this is resolved in MWS at the moment. So @jeremyruston will need to jump in here.
MWS (Multi Wiki Server) plugin - is a plugin itself. It contains server side and client side functionality, that can be activated with a node.js command, which Jeremy explained in more detail at the last “hangout” – You can watch the whole thing to get more info about MWS.
To test that edition, it will be needed to have a development environment. So it is not ready for production yet. But is should be tested by interested users to get feedback. – As Jeremy called it in the live-stream. “The more feedback he gets, the more motivation he has to improve it”.
I suppose that’s the crux of these uncertainties about the whole thing. I’ve been wondering if I could work from the assumption that at least eventually this will be a plugin like other TiddlyWiki plugins that I can install on a local TiddlyWIki file.
Yeah, “server” is a term very often used in so many different technical concepts. Such a local instance would still be appropriate to refer to the MWS as a server of sorts, because the local files could still point to it. They are proverbial “clients” of the MWS either way.
In the more literal IP server interpretation, it also seems quite feesible that the server could very reasonably be conceived as a feature add in some regard - meaning that it doesn’t necessarily have to be an absolute statement of all functions. It also means that subtracting the server portion might be on the somewhat easier side of development.
There has been some stress on maintaining typical philosophies of TiddlyWIki. For these reasons, it seems that a local instance that could still be regarded loosely as a server by other local files could be in the plans - or even become part of the plans. My conception is also that MWS truly is not wholly and completely nailed down absolutely in terms of feature set.
It can be installed like a plugin, but it has a server component too. So installing it into a single file wiki will not really help here.
You may be interested in: Use WebDAV for saving a single file wiki, which is production ready, with it’s own complexities. It describes several methods to save single-file wikis on a home-network using WebDav.
You are right MWS is a server addOn, that will activate an SQLite database file as a data-store.
In contrast to the “file based store” of the standard Node.js-server
SQLite has some properties that align very well with the TW philosophy. Especially "compatibility"
From the SQLite homepage:
What Is SQLite?
SQLite is a C-language library that implements a small, fast, self-contained, high-reliability, full-featured, SQL database engine. SQLite is the most used database engine in the world. SQLite is built into all mobile phones and most computers and comes bundled inside countless other applications that people use every day. More Information…
I did highlight some elements (and removed the links), that are almost the same wording that we use for our single file TiddlyWiki’s.
The SQLite database also is a single-file, where the developers want to guarantee compatibility at least up to 2050.
The SQLite file format is stable, cross-platform, and backwards compatible and the developers pledge to keep it that way through the year 2050. SQLite database files are commonly used as containers to transfer rich content between systems [[1]][[2]][[3]] and as a long-term archival format for data [[4]]. There are over 1 trillion (1e12) SQLite databases in active use [[5]].
As I wrote at the beginning of this post. You may be interested in the WebDav servers and may be also in the Node.js server, which are well tested.
I think the feature set of MWS is already very clear, since it is very very similar to what we had for TiddlyWeb and TiddlySpace (which are discussed in the video I did mention) – Only the technology which is at our hand now, has evolved quite a bit.
Unfortunately part of the entire point of what I’m saying is about including use cases that avoid these types of servers. That’s obviously specifically one of the coolest things about TIddlyWiki!
The case of simply running from files in an application is so much simpler that it seems quite worth it! Avoid as many daily usage oddities as possible.
I was not even foremost trying to push the features here, because it’s the wrong place - just really wanted to get some clear specifics nailed down. However, if not for MWS, consider these functions for Tiddly Desktop.
I’m in the throws of considering learning development, but unfortunately I have my doubts about the refinement of my own personal attempt. Nevertheless, this has been influential. If I end up creating anything worthwhile, then it might be of interest (or even then it might not)
As was clarified in the last 20 year anniversary stream, now video, you will always be able to generate and use a single field wiki from one composed by MWS. As was highlighted, even the current empty.html is currently generated by a the existing node server implementation. So the single file wiki continues to live a long side or on top of a server version which itself is constructed from files on GitHub.
If I understand your interest you are interested in a stand alone wiki solution with its own saving, is that true, independent of a server?. Have you played with the now aged tw.exe and mht file versions.
I’m hoping the localhost is not essential for anything here! I often update my host file to create other local server names, still pointing to 127.0.0.1.
Node listen permits any local address from 127.0.0.1 to 127.255.255.255 I tend you use 127.0.4.1 and may add name in the hosts file to give it a name.
Personally I think changing away from the 127.0.0.1 is wise because there are a lot of server like solutions that use this address and may not permit changing it.
However the approach I prefer is to add another (static) IP Address to the computer on which it runs such as 192.168.4.200 which is in the same network and a host file entry;
servername 192.168.4.200
Use this address in the listen command
Now all links I use are to the server use servername
Later,
I can move the IP Address to another computer
I can move the server name into DNS (Delete host entry)
I can change the IP Address on the server in DNS
all without changing stored links.
One advantage of another local address is you can use port :80 rather than 8080 so there is no need to provide the port number in the address as 80 is default for loading html
I hope this approach can be applied to MWS @jeremyruston
