Roan Kattouw <> changed:

           What    |Removed                     |Added
             Status|RESOLVED                    |REOPENED
                 CC|                            |
         Resolution|FIXED                       |

--- Comment #6 from Roan Kattouw <> 2010-01-31 10:03:06 
UTC ---
The notification timestamp is not quite a 'last seen' timestamp, it's the
timestamp of the first unread revision, or NULL if there are none. I'm vary of
allowing users to set it to any old value because I don't know what will happen
when its value is invalid (lemme look that up).

Use case #1 concerns screen scraping while getting page contents and diffs is
possible through the API (I'm pretty sure this doesn't touch
wl_notificationtimestamp). If your screen scraping unnecessarily and these
kinds of issues come up, they're your problem.

Use case #2 sounds valid ('mark as read'). It can easily be done by visiting
the page in the background with AJAX, although I agree that's a hack and the
API should offer a 'mark as read' feature. That, however, would set the
timestamp to NULL, not to an arbitrary client-provided timestamp.

Use case #3 is a good one. I think this feature should be in core and exposed
through the UI as well as the API.

Use case #4 is based on a misunderstanding of what the notificationtimestamp
does: setting it in the future will not prevent it from showing up in the
watchlist, it'll just show it as having been changed in the future and confuse
the code showing you the diff.

I'll reopen this bug for use case #2, and I suggest you open a new one for #3
(specifically for the mark as unread feature to be available in core).

Configure bugmail:
------- You are receiving this mail because: -------
You are watching all bug changes.

Wikibugs-l mailing list

Reply via email to