Hi Chris, > I'm happy to advise and support people, and do try to keep track of > anything that has some relevant to TiddlyWeb. However I don't want to > be in the position of initiating a repo as someone else doing so is a > clear sign of real commitment by someone or some group. I think it > would be a bad idea to remove that signal. > > If that signal is lit, then woot, I'll watch closely. >
Totally understand. So, let's wait and see some more when attempted implementation(s) start trickling down. It's effectively this line that is the issue: > > > https://github.com/Jermolene/TiddlyWiki5/blame/3df341621d30b205775288e324cef137c48e9f6e/plugins/tiddlywiki/tiddlyweb/tiddlywebadaptor.js#L68 > > > That is the only place that the recipe for the adaptor is set but it > uses a piece of data that only exists on TiddlySpace. As I've > described here: > > https://groups.google.com/d/msg/tiddlyweb/UcYrnvGwNUQ/UJRgSn4VjfYJ > the recipe can be set manually but it would better if TiddlyWiki5 > could ask the user what recipe on what server they want to use and > load that into a story (either including it in the current, replace > the current or making a namespaced one adjacent to the current). > I see, so there are actually a few challenges... 1. expose those recipes to "wiki authors", if only manually - this presupposes to manually manage recipes AND user data at the TiddlyWeb serverside 2. allow to more dynamically configure server(s) and recipe(s) to CRUD from within TiddlyWiki - a crucial part may be in the plural above and whatever conflict handling is needed with - changing recipes - conflicting recipes (duplicate contents, execution order / precedence) - how all that plays out with plugins and themes It looks like the "simple", straight forward TiddlySpace setup has some rather reliable and ready-to-use tenets to work with... for which leveraging all the generic TiddlyWeb potential could quickly increase complexity on the client-end to highly challenging scenarios. For one, in TiddlySpace you only ever authenticate against one server / service: TiddlySpace. That simplifies handling multiple "spaces" / remote locations to talk to by magnitudes, even though it would perhaps be an incredibly powerful thing to hook up to a number of arbitrary (TiddlyWeb or other) server nodes from a single wiki instance... for which there is some "home recipe" and server holding its basic configuration. A cross-server implementation would surely play along the theme of TiddlyWiki being a "guerilla wiki"... dynamically pulling stuff, even ad-hoc. Switching that "wiki view" from one recipe / remote content pool to another. Some remote recipes / bags could be used conjointly: a home / setup bag, some template foo, a libarary bar, an app baz ...and then others loaded dynamically / switched to, e.g. "TiddlyWiki plugin repo"... alongside ways of moving and merging things from remote location A to B. Imagine some kind of TiddlyExplorer that would — like any local file system explorer — list any connected remote locations with support to drag and drop / move things from a source to a target... and the corresponding conflict handling. So, one layer would be to explore those remote locations and cook the desired contents into target locations and then to define "wiki instances" that feed off of certain remote sources. The explorer could be an entirely independent application from authoring any thus set-up "wiki instance". Sure, if there were a number of remote sources — if only bags (in recipes) — being considered, there'd have to be some ui that allows a user to select and define which one to read from and write to at a given moment, e.g. some form of "select" in both view- and edit-mode that switches to the corresponding remote location for loading or writing. True. There are (as with everything) simple and deluxe ways to handle > things. The easiest thing to do is to respond to the HTTP response > code for an edit conflict with a warning message to the user. Then > they can choose to resolve it however they like. > All this client-server-talky-talky seems to beg for a thorough requirements analysis / conceptual design... or possibly / alternatively one who dares... 1. fiddle their way accross all gaps and hurdles, testing and connecting existing infrastructure pieces to that TW5-Collaboration-Puzzle 2. start a conversation so as to breathe some life into any missing links The direction I'm trying to push things is that as much smarts as > possible are in TiddlyWiki. This is possible. The APIs exist such that > a very minimal tiddlyweb server can do most of the things people have > been wanting. > Mario mentioned that managing recipes, bags, even users may not entirely be in the scope of the TiddlyWeb API. Is that so or what aspect(s) of a TiddlyWeb setup can be managed via HTTP(s), if any? Otherwise, how do you envision a meaningful default workflow so as to get a TiddlyWeb instance up and running in a multi-user environment? I guess one big question is: What do we mean by collaboration? What does it entail? - user setup / registration / authentication? - "shared", multi-user wikis - access rights ? r / w - admin vs. editor vs. subscriber? - user wikis / spaces / profiles - "space" inclusion Yes, I suspect so, but it really comes down (if not using the > websockets option) of frequently asking the server for info at the > right url: > > https://tank.peermore.com/bags/cdent/tiddlers?select=modified:%3E2015 > > (anything in that bag since the beginning of the year) > > Those selects work on any tiddler collection. There are also ways to > do it with searches. > I see, so again it's a task that begs for someone to start playing with a TiddlyWeb server and test out certain communication patterns as to how suitable they are to implement polling in a collaborative environment and then properly handle (merge) conflicts, mostly. 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.
