[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [hudson-dev] Going to a event driven architecture?
|
On 3/7/12 10:30 AM, Henrik Lynggaard Hansen wrote:
2012/3/6 Winston Prakash<winston.prakash@xxxxxxxxx>:
That is why I think we need to think more in terms of events
invalidating caches or results rather than time.
I believe here you are not meaning the rendered HTML cache right? Because
that cache is in the container level which the model has no access to.
I am thinking of the "data model" which is passed to the jelly files
when rendering a page or widget.
In my own (in house) plugin, the jelly page accesses two data object
using ${it.getBuuildState} and {it.getEnvironmentState}, these two
objects are cached in my plugin (which is a singleton), and only
recalculated when RunListener fires an event.
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
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
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.
Having a Event Registry does makes sense, if the consumers of the events are
known like RSS
Why only of the consumers are known?,
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?
- Winston
Best regards
Henrik
