doc/todo/recentchanges.mdwn

   1 * Why isn't it statically-genereated, but generated dynamically by CGI? It
   2   seems like it could be beneficial to have it rendered in the post-commit
   3   hook, just like everything else in the wiki.
   4
   5   > I hope to statically generate it eventually, currently the problem is
   6   > that it takes at least several seconds to generate the recentchanges
   7   > page, and adding several seconds to every page edit is not desiriable. If
   8   > the time can be reduced it could be done, I'm also not adverse to
   9   > adding an optional way to statically render it even at the current
  10   > speed. --[[Joey]]
  11
  12 * Also, is it planned/desired that recent changes generate the same
  13   information in RSS feed format? This seems like it could be a useful way
  14   to keep track of the wiki as a whole.
  15
  16   > This is used by various interwiki type things, I think, so should be
  17   > done.. --[[Joey]]
  18
  19 * Lastly, would it be possible to use the recent changes code with a
  20   pagespec? I understand this sort of infringes on territory covered by the
  21   inline plugin, but the inline plugin only puts a page in the RSS feed
  22   once, when it's created, and I imagine some people -- some deranged,
  23   obsessive-compulsive people like myself -- would like to know about the
  24   changes made to existing pages as well as newly-created pages.
  25
  26   > That would work rather well for pages like [[todo]] and [[bugs]], where
  27   > you want to know about any updates, not just initial
  28   > creation. --[[JoshTriplett]]
  29
  30   > Of course you can use email subscriptions for that too.. --[[Joey]]
  31
  32   >> I have more thoughts on this topic which I will probably write
  33   >> tomorrow. If you thought my other patches were blue-sky, wait until
  34   >> you see this. --Ethan
  35
  36 OK, so here's how I see the RecentChanges thing. I write blog posts and
  37 the inline plugin generates RSS feeds. Readers of RSS feeds are notified
  38 of new entries but not changes to old entries. I think it's rude to change
  39 something without telling your readers, so I'd like to address this.
  40 To tell the user that there have been changes, we can tell the user which
  41 page has been changed, the new text, the RCS comment relating to
  42 the change, and a diff of the actual changes. The new text probably isn't
  43 too useful (I have a very hard time rereading things for differences),
  44 so any modifications to inline to re-inline pages probably won't help,
  45 even if it were feasible (which I don't think it is). So instead we
  46 turn to creating diffs automatically and (maybe) inlining them.
  47
  48 I suggest that for every commit, a diff is created automagically
  49 but not committed to the RCS. The page containing this diff would be
  50 a "virtual page", which cannot be edited and is not committed.
  51 (Committing here would be bad, because then it would create a new
  52 commit, which would need a new diff, which would need to be committed,
  53 etc.) Virtual pages would "expire" and be deleted if they were not
  54 depended on in some way.
  55
  56 Let's say these pages are created in edits/commit_%d.mdwn. RecentChanges
  57 would then be a page which did nothing but inline the last 50 `edits/*`.
  58 This would give static generation and RSS/Atom feeds. The inline
  59 plugin could be optionally altered to inline pages from `edits/*`
  60 that match any pages in its pagespec, and through this we could get
  61 a recent-changes+pagespec thing. You could also exclude edits that have
  62 "minor" in the commit message (or some other thing that marks them as
  63 unremarkable).
  64
  65 You could make an argument that I care way too much about what amounts
  66 to edits anyhow, but like Josh says, there are use cases for this.
  67 While this could be done with mail subscriptions, I can think of sites
  68 where you might want to disable all auth so that people can't edit
  69 your pages. --Ethan
  70
  71 > I really dislike all Wiki engine recentchanges pages.  They all tend to be
  72 > fairly machine readable, but confusing for non-wiki users to grok.  And I've
  73 > yet to see an _attractive_ recentchanges implementation.  IkiWikis' is no
  74 > better or worse than the others.
  75 >
  76 > I really like the frontpage of [Bill
  77 > Seitz](http://webseitz.fluxent.com/wiki/FrontPage) as an recentchanges
  78 > format.  Note how he uses some clever css to show changes in different
  79 > sections of the website.  I modeled my own
  80 > [recentchanges](http://xtermin.us/recentchanges) page page on his ideas.  This
  81 > probably isn't appropriate for non-WikiLog style setups, but is this
  82 > something closer to what you what was requested?
  83 >
  84 > BTW: My recentchanges plugin does not seem to add a lot processing time
  85 > to compiling.  Then again, I'm not pulling changelog message from the RCS
  86 > backend.
  87 >
  88 > -- CharlesMauch