Event notification is usually asynchronous. Synchronous notification requires polling which is very inefficient. When a node changes all readers receive an event, and will update their display asynchronously.
Individual users may wish to subscribe to events (or not). This places selection overhead on the server. For every operation the server must check which client applications have subscribed to that event. This overhead can be placed with the client by making the client ignore unwanted events (and letting the server send them anyway).
Fine-grained Notification
Notification of all operations on objects and attrributes in objects should
be supported, including notification of lock, unlock, delete and write
operations on a find-grained level.
Notification can only be (reliably) be implemented at the same granularity
level as locking.
Persistent Event Subscription
Event information should be kept persistently in the hypertext system,
for the same reason as persistent locking.
If either the server or the client crashes, both should be able to
recover the event subscriptions.