Hi there!

I've only skimmed previous posts so forgive me if this came up already, but 
I wanted to throw in my 2c.

Most of this is from the context of accessing TW from more than one device. 
Before I can talk about why having TW support PWA features would be a good 
idea, I want to give some background.

The ideal setup for me personally looks like this:

1. Central server running TW and acting as the source of truth and storage 
of all my tiddlers.
2. The tiddlers are versioned for easier maintenance and fewer worries 
around deleting or changing things.
3. The tiddlers are regularly backed up to protect against hardware failure 
and malware / accidental deletion. 
4. I can access TW from any device via a browser or other more appropriate 
means.
5. The local TW running on device is connected to the central server so 
that the tiddlers are shared between devices and not siloed.
6. The device-local TW can run offline, which means that there needs to be 
local storage that gets synced with the server once the device comes back 
online.

With these I could really use TW anywhere robustly and reliably.

I have a large part of it figured out, but there are still some system and 
UX level gaps. I will describe what my current setup and possible 
implementations can be for each of the points above:

1. Central server. I have the vanilla TW nodejs running in a Docker 
container on my Synology server and so far it seems great. The vanilla 
server saves tiddlers as files already, so I just mount that save dir as a 
volume, so tiddlers persist outside of Docker on the host.
2. Versioning. Based on a blog post I found, my tiddler files are part of a 
git repository. To commit I'm running a modified gitwatch that looks for 
changes to tiddler files and commits automatically after a few seconds. 
History in git is stored as deltas and compressed, so the history might 
take _less_ space than the working copy at the beginning at least. 
Reverting / looking at history is a little inconvenient as it's not 
integrated into TW, but that can be improved with a plugin and a 
server-side service.
3. Backup. Since tiddlers are saved as files on the server host and I'm 
running nightly backup on it, this comes by default. Any backup service 
that works on the filesystem level would work here however.
4. Device access. This already seems to work pretty well on desktop and 
mobile. The UI is pretty responsive and works well on small screens for 
most things.
5. Central tiddlers. This also works pretty well. The vanilla nodejs server 
has a REST API and the TW client that it serves connects to it and uses it 
as the default saver. So all the data is persisted on the server and not 
locally.
6. Offline mode. I don't have a solution that I really like for this yet. 
There are some attempts to do this, most notable seems NoteSelf. It syncs 
to a CouchDB database however and for now I prefer having tiddlers stored 
as files, due to the advantages that brings for points 1., 2. and 3.


Expanding on 6. Offline mode:

I believe this is the only context where PWAs make sense. If the app is 
already offline (served from the local file system, saving via browser 
plugin, or running offline as a native app), then the concept of a PWA 
doesn't make sense, since afaik the core problem they solve is offline mode.

In the context of an online TW (like described in the setup above), it 
would make sense for it to support PWA features (localStorage, offline 
service worker responsible for sync, etc.). This way you could open up a 
website hosting your TW at any point, even when you're offline and it would 
store all the changes in the browser cache, then sync them up when you 
connect back to the central server.

This would solve 6. without having to create a separate application for 
each OS just to handle the offline, caching and syncing problem. In Chrome 
you can even install these kinds of websites as system apps, so they open 
up in their own window and act like native apps to a certain degree, on 
both desktop and Android. For example, the Home Assistant client does this 
and it works great.

I believe a proper syncing / diffing system is the only big roadblock that 
currently stands in the way of having true offline mode and sync. I know 
there is some effort being put into the diffing part (there's a macro for 
diffing tiddlers), though I'm not sure how far TW currently goes wrt sync 
with the nodejs REST API.

Obviously expecting everyone to run the same setup as I am is unreasonable, 
especially if you just want to try it out or if you don't want to manage 
servers and so forth. If you use more than 1 device regularly though, I 
would think you'd want some form of syncing between them and that's why 6. 
would be beneficial, even if you connect to the cloud, where someone else 
runs a variation on 1., 2., 3. for you.

I'd be interested if anyone has a better solution for any of the parts of 
this system or a better one entirely.

Best,
Miha

