At 02:16 2000-11-10, you wrote:
>ingo schuster wrote:
>
> > At 15:04 2000-11-06 -0800, sbelt wrote:
> > >Do you (or anyone) know how to override the cacheing mechanism? I have
> > >modified the FileServerPortlet so that it will pass the turbine
> > >userid/password to the target URL (using post method). I am trying to
> > >retrieve personal task-list information in the portlet. For some reason, I
> > >cannot get around the cache so that I get the first user's list on all
> > >subsequent instances.
> > >
> > >Any help/direction is appreciated.
> >
>
> >
> > This is an important concern! Ideally, there would be a way to mark certain
> > data sources as uncachable. A problem that we found lately:
> > The users' configuration files (<user>.psml) get cached as well - not if
> > they are local, however we are thinking of storing them remotely in a ldap
> > directory (and still access them through the http request). If now a user
> > can customize his/her portal page, the configuration file changes, but the
> > cache still returns the old version!
> > I never actually understood, why a JetspedDiskCacheEntry has a minimum
> > expiration time, but if we stick to this, we should provide a way to
> > invalidate a DiskCacheEntry (e.g. to be used by the
> UserProfiler/Customizer).
> >
> > I therefore propose to add following method to the DiskCacheEntry
> interface:
> >
> > public void invalidate();
> >
> > The implementation for the JetspeedDiskCacheEntry would be:
> >
> > public void invalidate() {
> > expires = 0;
> > }
> >
>
>I don't like that the user of a resource handles expiration of the
>resource. This
>should be done by the resource itself or by the administrator of the site.
>
>It would be better to have a mechanism to mark that some URL are what we
>now call
>local (later we will call it dynamic or non-cacheable). The current
>implementation does this only for URLs in the localhost. It should do this
>for a
>set of URL prefixes or sufixes, that you can set in the configuration.
>
>In this way, users of the Cache should not manage behaviour of the
>entries, but
>the administrator will mark at deployment "uncacheable" resource extensions,
>sites or parts of the space of a server (/cgi-bin, /servlet, etc.)
This might be ok for most cases, but I think that's not optimal for psml files:
A user's psml file is needed for every request, i.e. it would be
advantageous to cache it.The psml file will change only rarely, however if
that's the case, we can't use the cached version any more.
You see, the problem is that a psml file is not either cacheable or
uncachable, instead it can be cached as long as the customizer doesn't
update it - only then it has to be reloaded.
ingo.
> >
> > --
> > --------------------------------------------------------------
> > Please read the FAQ! <http://java.apache.org/faq/>
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Archives and Other: <http://java.apache.org/main/mail.html>
> > Problems?: [EMAIL PROTECTED]
>
>
>
>--
>--------------------------------------------------------------
>Please read the FAQ! <http://java.apache.org/faq/>
>To subscribe: [EMAIL PROTECTED]
>To unsubscribe: [EMAIL PROTECTED]
>Archives and Other: <http://java.apache.org/main/mail.html>
>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]
