Sebastian Werner <[EMAIL PROTECTED]> writes: > Am 18.05.2007 um 14:11 schrieb [EMAIL PROTECTED]: > >> Sebastian Werner <[EMAIL PROTECTED]> writes: >> >>> I don't like the solution to be integrated in qx.core.Target. I would >>> like it better to add specific events to a special event router which >>> then informs registered objects about any of these events. This is a >>> lot cleaner than exclude tables and a deep integration in >>> core.Target. The overhead of many events would be to dramatic. I can >>> imagine of something like a widget monitor which reacts on all >>> widgets relevant stuff and for example a IO monitor which monitors >>> all IO related things. >>> >>> What do you think? >> >> Hi Sebastian, >> >> That concept sounds fine. I'm not sure I follow where you'd add it, though, >> if not in Target. If one wants to monitor all, or some very large subset of >> events, where else could you put it that has access to the information? >> >> I expect that in the implementation I checked in last night, the overhead is >> quite small since it effects only events with listeners if the variant isn't >> enabled. I am concerned about the overhead when the variant _is_ enabled. > > Derrell, > > Each overhead even if really really little is to much in my opinion because > it also sits on time critical stuff.
That may be. Part of my testing was going to be to determine how much overhead there was in the simple "if" condition (with map look-up for exclusions). > The whole idea for the message bus is instead to use it only for not-so time > crititcal information. > > I would say, that a first step, before implementing something is, to get a > clear view of which currently existing events are interesting. I think a > whitelist is better than a blacklist in this case. A message bus listener > which reacts on all the possible events of different areas e.g. io, widgets, > focus, whatever is not quite often - if it exist at all. The problem with a whitelist is that one should be able to use a monitor to determine what events are being dispatched. In other words, we don't always know which events are interesting ahead of time. To set up the whitelist, you have to already know, so that pretty much defeats that particular purpose. It should be possible to get notified of *all* events (even if that incurs some overhead). If the overhead is significant, the monitoring should be enabled by a variant, so apps that don't require the monitoring can run at full speed. >> I'd definitely like to hear more about how you would implement the special >> event router. Sounds quite interesting! > > OK, lets continue our discussion on Monday. Great. Christian, I'd suggest not implementing anything based on what I checked in last night. I suspect it'll get reverted, and replaced by something completely different. Cheers, Derrell ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ qooxdoo-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
