While writing tests for the ICAT notification for release 4.2 - which is almost ready - I noticed some usability issues:
To request that the primary key of the entity is stored in the message you request "entityId" but pick it up as "pk". As there is also the field entityName I propose to add an extra field entityId to the message with the same value so that "pk" can be removed in the future.
The message does not include the access type "CRU or D" - this will require one more field in the database table to control its selection.
The support for Notifications for search operations is rather poor - only simple entity names are acceptable. To do a better job would require yet one more field in the database holding a fragment of JPQL. It is not efficient to evaluate each returned entity against the notification requests as this would produce a lot of extra queries - which is why I don't do it currently. What could be done however is to combine the authorization rule with the selection query and then add each notification request in turn - returning, for each request, a count which if non-zero would indicate that the message should be constructed and sent. This would require that a very small number of quite complex queries would need to be formulated. To evaluate the utility of this requires some ideas on how people would actually like to use notifications.