Re: [tw] TWShell

[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 mains moving 
maintenance from many projects, with decent funding, to a community with no 
funding. 

-mario


-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to tiddlywiki@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/ca04506a-3feb-47b9-9bb9-da7da3a7bb4c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [tw] TWShell

[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  

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to tiddlywiki@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/ff7fe300-abdc-4720-a235-de16a76c12d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [tw] TWShell

[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:
> 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?

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

> 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 
)

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

> 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?
> 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.
> 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.
> A shell for multiple tiddlywikis management is required (e.g. a type of 
> TiddlyDesktopQ  extension). 

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

-- 
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+unsubscr...@googlegroups.com.
To post to this group, send email to tiddlywiki@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit