Raphael Luta wrote:
> "Brekke, Jeff" wrote:
> >
> > > There's only 1 package to implement as a service before we can remove
> > > the JetspeedServlet: the daemon stuff.
> >
> > I've been looking into this. There was talk of converting these to turbine
> > scheduled jobs and using the turbine scheduler. This is great, but will
> > require a database backend to hold the scheduled jobs, which in turn means
> > Jetspeed could not run without a database. John Thorhauer has created a
> > turbine scheduler that initializes from a properties file. We could use his
> > scheduler and implement it in Jetspeed or I was thinking of attempting to
> > merge this with the Turbine scheduler ( if possible ) and contrib back into
> > Turbine.
> >
> > Converting the daemon implementations into scheduled jobs seems
> > straightforward. Any comments? Am I missing something?
> >
>
> +1 for using scheduled jobs.
>
> I think it would be best to leverage the URLManager service in the process.
> If we define an extended URLInfo record, by adding the fields:
>
> updateFrequency: the number of seconds between updates for this URL
This should be the info coming from the OCS file (if any) or the Expires: HTTP
header (if > 0) or a default value if there is no other info. Is it good?
>
> lastUpdate: timestamp of the last update
This information comes from the updater thread (handled by the store)
>
> urlType: (FEED|CONTENT|...)
I'm not sure about that one. There are other types of URLs, like DTDs, and other
potentially appearing (may be PSML, stylesheets/skins, ...) that could be handled
by the same mechanism. I was thinking that any object that is interested in a
given URL registers with the Resource/CacheableResource (so it is called in my
current code) associated to this URL as a java.util.Observer. Whenever the URL
expires, or is refreshed, or changes state in any way, the manager will notify the
registered objects.
As the cache URLs are asked by other objects during initialization, they would
re-register at boot every time, so this information would not be needed.
>
> source: Vector of URL of the feed(s) in which this URL is described
Again, this is complex to maintain. I would prefer to use the Registry for RSS
Portlets, and have objects wishing to know about updates of a URL to register as
Observers.
>
>
> We can write a URLManagerScheduledJob (executed at frequency set in JR.p) to
> schedule a DiskCacheUpdateJob on any entry whithout a pending
> DiskCacheUpdateJob in the schedule list to refresh the content of this URL
> at lastUpdate+updateFrequency and update the status and lastUpdate records
> in the corresponding URLInfo.
>
> If the URL updated is modified and the urlType is FEED, execute a
> FeedUpdateJob which would unregister/register all the entries in the
> URLManager whose source contains the feed URL.
>
> This has many advantages over the current system but will require the
> URLManager URL records to be stored in a DB for rapidity of access.
>
> Comments ?
>
See above. I'm interested in the Scheduler mechanism. Currently, I'm implementing
Resources as "implements Runnable", so that they can be used (casted) as
parameters for their own update tasks. I will look if it would be simple to change
this so that they encapsulate a Turbine Scheduler job, instead.
>
> --
> Rapha�l Luta - [EMAIL PROTECTED]
>
> --
> --------------------------------------------------------------
> Please read the FAQ! <http://java.apache.org/faq/>
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
Problems?: [EMAIL PROTECTED]
