X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/08e9c427a9be88b43866cff1aa1c1ed6381a93f5..832d4d31d177d5d5f848250496048a00e9d70e2f:/doc/todo/recentchanges.mdwn?ds=sidebyside diff --git a/doc/todo/recentchanges.mdwn b/doc/todo/recentchanges.mdwn index 6817d3298..25a8ea4db 100644 --- a/doc/todo/recentchanges.mdwn +++ b/doc/todo/recentchanges.mdwn @@ -22,3 +22,123 @@ once, when it's created, and I imagine some people -- some deranged, obsessive-compulsive people like myself -- would like to know about the changes made to existing pages as well as newly-created pages. + + > That would work rather well for pages like [[todo]] and [[bugs]], where + > you want to know about any updates, not just initial + > creation. --[[JoshTriplett]] + + > Of course you can use email subscriptions for that too.. --[[Joey]] + + >> I have more thoughts on this topic which I will probably write + >> tomorrow. If you thought my other patches were blue-sky, wait until + >> you see this. --Ethan + +OK, so here's how I see the RecentChanges thing. I write blog posts and +the inline plugin generates RSS feeds. Readers of RSS feeds are notified +of new entries but not changes to old entries. I think it's rude to change +something without telling your readers, so I'd like to address this. +To tell the user that there have been changes, we can tell the user which +page has been changed, the new text, the RCS comment relating to +the change, and a diff of the actual changes. The new text probably isn't +too useful (I have a very hard time rereading things for differences), +so any modifications to inline to re-inline pages probably won't help, +even if it were feasible (which I don't think it is). So instead we +turn to creating diffs automatically and (maybe) inlining them. + +I suggest that for every commit, a diff is created automagically +but not committed to the RCS. The page containing this diff would be +a "virtual page", which cannot be edited and is not committed. +(Committing here would be bad, because then it would create a new +commit, which would need a new diff, which would need to be committed, +etc.) Virtual pages would "expire" and be deleted if they were not +depended on in some way. + +Let's say these pages are created in edits/commit_%d.mdwn. RecentChanges +would then be a page which did nothing but inline the last 50 `edits/*`. +This would give static generation and RSS/Atom feeds. The inline +plugin could be optionally altered to inline pages from `edits/*` +that match any pages in its pagespec, and through this we could get +a recent-changes+pagespec thing. You could also exclude edits that have +"minor" in the commit message (or some other thing that marks them as +unremarkable). + +You could make an argument that I care way too much about what amounts +to edits anyhow, but like Josh says, there are use cases for this. +While this could be done with mail subscriptions, I can think of sites +where you might want to disable all auth so that people can't edit +your pages. --Ethan + +> I really dislike all Wiki engine recentchanges pages. They all tend to be +> fairly machine readable, but confusing for non-wiki users to grok. And I've +> yet to see an _attractive_ recentchanges implementation. IkiWikis' is no +> better or worse than the others. +> +> I really like the frontpage of [Bill +> Seitz](http://webseitz.fluxent.com/wiki/FrontPage) as an recentchanges +> format. Note how he uses some clever css to show changes in different +> sections of the website. I modeled my own +> [recentchanges](http://xtermin.us/recentchanges) page page on his ideas. This +> probably isn't appropriate for non-WikiLog style setups, but is this +> something closer to what you what was requested? +> +> BTW: My recentchanges plugin does not seem to add a lot processing time +> to compiling. Then again, I'm not pulling changelog message from the RCS +> backend. +> +> -- CharlesMauch + +---- + +Here's a full design for redoing recentchanges, based on Ethan's ideas: + +* Add a recentchanges plugin that has a preprocessor directive: + \[[!recentchanges num=100 pages=* template=recentchanges.tmpl]] + If put on the [[recentchanges]] page, this would result in up to 100 + recentchanges/change_$id.mdwn files being created. +* Which means the plugin has to store state and use a checkconfig hook + or the like to create the requested pages (and delete old ones) when + the wiki is rebuilt and when the post_commit hook is run. +* Then it's a simple matter of using inline on the recentchanges page + to display the changes. (With a special template to display nicely.) +* Rss/atom comes for free.. +* So drop mail notifications. +* If someone wants to subscribe to notifications for only a subset + of pages, they can either filter the recentchanges in their rss + aggregator, or they can set up their own page that uses the recentchanges + directive for only the pages they want. +* The `rcs_notify` functions will be removed. +* To add diffs, another plugin can add a pagetemplate hook that calls + a `rcs_diff`. (optional) +* So to update the changes files, just call `rcs_recentchanges`, create + files for each new id, and delete files for each id that is no longer + included. +* The cgi support for recentchanges can be dropped, or moved to a different + plugin. + +I'm unsure how fast this will all be, but by using regular pages, there's +cacheing, at least. The main slowdown might turn out to be the inlining and +not the generation of the changes pages. The current cgi recentchanges +code saves a tenth of a second or so by memoizing htmllink, an optimisation +that won't be available when using the more general inlining code. + +An obvious optimisation, and one implied by this design, is that each change +file is only written once. This assumes that the data in them doesn't ever +change, which actually isn't true (svn commit messages can be changed), but +is probably close enough to true for our purposes. + +Another optimisation would be to htmlize the change files when they're +written out -- avoids re-rendering a given file each time a new change is +made (thus doing 1/100th the work). + +Links in the change files to the changed pages will need special handling. +These links should not generate backlinks. They probably shouldn't be +implemented as wikiliks at all. Instead, they should be raw, absolute +html links to the pages that were changed. + +Only problem with this approach is that the links break if the changed +page later gets deleted. I think that's acceptable. It could link to +`ikiwiki.cgi?do=redir&page=foo`, but that's probably overkill. + +--[[Joey]] + +[[done]] !! (in this branch at least :-)