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