Move tiddlywebadaptor and filesystemadaptor into the core

[Jermolene]

The plugins tiddlywiki/tiddlyweb and tiddlywiki/filesystem currently need to be specified manually for wikis that need client-server functionality.

This is the reason that the core provides both a tw5.com edition and a tw5.com-server edition; the latter includes the former, but adds the two plugins.

For end users, it means that the instructions are complex for setting up a wiki that is to be used both to build standalone HTML files and serve over HTTP.

We could move the two plugins into the core to avoid this. They would add approximately 20KB to the size of the core.

Neither plugin currently has any means of configuration; if they are loaded in a wiki then they will attempt to perform their respective tasks.

We'd need to provide a means to disable the filesystem adaptor for wikis that shouldn't write their changes back to the file system. For example, the external images build process currently modifies image tiddlers to add the "_canonical_uri" field. We wouldn't want those modified images to be written back to the wiki folder. So, we could provide a new config.writable entry in tiddlywiki.info files that disables the filesystem adaptor when set to "no". Sadly, it would not be a backwards compatible change unless we perhaps used "no" as a default, and accepted the presence of tiddlywiki/filesystem in the plugins list as an alternative way to trigger "writable" mode.

The tiddlyweb adaptor would need to gain explicit configuration to tell it to attempt to sync to a particular server. Perhaps $:/config/TiddlyWebServerURL might be interpreted as the base URI to attempt to sync to; if the config tiddler were missing or blank, then no attempts to sync would be made.

[pmario]

What if we move the server configuration, into its own section in the tiddlywiko.info file. Similar to the "build" section.

eg:

{
    "plugins": [
        "tiddlywiki/nodewebkitsaver",
        "tiddlywiki/github-fork-ribbon",
        "tiddlywiki/browser-sniff"
    ],
    "themes": [
        "tiddlywiki/vanilla",
        "tiddlywiki/snowwhite"
    ],
    "languages": [
        "en-GB"
    ],
    "build": {
        "index": [
            "--rendertiddler","$:/core/save/all","index.html","text/plain"],
        "encrypted": []
    },
    "present": {
        "index": {
            "plugins": [
                "tiddlywiki/tiddlyweb",
                "tiddlywiki/filesystem",
                "tiddlywiki/codemirror",
                "tiddlywiki/highlight"
            ],
            "server": {
                "port": "8080",
                "roottiddler": ""
                "rendertype":"",
                "servetype":"",
                "username":"",
                "password":"",
                "host":"",
                "pathprefix":""
            }
            "config": {
                "default-tiddler-location": "./tiddlers"
            }
        }
    },
    "config": {
        "retain-original-tiddler-path": true
    }
}

So we can call it like this:

• tiddlywiki ./editons/tw5.com --present index
• tiddlywiki ./editons/tw5.com --present index --server ... will overwrite the settings used in tiddlywiki.info

I would use --serve instead of --present, but it is too similar to the --server command.

[pmario]

If the above is too complicated, the "present" section could look like this too.

"present": {
        "index": [
            "--plugins","tiddlywiki/tiddlyweb","tiddlywiki/filesystem",
            "--server", "8080", "$:/core/save/all", "text/plain", "text/html", "username", "password", "host", "pathprefix"
            ],
        "myindex": [
            "--addplugins","tiddlywiki/tiddlyweb","tiddlywiki/filesystem",
            "--removeplugins","xxxx",
            "--server", "9090", "", "", "", "", "", "10.0.0.6", ""
            ]
}

So imo most code, which manages the "--build" command could be reused.

[Jermolene]

What if we move the server configuration, into its own section in the tiddlywiko.info file. Similar to the "build" section.

How we manage the server configuration is orthogonal to whether we move these plugins into the core. But I agree about using tiddlywiki.info for server configuration.

So imo most code, which manages the "--build" command could be reused.

In fact, your example would already work in the build section of tiddlywiki.info.

"--addplugins","tiddlywiki/tiddlyweb","tiddlywiki/filesystem",

Note that I'm not suggesting that we add an "addplugins" command. It would be hard to do, since by the time the command is executed we've already constructed the wiki object. I'm suggesting moving the functionality of those two plugins into the core.

