Re: [Gnu-arch-users] Wiki software using arch as a datastore?

[Johannes Berg]

On Sun, 2004-02-01 at 02:19, Robin Green wrote:
> 1. Revision control: Keeping only one prior version of each page (as
> some wikis do or did) is unsafe because it allows malicious damage.
> Why not keep a complete history?

Thats one thing I've been wondering too, though some wikis actually use
RCS as their backend IIRC.

> 2. Page moves/renames: arch would obviously support revision control
> in the presence of moves and renames. Although an ability to say
> "this file is the merge of this file and that file" or the reverse,
> "these N files are the decomposition of this file", would be a nice
> feature to add to arch - for source code tracking as well as for
> Wikis.

Would you link pages using their tla tag? Basically automatically stick
some tag into the page and link using that?

> 3. Disconnected editing: [...]
> 
> 4. Wiki forking: [...]

(see below)

> 5. Fixing the "trusted admin" vulnerability. Users should not have to
> trust that the wiki admins - who they may never have met and may have
> no reason to trust (or may even have reason to _distrust_) - will not
> abuse their privileged position, e.g. by "rewriting history" or
> erasing things because they don't like them.
> 
> If a user cryptographically signs all commits, then fraudulent changes
> to that user's commits could be detected.

Basically you're saying that whatever a user entered can always be
verified as being entered by them. Do I get that right?

> Similarly, there should be the option of building a distributed,
> redundant wiki, to limit the damage an internal or external attacker
> could do. I haven't decided how best to do this.

Simply auto-mirror the underlying tla archive someplace else? If you
store full history, there's no real damage that can be done if you have
the archive data.

> 6. Staging areas for less-trusted newbies.[...]
> 
> 7. Microbranches [...]

6 is just a special case of 7, isn't it? Each `newbie' gets their own
branch and if they turn out to produce good contents the main wiki
merges from them.

Together with 3 and 4 I think what you're proposing is basically two
things:
1) a wiki using the filesystem as its storage
1a) it should allow rename but thats not too much of a problem
2) a web-front end for the following tla functionality:
 - commit, update
 - branch
 - star-merge
 - some more

1) already exists. You just need to make the wiki aware of multiple
branches (ie. some selection mechanism), so you can go to some special
page and say: "hey, now I want to see this directory instead". Then a
directory just corresponds to a checked-out copy of the branch.

Additionally, each file modification must do a commit on the underlying
file-system. You get into trouble though if multiple people try to edit
different or even the same pages

2) is harder. But you get the benefit of arch's distributedness, so as
long as all servers have tla and the same wiki they can cooperate.
Now you need:
  - a way to branch inside the same server
  - a way to tell one server to branch from some other wiki server
  - merge functionality, including handling rejects
  - much more

Having thought about it now I think that it isn't all too useful.
Actually, a web interface to tla might be useful ;-)
But there appears to be no fundamental difference to just having
everyone edit html files and handling those in arch, except for the
different way of editing files and the web interface.
And you still need some wiki administrator that continually processes
merge requests from other wikis etc. (or you use pqm)

Hey, now I'm back to thinking it would be useful. I can see me sitting
here and thinking -- heck, I'd love to be able to put this information
into the gnu arch wiki now (actually, this happened to me yesterday).
But I can't because I'm not online. 
With an archwiki I could have a local copy on my webserver, edit that,
and send a merge request to the main wiki, all to be processed when I am
online again. The only question is what the main wiki requires to accept
merge requests.
If you accept that for now you'd need to branch manually, you could
probably get this running fairly soon. One thing that would help
_really_ a lot would be `tla commit -- new-file', because then each wiki
edit could simply commit the only file it edited. Maybe later you'd want
to be able to logically group changes (ie. have the user do: start
transaction, do edits, commit transaction).

Oh, and is there some other place to discuss this topic?

johannes
-- 
http://www.sipsolutions.de/
Key-ID: 9AB78CA5 Johannes Martin Berg <address@hidden>

signature.asc
Description: This is a digitally signed message part