From: Steve W. <sw...@pa...> - 2001-06-11 02:44:25
|
Thanks for the tour, Joel! On Sun, 10 Jun 2001, Joel Uckelman wrote: > So, here's what looking around has suggested to me: > > 1. Should changes be stored incrementally, and old pages built from them? > Or should diffs be calculated from stored pages? The former conserves > storage at the expense of CPU cycles, the latter the opposite. Or maybe > incremental diffs and old pages should both be stored, period? This seems > like a basic design decision, rather than something that would be > user-configurable. I have a core belief about Wikis: they do not scale. They do not scale in terms of the number of users, that is. I think a Wiki can hold about as many active users as a mailing list; once you go beyond a certain number of daily posters to a mailing list, it's no longer feasible to read that mailing list. There's too much information and too low a signal to noise ration. So conserving cpu cycles is a non-issue (relativley... we are not going to start using bubble sorts!) Storage space, on the other hand, will only get cheaper and more vast as time goes on. So we will store whole pages and calculate diffs as needed. I think diffs are not needed much anyway. (I mean, there is a low demand for them vs. other features users use, like search. Diff is critically important to have though). My favorite diff implementation of all time is actually not in a Wiki but would serve as a good model for us to emulate: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phpwiki/phpwiki/README.diff?r1=text&tr1=1.6&r2=text&tr2=1.8&diff_format=h I like the side-by-side comparison and the color coding. I've found this incredibly helpful when doing development. You can play with a tool called "sdiff" on a lot of Unix systems too, which will give you a simple monochrome side by side diff. > 2. Buttons/links associated with versioning (and everything else!) should > have obvious functions, or at least ones that can be determined after a few > tries. Duh. MoinMoin was a particularly egregious offender in this regard. > > 3. Diffs should be easy to read, but not so sparse as to omit useful > information. I like the way diffs are done in phpwiki right now. Good job, > guys. All credit to Jeff! I doubt we'd even have diffs without his commitment and amazing hacking abilities. > 5. Ability to access all revisions from a single page is a Good Thing. > Having to click a zillion times to get to the one you want is not. Again we could copy viewcvs.cgi: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/phpwiki/phpwiki/README Rather than clutter the reading page with a million links to do things, I think we're better off just having the "diff' link go to a page like the one above. > 6. The major/minor revision distinction would provide a good way to tag > pages that were altered, e.g., to correct typos. It could also be used by > someone malicious who wanted to draw attention away from revisions, though. > This, like all things Wiki, would depend on the goodwill of the user. With user auth, this problem would be rare, one would hope. > 7. How exactly does the current version of phpwiki decide what to archive? > I've noticed pages with archiving for the immediately previous version, a > version more than one change out of date, and no previous versions at all. > What's the deal? It goes like this: If you edit the page and you are not the previous author, the old version is archived. You can continue to edit the page forever after and it will not archive another version (as long as you come from the same IP address, which is how we track the author). This has turned out to be a problem for some people who are the sole users of the Wiki. This algorithm was taken right from the WikiWikiWeb itself. I think we'll go with the MeatBall approach of the "do not archive, these are small changes" option. Better to archive minor changes than to lose information. ~swain --- http://www.panix.com/~swain/ "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." -- Frank Zappa |