On Thursday 26 February 2004 23:18, Berin Loritsch wrote: > Niclas Hedhman wrote: > > This is the driving pattern for the OSGi framework. > > > > In principal I like this a lot, however, there is a "downside" (and a big > > one that I know someone like Stephen faint over); > > > > You don't know if the component can fulfill its 'purpose', since it may > > not be fed required information from "dependent" components, and > > especially not prior to the components are instantiated. > > In some respects, you can code the event classes to enforce or require the > proper information. It *does* make the stack trace messier, so debugging > these babies is more difficult. It is always best to keep the types of > events and contracts with the events as simple as possible. I've been > doing this for about six months now.
Debugging; :o) Once the Event infrastructure in place, the intimidating stack traces is less so, just look at the first couple of entries, and ignore the rest. (I have been in this boat since 96/97). My point; Stephen is very much of the opinion that the container should validate that the deployment requirements are fulfilled, so called rigid. The EventDriven architecture is very much the opposite, and allow you to plug in stuff later, even to fulfill dependencies of other components that have been "starved". > I highly recommend you take a look at GUIApps' EventBus. It is very > simple, and not a lot to it. You can subscribe for a particular type of > event, as well as add filters to more fully refine what events you want to > be notified of. URL? > Not to mention you can run into issues of double > notification if you add a listener twice (once in two different locations). > KISS. Double notification is unresolved at a semantic level. IMVHO, if I do double registration I should get double notification, as well as have to do double de-registration. But this is not the place for this discussion. > > In both case, I think that the primary concern for us would be the > > "Availability Contract", which somehow communicate with the component > > when other components are available or not. Because once that is defined > > in framework, both the above patterns, and re-loadable traditional AF4 > > components, can be implemented in the container. > > You'd be surprised with this "requirement". Unless you put your entire > interface on the hub, you only need to notify other components when certain > events happen. For example, when I save changes to a type of information, > I would send an Update[INFO]Event on the bus, and any component already > loaded that needs to know if that type of info is updated will recheck the > values. It's pretty handy in that respect. If you send an event that > requires something else created and ready for you, then you will run into > some problems if things are not started in order. Its easier to use a > direct method in that case. I think you missed my argument. If we allow services to come and go asynchronously, we should provide a mechanism for the component to know that a service is/becomes or is not/"no longer" available. This is somewhat orthogonal with the EventBus discussion. Components that are "AvailabilityAware" can have multiple strategies in place to fulfill the service, depending on available services. Having spontaneous events every now and then doesn't help for this. Cheers Niclas --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
