On Monday 20 July 2009 16:21:05 Jonas Bengtsson wrote: > On Mon, 20 Jul 2009 13:57:56 +0100 > Matthew Toseland <[email protected]> wrote: > > > On Sunday 19 July 2009 03:01:15 Jonas Bengtsson wrote: > > > On Sat, 4 Jul 2009 12:46:06 +0100 > > > Matthew Toseland <[email protected]> wrote: > > > > > > > On Saturday 04 July 2009 02:24:13 Jonas Bengtsson wrote: > > > > > On Fri, 3 Jul 2009 20:15:01 +0100 > > > > > Matthew Toseland <[email protected]> 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. > > > > > Seems to make a lot of sense IMHO. For the most complex case we create an > > event, separately from the main UAM, and register it, resulting in its > > being sent to subscribers, but when we render the feed statically or on the > > homepage, we just pull the summary. > > > > I don't think many events are similar to the ClientRequest mechanism, a lot > > are essentially global. But it sounds like the ClientRequest-like events > > are handled adequately. > > > > One thing this doesn't give is a chronological event log - but maybe it's > > not desirable. > > Aren't the events registered in a chronological order? For > ClientRequests the requests that are finished first is registered > first. Wouldn't it be simple to add logging code to the > register-function? Exactly what do you mean with a chronological event > log?
A page with a chronological list of events, as they were when they were created, whether or not they've been dismissed?? > > There is also one extra complication that I haven't dealt with yet, > what it means for an event to be unregistered. An ordinary UserAlert > is added once and it may also be unregistered once. An event may be > registered several times, but only the latest event is display. If the > event is unregistered the next event registered will be displayed. For > the Announcer this means that if the user dismisses the latest > annoucement-event, tha next announcement-event registered will still be > displayed. There should be to different ways to unregister an event. > One would stop all future registered events of the type from > being displayed. The other would only removes the latest registered > event, future registed events are not stoped. Hmmm... in the complex case, we only display the summary, so we can dismiss the summary and make the events go away with it. In the simple case, an event is handled as an alert. You want to be able to silence the event generator permanently? You could do this on a per-event-generator basis by overriding onDismiss? > > A solution to this would be to remove the isEvent()-function and > create a subinterface UserEvent of UserAlert. The UserEvent-interface > could have the function: > boolean unregisterIndefinatly() > that returns true if no future registered events should be displayed if > the event is unregistered. The UserAlertManager could use a Set to keep > track of which events have been indefinatly unregistered. Is this a > good solution the the problem of what it means for an event to be > unregistered? I'm not convinced. You'd have to have a single object that represents the potential to create events, plus one object per actual events; unregisterIndefinitely could run on the former. But it may be better to just pass it on and keep the flag in the actual originator??? You'd have to do a load of refactoring of event generators either way...
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
