Plse. skip this now, if you are not interested in improvements to recent-changes and page-history behaviour. ------ References: http://bugzilla.wikipedia.org/show_bug.cgi?id=603 (delete/undelete cycle does not preserve oldid) http://bugzilla.wikipedia.org/show_bug.cgi?id=454 (Enotif 1.33) Introducing an abbreviation: last-visited revision (LVR; lvr) I would like to ask you something with respect to a suggestion to improve the recent-changes and page-history behaviour. Status: ====== As far as I understand the software and Brion, old_id is *not* a permanent and fixed identifier for a certain revision of a page. It is only valid for a while and under certain circumstances. However, the Email-Notification patch (Enotif) and some users request a "(diff-to-my-last-visited-revision)" (lvr-diff) link, which *is* implemented in the recent Enotif 1.33 patch coming this weekend - based on old_id - which works unless that lvr revision is deleted in the databases e.g. by scheduled RC pruning. Problems: ======== 1) old_id cannot be used as 100%secure pointer to a certain revision (eg. LVR) of a page. 2) Currently, any older revision of a page is deleted after a while Question to you and proposal: ======================== Given, that the RC History may be pruned after a while and that old_id can change due to a delete/undelete cycle of that page, I propose to built an LVR-REPOSITORY (last-visited-revision), which can be compressed. If a certain pageX is watched by a UserZ, I herewith propose to permanently save the "last visited revision (lvr) of pageX". This is the page revision just before the UserZ got an enotif, because someone else edited the pageX to revision (lvr+1). Enotif 1.33 already has this implemented and knows (lvr), but does currently not save the page content. This pageX(lvr) must now neither be touched by regular RC history pruning nor by delete/undelete cycles and must be saved. To free memory resources, it needs theoretically only be saved *until* the watching UserZ visits the *current* revision of page - as this action automatically clears the notification flag (this mechanism being open for further improvements). In the worst case, we need a repository of size "total number of watched pages of all watching users". For example, if 1.000 users have 50 pages in each of their watchlists, we need a repository for 50.000 pages, which stores the "last-visited-revisions" for all watched pages for all users. Please let me know, how you think about my proposal. Enotif could manage the repository, as it keeps track of users visiting their watch-listed pages. The repository can be a separate database or realized as flag in the old and rc databases, which forbids the RC pruning or other routines to manipulate (eg. delete) that certain LVR. Invitation ======= If you have another idea, or if I have overlooked something, which can happen, please let me know this by mailto:mail@tgries.de?Subject=LVR . Thanks in advance Tom Berlin