Santiago Gala wrote:
>
> 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?
>
That's what I imagined yes.
> >
> > lastUpdate: timestamp of the last update
>
> This information comes from the updater thread (handled by the store)
>
If the store keeps a monitor thread running there's no need for a DiskCache
dameon functionality.
> >
> > 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.
>
We are on the same line of thinking except that I think an object interested in
a given URL should register to the URLManager. When the resource is refreshed,
the Resource notifies the manager which can take any appropriate action.
Thus the URLmanager acts both as a facade to the integrated syndication system
and as a mediator between resources and consumers, uncoupling the development
of these.
In the future, a generic ResourceManager interface may be defined, where the
URLManager may be the default implementation but you could also plug other
CMS system like Prowler, OpenCMS, Slide, etc...
In short, I'm -1 for any direct relations between the syndication stuff
(and the disk cache is definetly part of the syndication stuff in Jetspeed)
and the portlet display system. Every interaction should use mediator object
in order to create a loosely coupled system.
> >
> > 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.
>
See above. Componentization means we won't have a single RSS Portlet registry
but we may have a Portlet registry and a DataSources registry which would only
be used by a JetspeedSyndicationPortlet.
> >
> >
> > 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.
>
I don't know if it's a good idea that resources implementaion themselves know what
they should do, it creates a tight coupling between the resource and how it should be
used. Again, I think it's better to use a Manager component as a mediator (GO4 pattern)
for all the components of the syndication stuff.
--
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]
