On Mon, 2 Mar 2015, Tobias Beer wrote:
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 probably not the most productive strategy but time being what it
is...
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.
Yes, this is very in line with the vision of TiddlyWiki/TiddlyWeb
interaction that I've always been shooting for. Your additional
descriptions are very good.
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?
The _API_ supports managing recipes, bags and policies for both,
directly in the TiddlyWeb core. There's a plugin,
tiddylwebplugins.socialusers, which adds _API_ support for users.
What's not present is client side tooling (libraries, UIs) for
managing the operations.
I think there's a perception that doing CRUD on recipes, bags and
users in TiddlyWeb is quite complex. What's complex is effectively
implementing the concepts. The actual operations are simple PUT
requests with a relatively small amount of JSON[1].
One a tiddlyweb instance is created, installed and configured (with
the socialusers plugin), it is possible to manage all the necessary
operations over the API.
(You might be wondering why the socialusers plugin is a plugin rather
than built it. Basically it is because it requires an explicit step
for the admin of the service to say "Yes, I want to expose user
management over the web.")
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.
Seems so. I think that's the general truth: people just need to try
stuff and see where it goes. There's a tendency to want to solve
problems before they are concrete.
[1] A good starting point for the API is here
http://tiddlyweb.tiddlyspace.com/HTTP%20API or here
http://tiddlyweb.tiddlyspace.com/explorer
--
Chris Dent http://burningchrome.com/
[...]
