Setup for a few editors and many read-only viewers

#1

I’m trying to figure out how to deploy several wikis where—for each independently—there will be a handful of editors and many more viewers who get a read-only view. I was wondering if others have managed to get something like this running.

In the cases where I’ve done something close to this, my editors have been tech-savvy users of Nodejs and git; in those, I could just deploy with GitHub pages, allowing the user to run Node locally and push git changes at appropriate times. Rare merge conflicts can be handled through git tools. When running in Node, the edit interface is visible; when running stand-alone, including through GitHub pages, it’s hidden.

In the cases I’m trying to figure out, the additional editors do not have those skills. So far, I’ve been the only editor, but I really want to open these up. For instance, there’s one for which I’m one of two co-Chairs for an organization. I would like the other co-Chair to be able to modify most of the content, for the Secretary to be able to posts agendas and minutes, and for the Treasurer to post financial reports. However, I’m not looking for a granular permission model. I’m perfectly happy if anyone with edit rights would be able to change any content. I would expect to still do all the infrastructure work myself.

I would like to do this without passing updated versions back and forth.

I’m quite willing to consider other options, but right now my dream scenario looks like this: When a non-editor visits, s/he gets the read-only view, hiding all buttons and toolbars that don’t affect her. (When MWS is complete, I would hope this could be done with a bags/recipes model and not even send the edit interface to these users, but I wouldn’t be upset to continue my current technique of simply hiding it in a Startup action.) When an editor visits (perhaps at a different URL), s/he authenticates somehow (probably an OAuth server, but we’ll see) and has all the edit tools available. As s/he saves tiddlers, the server commits the changes to git, and on demand or after a period of quiescence, pushes the changes back to the GitHub repository. There might also be a mechanism to declare new versions when you choose to manually push. I don’t know what the best synchronization model would be, but these are low-activity wikis, and I could live with almost anything for that.

So… any ideas?

#2

Scott, I have spend many hours in an attempt to do this since the neglect of the node based Bob solution. The one I like most is one that also works on single file wikis is the serial editor approach.

serial editor approach

Treat tiddlywikis as smart documents with their own document management layer, allowing the document to be checked in and out and back in by valid users/editors. In addition to this add a security layer for only the editors eg through PHP but then within the set of editors (who clearly you trust) control the document editing process.

Serial editing is where a trusted group of users are entitled to edit a document but only one at a time to ensure no conflicts. ie serially, one after the other.

As is often the case, the suitability of such a method depends on the data, the frequency and volume of edits etc… Personally I have found with many “smart Documents” there are usually only a few editors ever active against one document. If you have many at once a multi-user solution with a backend database maybe more appropriate.

I have done various Proof of Concepts for each and every aspect of building an effective solution for “Serial Editing” but it becomes complex and self referential very quickly so I have not yet pushed it into a deployable solution. It gets hard doing such things on ones own.

  • I am happy to share component solutions if you decide to develop a serial editing solution.

Post Script: I did leverage tiddlywiki on SharePoint to handle the check in and out, as tiddlywiki can save to webdav and SharePoint can handle most of the serial editor functionality.

  • This points to the possibility of providing a tiddlywiki wrapper type solution to control the right to serial edits.

I must say I have raised this many times and disappointed the community has not yet gotten behind such an approach. It would really open up the possibilities of a true CMS

#3

Post Script:

The new Multi-wiki server solution could be the answer if you structure the wiki so the multi-editor process works at a logical level.

#4

Yes, that is much like the current state of things. In two of these wikis there are other users who have make occasional edits (a fact I glossed over in the OP.) But I’ve then simply taken the version they emailed me and overlayed my local Node version with it, using a command like tiddlywiki path/to/wiki/dir --load path/to/updated/wiki.html. I find this error-prone and too dependent upon me being in the loop. Putting this in a shared space where people can just take and modify the canonical version would make this better. I’m not particularly worried about contention between two editors, although I’d prefer to avoid the possibility.

I’d would really like to make this more this more robust, though.

I think it will solve some of the problems I’m worried about, but I don’t know if will really handle the Auth layer as I would hope. @Arlen22, any thoughts?

#5

This is feasible, but like you I don’t like it. Too manual, demands caution and adds risks, although this could be automated.

I prefer when they just go to edit and see if its available and check out to start editing. Basically build an effective workflow process without wiki owner intervention. One could even send an email when the document is checked in.

#6

Absolutely. That’s what I want to replace.

I’d like to go one step further, and avoid checking out and checking in the document. (Too many horrible memories of Visual Source Safe!) I can mostly use git to avoid that, only dealing with merging issues if the users are working in the same sections of a single tiddler. For any of this, I would need a server solution, which makes me think I want to extend the Node version with this feature. Doing it in something like PHP would to my mind simply add complexity.

I’m mostly hoping to find if others have already done something like this in a sharable way. I’m guessing the answer is “No”, but I want to be sure. While I probably have the skills to extend the Node server this way, I have very little interest in that work. It’s very hard to get motivated to start working on it.

#7

I wonder if anyone has experience using the Node.js version of TiddlyWiki with Syncthing for multi-user synchronization.

#8

@tomzheng: Are you saying that this already exists? Or only that a two-way syncing version is available?

#9

If that is the case I think you force yourself towards a node server solution.

#10

I have assumed that all along. But that does not concern me. I will have to find some inexpensive Node hosting, which shouldn’t be difficult. But I want to see first if others have already figured this out.