TWShell

[oleghbond]

Development is a process. Development of Tiddlywiki - is a process too. By itself, any process is purposeless - it is just a manifestation of specific laws under certain boundary and initial conditions. Similarly, with the development of Tiddlywiki - indeed it is the exciting saga for the sake of self-improvement. But really that is not a goal. That is a process.

So, now about specific things. No doubt Tiddlywiki is an outstanding tool for Web content creating. There were said a lot about that. It would be better once to touch it, to come to the same conclusion independently.

However, with all the advantages Tiddlywiki does not lack shortcomings, which significantly slow down its wider use.

Main "stumble stones" in Tiddlywiki use, in my humble opinion, is in the entry resistance of "zero" users (newcomers) who need a tool with a convincing set of capabilities for organization a personal space as well as cooperation in the global network, but who are of little interest to study how it is devised inside.

Reasons

More specifically these "stumble stones" could be described as follow:

• Some inconvenience of use:
  1. Multi-step installation procedure, especially when one runs multiuser tiddlywiki in git-network under Node.js + git + tortoisegit + githab / gitlab.
  2. Control elements for the whole (git-network based) system are not consolidated, i.e. dispersed over various separate software components.
• Intrinsic scalability limits:
  1. A sole tiddlywiki is pretty closed document - all the benefits of internal tiddler use: filtering, transclusion, powerful search, links etc. are not applicable to external tiddlers.
  2. For scalability one tiddlywiki needs permanent links to other (i.e. external) tiddlywikis. Permanent external links are usually achieved by placing a tiddlywiki or its generated static pages under a permanent domain name.
  3. But even the latter is not completely solve the issue: usually a tiddlywiki itself is quite heavy file from several upto several dozen MB; also intrinsic API for external tiddlywiki data manipulation is absent (at least for my knowledge); generated by Tiddlywiki static pages are helpless in this context as well.
  4. Somewhat aside, but equally important for scalability is creating a basic mechanism for multilingual synchronization of several tiddlywikis.

Primary task list

Based on the aforesaid here I formulated a primary task list. It is just my personal vision. So everyone is free to add own issues, however, keeping in mind the two main priorities:

1. ease of installation and management, and
2. scalability as a platform for multiuser web collaboration.

So the primary task list looks like:

1. A single installer is required for all the necessary starting components and settings, including: Node.js, tiddlywiki, git, tortoisegit (if necessary), etc. for main operational systems.
2. A shell for multiple tiddlywikis management is required (e.g. a type of TiddlyDesktopQ extension). Among other things, the shell must be capable of:
   • Interoperable in respect of variety of operating systems and browsers;
   • Locally create, delete, move, etc. tiddlywikis under node.js;
   • Run a separate tiddlywiki under node.js from a file explorer of a given operating system through, for example, double click or a context menu;
   • Carry out a minimum required set of operations to synchronize local and global repos, including: commit, push, pull, diff, etc.
   • Minimum required control over static pages publishing on Githab / Gitlab Pages;
3. Providing a type of mediawiki interwiki syntax for links to external tiddlywikis. For example, a reference to a tiddler from another tiddlywiki may have a look like: [[anotherTW:Interesting staff]]. Realization of certain interwiki web services also is possible.
4. Organizational Page on Githab / Gitlab Pages is a root page for a number of other pages of projects or user groups under this root page. API for automated collection of information about underlying pages for the organizational page is required for further use.

[Jeremy Ruston]

Hi Oleg

Thanks for the notes — I’ve enjoyed your postings over the last few weeks.

Development is a process. Development of Tiddlywiki - is a process too. By itself, any process is purposeless - it is just a manifestation of specific laws under certain boundary and initial conditions. Similarly, with the development of Tiddlywiki - indeed it is the exciting saga for the sake of self-improvement. But really that is not a goal. That is a process.

My own day to day work on TiddlyWiki is generally prompted in a couple of ways:

* By requests from community members. I’ll often implement things because somebody asks for them, and they look fun or easy to do. For example, the new QRCode plugin was prompted by such an enquiry

