X-Git-Url: http://git.vanrenterghem.biz/git.ikiwiki.info.git/blobdiff_plain/bf4e6716cc57eb6d0dfca43ce92b64934950513e..89a5dde72e00feb9e86537aee5992c86ed0582d7:/doc/todo/recentchanges.mdwn?ds=inline

diff --git a/doc/todo/recentchanges.mdwn b/doc/todo/recentchanges.mdwn
index 7337c3d49..11a39d610 100644
--- a/doc/todo/recentchanges.mdwn
+++ b/doc/todo/recentchanges.mdwn
@@ -2,18 +2,19 @@
   seems like it could be beneficial to have it rendered in the post-commit
   hook, just like everything else in the wiki. 
 
-  I hope to statically generate it eventually, currently the problem is
-  that it takes at least several seconds to generate the recentchanges
-  page, and adding several seconds to every page edit is not desiriable. If
-  the time can be reduced it could be done, I'm also not adverse to
-  adding an optional way to statically render it even at the current speed.
+  > I hope to statically generate it eventually, currently the problem is
+  > that it takes at least several seconds to generate the recentchanges
+  > page, and adding several seconds to every page edit is not desiriable. If
+  > the time can be reduced it could be done, I'm also not adverse to
+  > adding an optional way to statically render it even at the current
+  > speed. --[[Joey]]
 
 * Also, is it planned/desired that recent changes generate the same
   information in RSS feed format? This seems like it could be a useful way
   to keep track of the wiki as a whole. 
 
-  This is used by various interwiki type things, I think, so should be
-  done..
+  > This is used by various interwiki type things, I think, so should be
+  > done.. --[[Joey]]
 
 * Lastly, would it be possible to use the recent changes code with a
   pagespec? I understand this sort of infringes on territory covered by the
@@ -21,3 +22,48 @@
   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