On Sat, 4 Jul 2009 12:46:06 +0100 Matthew Toseland <toad at amphibian.dyndns.org> wrote:
> 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". I have commited code that allows events to be registered with the UserAlertMangager. An event is a UserAlert that has a isEvent-function that returns true. At the moment there is both a isEventNotification and the new isEvent-function. These are similar and might be merged, or one of the should at least change name. The difference between an event and an alert is that only that last event of a certain type is displayed, even if several events of that type have been registered. The UserAlertManager uses a map from the class-name to the latest registed event. When an event is registered the current event is replaced with the new one and a message is sent to FCP-subscribers. This works well for the events created by the Announcer. The content of the alert on the alerts-page only depends on the last event registered, the information from all previous events can be discarded. A more complex type of event is the one that is registered when a ClientRequest completes. The UserAlert doesn't only contain information from the last event, instead it contains a summary of all previous registed events since the alert was last dismissed. To achieve this there are three maps in QueueToadlet, one for each request type. The identifier of a completed request is used as key and an event is used as value. When a request completes an event is created and added to the appropiate map. The event is then registered with the UserAlertManager. Each type of event uses it's corresponding map to create a summary of the completed requests. What is the most common type of event? If many events are similar to the ones of completed request it might make sense to optionally store registered events in the UserAlertManager. Please comment on the choice of architecture. I have tried several different architectures before arriving at this simple one. -------------- 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/20090719/90e620a8/attachment.pgp>
