[EMAIL PROTECTED] escribió:
> Santiago Gala wrote:
> >
> > I'm using Observable for tests, but we can change this class by some
> > other
> > interface if needed after the concept is tested. I will look for similar
> > patterns in Turbine/Avalon code.
> >
>
> I thought that the Observer pattern was deprecated in Java and a
> Listener/Event model was the recommended way of doing things now.
>
I meant something like this. The idea is that the resources (see below) would
have a mean to notify users of state changes.
>
> In any case, I think there are several issues with the disk cache system
> right now, the main one being that it's over-used throughout the current
> jetspeed code, as an interface for accessing remote documents, config files,
> etc... We have to stop this !
>
> We should :
> 1- Define what is the *real* purpose of the DiskCache
> IMO, the cache should not try to be as intelligent as it is now
The purpose of the cache is to serialize/cache access to (external)resources.
It was designed for OCS feeds and RSS channels, as well as DTDs.
The problem is that unless we have a transparent access mechanism, the cache
will have to take whatever URL it is given. For instance, if you use the
FeedManager to process a "local" feed, and the FeedManager asks for a cache
entry (as it should), you will end up having "local" remote urls. Testing in
the user code for local urls is definitely BAD.
So, I would add the ability to distinguish cacheable vs noncacheable resources
to this.
In my summary:
1- To centralise url resource access. In the configuration, there will be means
to distinguish which resources will be cached and which ones will be returned
transparently.
2- To serialise access to some (configurable) resources, caching them, and
taking care of refresh
>
>
> 2- Define what kind of repository access we need in Jetspeed
> I can see at least 2:
> - remote syndicated document repository
> - configuration file repository
> others ?
>
What do you mean by "configuration file repository"? Are "local syndicated
document repository" files included here?
>
> 3- Define facade class/interface for accessing these repositories
> * syndicated document = URLManager service
> * configuration files = Persistence service ?
>
I think the facade should be the same, as both kinds of resources are URLs from
the user(developer) point of view.
I think we could have two different services:
a URL Manager Service that would take care of point 1 above, and configure
factories of "Resources" according to configuration. There could be at least
three such factories:
- transparent (local) url resources
- cached resources
- writable (i.e. persistable) resources
a Disk Cache Service, with specialized "CacheableResource" interface.
a Persistence Service, with specialized "WritableResource" interface.
>
> 4- Implement these services so that they (don't) use the DiskCache as
> they see fit
>
As I said before, I would not burden the developer with the effort to
distinguish which resources are of each kind. There should be a configurable
service that takes care of that. When Jetspeed is deployed, the administrator
will tell which resources are local, which are persistent, which are cacheable.
>
> 5- Replace all the other references to the DiskCache in other parts of the
> code to references to the appropriate Facade classes.
Completely agreed
>
>
> 6- Have a party :)
In Santa Clara? :) I will take care of the first round of beers. (Please remind
me then/there that I promised. I am a cheapstake)
I have parts of the code, but I felt it was not right. Now I see why. We need
to agree about the basic Resource interface, and the Resource dispatcher. Once
we have this code right, all code using resources should do a call like:
Resource res = URLManager.getResource( url ); // maybe ResourceManager
and process this resource (get a Reader, get an Object, get a Writer (after
casting to WritableResource), add a Listener, get a Stream, get
CharacterEncoding, ...) after. The configured URLManager will return the
appropriate kind of resource according to configuration.
>
>
> --
> Raphaël Luta - [EMAIL PROTECTED]
> Vivendi Universal Networks - Services Manager / Paris
>
> --
> --------------------------------------------------------------
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Search: <http://www.mail-archive.com/[email protected]/>
> List Help?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
