Raphael Luta wrote:
> ingo schuster wrote:
> >
> > >
> > >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.
> >
>
> I think PSML constructs should be cached using the global cache service of
> Turbine.
>
That is a memory cache. The problem is that the PSML should be fetched/parsed
atomically, and then stored in a memory cache such as the Turbine one, to avoid race
conditions if we use frames. This is true of most external resources, that should be
fetched atomically and then cached until they expire.
With regards to the retrieval of external resources (basically URLs) Jetspeed needs
an API that respect several requirements:
- No resource will be fetched in parallel by more than one thread. One thread will
fetch it and the others will wait until completion.
- No resource will be fetched again until it expires.
- A writable resource will expire as soon as it is written.
- Calls to check availability, get a Reader and get a Writer on the resource.
GetObject for non character stream objects.
- I notice now that we need a hook for Fetching, depending on the type of object
(e.g. parsing/unmarshalling XML is included in the process)
This is very important for external URL (I remember when I fixed the fact that
Netscape DTD was being fetched in parallel from the web a few hundreds of times on
Jetspeed Initialization), but having a uniform Resource Access API in also important
to be able to abstract use of different mechanisms/setups in Jetspeed.
For example, a File based implementation, a HTTP based implementation (with or
withour webDAV) and a DB implementation are three common setups that we need to
handle. In the case of generic Objects, other marshalling/unmarshalling
implementations can be devised (for example the unmarshalling of user PSML).
We are currently considering webDAV for our access to the Resource server in our
first trial implementation, having one machine that will get the resources and handle
caching, expiration and locking of writes, while a farm of Jetspeed servers will have
configured webDAV access to these machine and maybe local caching of some external
resources. Still, it will use the (missnamed)JetspeedDiskCacheEntry to coordinate
access to the resources.
The advantage of using Turbine Services for that is that I can start writing (and
commiting) a ExternalResourceService without breaking any code as long as we don't
use it, test it in my private setup, and change current implementation atomically
once it is tested.
>
> --
> 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]
