Santiago Gala wrote:
>
> Currently we are using the isLocal() call in DiskCacheUtils. It looks for virtual
> URIs (no protocol) and localhost URIs as local, and all else remote.
>
> The current strategy is that local things are not cached, but delivered directly
> through URLConnections, while remote entries are cached.
>
> My proposal is that we have a list of regexps in the configuration specifying non
> cacheable entries:
>
> - A given server is non cacheable.
> - Part of the space of a given server is non cacheable
> - All URIs with a given suffix are not cacheable
> - all .*/servlet/.* entries are not cacheable ...
>
> The internal marking will be done by having something like:
>
> ResourceStoreEntry is an interface, abstract representation of an external resource.
> It would support downcasting for common variants (in example isWritable() and
> getWritableResource() that would down cast it to a WritableResourceStoreEntry).
>
> HttpResourceStoreEntry is a concrete, non-cacheable representation for HTTP URIs. A
> subclass of this could implement the Writable interface (see down) through simple
> HTTP PUT.
>
> FileResourceStoreEntry is a concrete, non-cacheable representation for file URIs. It
> could implement the WritableResourceStoreEntry interface
>
> CacheableResourceStoreEntry is an abstract representation of a cacheable resource
> with semantics for expiration or refresh.
>
> WritableResourceStoreEntry is an abstract representation of a writable resource with
> a getWriter methods to handle character writing (beware i18n, all writing is better
> done as characters that as bytes).
>
> DAVWritableResourceStoreEntry is a concrete representation of a DAV resource that can
> be written using DAV
> ...
>
> This has not been implemented yet, but I think we should go into something similar to
> that for having the cache as something more abstract. All external resources in
> Jetspeed should use this abstraction, to enable other features like caching, maybe
> authentication or other similar checks, and to tackle with the problem of parallel
> download of the same resource by different threads. Now, all external resources use
> the DiskCacheEntry abstraction, but it is not as powerful and modular as the things
> we are envisioning for Jetspeed.
>
What you need in a content management API which exposes some document
manipulation functions (restrieve/store/update/properties/...) and
implement different data source providers such as a syndication system.
Such a system may have a notification feature for informing its clients
that the data source has changed in the repository.
In believe, most of this is already done by Prowler. For complex needs
I think it's way easier to port the syndication to prowler and write a
ProwlerPortlet than rewrite a complete Content Management system.
--
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]
