Riz, Thanks you for your considered response.
While it is fresh in our minds; > > Here is purely philosophical reason behind hesitation. My vision for > timimi is that once installed, user should not have to install anything > further. If I am doing my job right, user should almost forget that timimi > exists. This I believe, is the greatest success of a piece of software. To > ensure this, timimi should depend only on things that are part of core > tiddlywiki. > So I totally agree with this approach. Stick to it. > First is to create a entirely different browser plugin for this. Such a > scenario will have atleast 3 moving parts - > 1. Browser plugin > 2. Native host/backend > 3. Additional tiddlywiki plugin/saver to generate a new version of save > object that corresponds to these browser plugin. > Are you saying item 3 is the plugin to permit locking? > Now as I said, this is rather unpleasant because user will have to install > the plugin to each and every wiki he uses. Sure, an argument can be made > here that user need to install it only if they require the particular > feature. Still, unpleasant. > > Second is my favorite. Mostly because I have a few more ideas regarding > this direction > > Jeremy has hinted an update to attributes generated by tiddlyfox.js > <https://github.com/Jermolene/TiddlyWiki5/pull/4526#issuecomment-606562156>. > If we are adding attributes anyway - why not add a couple more. Currently > save object sends just the data and path to tiddlyfox. Imagine if there are > the following attributes too. > > 1. backup-path > 2. lock-status > 3. unique-id for the session > > Now let me expand my thinking here. > > 1. You have a TW5 file open. You have button that generates a "lock" > 2. The "lock" button creates a unique ID for the session which gets > associated with the the path of the file. > 3. Now when save is triggered, this unique ID and lock command is send > along with other data points in save object > 4. From then onward, whatever-does-the-actual-saving, will *save to that > particular path ONLY if save command is accompanied by the particular > unique id*. > 5. Finally user can send an unlock command to remove this restriction. > 6. If user opens it another browser - user could be notified saying that > this file is locked and asking him for explicit permission to unlock it. > That is really nice,but I assume this is saved to the actual wiki, not only in the Native host/backend, because other users can't see that. If two of us open the wiki then one locks it, the other will not know this is so from their copy in their browser. - If we lock the wiki on the Native host/backend, then I can avoid this by testing for this before allowing another session to lock it on ONE computer. - If we store it in the Wiki, the second users attempt to lock it, should first reload the wiki, to check it remains unlocked. - So in conclusion the first attempt to lock the wiki should reload the wiki, to check it was not locked in the interim. Such a mechanism could be utilised by any savers - tiddlydesktop, timimi - > even Bob I guess. > If designed well with more than one saver this needs to be independent from the saving solutions including Timimi > > Oh, and the backup-path attribute so that you can have individualised > backup paths for each tiddlywiki file. The backup path you set in timimi > settings will be default, but if a tiddlywiki file has a backup-path > specified, it will override the default and save it that location. > Nice, What would be interesting is if either a seperate file/folder or the backup folder could also store the current Version (last save) The currentCopy could become the next backup, but if that copy is not locked, then arguably the backup could be on a shared drive, cloud storage for someone or another device to access when away. It is actually a common use case for an individual to need to resolve the possibility of overwriting ones own work from another device. Love your work Tony -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/9765f097-dd58-4379-a21e-08d4800535fd%40googlegroups.com.
