[EMAIL PROTECTED] escribió:
> Raphael Luta wrote:
>
> > [EMAIL PROTECTED] wrote:
> > >
> > > Raphael Luta wrote:
> > >
> > > > 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
> > > >
> > > > 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 ?
> > > >
> > > > 3- Define facade class/interface for accessing these repositories
> > > > * syndicated document = URLManager service
> > > > * configuration files = Persistence service ?
> > >
> > > These interfaces need to be extensions to the portlet API.
> > >
> >
> > I'm not sure of what you mean here. I assume you say that the
> > service should be compatible with the service-access API which
> > is (should be) part of the Portlet API. Correct ?
>
> The Portlet API needs to include interfaces for
> - Persistence
> - Access to User Info
> - Access to URLs
> - Access to Location Info
> - etc
>
> so that portlets written using the Portlet API can ultimately run on
> all portal implementations that provide a portlet engine that implements
> the Portlet API.
>
I think that all the URL related apis should use compatible (i.e.
subinterfaces) specification, so that a portal developer can ask for a URL
content withoout having to test if the url is remote, if it is writable, etc.
We have plenty of examples of what happens when the user code is responsible
of these tests. The system gets plenty of difficult bugs. So I think that all
the url access should be done using the same API.
>
> I hadn't thought of an interface to get URL content via a cache as a part
> of the Portlet API before, but its seems useful. It would allow a portlet
> to take advantage of a portal's caching mechanism without becoming
> dependent on a particular portal implementation.
>
> Best regards,
>
> Thomas
>
> Thomas Schaeck
> IBM Pervasive Computing Division
> Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED]
> Address: IBM Deutschland Entwicklung GmbH,
> Schoenaicher Str. 220, 71032 Boeblingen, Germany
>
> --
> --------------------------------------------------------------
> 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]
