Shopping for Android & Windows -- Systems the world uses ... :-)

[@TiddlyTweeter]

 1 -- Android --- Quinoid (might be #2 if it had any competition)

 2 -- Windows browser --- Firefox + Timmimi

 3 -- Windows desktop --- TiddlyDesktop (could be #1 or #2 if it were slightly more like a browser, fully portable & updated a bit more often)

 4 -- Easiest development environment -- BobEXE (serious productive work without having to learn node)

 (5 -- TENTATIVE ... Windows "ANY Browser" --- Universal Restore System [currently just proof of concept, but might become #1 or #2 because it makes saving use one method for all and every browser])

Heavy Opinion on main options :-)

And yours?

Josiah

[@TiddlyTweeter]

Repeat for email ...

[Riz]

Let us consider the possibilities.

If we are looking for a solution external to browser, there is a couple of issues.

First, TW5 does not store the save path anywhere in its body and rightly so. This means there is no way for any solution to know where to move the latest TW5 file to. So it comes down to the user to tell the saving program where to save the wiki. Best case scenario, user has to create a settings file outlining which html file to move where. User has to do this for every wiki he ever uses and will have to edit it everytime he moves wiki or renames it. More importantly, power shell or bash cannot be the language of choice for this because that would mean separate scripts for different platforms, which would defeat the purpose of creating a unified solution (and pardon me Oh Lord, for I just called power shell a language). Node and Python are options. However, windows users might need specially created executables with third party softwares, while Linux and Mac users would need to install the said languages just to run the script, sometimes specific version of the said languages (looks at python intendly). That would leave us with C family, Rust or Go to write up a cross platform solution.

Oh did I mention user also have to remember to start up the program every time he launches the wiki. Consider someone who uses Dropbox folder to sync his TW5s. One day he forgot to start up the saver script as he had a lot in mind. He reaches office only to realise that all his edits from home exist only in the download folder of his home PC. Boy! would he ditch such a solution a fast.

For what it is worth, there is an existing solution resolving atleast some of the issues I mentioned above and that is Tiddlyserver. In tiddlyserver, you can mention entire folders in the settings file, so that even if you rename the file, it would save on merit of being in the directory. If you are up for installing node js and want one solution to work across your devices, and is confident that you will remember to start the server everytime, you do not need to look further than Tiddlyserver. However Tiddlyserver is more of a solution for those who already bought into the ecosystem. You need to install node, manually edit the JSON settings files and all. For anyone attempting to create such a solution in future, I would recommend TOML instead of JSON for settings file to provide a less jarring user experience.

Finally there is the issue of resolving name conflicts. How to set that logic. Let us assume I have a TW5 named "tiddlywiki.html". The logic would be as follows.

Script should watch the download folder, whenever a file named "tiddlywiki.html" appears in the folder, it should move the file to a proper location. So you save your TW5, "tiddlywiki.html" appears in download folder and is moved to its location, overwriting the file there. All good so far. However, after working for a couple of hours, you go and download the official tiddlywiki.html from tiddlywiki.com. Guess what just got overwritten?

Now change the name tiddlywiki.html with something like "annual reports.html" and you will understand the gravity of the situation. Even if set up a proper back up solution to prevent losing works entirely, it doesn't discount the fact that files will end up in unintended folders.


My point is, it would be logically unreasonable to think that any Tiddlywiki user would have more number of browsers than the number of Tiddlywiki html files. So even if we create solutions that would require separate set up per browser, it would take 2 or maximum 3 set ups per user. While powershell scripts and the like would take repeated manual intervention from the user, way more error prone and would be in general a hack. It would be my pleasure to be proven wrong. Who knows, TW5 could be the frontrunner for powershell renaissance.


Sincerely,
Riz

[Mark S.]

On Tuesday, May 21, 2019 at 12:02:59 PM UTC-7, Riz wrote:

Let us consider the possibilities.

> More importantly, power shell or bash cannot be the language of choice for this because that would mean separate scripts for  different platforms,

What? Users already have to use separate technologies for Firefox, Chrome. They have to launch different versions of Bob or Tiddlyserver for different platforms.

Having different scripts for different platforms is perfectly reasonable and isn't an impediment to adoption.

 

> Node and Python are options. However, windows users might need specially created executables with third party softwares, while Linux and Mac users

Some people will be uncomfortable, or prohibited, from installing executables on their platforms. Installing additional tools may also leave the machine vulnerable to additional hacks.

 

> Oh did I mention user also have to remember to start up the program every time he launches the wiki.

You could launch the script from the startup directory. I have to launch Bob, Tiddlyserver, or node.js whenever I want their services. This is similar.

Powershell isn't a full-fledged language, but for this task it doesn't need to be. You could argue that installing Python or node just to save your TiddlyWiki file is like using a steam shovel to serve up breakfast.

> For what it is worth, there is an existing solution resolving at least some of the issues I mentioned above  and that is Tiddlyserver. In tiddlyserver, you can mention entire folders in the settings file, so that even if you rename the file, it would save on merit of being in the directory. 

Currently, TiddlyServer 2.0 doesn't work on my system. TiddlyServer 1.0 works and is great, but it does require installing node and configuring a JSON file.

> Finally there is the issue of resolving name conflicts. How to set that logic. Let us assume I have a TW5 named "tiddlywiki.html". The logic would be as follows.

The solution, is to always use unique file stem names. Perhaps those instructions could go in bold print. Sometimes you can't save people from themselves. But it's not as bad as you thing. More below.

> Guess what just got overwritten?

First off, nothing will get overwritten unless you have, contrary to the directions, deliberately told the script to save to TiddlyWiki*.html

Second, nothing you need will be overwritten!  There are two scenarios. One is that you download while working on an open file which you have foolishly called TiddlyWiki.html. In that case you will continue to save, and each of those saves will be to your download directory -- the files being saved are still the correct file! The file in the original location will be written over just once by TiddlyWiki.html. But all the rest of the saves will write over that one, fixing the problem.

The second case is that you download but don't have your TiddlyWiki file loaded. When you do load your TW file, immediately you will recognize that something is wrong. You have the wrong file. But your saved work, the last time you saved, is still in the downloads directory. You can delete or rename the offending tiddlywiki.html in the downloads directory, and then copy over the last, correct tw to it's target location. The point is, your actual data is saved.

I'm not fond of Chrome, but currently it has 60% of the browser market. Firefox no longer offers significant advantages over Chrome, and has a market share of less than 5%.

Having a browser-agnostic, non-executable option is just one more tool for making saving easier in TiddlyWiki

-- Mark

[TonyM]

Some quick notes

Because I am not sure I understand this conversation. A bit off topic perhaps - but real information.

1. In your browser such as FireFox (and others?) you can set "let me choose the download location every time", When using the default download saver drop your wiki in a folder on its own,  just replace the existing file.
2. Timimi on Firefox is set and forget - for single file wikis from any folder and save to any folder
   
3. Bob.exe is very easy to use without trying to do anything special.
4. In TiddlyServer you can add a folder or more to settings, and browse for you single file or Folder based wiki without an entry in any file. A Virtual or physical folder structure can be used/created.
5. On Windows renaming a file to tiddlywiki.hta uses Internet Explorer and can save locally
   
6. On SharePoint renaming a file to tiddlywiki.aspx uses any browser and can save back (store in a webPages library for speed and checkout to one editor)
7. TiddlyDesktop lets you make use use of higher desktop privileges allowing links in file or folder wikis that let you open File explorer, default Browser or even executables.
1. Did you know file://c:/ in firefox creates a directory you can browse and dragging and dropping files found there on TiddlyDesktop captures the full local file path?, also you can drag items in FF address bar as well.
8. Installing AMPPS MAMP etc.. allows you to host wikis on a local apache server and use TW-receiver, set an forget
9. With the forthcoming local storage plugin you can work and save in local storage then download like in option (1) every now and then as a backup, let Windows add the version to the file to keep multiple backups, if you loose the local storage, return to the original site and import the latest backup.
10. Installing vanilla nodeJS lets you make use of static tiddlers, serve files from you desktop to your browser so you can load only those at a time if you wanted on large wikis.

 PS New version firefox is challenging Chrome

Regards

Tony

[@TiddlyTweeter]

Thanks Riz for your detailed response. 

I add a few comments later. I need think on it a bit more to be fair.

But before I do comment I think its useful to say that what I (and maybe Mark S.?) twigged is NOT the Save problem but, rather, we are dealing with the RESURRECTION Problem (Mark can do it, I can only talk about it).

Resurrection from the Download swamp got interesting. An unforeseen consequence of "web standards"? Basically most every browser now standardises on agreed Download directory. 

Good news for WIDE solutions, I think?

Best wishes

Josiah

[@TiddlyTweeter]

Ciao TonyM

I appreciate your overview. Its accurate and useful.

BUT I was only meaning SINGLE FILE WIKI.

Concerning the specific issue ... well actually the thread went different than I thought it might ;-) lol.

For the SPECIFIC issue I was mainly interested in was limited to exploring whether usage of the Downloads folder TW could enable a UNIVERSAL RESTORE method?

Frankly I am fed up with discussing Chrome & Firefox, as if they were the world.

EDGE, for instance, is very good if you want to explore using verbal commands. TW can't save it.

IMO the further TW can get towards Generic  solutions the better.

Would it not be better to have ONE method on Hans Solo?

One method to RESTORE wiki, whatever the browser?

That IS the question.

Best wishes

Josiah

[@TiddlyTweeter]

Riz wrote:

Let us consider the possibilities.

If we are looking for a solution external to browser, there is a couple of issues.

First, TW5 does not store the save path anywhere in its body and rightly so. This means there is no way for any solution to know where to move the latest TW5 file to. So it comes down to the user to tell the saving program where to save the wiki. Best case scenario, user has to create a settings file outlining which html file to move where. User has to do this for every wiki he ever uses and will have to edit it everytime he moves wiki or  renames it.

You are right.

But I think the issue here is whether the chance of dysfunctional dead-end is any worse than normal?

More importantly, power shell or bash cannot be the language of choice for this because that would mean separate scripts for  different platforms,

Are you sure? What I mean is: we ARE on different platforms already.

 

Oh did I mention user also have to remember to start up the program every time he launches the wiki.

I'm not sure this would Now be anymore of a problem than it is already? What makes it different here already?

 

Consider someone who uses Dropbox folder to sync his TW5s. One day he forgot to start up the saver script as he had a lot in mind. He reaches office only to realise that all his edits from home exist only in the download folder of his home PC. Boy! would he ditch such a solution  a fast.

I love Mr Dropbox. This issue I think I agree with.

For what it is worth, there is an existing solution resolving atleast some of the issues I mentioned above  and that is Tiddlyserver. In tiddlyserver

I'm sure that is true. But it over complicates the issue.

Maybe I did not make clear enough. Single Wiki. Whatever Browser. Enabled auto-restore on save. 

Seems reasonable?

Best wishes

Josiah

[TonyM]

Josiah,

Thanks for clarifying. Why do you focus on restore rather than save?

A universal solution would be great, and anything is possible especially with skills and creativity. The issue with universal is it needs work throughout the universe. Perhaps the top 3 to 5 browsers would go 99% of the way. Wrapping some of the solutions in an install may help.

However I would put my money on ensuring tiddlywiki complies with progressive web apps, PWA. In some ways tiddlywiki was this before pwas existed. I expect pwas to be possible on all top browsers and platforms in time.

Despite the nay sayers persistent storage on the client is possible and top solutions depend on it already. Even if the client opt in process needs to mature.

But perhaps there are other ways. We will find them as a team.

Regards
Tony

[@TiddlyTweeter]

TonyM wrote:

 

Thanks for clarifying. Why do you focus on restore rather than save?

Good question.

Simply, Restore from Downloads looks like THE closest thing to a Global Method.

It would work with any browser.

Josiah

[Mark S.]

On Wednesday, May 22, 2019 at 3:22:09 AM UTC-7, TonyM wrote:

 

> Timimi on Firefox is set and forget - for single file wikis from any folder and save to any folder

Doesn't work with Edge, or Vivaldi, or Chrome.

> Bob.exe is very easy to use without trying to do anything special.

Doesn't save/load single file TW's.

> In TiddlyServer you can add a folder or more to settings, and browse for you single file or Folder based wiki without an entry in any file. A Virtual or physical folder structure can be used/created.

TS 2 doesn't save single files on my system. It's part of the reason I'm thinking about other approaches.

> On Windows renaming a file to tiddlywiki.hta uses Internet Explorer and can save locally

Doesn't help for Chrome, Vivaldi, FF, ...

> On SharePoint renaming a file to tiddlywiki.aspx uses any browser and can save back (store in a webPages library for speed and checkout to one editor)

 

I seem to recall that this was a commercial subscription that was required.

> TiddlyDesktop lets you make use use of higher desktop privileges allowing links in file or folder wikis that let you open File explorer, default Browser or even executables.

TD installed takes almost 300 megs of space. Not a lightweight, portable, browser-powered solution. Also, for me, it would really help if it didn't require reboot whenever you re-opened a data folder TW.

 
   > Did you know file://c:/ in firefox creates a directory you can browse and dragging and dropping files found there on TiddlyDesktop captures the full local file path?, also you can drag items in FF address bar as well.

You'll need to explain how to get this to work. I've tried multiple times and haven't succeeded. I think you're saying if you use FF as a file browser you can drag and drop. Have to try that.

> Installing AMPPS MAMP etc.. allows you to host wikis on a local apache server and use TW-receiver, set an forget

I don't think installing and forgetting a full-blown apache server is a good idea for most people. You've opened up a world of security concerns. I bet there's a fair bit of "setting" before you ever get to the "forgetting" part.

  > With the forthcoming local storage plugin you can work and save in local storage then download like in option (1) every now and then as a backup,

Jeremy has told us that the local storage plugin shouldn't be considered as a storage mechanism. It is used in other apps, so, let's see. The main thing is that you lose transparency. Without deleting your profile you can't be sure that you've removed all traces of your original file.

> Installing vanilla nodeJS lets you make use of static tiddlers, serve files from you desktop to your browser so you can load only those at a time if you wanted on large wikis.

Not a single-file TW solution. Requires node to be installed and a server to be continuously running.

  > PS New version firefox is challenging Chrome

No, it's not. Did you know that 90% of Mozilla's revenue comes from Google? Do you really think G will
let Mozilla create a truly competitive product?

I've heard promises of improved browser performance since the dawn of the internet. It never happens.
The only thing that improves actual performance is hardware and bandwidth.

Mozilla could improve usability, however, simply by bringing back extensions. But of course, G wouldn't like that.

-- Mark

 

[@TiddlyTweeter]

I just want to add one simple observation on Mark's comments.

I do NOT think its healthy we habituated ourselves to Chrome OR Firefox talk.

TiddlyWiki should USE browsers, not be a Slave to any specific one.

Who is Commander? TW or Browser?

Thoughts

Josiah

[@TiddlyTweeter]

Mark S. wrote:

Doesn't work with Edge

Small footnote. Love it or loathe it, Edge is a an interesting browser in its integration with its OS. One thing, is its recognition of vocal commands is very good. Very good.

I see no reason its not on the same TW footing as Firefox and Chrome.

I hope we can get there.

Best wishes

Josiah

[Riz]

Let me clarify my comment. I did not want to promote an external solution in any language, be it python or node or bash for this purpose. My point was, any solution for single file TW5s that doesn't involve browser will have multiple edge cases, restrictions and will be a short sighted solution.

As for timimi not supporting chrome and others, may I remind you that timimi 1 still runs on chrome? The question is not is it currently supporting other browsers. Instead the question should be, can the underlying mechanism of timimi be extended to support other major browsers. The answer is a resounding yes. The only matter is time for the actual development, not technical or technological. The browsers which support the same mechanism is as follows:
- Chrome
- Firefox
- Edge (They are changing their API to be same as chrome's. So it is not even required to develop a separate extension, just reuse chrome)
- Vivaldi - Same case as edge
- Brave - Same case as edge
- Opera

Sincerely,
Riz

[TonyM]

Riz,

I think an approach to this with timimi on all browser platforms, with a friendly installer for each so they look very similar is the best way to go for single file wikis. The reason being Timimi treats the wikis just like any other file that can also open in the browser. 

This approach accepts there needs to be an OS or Browser piece for each platform and lets us respond to change in the future.

Regards

Tony

[TonyM]

Mark,

I have a different view on a number of the items you responded too, however my post was a little off topic in the first place I do not want to perpetuate this too much.

> On SharePoint renaming a file to tiddlywiki.aspx uses any browser and can save back (store in a webPages library for speed and checkout to one editor)

 

I seem to recall that this was a commercial subscription that was required.

 

Yes, but it may work with regular office or One Drive accounts and may be quite broad in applicability. If we are talking about universality and file based wikis, this is part of the story. Add Dropbox, Google Drive, AWS etc...

 

> TiddlyDesktop lets you make use use of higher desktop privileges allowing links in file or folder wikis that let you open File explorer, default Browser or even executables.

TD installed takes almost 300 megs of space. Not a lightweight, portable, browser-powered solution. Also, for me, it would really help if it didn't require reboot whenever you re-opened a data folder TW.

300 megs is becoming trivial for desktops today. Reboot requirement, I have not observed this?

 

 
   > Did you know file://c:/ in firefox creates a directory you can browse and dragging and dropping files found there on TiddlyDesktop captures the full local file path?, also you can drag items in FF address bar as well.

You'll need to explain how to get this to work. I've tried multiple times and haven't succeeded. I think you're saying if you use FF as a file browser you can drag and drop. Have to try that.

Yeah try it, if its important start a thread, or use discord.

> Installing AMPPS MAMP etc.. allows you to host wikis on a local apache server and use TW-receiver, set an forget

I don't think installing and forgetting a full-blown apache server is a good idea for most people. You've opened up a world of security concerns. I bet there's a fair bit of "setting" before you ever get to the "forgetting" part.

The packages are getting easier, the possibilities increasing and the occasions in which users may using this for other reasons are increasing. This was a little off the topic of universal, sorry.

 

  > With the forthcoming local storage plugin you can work and save in local storage then download like in option (1) every now and then as a backup,

Jeremy has told us that the local storage plugin shouldn't be considered as a storage mechanism. It is used in other apps, so, let's see. The main thing is that you lose transparency. Without deleting your profile you can't be sure that you've removed all traces of your original file.

I understand Jeremys argument, but disagree when it comes to using local storage to enable immediate, interactive and savable wikis hosted on line. It is about what it enables more than depending on it for long term storage, and PWS's are challenging this perspective. Some of my own work to allow serial editing of single file wikis, check in check out and user management has a lot of promise, but it contains a number of innovative tricks I am yet to work through.

There is a clear Local storage button already, but if this is my wiki on my computer?

 

> Installing vanilla nodeJS lets you make use of static tiddlers, serve files from you desktop to your browser so you can load only those at a time if you wanted on large wikis.

Not a single-file TW solution. Requires node to be installed and a server to be continuously running.

I agree but if we had a simple installer, and the way to add wikis easily we can leverage Nodes own cross platform work to keep tiddlywiki cross platform. Perhaps updates to TiddlyServers settings process or single file wikis on bob.exe would help this a lot.

 

  > PS New version firefox is challenging Chrome

No, it's not. Did you know that 90% of Mozilla's revenue comes from Google? Do you really think G will
let Mozilla create a truly competitive product?

I do not understand this revenue issue, but have a look at the recent FireFox release notes. And by the way it is as good as or better for me than chrome already.

Regards

Tony 

[Mark S.]

On Wednesday, May 22, 2019 at 4:41:14 PM UTC-7, TonyM wrote:

Mark,

300 megs is becoming trivial for desktops today. Reboot requirement, I have not observed this?

 

Misses the point. TiddlyWiki used to be this light-weight, single file solution. 300  megs is not lightweight, even today.

 

> Installing vanilla nodeJS lets you make use of static tiddlers, serve files from you desktop to your browser so you can load only those at a time if you wanted on large wikis.

   >> Not a single-file TW solution. Requires node to be installed and a server to be continuously running.

>>> I agree but if we had a simple installer, and the way to add wikis easily we can leverage Nodes own cross platform work to keep tiddlywiki cross platform.

>>> Perhaps updates to TiddlyServers settings process or single file wikis on bob.exe would help this a lot.

 

 

Meanwhile,  a batch file with less than a hundred lines of code can provide the features that you do need.

> No, it's not. Did you know that 90% of Mozilla's revenue comes from Google? Do you really think G will
let Mozilla create a truly competitive product?

 >> I do not understand this revenue issue, but have a look at the recent FireFox release notes. And by the way it is as good as or better for me than chrome already.

It means that Firefox is owned by Google in all but name.
Mozilla will do nothing to make Firefox better in any important way than Chrome.
Personally, I would gladly have a little loss of performance in exchange for getting
the old extensions back.

-- Mark

[TonyM]

Mark

thanks for the responce

300 megs is becoming trivial for desktops today. Reboot requirement, I have not observed this?

 

Misses the point. TiddlyWiki used to be this light-weight, single file solution. 300  megs is not lightweight, even today.

 

TiddlyDesktop is a TiddlyWiki manager to manage multiple-wikis. provide access to the local OS and the wikis are still light-weight. As far as I can tell there is no lighter way to get a Desktop TiddlyWiki manager without  a lot more complexity. I have not succeeded but it can also serve wikis on the LAN.

> Installing vanilla nodeJS lets you make use of static tiddlers, serve files from you desktop to your browser so you can load only those at a time if you wanted on large wikis.

   >> Not a single-file TW solution. Requires node to be installed and a server to be continuously running.

>>> I agree but if we had a simple installer, and the way to add wikis easily we can leverage Nodes own cross platform work to keep tiddlywiki cross platform.

>>> Perhaps updates to TiddlyServers settings process or single file wikis on bob.exe would help this a lot.

 

 

Meanwhile,  a batch file with less than a hundred lines of code can provide the features that you do need.

If this means keeping the saved wikis under the browser this adds complexity to the workings, more places for error and loss. I stand to be corrected on this.

 

> No, it's not. Did you know that 90% of Mozilla's revenue comes from Google? Do you really think G will
let Mozilla create a truly competitive product?

 >> I do not understand this revenue issue, but have a look at the recent FireFox release notes. And by the way it is as good as or better for me than chrome already.

It means that Firefox is owned by Google in all but name.

If possible please share references and evidence, it sounds a bit odd to me

Both FireFox and Chrome have led on features which the other then adopts, and all are based on the concept of the "Universal Client".

 

Mozilla will do nothing to make Firefox better in any important way than Chrome.
Personally, I would gladly have a little loss of performance in exchange for getting
the old extensions back.

-- Mark

A lack of controversy in a conversation indicates we are not asking the difficult questions - TonyM

Regards

Tony 

[@TiddlyTweeter]

Ciao  Riz

Its good what you wrote. And I'm very grateful for what you have done. If you have time to extend Timimi to other browsers it would be great! I just don't see other programmers supporting you. Isn't it a lot of work alone?

This thread got slightly side-tracked into discussion of save/restore in general in TW. Understandable. But part of my intent was to focus on Android and Windows (market share dominance) and a minimal universal solution on save/restore that will work in any modern browser in them. ONE solution. It makes uptake easier I think that way?

To be honest the current options on first start are not exactly a turn-on for a starter! :-) Too many options?

Very best wishes

Josiah

[@TiddlyTweeter]

This has been a very interesting thread.

One that went a way I never anticipated and led to astute comments & discussion from folk who understand TW saving/restore issues well.

The ONE thing I take away from it that is I think significant is the IMPLICIT idea TW (in reality) needs Chrome or Firefox for neat saving is not ideal. 

Far better to have one method supporting any modern browser. The sign would be we'd never need mention the browser model name.

Thoughts

Josiah

[Mark S.]

On Wednesday, May 22, 2019 at 6:31:40 PM UTC-7, TonyM wrote:

>>   Meanwhile,  a batch file with less than a hundred lines of code can provide the features that you do need.

> If this means keeping the saved wikis under the browser this adds complexity to the workings,
> more places for error and loss. I stand to be corrected on this.
   

So .... you're saying that using the native, automatic, absolutely
safe and fool proof default save mechanism is COMPLEX, but using a
full-blown, hackable web server is NOT ?
 

[@TiddlyTweeter]

TonyM wrote:

This approach accepts there needs to be an <snip> Browser piece for each platform.

Right.  And maybe it might be better NOT to do that? IF there is a way its avoidable? Having to individually support browsers one by one is a lot of work. 

Best wishes

Josiah

[TonyM]

Mark,

I am not saying that. However if users can be easily confused, or server alternatives simple to install I believe they can compete with such solutions.

The default save mechanism where you must select the destination and overwrite the same file, if your browser permits, is easy to loath after a few saves, and discorages saves. If the folder is under the browser it makes it harder for people to think of the wikis as simple "documents" to be managed and cloned etc...

I am in favor of solutions like you propose, I wrote some myself years ago. I call the process of monitoring files a "sentential process", watching for change. My experience is they are somewhat "britial", however if they can be packaged for installation, and address multiple platforms they could be excellent. One avenue, ironically, is on TiddlyDesktop it is easy to include instructions for installing a sentential from code stored in tiddlers, because of the desktop interaction possibilities. I think the sentential solution may be a good choice along with other desktop interactive solutions. If people want a higher level of desktop interaction a sentential solution may be good for more than tiddlywiki.

When it comes to using a server package it can be hosted by default on the local host only, which keeps it fairly secure and less hackable, and after all, many things are "served" today.

Regards

Tony

[Mark S.]

The default save mechanism can be set to not write over, but to automatically save as a series of files MyFile, MyFile (1), MyFile (2) ....  This happens quietly in the background. You can change settings in your TW file so that it even happens automatically whenever you change the TW file. The batch code finds the most recent one to copy to the file's original home directory. There's nothing really confusing about it ... unless you're trying to view it that way.

[TonyM]

Mark,

Please correct me if in the following words, I am incorrect. Answering the questions as well please. 

So we can say "this method allows you to open your TiddlyWiki from the "original file location" (where ever you choose), it saves the TiddlyWiki in the browsers "download" location, but this file is synchronised back to the original location?

When Tiddlywiki is set to save automatically, each time it saves, the next version filename is used. 

• Is there any popup dialogue you have to complete?
• Will it work for the different browsers?
• Need they alternate configurations?
• I assume we need to set one "original location", does this need to be set in the command file?
• Must "let me choose where I download files" be disabled?
• Can we build this to cater for every Operating system?

If there are any limitations I would be happy to work with you to try and eliminate them, at least on Windows.

I have this vision that such a solution could have the instructions and the necessary "code" ie command or script files built into empty.html (very low overhead) and the method by which to install the code locally.

Yours with a view to collaboration and simplifying tiddlywiki access.

Tony

[@TiddlyTweeter]

Ciao TonyM

I been playing with Mark S.' PowerShell solution (https://groups.google.com/d/msg/tiddlywiki/tMLfNs1K3JU/gkrGu-ubAQAJ).

My comments are based on experiments with that.

TonyM wrote:

So we can say "this method allows you to open your TiddlyWiki from the "original file location" (where ever you choose), it saves the TiddlyWiki in the browsers "download" location, but this file is synchronised back to the original location?

YES. Though I think "Restored" is a better description since the TW saved it. Its not a sync on latest. Its restore of latest. I think.

 

When Tiddlywiki is set to save automatically, each time it saves, the next version filename is used. 

• Will it work for the different browsers?
  

YES. That's the point! I works with ANY modern browser. 

For instance: Open three browsers with the same TW. Download save in each. The latest version gets restored regardless. 

• Need they alternate configurations?

NO.

Footnote: there are small differences in how some Browsers save the version naming. They are easily dealt with in the restore name matching.

 

• I assume we need to set one "original location", does this need to be set in the command file?

Most users, I think will use the Windows "default" downloads location that any browser you install starts with. But, longer term, it should be possible to monitor more than one location if a user has set up their browsers to save to different places. Right now the script just monitors one (by being in it). I think this is an issue of "how tech do you want to get?" But ground zero is one monitored directory. The rest is a matter of further coding. I don't want to load Mark S. up with work when its maybe not needed.

His thought about this method is, I think, good.  And he needs time and appreciation.

 

Must "let me choose where I download files" be disabled?

NO. 

But it won't work if you save someplace not being monitored.

• Can we build this to cater for every Operating system?

Probably.

The back story is that precisely because of the demise of the old methods the browsers had to converge on some kind of consistent method on naming and download directory, whatever platform. 

Likely an unintended consequence, but basically all modern browsers inter-acknowledge on download saving. PowerShell solution on Windows should be translatable to other OS. The principal of "Restore" is not complicated.

Tony, FYI the only issue I see is TIMING. The downside of using an external script to native TW methods on saving is that Restore is that you need to POLL the Wiki often to keep contemporaneous. This may be slightly confusing to end-users under some circumstances. 

Say I monitor with the script my wiki every 10 minutes but saved 5 minutes ago ... if I refresh then the changes won't show. 

Mark set the default polling in test to 10 seconds. I'm not sure I'd use that but I think that is part of the reason--so its very likely the auto-restore is in line with expectations of what you entered in the wiki.

Best wishes

Josiah

[Mark S.]

On Friday, May 24, 2019 at 4:13:39 AM UTC-7, @TiddlyTweeter wrote:

But it won't work if you save someplace not being monitored.

• Can we build this to cater for every Operating system?

Linux has a rich library of shell tools. I'm reasonably confident that it's possible to do the same with Linux. The one additional bit of code that people will need from their distributions is the "sleep function".

Strangely, that ability isn't built-in to the shell.

Sadly, I had started writing code for Linux, but I foolishly was writing on a persistent flash drive which turned out to not be all that persistent. So later.

I said I was not a Powershell aficionado (last week I didn't even know how to spell PowderSell). I'm also not a bash aficionado. I know there are people here who are really good with shell scripting. Maybe one of them will take an interest before I get around to it.

Mac has a linux-like environment. So presumably any scripts for Linux will be nearly ready for anyone on Mac. Hopefully someone from the Mac world will take an interest, since I don't have a Mac device.

Tony, FYI the only issue I see is TIMING. The downside of using an external script to native TW methods on saving is that Restore is that you need to POLL the Wiki often to keep contemporaneous. This may be slightly confusing to end-users under some circumstances. 

 

The only time you need to reload is if you're installing a plugin.
Anyone advanced enough to be installing a plugin will be
advanced enough to know how the "restore" mechanism works. Right? ;-)

It needs something more catchy than the "restore"  terminology. Maybe the "Phoenix", "dezombifier", or "nine-lives" process. Something to think about.

-- Mark

[TonyM]

Thanks Gentlemen, mark and josiah for your considered responses.

I will read through this again, perhaps more than once and think deeply about it. Like you both I would love for us to find nirvana for tiddlywiki saves.

Whilst I have being a script kiddy with PowerShell I have a very high level of batch programming skills .bat and .cmd and have automated windows desktop and servers many times. As mentioned before I call these monitoring scripts sentenials, and they capture files or data.

A solution such as this may be applicable to more than tiddlywiki.

Something about the current solution concerns me when it comes to first time users and making it as simple as possible, but you have developed a good approach. Let me see if I can add to this.

Regards
Tony

[@TiddlyTweeter]

Mark S. wrote:

It needs something more catchy than the "restore"  terminology. Maybe the "Phoenix", "dezombifier", or "nine-lives" process. Something to think about.

Lazarus?

Nine Lives  / 9-Lives / shortform: 9L ?  Seems suitably catty for TW :-)?

Thoughts

Josiah

[@TiddlyTweeter]

TonyM wrote:

Whilst I have being a script kiddy with PowerShell I have a very high level of batch programming skills .bat and .cmd and have automated windows desktop and servers many times. 

Right. Opens the possibility that Mark S.' script could be invoked from a batch that does supportive things (for instance provide informational directory listings or customised help?)

Now we have his PowerShell code that works for decent testing it would be interesting to see what folk like you could add around it!

Best wishes

Josiah

 

[Jed Carty]

osx has bash with most of the common commands available, so bash scripting on osx is almost identical to on linux. I think that there are some subtle differences in how osx and linux handle file watchers but I don't remember what they are so that may not affect this. From what I have seen bash scripting can do anything done in powershell so that shouldn't be a problem.

As a side note, the workflow for single file wikis on Bob isn't too terribly far from being able to just open an html file from within bob and have the changes autosaved back to the single file wiki. It won't ever be as simple as just double clicking on the html file because there is no way to associate just the tiddlywiki html files with Bob.

[TonyM]

Jed an aside of your aside

As a side note, the workflow for single file wikis on Bob isn't too terribly far from being able to just open an html file from within bob and have the changes autosaved back to the single file wiki. It won't ever be as simple as just double clicking on the html file because there is no way to associate just the tiddlywiki html files with Bob.

You may recall, I was trying to get others to recognise .tw as a valid tiddlywiki file extension. Most browsers and applications will open this and discover it contains html and display it correctly. As you say "no way to associate just the tiddlywiki html files with Bob"  but there is if they are .tw files. I currently do that on my Windows Desktop, but have not learned how to launch bob with a html (or in this case tw) file as a parameter.

If we start doing this nothing is lost and something is gained. There is not need to register the file extension except on the local PC, it could be made more unique with tw5 but will we ever need to distinguish between versions of tiddlywiki, when the html handles this?

Regards

Tony

[@TiddlyTweeter]

TT wrote ... 

... the only issue I see is TIMING. The downside of using an external script to native TW methods on saving is that Restore is that you need to POLL the Wiki often to keep contemporaneous. This may be slightly confusing to end-users under some circumstances.

Mark S. commented ...

The only time you need to reload is if you're installing a plugin. Anyone advanced enough to be installing a plugin will be advanced enough to know how the "restore" mechanism works. Right? ;-)

LIKELY RIGHT!

But not 100% sure yet. When I buy bacon I tend to ASSUME the scales are correct. I may get annoyed if they aren't :-). 

In TW terms I'm unclear.

What am I trying to say? 

Not sure! 

Something like "How do I KNOW it worked?" 

!!! I hasten to add I don't think that is an issue with your script !!! 

Rather, what info (if any) does an end-user need to understand it?

Simply thoughts

Josiah 

[@TiddlyTweeter]

Jed Carty wrote:

... From what I have seen bash scripting can do anything done in powershell so that shouldn't be a problem...

Good news!

Josiah

[Mark S.]

On Saturday, May 25, 2019 at 1:58:22 AM UTC-7, Jed Carty wrote:

...

As a side note, the workflow for single file wikis on Bob isn't too terribly far from being able to just open an html file from within bob and have the changes autosaved back to the single file wiki. It won't ever be as simple as just double clicking on the html file because there is no way to associate just the tiddlywiki html files with Bob.

Hi Jed

If you have a Bob wiki and export it as a single file, and then make changes to the single file, is there a way to bring those changes back into the original wiki without individually selecting changed tiddlers?

Thanks!

[PMario]

Hi Tony,

I think you forgot about the WebDav savers, which IMO are a little bit underestimated.

-mario

[@TiddlyTweeter]

Jed Carty wrote:

... the workflow for single file wikis on Bob isn't too terribly far from being able to just open an html file from within bob and have the changes autosaved back to the single file wiki. It won't ever be as simple as just double clicking on the html file because there is no way to associate just the tiddlywiki html files with Bob.

A side note. 

In some ways BobEXE looks ideal for setup operations on backup, restore and general organisation of wiki. It can change itself interactively in a contained way that is very flexible. 

I been playing around with it to see how to tweak a custom version such that on first run the user gets a wizard for setup. Bob has advantages over TiddlyDesktop in that it should run in any browser and you get full access to the browsers strengths as well as be able to invoke most anything the OS can do. And even though its very powerful an end-user would not necessarily need exposing, I think, in a customised version, to all the options and functions. 

If I were a bit more tech savvy I think I'd use it as a a kind of wrapper for diverse projects. Customisation possible with it is really excellent.

Thoughts

Josiah

[@TiddlyTweeter]

PMario wrote:

...  WebDav savers, which IMO are a little bit underestimated. 

I agree. I think the key question I was thinking about when I started the thread was only really about "is there one methodology?" That is: (a) simple to understand and implement; (b) works in most every scenario. 

That doesn't stop anything else being possible. Merely asserting some kind of "ground zero" with a simple methodology that can work regardless for single-file wiki in any browser. Adding "auto-restore from download" looks close to that aim?

WebDav is good but I wouldn't say it was easy :-)

Its just a line of thought

Best wishes

Josiah

[TonyM]

Mario

Good point about Webdav. I set it up on IIS and it worked well. I belive its available on other platforms.

As a technology do you know more about its availability and benefits?

Regards
Tony