On Saturday, November 23, 2019 at 2:50:37 PM UTC+1, Arlen Beiler wrote:
>
> I think the bob saver can be expanded to use a browser plugin. This can 
> address some of the security concerns with having a freely available saver 
> listening on the network. And it’s also simply installable as you say. I 
> must have heard enough complaints about corporate networks that I thought 
> those environments have all the trouble, but maybe I was wrong. I guess 
> putting a simple working solution in place first and then improving it 
> would get us a long way. 
>
> On Sat, Nov 23, 2019 at 08:16 TiddlyTweeter <tiddly...@assays.tv 
> <javascript:>> wrote:
>
>> Ciao Stefan
>>
>> *Great post. To the point.*
>>
>> Fully agree that the POINT in all this should be to enable users to do TW 
>> with the same level of simplicity they have for other apps. 
>> Basically, nowadays standard, it comes down to one approach for mobiles 
>> and one approach for desktops.
>>
>> IMO we have, actually, MINOR, issues between now and full cross-platform 
>> unity of approach. *So close. Yet so far off.*
>>
>> One thing, largely OVERLOOKED in this thread, with its (necessary) focus 
>> on mechanisms, is that end-users are primarily interested in CONTENT. 
>> They don't care HOW they get it, just so long it's simple enough. I wish 
>> "Desire for Content Delivery" would matter more here as it is a vital piece 
>> of understanding the issue ...
>>
>> I really believe that normal end user working practice is central to this 
>> discussion. The issue is, I think, just this ...
>>
>>    - ... a person who wants to get something done, using conventional, 
>>    recognisable, common, methods.
>>
>> My 2 cents.
>>
>> Best wishes
>> TT
>>
>>
>> *(Footnote: Unfortunately TiddlyDesktop is not properly portable yet [it 
>> currently uses absolute addressing to wikis] so its not yet ideal.)*
>> Stefan Pfister wrote:
>>>
>>> Hi,
>>>
>>> # The Goal and big question:
>>>
>>> * a simple way for naive and casual users to save their tiddlywiki 
>>> (again and again)*
>>>
>>>
>>> I read this thread with much interest. In my opinium there is still one 
>>> big aspect, which should be mainly considered. As a casual and 
>>> non-technical user of tiddlywiki and as a teacher, who wants to show the 
>>> students at school something with tiddlywiki I want to say:
>>>
>>> The easiest way to use a tiddlywiki is to double-click on a file with a 
>>> tiddlywiki in it. I doesn't matter which ending this file has. If it is 
>>> "html", "tw" or something different. If the user can simply click on it and 
>>> it opens in a way which makes it possible to use it without struggling with 
>>> the saving mechanism.
>>>
>>> This works with the so called hta-hack under Windows really well. Simply 
>>> changing the ending of the tw-file to "hta" and you have a simple working 
>>> one-file-tiddlywiki with saving mechanism. This is really usable. For me as 
>>> the user the inner mechanism is not my point of interest. I can simply us 
>>> this in class but only with windows devices. Something more universal and 
>>> platform independent would be great.
>>>
>>> A single TW-file with a working saving mechanism in it which opens per 
>>> doubleclick in a browser or even in a separate portable program like 
>>> TW-desktop (something which organises the saving) would be a great progress 
>>> in usability for the non technical and casual user of tiddlywiki. This is 
>>> the normal behavior of programs and files. The most simple users know this. 
>>> This is an easy workflow. I use this kind of workflow every day. I simply 
>>> don't want to install or configure something special in order to be able to 
>>> save my work. But it is in most cases not much of a problem to install a 
>>> app or a program in order to use it. I know there are restricted 
>>> environments but for the normal user: The normal way to use a programm is 
>>> to install something a *.exe or under linux a *.deb and simply use it.
>>>
>>> Just my two cents.
>>>
>>> Regards,
>>>
>>> Stefan
>>>
>>>
>>>
>>> -- 
>> 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 tiddl...@googlegroups.com <javascript:>.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/tiddlywiki/dabe0b3f-9095-45d0-86c5-65fd29a1441c%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/tiddlywiki/dabe0b3f-9095-45d0-86c5-65fd29a1441c%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywiki/60b58373-13e8-427a-b7c8-c50f5597b496%40googlegroups.com.

Reply via email to