* By the needs of my own consultancy work through Federatial. These days, most of that work involves TiddlyWiki in some way, and often involves core additions or improvements. For example, the recent work on the XLSX importer was originally done as part of work I was doing for a client

So, now about specific things. No doubt Tiddlywiki is an outstanding tool for Web content creating. There were said a lot about that. It would be better once to touch it, to come to the same conclusion independently.

I’d agree if you’re saying that our goal should be that users encountering TiddlyWiki can immediately see its value.

However, with all the advantages Tiddlywiki does not lack shortcomings, which significantly slow down its wider use.

Main "stumble stones" in Tiddlywiki use, in my humble opinion, is in the entry resistance of "zero" users (newcomers) who need a tool with a convincing set of capabilities for organization a personal space as well as cooperation in the global network, but who are of little interest to study how it is devised inside.

I think you’re saying here that the barriers to getting up and running with TiddlyWiki are too high, particularly if it is on the internet.

I’d make a couple of observations:

* The simplest possible configuration of TiddlyWiki from the perspective of a brand new end user would be a conventional centralised, commercial service, just like wordpress.com

* There are remarkably few barriers for users getting up and running with the standalone HTML file configuration. The main barrier is in practice conceptual: users are generally not familiar with the serverless way of working

* The difficulties with getting TiddlyWiki up and running in the cloud are the same as for any other similarly architected app. In other words, TiddlyWiki on the server is just a pretty standard Node.js app, and there are now a multitude of options for packaging such applications up for easy deployment

More specifically these "stumble stones" could be described as follow:

• Some inconvenience of use:
  1. Multi-step installation procedure, especially when one runs multiuser tiddlywiki in git-network under Node.js + git + tortoisegit + githab / gitlab.

Agreed, but isn’t the answer to perhaps use containers?

• 2. Control elements for the whole (git-network based) system are not consolidated, i.e. dispersed over various separate software components.

I’m not sure what you mean here. Are you referring to the source code?

• Intrinsic scalability limits:
  1. A sole tiddlywiki is pretty closed document - all the benefits of internal tiddler use: filtering, transclusion, powerful search, links etc. are not applicable to external tiddlers.

Well, there’s the _canonical_uri mechanism which enables quite a lot of things to be done with external resources.

• 2. For scalability one tiddlywiki needs permanent links to other (i.e. external) tiddlywikis. Permanent external links are usually achieved by placing a tiddlywiki or its generated static pages under a permanent domain name.

Dat links are another possibility (see https://datproject.org)

• 3. But even the latter is not completely solve the issue: usually a tiddlywiki itself is quite heavy file from several upto several dozen MB;

That depends on the configuration chosen.

• 3. also intrinsic API for external tiddlywiki data manipulation is absent (at least for my knowledge); generated by Tiddlywiki static pages are helpless in this context as well.

Can you elaborate on what you mean here?

• 4. Somewhat aside, but equally important for scalability is creating a basic mechanism for multilingual synchronization of several tiddlywikis.

That’s something that has cropped up in my consultancy work; I believe that we have all the pieces required.

1. A single installer is required for all the necessary starting components and settings, including: Node.js, tiddlywiki, git, tortoisegit (if necessary), etc. for main operational systems.

Mario has done work on packaging TiddlyWiki as a container.

2. A shell for multiple tiddlywikis management is required (e.g. a type of TiddlyDesktopQ extension). Among other things, the shell must be capable of:
   • Interoperable in respect of variety of operating systems and browsers;
   • Locally create, delete, move, etc. tiddlywikis under node.js;
   • Run a separate tiddlywiki under node.js from a file explorer of a given operating system through, for example, double click or a context menu;
   • Carry out a minimum required set of operations to synchronize local and global repos, including: commit, push, pull, diff, etc.
   • Minimum required control over static pages publishing on Githab / Gitlab Pages;

Interesting, I’d like to see that.

3. Providing a type of mediawiki interwiki syntax for links to external tiddlywikis. For example, a reference to a tiddler from another tiddlywiki may have a look like: [[anotherTW:Interesting staff]]. Realization of certain interwiki web services also is possible.

That’s entirely possible via macros right now (eg, <<interlink  “anotherTW” “Interesting staff”>>), and we could add a parser rule for a simplified syntax

4. Organizational Page on Githab / Gitlab Pages is a root page for a number of other pages of projects or user groups under this root page. API for automated collection of information about underlying pages for the organizational page is required for further use.

Have you seen the bag/recipe concepts of TiddlyWeb? It’s a model for server-side sharing of Tiddlers that was developed back in 2008 that has proved solid. It’s the basis of the HTTP interface between the TW client and server.

Overall, I’d like to see TiddlyWiki better serve the needs of multiple audiences:

* commercial services for general users

* easy Node.js app deployment for advanced DIY users

* continued support for the standalone configuration in the browser for most DIY users

Best wishes

Jeremy

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/af9fe0ed-bfbb-42da-99cd-2b5795f0a097%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Josiah]

