>
> If we speak about distribution on file level (in the cloud) the question
> is if it's neccessary to do that separation of data & logic on file level
> as well. One would think so.
>
Yes. You would have tiddlers...
- in a desired file-format:
- for that purpose, TiddlyWeb implements serializers
<http://tiddlyweb.tiddlyspace.com/serializer> that return different
formats
- e.g. txt (=tid), json, html, wiki
- at a desired storage
- a file system with folders (or bags in TiddlyWeb
<http://tiddlyweb.tiddlyspace.com/bag> / TiddlySpace)
- a database, possibly with (even typed) tables
- proper interfaces on both ends that handle all that browser <> server
talky-talky
But I like the 1 file approach of tw5 very much and would not like to give
> it up if it's not really neccessary - it makes things very handy at all.
>
It sure makes it easy to share and host a wiki (for an individual),
but is entirely counter-productive for anything collaboration.
If somebody would ask me for a blueprint of file level syncing of TW5 in a
> efficient but also simple way I would suggest the following:
> - keep things simple with the single file approach - over disadvantages it
> has many advantages
>
...which don't pay out with multi-user, in fact, are in stark contrast to
it.
- on sync side A:
> -- use the TW5 autosave capabilities to do not a save but an export of a
> file (call it syncStatusA) that has the following contents
> --- the logic to say what has changed (tiddler updated)
> --- the data that changed (tiddler data)
> -- the exported file will be automatically synced (if thats possible) by
> the cloud service client you are using (it's possible in mine)
> - on sync side B:
> -- use the TW5 autosave logic to do an import (read) instead of an export
> (if that's possible???)
> -- look for a exported file that has also been synced in the current file
> space (the syncStatusA file) and import it
> -- maybe a file naming convention for the syncStatus file is neccessary &
> sufficient here, but a property inside tiddlywiki describing the exact name
> of the import file for the current session would do it
>
Yes, but at the end of the day you want one storage location, not two, and
so you need to save an entire wiki and make sure entire wiki's are properly
merged, not some hoped-to-be-temporary handshake files. What happens to
those "exported dumps"? When are they discarded? How to know what's new and
when conflicts are finally merged? Do 3 of 4 group members set a
flag...file ...that says "ok, I merged your dump, now what"? When does the
dump get deleted? Can I cancel that last commit? How is that feedback loop
working? A single file won't do, obviously, as A might want to push to B
might push to A.
- if you don't want to think about the implications by working with both
> wikis on sides A & B on one and the same syncStatus file, then you have to
> choose a different name for the import and the export file of one wiki - or
> respectively, choose a different name of the syncStatus import/export file
> on both sides A & B - then you have a handshake, don't you?!
>
If you want a single syncStatus file then that needs to be locked by the
emanating wiki up until *all* others have merged the changes. I see a lot
of problems already in that workflow. For TWc, there was TiddlyLock, which
essentially put a lock-file next to TiddlyWiki saying "I am working on it,
so you can't"... already this simple thing had so many known unknowns that
essentially you ended up overwriting each other's edits... or not being
able to work in TiddlyWiki at all!
- naming the import & export file different would be meaningful to make the
> sync robust for the unknown conditions of the cloud service (sometimes
> there's automatic file versioning, etc.)
>
It would also make it much more difficult to figure out what (still) needs
merging and what doesn't... let alone where to get it from, filewise.
- so finally, the names of the files could be syncStatusA and syncStatusB
> and they would be synced by the cloud service and carry the information and
> data what has changed and will be imported automatically
>
Who / what gets to decide when to delete the file?
> - and with minimal manual interaction of an handshake for a session you
> could have a synced tw5
>
You will need manual interaction, there is a lot of potential for merge
conflicts. What if I fail to merge?
- a session would mean here that you start with a synced wiki (copies) and
> do handshakes by determining the name (convention) of the syncStatus file
> considering the current cloud conditions
>
At what point am I allowed to close my wiki? When is it saved?
- after the sync the syncfile of A has to be deleted by B and A is not
> allowed to write a new syncfile while the old syncfile exists
> -- that would work for a little number (10?) of team members, at least for
> 2, wouldn't it?
>
Won't I be waiting for who knows how long until someone decides to close
their browser session and allows me to push my changes? How do I even know
they're still having that session open or not in their notebook (or mobile
or desktop) on stand-by? Do I need to know? When I start my browser, am I
irectly being greeted with my own yet unmerged sync-file, that of someone
else?
- if you are more than 2 - say 10 - and you need for technical tw reasons
> not the naming convention but the exact name of the syncStatus file, then
> you would need the possibility to tell your tw not only one import/export
> naming convention of the syncfile, but 10
>
I guess a sync folder should do. Did you notice how we already have more
than one file? So, I'm wondering, if there is no single file paradigm with
multi-user, why bother struggling with such bricolage?
> - in this case after updating a tiddler on side A nine (9) syncfiles will
> be created for the team members
>
Big ouch, don't you think? Again, when am I finally allowed to save my
wiki? Do I, at some point, need to sync back my own file, because I
couldn't save?
- so sync should be possible this way for small teams and I think you could
> put that functionality into a plugin
>
Here's one thing I am entirely positive about: Please don't make me the
admin to that process.
> - this would keep things quite handy for a 3 person team and would be a
> large benefit in workflow
>
In an ideal world with all things going smoothly, there's a window this can
work, but in so many ways it's nothing I would spend my energy on. I would
only recommend this process in the case where there is usually one
maintainer of the wiki and only rarely contributions by others.
Here's a proposal: Make a flowchart / bpmn chart, whatever ... that dares
to define this process in a water-tight manner. Once we get this design in
a loophole-free manner, something could perhaps be implemented. Right now,
I don't see an even remotely water-tight process, I see some strokes on a
canvas that don't quite form a picture just yet that reads: Let's
TiddlyCollaborate... "singlefile"-style.
So, here's my bottom line for now:
multi-user means
- single tiddler store
- with folders / bags / db tables (/ and also filters / recipes /
permissions)
- proper server
- serving TW
- serving tiddler collections
- providing a CRUD interface per tiddler
- proper interfaces on both ends
- so a standalone wiki knows to communicate with that server
- and the server knows to handle those requests
So, this begs, above all, for a specification of a
server-and-browser-agnostic-interface/-protocol that any server or browser
can implement so as to talk with each other in their desire to exchange
tiddlers in the context of a TiddlyWiki wiki or otherwise.
Best wishes, Tobias.
--
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 post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/tiddlywiki.
For more options, visit https://groups.google.com/d/optout.
