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.
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.
- old_id cannot be used as 100%secure pointer to a certain revision (eg. LVR)
of a page.
- 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
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.
If you have another idea, or if I have overlooked something, which can happen,
please let me know this by mailto:firstname.lastname@example.org?Subject=LVR .
Thanks in advance