On Friday 27 February 2004 01:15, Berin Loritsch wrote: > Niclas Hedhman wrote: > THe biggest issue I had to overcome (and it did not > take me long to develop some guidelines to avoid it completely) is the > icky circular event logic.
Can be somewhat difficult. I know it is more common in GUI apps, since you often are both the consumer and producer of the same EventType (property modified for instance). What is your solution? Sticking the "original source" into the event? In my systems, it is less of an issue, as it is very rare that consumer and producer are linked in "both directions", but it happens, and I use two solutions; 1. The event that arrives back at the source doesn't trigger a new event, since the incoming event has "no effect", for instance, the event results in an value update, but a new event is only fired when the value has actually changed (and in some cases, I also use an "minimum change" for float values). 2. A ThreadLocal variable that are set prior to the fireEvent() and checked on event entries. A very efficient way to 'disable' incoming events. > :/ It all comes back to the problem at hand. Until you can prove it is > : really > a problem, it is merely a case of misunderstanding the system. Too rigid a > spec makes the software bloated and slow, while too loose a spec makes > things prone to breaking unexpectedly. Agree. > I am still out on my verdict which one is preferable to err towards. One > might argue that you are "safer" with the over designed system, but I > wonder if that is really the case. I have been too much in Jini-land, where things are very liquid. But once one get the hang of writing services that are more autonomous it becomes really neat. > I may have missed it. I am just saying that in many cases, you won't need > the availability requirement. Exactly, I am not saying that it is always required, just as initialize() is not always required. But, if an AvailabilityAware notion existed in AF, it would be possible to implement more interesting systems. But with such a contract in AF, it would be possible to implement all kinds of cool features in the container; hot (re)deploy, Jini, moving agents, self-healing systems, load balancing clusters... Without it, it is not really possible without very specific components :o( This is somewhat independent of EventDriven programming, but Availability can support the EventDriven pattern. Niclas B.t.w Nice seeing you active in Avalon :o) ! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
