[hudson-dev] Going to a event driven architecture?

[Henrik Lynggaard Hansen <henrik@xxxxxxx>]

Hi

During the discussion on performance, one of the topics that has come
up frequently is How often do we need to refresh this information or
how long can we cache this result e.g. when talking about the ajax
results, rss feeds etc.

The more I think about it, the more I think we are going in the wrong
direction, because the right answer to questions like that is not a
amount of time, but rather he simple answer we need to refresh the
calculated information when the information or state changes e.g the
ajax build queue should change when the actual build queue changes.
That is why I think we need to think more in terms of events
invalidating caches or results rather than time.

I have used this approach in our status board plugin I mentioned on
the call. It performs a one time calculation of the data needed for
the web page, and only does a recalculation when a build changes state
by implementing RunListener.

There are only 2 things which isn't cached and that is the "Time
since" strings and the claim information because that information is
added after the build is completed and there isn't an event  to listen
for.

That brings me to my suggestion, I think there maybe should be a
Hudson component that provides a gateway to publishing  and
subscribing to events like below

In a subscriber

@Inject EventRegistry
events

events.registerListener(ClaimEvent.class, new ClaimListener());

in a publisher

@Inject EventRegistry
events.

EventQueue<ClaimEvent> claimEvents = events.registerEvent(ClaimEvent.class)

claimEvents.fireClaimAdded(new ClaimEvent(...))
claimEvents.fireClaimRemoved(new ClaimEvent(...))


Another approach would be to be Listerners as extentionPoints like RunListener.

I don't know which is the best approach my goal is just that people
start thinking in events, and it should be as easy as possible for
plugin developers to add new event types to the system, and not spend
their time managing lists of subscribers etc.

Best regards
Henrik