Confirmed users
1,927
edits
BMO/ChangeNotificationSystem: Difference between revisions
Jump to navigation
Jump to search
→Design and Approach
(Created page with " = Team = BMO team (dkl, glob, mcote), ebryn (contract developer on front end), peterbe (advisor from web tools) = Problem = With a focus on Bugzilla as a platform, facilit...") |
|||
| Line 22: | Line 22: | ||
= Design and Approach = | = Design and Approach = | ||
We will implement a separate server that polls the database directly (or otherwise receives notifications from the database) for changes to bugs and passes on *only the ID* of the changed bug to its clients. The clients can then use the main Bugzilla REST API to determine the exact changes, which will enforce permissions as usual. For simplicity, clients | We will implement a separate server that polls the database directly (or otherwise receives notifications from the database) for changes to bugs and passes on *only the ID* of the changed bug to its clients. The clients can then use the main Bugzilla REST API to determine the exact changes, which will enforce permissions as usual. | ||
To be determined is whether all updates are pushed out or whether one can subscribe to particular bugs. For simplicity, we might want to notify clients of ''any'' changed bug; there is no support for subscribing to particular bugs. The notification data is very small (a bug ID, currently 6 or fewer characters); however, if bugs are changing very rapidly, this might still generate an undesirable amount of traffic. In this case, we should implement a simple subscription command, although to make this useful, probably some other related commands would be required (unsubscribe, list subscriptions). Some benchmarking will be needed to make this decision. | |||
'''Important note''': this whole design relies upon the idea that ''knowing the ID of a changed bug'' is not a security risk. This should be reasonable, given that the only information that is conveyed is that some bug has changed. One could use this information to determine the frequency of changes to a particular bug over some time frame, and hence ''perhaps'' an increased interest in a particular bug, but the changes could be to anything--main bug fields, comments, tracking flags, dependencies, etc. | '''Important note''': this whole design relies upon the idea that ''knowing the ID of a changed bug'' is not a security risk. This should be reasonable, given that the only information that is conveyed is that some bug has changed. One could use this information to determine the frequency of changes to a particular bug over some time frame, and hence ''perhaps'' an increased interest in a particular bug, but the changes could be to anything--main bug fields, comments, tracking flags, dependencies, etc. | ||