[Spangenhelm]

Hi @Jermolene since everyone does not need it, or not all the time, even though it is really lightweight i am against including it in the core but rather leave it as plugins, plus, with the new awesome library feature to find and install them it is easier than before.

[Jermolene]

Hi @Spangenhelm the filesystemadaptor is 10KB and the tiddlywebadaptor is 15KB, so they are a very small proportion of the core plugin (currently 1.2MB). Annoyingly, the plugin library can't be used to install these components under Node.js; one has to edit the tiddlywiki.info file.

[pmario]

I think the biggest win is, that we can get rid of the xxx-server editions. see OP

This is the reason that the core provides both a tw5.com edition and a tw5.com-server edition; the latter includes the former, but adds the two plugins.

[Spangenhelm]

@pmario you are right, but for this we need an easy way to add the two plugins to our project and, as @Jermolene said, we can't under node.js, editing the .info is no big deal but that is not what i would call "easy" or "practical".

What about this: to not use the .info to handle the plugins but rather use the folder containing them to know what to load and what to not. This way we just have to copy them into the plugin folder and we are good to go! So easy to handle, you want one you add it you don't want one you delete it!

[Jermolene]

What about this: to not use the .info to handle the plugins but rather use the folder containing them to know what to load and what to not. This way we just have to copy them into the plugin folder and we are good to go! So easy to handle, you want one you add it you don't want one you delete it!

Do you mean that there would be an independent copy of each plugin in each wiki folder that uses it? That can already be done; TW will load plugins from a plugins folder within the wiki folder.

The trouble is that it's not convenient for bulk upgrading; better for each wiki to reference a central repository of plugins, as provided in the TW5 distribution.

[danielo515]

I'm totally against this idea. What we have to do currently with the core is tho shrink it, not make it fastest. Adding two lines of text to the tiddlywiki.info file is not a big deal. In fact the init command does this already, so I don't see the benefits. In fact I only see problems with this. You have already described a new scenario that I found more complex and complicated that the current one! You have to manage several new configurations, add metadata fields to the Tiddlers just to make them behave normally. And even worse, it is not backwards compatible. There are other features very needed for every scenario that you have discarded just because they are not backwards compatible. Definitively a non go for me

[Spangenhelm]

@danielo515 :ok_hand:

[tobibeer]

How about a --serverbuild command that essentially extends the --server command with a specified build target (as its first parameter)? That might do away with requirements for extra editions.

[pmario]

Since the ticket is about 1 year old and we didn't have many issues, with the tiddlywiki.info file, the way it is. I think it should be a "wontfix"

The ticket should make the workflow easier, but I think the second part of the OP also introduces new complexity, that is even more complicated a the status quo.

We'd need to provide a means to disable the filesystem adaptor for wikis that shouldn't write their changes back to the file system. For example, the external images build process currently modifies image tiddlers to add the "_canonical_uri" field. We wouldn't want those modified images to be written back to the wiki folder. So, we could provide a new config.writable entry in tiddlywiki.info files that disables the filesystem adaptor when set to "no". Sadly, it would not be a backwards compatible change unless we perhaps used "no" as a default, and accepted the presence of tiddlywiki/filesystem in the plugins list as an alternative way to trigger "writable" mode.

The tiddlyweb adaptor would need to gain explicit configuration to tell it to attempt to sync to a particular server. Perhaps $:/config/TiddlyWebServerURL might be interpreted as the base URI to attempt to sync to; if the config tiddler were missing or blank, then no attempts to sync would be made.

Also hardcoding those 2 plugins into the core will introduce the need for a --remove-plugin option, if new adaptors will be developed in the future.

So that's why I think, we should stay with 2 configurations, because they actually are 2 different editions. .... but as always there will potential for better docs ;)

[pmario]

@Jermolene ... IMO not needed anymore. We do have the tiddlywiki +plugins/tiddlywiki/filesystem +plugins/tiddlywiki/tiddlyweb editions\empty --listen command syntax now.

IMO should be closed

[Jermolene]

Thanks @pmario