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

[Henrik Lynggaard Hansen <henrik@xxxxxxx>]

2012/3/8 Winston Prakash <winston.prakash@xxxxxxxxx>:
> On 3/7/12 10:30 AM, Henrik Lynggaard Hansen wrote:
>> For other semi static things like rss feeds, it could be that the even
>> triggered writing of a file on disk. This file would be served as
>> "static" with a short expires header. In a way caching the rendered
>> html, but on disk not in memory.
>
> Let us say RSS model ..
>
> - The model subscribe to various events and refresh itself
> - Model sends out Model Changed event
> - RssStaticWriter (just invented it) listens to RSS model change event,
> invokes Jelly rendered to render the HTML  and persist
> - When HTTP request comes for the RSS, we simply stream back the persisted
> HTML.
>
> Theoretically sounds good, we need to see how difficult to implement it

Yes that is the high level idea :-) although I would properly have add
a feature where you register the persisted file, so that we can do
nice URL to file location mapping. Because if we add that, we can also
write project specific and build specific files

Possibly even make the expires header customizable
>
> There are two improvement
>
> - We don't refresh the model when HTTP request comes for the RSS
> - We don't render the HTML from model when we get the request

Yes :-)

> IMO, the benefit of the second may not be as dramatic as the first one. But
> makes sense to experiment  and get a quantitative measure of the benefit.

That depends on the resource being persisted, if it is a graph being
drawn or something similar then the second one might be significant
too.

>> I am asking since the main consumers of events will most likely be 3.
>> party plugins which are not "known". or have I misunderstood you?
>
> See your point. How do the consumer (3rd party plugins) know about the
> event. Something like
>
> - The plugin that publishes the events documents the events?
> - Centralized UI to view the available events and their usage?

I would properly start with plain documentation to not complicate
matters. Speaking of centralized UI, perhaps a audit/log view of
events fired could be good but that is a value add

I will try to see if I can come up with something over the weekend

Best regards
Henrik