> 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]]
sipb-www / ikiwiki.git / blobdiff