On Fri, 3 Jul 2009 20:15:01 +0100 Matthew Toseland <toad at amphibian.dyndns.org> wrote:
> An architectural issue: > Some user-alerts get updated frequently, is this a problem for the whole feed > subscriptions model? Do we want to send updated alerts to the FCP > subscribers? An example (not yet implemented) is that we will probably use a > single alert to tell the user that they have 5 new messages, rather than > showing an alert for each message; same with downloads. At the moment the architecture only works properly for alerts that are static. This includes alerts about new text messages, completed downloads, updated bookmarks and so forth. A FCP-message is only sent to subscribers when it is registered with the UserAlertManager, not when an alert is updated. > Really this suggests that maybe we want to separate events from alerts? > Alerts are a list of problems or notices that are valid _now_, events are > discrete moments in time? Perhaps an event is simply a new alert or a change > to an alert, but really we want the event to describe _what has changed_ > (file X downloaded), not the new status of the alert (6 files downloaded, > rather than 5). You are right. It makes sense to differentiate between events and alerts. My original idea was to have a class responsible only for the FCP clients subscribing on feeds. But by merging it with the UserAlertManager it required less modification to existing code. > Thoughts?? The biggest problem is that it is hard to detect when an event has occured. Both the alert page in FProxy and the atom feed file works with polling. When they call getText() or getHTML() they get the latest version of an alert. This approach won't work FCP subscribers. What is the best way to detect updates? Should the class responsible for FCP subscribers be a ClientEventListener? If an action is taken that updates an alert a new type of Event could be created. This would require modifications to all classes that take actions that cause events that are to be visible to FCP subscribers. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090704/6bfde2c5/attachment.pgp>
