On Mon, 20 Jul 2009 13:57:56 +0100 Matthew Toseland <t...@amphibian.dyndns.org> wrote:
> On Sunday 19 July 2009 03:01:15 Jonas Bengtsson wrote: > > On Sat, 4 Jul 2009 12:46:06 +0100 > > Matthew Toseland <t...@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 <t...@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. > > > 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? 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. 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?
signature.asc
Description: PGP signature
_______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