Ciao Oleg & Jeremy

Great thread. Love the detail. BOTH for its, well, details, but ALSO for instancing THE COMPLEXITY (aka richness).

 

On Sunday, 5 March 2017 09:38:00 UTC+1, Jeremy Ruston wrote:

Overall, I’d like to see TiddlyWiki better serve the needs of multiple audiences:

* commercial services for general users

* easy Node.js app deployment for advanced DIY users

* continued support for the standalone configuration in the browser for most DIY users

Jeremy, simple question: are these THREE routes so identifiable publicly clear yet?

Best wishes

Josiah  

[Jed Carty]

I am hopefully going to be working on some parts of this now. I am hoping to have tiddlywiki be one way to control the robot I am making. The robot is mainly run as a node script and I am hoping to have a wiki running on node that will let you control the robot in realtime by loading a webpage served by the robot. If things work out well I want this to me a flexible interface between a tiddlywiki server and any other node program.

I also just finished a bash script (on GitHub here) that has been helping a lot in streamlining development for me. It checks to see if any plugins need to be updated, if so it builds a demo wiki for the plugin and then builds a directory wiki that lists the plugins (the generated wiki is here). It marks newly changed wikis as in need of testing, when you change this status to ready (you have to do it manually so force you to actually test things and if it is set to upload, it uploads all the changed wikis to the correct places. It also builds a plugin library of the plugins and uploads the updated version if all the plugins have been tested, otherwise it uploads to an alternate unstable library. It doesn't handle committing and pushing to git yet but I am not sure if I want to have that in the same script or not.

Things like this help me a lot with development and hopefully will be helpful to other people. The script is configurable but I am not sure how useful it would be to other people so feel free to leave feedback about what would make it easier to use or more useful.

I am hoping that by making the tools that I use like this usable by other people it will help with things like node.js app deployment. 

I like the idea of making an install script for node, tiddlywiki and git. I have some similar things I have been using to create images for the robot I am working on so creating a version that does tiddlywiki instead shouldn't be a big problem. I will probably work on one that will work on linux and OS X, I don't have any windows machines to work on so I am not expecting to make one for windows any time soon.

[PMario]

On Sunday, March 5, 2017 at 9:38:00 AM UTC+1, Jeremy Ruston wrote:

1. A single installer is required for all the necessary starting components and settings, including: Node.js, tiddlywiki, git, tortoisegit (if necessary), etc. for main operational systems.

Mario has done work on packaging TiddlyWiki as a container.

That was TiddlyWeb, the python based version, in combination with TWclassic and some experiments with TW5.

----

The requested combination can't be done in an OS agnostic way.  nodejs, tiddlywiki and git are available for windows, linux and macOS. .. but tortoisegit is a windows only file-explorer extension.

The second problem I see here is: node, tw and git may be basic requirements without much discussion. ... but git GUIs depend on the users taste. There are a lot of them and reaching consensus which one to bundle will be close to impossible, because the users tastes are different.

----

Packaging different components into a single installer imo will just create a lot of maintenance and it will just shift the problems that come up with the original packages to the bundled package. Which means moving maintenance from many projects, with decent funding, to a community with no funding.

-mario