Ive always thought something like this could work:

https://github.com/nodegit/nodegit

where saving a tiddler could trigger a commit object. That way, conflicts, 
merges, etc could be handled the way it is usually handled in version 
controlled systems.

On Thursday, January 31, 2019 at 10:14:34 AM UTC-6, joearms wrote:
>
> An alternative might be some form of transaction memory.
>
> When a tiddler is served over a network it has last-modified time (this is 
> the time when the server
> last stored a modification)
>
> If a user edits a tiddler and sends it back it should include this time.
> Call this Told.
>
> When the server receives an updated tiddler it checks to see if Told 
>  is identical to the current last modified time of the tiddler if so the 
> update
> succeeds.
>
> If the two are not identical the update fails - and the user is told that
> their new tiddler value is not an update to the latest value of the 
> tiddler.
>
> They should then get the latest version and resolve any conflicts.
>
> This works pretty well if we make a couple of assumptions
>
>    1) people do not edit the same tiddlers at the same time
>     2) edits are relatively quick
>
> This way nothing gets locked and there are no checkins/outs.
>
> Actually, each tiddler could be (internally) a write-append-only log of 
> diffs
> this way no data gets lost and we can back up to any old value.
>
> Cheers
>
> /Joe
>
>
>
> On Wednesday, 23 January 2019 01:50:01 UTC+1, TonyM wrote:
>>
>> Folks,
>>
>> I have raised this a  number of times in a number of contexts but *NOW I'm 
>> Serious - We need Check in and Check Out*
>>
>> TWC had a method to allow serial editors and a lock file (that all can 
>> see). We need this as an option to TW5 as well.
>>
>> Why?
>>
>>    1. TiddlyWikis can be used as smart documents served from a file or 
>>    network location without fear of contention and overwrite (Single File or 
>>    Network served)
>>    2. Its a "poor mans" multi-user wiki - Serial multi-user update 
>>    access NOT Multi-user multi-access
>>    3. TW-Receiver could provide read/update access to any number of 
>>    users knowing simultaneously is not available.
>>    4. The lack of such a facility is driving some of the complexity we 
>>    face trying to simplify the saving process, if we could check in out 
>>    documents reliably we secure the the wiki from corruption/overwrite. 
>>    5. It could help users protect them from themselves opening the same 
>>    wiki from more than one tab/or browser without needing a server solution.
>>    6. Perhaps TiddlyDesktop and the other servers could also honour this 
>>    allowing free transfer between platforms.
>>
>> How
>>
>> I am confident we have the technology and avenues by which to achieve 
>> this, I do not believe their is a technical barrier any more. An example in 
>> point is some of the local save tools, we know they are writing information 
>> such as backups, so we have the ability to read and write a switch/lock and 
>> we can include an informational user name in that switch.
>>
>> We could provide a checked out to current user with a save and check in 
>> button. We could provide a NO check out user with a reload and check in 
>> button (if not locked)
>>
>> I can provide more technical possibilities if requested, but some of you 
>> I expect already know how to do this.
>>
>> Feedback please!
>>
>> Thanks tony
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to tiddlywikidev+unsubscr...@googlegroups.com.
To post to this group, send email to tiddlywikidev@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywikidev.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/tiddlywikidev/f92dba1b-a115-46e1-b43c-97656be4e51a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to