Notification (&Query) Requirements Meeting
Date: 17 Dec 2003
People: AndiVajda, JohnAnderson, HeikkiToivonen
Definition: A collection is a list of items where each item is a list, an item or a query.
It seems like there might be a discrepancy on what Mitch calls a collection and what the repository sees as a collection. This could be a potential problem (potential because the application could probably figure things out, but it might be unnecessary complication).
Two kinds of notifications:
- Collection changes
- Item changes
A change in collection means:
- a member added
- a member deleted
- any detail in a member changes (basically, any attribute changes)
Timing of notification: when commit happens, the repository can notify.
We decided on two kinds of interests in notifications, and the application above the repository makes the decision what to use. Either the application can register interest in
collection changes and it will receive one notification for all the changes in the collection, or it registers an interest in
all individual changes.
NOTE: Potential issue for future: application has registered interest in individual changes, but some change in repository (maybe caused by another application or by the repository itself) changes a large number of items, which can cause more notifications for the application than it was prepared to handle, causing at least performance problems.
We want the notification part in the repository to be as small as possible, and put more logic in layers above it.
If the repository needs something from the notification manager, we should be prepared to change the notification manager.
Notification manager should be the central communication point about notifications between the application(s) and the repository.
There must be an API for the application(s) above to register interest in different types of changes in the repository (collection/item, attribute change, ...).
The repository needs to be able to figure out fast if an item belongs to a query (possible at least in cases where query result does not depend on the items returned by the query, but in general this does not seem to be possible).
Andi sees at least one way to implement some changes quickly, but it is not yet completely clear if that is the right way to go (see discrepancy about collections above).
Andi to discuss things (especially the query aspects) with Ted before proceeding with implementation.
I'm probably forgetting some important parts, particularly during the open discussion after the meeting (Katie also took part)...
-- HeikkiToivonen - 19 Dec 2003