Mario,
I applaud your suggestion looking at data tiddlers and have experimented in
that space as well.
I do want however to ensure the the Original Thread is pursued. Ideally the
same mechanisms will be used in the various alternative scenarios.
In fact I have learned there are a large number of factors that influence,
not just the multi-user approach but also the choice of single, file,
server and hosting.
- As a result I plan to collect all these factors and see if I can
develop a decision tree to deal with this complexity.
- From there it will be possible to get a strategic approach to
developing components and methods across all the possibilities of
TiddlyWiki.
- Here is a quick list of possibilities that highlight what may
influence choices, by its preliminary nature you can see it is not
separating the solution from the user requirements.
- I often find someone is asking for multiple users but they only have
one editor and an indefinite number of readers which is the out of the box
behaviour anyway
Note: All of the below may exist in trusted, untrusted access environments.
How secure should the wiki (restorable) or totally tracked or locked down
1. Remote Read only tiddly reference on your computer (sourced elsewhere)
2. Local Read only tiddly reference on your computer (sourced elsewhere)
1. With or without install and file management access
2. With or without application install access
3. With or without browser choice
3. Read update wiki just for one on their computer
1. With or without install and file management access
2. With or without application install access
3. With or without browser choice
4. Read update wiki just for one on their computer and their Intranet
1. With or without install and file management access
2. With or without application install access
3. With or without browser choice
5. Read update wiki just for one on their computer and via other devices
when out of home
1. Transfer updates on return or before departure
2. Remote access to Wiki Host
3. Cloud storage
4. Cloud database
6. A wiki authored on a desktop LAN or Intranet and published on the
intranet (read multiuser)
1. for read only LAN public
2. for read only LAN user to those with a secure password
3. read only to LAN users those with a secure Encryption key
7. A wiki authored on a desktop and published on the internet (read
multiuser)
1. for read only internet public
2. for read only internet to those with a secure password
3. read only internet to those with a secure Encryption key
8. A wiki authored on a desktop and published on a shared cloud drive
(read multiuser)
1. for read only public
2. for read only to those with a secure password
3. read only to those with a secure Encryption key
9. A wiki authored/modified on the internet or Intranet by one editor
and published on the internet for public read only
1. but including local storage for their customisations and view,
most recently viewed etc..
2. but including the ability to export comments and other tiddlers,
for import by the one editor
10. Any combination of file or hosted tiddlywikis with serial editors,
one at a time, check in check out
11. Multi-user editors (Desktop, Server or Internet hosted variations)
1. Serial editor method,
1. Whole of wiki checkout
2. Tiddler based checkout perhaps with commits from local storage
once checked out
2. Multiple users with their own sandboxed wiki apparently updated
only by themself
1. Just so the core and initial wiki seeds the user wiki, after
that they are different apparent wikis.
2. User tiddlers saved to the wiki, in their own namespace and
visible to all
3. User tiddlers saved to the wiki, their own namespace, and
visible to all ONLY if "Imported" to the master
4. User tiddlers saved to the wiki, their own namespace, and
visible to other if published using the static tiddler method (Host or
export)
5. Users are using a subWiki which is federated to a master wiki
automatically
6. Users only see the master wiki until they make changes and get
a master + Overlay
3. Multiple users without sandboxing
1. Based on Bob perhaps
1. Using a consolidation view
2. Mechanisms in tiddlywiki to act as a multi-user CMS (at least
server versions)
I am sure there are more combinations and perhaps as many again of ways to
meet those requirements.
Where possible a single solution should suit a whole subset of
requirements, reducing the choices that must be made by the user/developer.
--
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 [email protected].
To post to this group, send email to [email protected].
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/85791098-b7dd-46e0-96d9-530625b7a6e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
