On Saturday 04 July 2009 02:24:13 Jonas Bengtsson wrote: > 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.
Yes, we need a separate, but related, data structure for events, see below. Events are important, it is worth putting the effort in, they will be visible through the system tray icon and probably on individual pages too (along with some per-page events such as detecting a more recent version of a page). > > 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. > IMHO a UserEvent is more like a UserAlert than a ClientEvent. We should have UserEvent inherit from UserAlert, and should have some class or method by which we can post a UserEvent, with a flag indicating whether to also register it as a (dismissable) UserAlert. Many existing UserAlert's can simply be changed to UserEvent's. However, some alerts are actually alerts whose content can change substantially, and these will need to have subsidiary events. I don't think you should necessarily implement events for every dynamic user-alert across the code, it would probably be more efficient if you just build the infrastructure, convert the alerts which are obviously events, and implement one or two proof of concept's. I can do the rest, later on. The obvious proof of concept is the download complete alert/event. Right now this is essentially an event, but it would be good to make the current alerts into events, and add a new alert which just says N downloads succeeded. This code is towards the end of QueueToadlet. Another possible proof of concept is the freenet-is-bootstrapping alert (in Announcer); there should be an end alert for that, something like "Freenet has successfully connected to 10 nodes, it should work now but may be slow for a while". -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 835 bytes Desc: This is a digitally signed message part. URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20090704/3e58efc4/attachment.pgp>
