Announcing the MultiWikiServer Plugin

#85

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.

node ./tiddlywiki.js ./edtions/multiwikiserver
   --mws-load-plugin-bags
   --build load-mws-demo-date
   --mws-listen

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”.

#86

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.

#87

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]].

SQLite source code is in the public-domain and is free to everyone to use for any purpose.

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.

#88

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)

#89

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.

#90

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.

#91

You can use any name as long as there is a configuration in the hosts file, so the network stack can find it.

#92

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

#93
#94

Quando, Quando, Quando … :wink:
Sorry for the unqualified and impatient post.

1 Like
#95

Ha detto che quando lo saprà me lo dirà.

#96

I wasn’t aware of this - is there documentation about what exactly is supported?

EDit - I wasn’t aware because have only recently had the interest. Multi-user is documented fairly well.

Mainly:

  • Basic Authentication (login)
  • Credentials (readers/writers control)
  • User Names for editing.