How does innerwiki sync to other servers?

How can do this ?

Problem Background

Because MWS is slow to develop, I have been trying to find other solutions. What I want is one where all the data is stored in a TiddlyWiki, but I can have multiple launch options. There are different layouts that I can set according to different launch options. Display different data. For example, the Life section displays life-related content.

I’m currently trying to solve this problem using tidgi, but I wish there was a more native solution. But it seems like there has to be a launcher that stores various startup parameters. Similar to tidgi, but maybe there’s a better solution. Have any nodejs users tried this?

Perhaps you could describe why and what you mean by different launch options. Why at launch. It is possible to provide parameters to tiddlywiki on a url or to the innerwiki plugin or radicaly alter how the same wiki is displayed.

What perceived problem’s are you trying to address, what started you on this journey.



I can explain it with the current plan. I’m currently using tidgi, a launcher that allows me to repeatedly add the TiddlyWiki of nodejs. So the three pictures above have a common nodejs folder behind them, rather than three nodejs folders. The reason why this can be achieved is that tidgi will assign a dedicated port number and workspace ID to each wiki added, regardless of whether it duplicates the existing wiki or not. After starting TiddlyWiki, corresponding info tiddlers will also be generated, such as’ $:/info/tidgi/workspaceID '. Based on these info tiddlers, I can directly enter the corresponding layout when starting a certain wiki. Of course, only the default layout and flex layout are shown here. In the future, I will write some custom layouts.

This can achieve what I need. All the data is stored in one TiddlyWiki folder, and there are multiple different display schemes at the same time. Why not switch layouts within a TiddlyWiki? Because switching layouts is relatively troublesome, and more importantly, the status tiddlers cannot be changed. For instance, if I need to search for AAA, I also need to leave a record of searching for BBB. If they are only in one TiddlyWiki, they cannot coexist. After all, the bottom layer is a status tiddler, unless we save it.

This current solution is quite good. You can even see that in the same folder, there are three different palettes. In the future, there can also be different fonts, and each tiddler has a different button. After all, a workspace is only responsible for its specific related content and doesn’t need all the buttons.

However, the biggest drawback of this solution is that it must rely on tidgi. Without tidgi, it cannot run smoothly. There can only be one layout or constantly switching layouts. I hope to see more native solutions. But I still can’t find it for now.

innerwiki might be a breakthrough point. By leveraging nodejs local data, an innerwiki can be generated. Meanwhile, the data saved in the innerwiki can be placed back in the local folder instead of having to generate html to save it. If innerwiki can achieve synchronization with other servers, I think it will be very influential. I saw someone write a similar component using just a few dozen lines of code, but the data still needs to be saved as html to save it. I hope innerwiki can save the tid data locally like nodejs does.

Interesting, i think i understand now.

Each wiki would be a session in a browser tab or embeded browser. Because they are launched on top of node they save to the server.

Innerwiki is built from commands, tiddlers and payloads in its parent. The default is similar to empty.html. as a result it saves with the default download saver. If an innerwiki is created from a html wiki be careful or the innerwiki can save over the parent.

However if you look deep into the innerwiki process you should be able to craft any wiki you want, even one that uses the node saver, but again you may need to set the right values not to overwrite

There are some technical details of innerwiki here. It would be even better if this solution could be feasible and documented as Jeremy mentioned above. Apart from how to implement it, I am also very concerned about the impact of this innerwiki on performance. Since the parent Node.js is also constantly running, is it better or worse in terms of performance? If the performance becomes faster, I will be very happy and willing to share this solution. If the performance deteriorates, only a few people who can tolerate this change can accept it.

@jeremyruston Could you explain to us how it is achieved?

It sound like what you would need there is just an iframe pointing at the other server.

Innerwiki works by the client side code using the a save template to create a the text of a TW HTML file that contains the specified tiddlers. The HTML text is then pushed into an iframe - while iframes usually display whatever is found at a target URL, but it is also possible to use open/write/close methods to load arbitrary HTML into the iframe.

My understanding you’re trying to use the Node.js syncer architecture within the innerwiki iframe to sync to another wiki, the problem is that the syncer expects to sync back to the server from which the wiki was loaded. There is no origin server for innerwikis, and there is no provision to sync with an arbitrary URL.

I have an idea. We only need one Node.JS, but it needs to be started multiple times to ensure there are different ports. As shown in the picture above, I embedded another one in the running entry, but the edited data can be saved in the same place, that is, both are displayed. I think this might be a form that TiddlyWiki refers to itself. I’m not very tech-savvy, but in a sense, this might be achievable. Even just through a Node.JS plugin. Just provide the given file path and port number, and start it locally.

This is a bit like one browser within another. I can even view the data in other nodejs tiddlywikis because essentially it’s connected to a local port.