Unique session ID and serial editing (multi-user single file wikis)

[AnthonyMuscio]

Folks,

As discussed here in the FireFox Doco
it says

• Whenever a document is loaded in a particular tab in the browser, a unique page session gets created and assigned to that particular tab. That page session is valid only for that particular tab.
• A page session lasts as long as the tab or the browser is open, and survives over page reloads and restores.
• Opening a page in a new tab or window creates a new session with the value of the top-level browsing context, which differs from how session cookies work.
• Opening multiple tabs/windows with the same URL creates sessionStorage for each tab/window.
• Duplicating a tab copies the tab's sessionStorage into the new tab.
• Closing a tab/window ends the session and clears objects in sessionStorage.

I was wondering if someone with Javascript and DOM knowledge could help me find a way to generate a large random seed as a session ID and provide it as a value or variable I can access in tiddlywiki. This would allow me to distinguish between tabs and browsers/ browser windows and use this as a key so one session can check out a single file wiki, and others with a different session ID can't check it out until the first releases it.

The only issue is if the tab is duplicated, but this can only happen in one browser.

I plan to pass the session ID in the URL on reload to the tiddlywiki, which will either grant or reject the check out. If granted the session ID will be saved in the tiddlywiki and only that session can save to disk/host etc...

I can then fiddle with the dirty indicator so it can only be cleared if a check-in process is undertaken, removing the session ID from the wiki and save/reload only then the user can close the browser or tab. This then releases the tiddlywiki for another session to check out.

This will then allow single file wikis to serial editing (multi-user single file wikis) just by forcing one user at a time relying on nothing but the wiki itself . All users will need write access, but the wiki manages who can make use of that right.

I really need someone with the technical skill to help me champion this valuable feature, that would empower the use of tiddlywiki (single files) in teams or or across multiple devices without data loss due to contention. The only contention is at checkout.

Regards
Tony

[AnthonyMuscio]

Other points;

• A timer system could cause a tiddlywiki checkout to expire, or force a save and checkout.
• Checkout could insist on contact information for the person checking out the wiki (so they can be asked to check in)
• This solution should be platform/host independent although I am concerned there is a bug in Timimi that cant handle the complex URL
• Hosts would include the Bob Saver, TW-receiver (php sites), cloud storage (Drive, DropBox etc...) and timimi and each of these would still demand all users who can checkout to supply the needed host credentials shared or unique.

[pmario]

What you describe is a locking mechanism. In theory this is a possible mechanism but in practice it causes all sorts of "dead lock" problems, especially since you want to store "the lock" in the wiki-file itself. This also causes a usability problem, since you need to open the file, to see that it's locked.

Dead-lock here means, that situations will happen, where nobody can get access to the wiki and you need to open it with a text editor to remove the lock. ... That's suboptimal and will cause trouble.

Such a dead-lock can easily happen. Eg: I do check out the wiki. So it is stored with the active lock to a file. Then I loose the network connection and close the browser. ... So the browser session ID is lost. So even I'm not able to remove the lock. ... Or I let the PC hibernate and go on holidays. ... The lock will be active, but my PC is locked with a password. .... and so on.

There has to be a simple mechanism to remove the lock. The only simple way I see here is, that the lock is a second file.Eg: Wiki-name: test.html .... lock-name: test.html.lock ... Where the .lock file contains the name of the user who locked it.

This also has the advantage, that users already see in the file-browser, that a file is locked. As I wrote, in your proposal, they would have to open the file first, to see that it is locked. ...

For system admins it will be easy to create access rights on the directory level, that only admins or maintainers can remove the lock-file. In an easy setting everyone can remove that file. .. It's less safe, but should still work for small teams.

The only problem here is browser access to the file level. which only can be done with the chromium file API atm.

[AnthonyMuscio]

Sorry I missed your reply

Mario- the method I propose is a soft lock. it can be defeated by anyone who has write access. (but discouraged).
Rather than detail it all I was hoping with this thread to simply get an answer for the OT "Unique session ID", even just very random long string that is remembered for the session within a browser and when revisited.

I like the idea of a second wiki but I have found its not essential, however such an edition would be useful for the community. It would certainly help if on a slow connection or large wikis.

However I believe its not essential because even if a user has write access unless it is checked out to them the save mechaisium is disabled and defeated (yes they can force it if necessary) but this is about trusted users and good faith (common in teams) and if not we go to the backups. In fact it may just be one user locking it to a tab in a particular browser, and stopping them using in another browser/tab.

I effectively avoid the second wiki by forcing a reload and request the checkout on the URI, and if granted immediately save the checkout status.

I just need a session id to tie such a lockout to a browser and session there in, the user level is just design.

[jms19]

It would surely be better to make some attempt to intelligently merge changes from different users ?

Maybe when saving some hints as to what was edited could be sent. I have no idea how this could work in a save mechanism independent way. It probably couldn’t.

(I recently started using TW5 for my random thoughts, use DAV and this is the first time I’ve come out of strictly lurking. I hadn’t appreciated how active TW5 development was. Great stuff.)

Jon

[pmario]

I recently started using TW5 for my random thoughts, use DAV and this is the first time I’ve come out of strictly lurking. I hadn’t appreciated how active TW5 development was. Great stuff.

Welcome. It's great, that you changed "mode" ;) ... Yes the WebDav saver is nice. WebDav itself would allow us to lock files, but nobody did explore those functions yet. ...

[AnthonyMuscio]

jms

I am happy to have you on board. I hope you can help here because this feature is the last big problem in my mind for tiddlywiki single files and easy serving on a range of platforms without node and bob.

I have considered intelligent merges and this is still a plausible method, especially for open surveys from read only wikis, then the results in a user based namespace, packaged in json file and submitted to the owner for merging. Even in this case a session id would help to uniquify any submission and help avoid clashes.

However I believe I can see a simpler and more useful solution discussed here in.

Tony