> Raphael Luta wrote:
>
> 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 reminds me of the service concept we discussed some time ago.
Similarly to other services, we could define a CacheService interface
for which different implementations may exist.
For obtaining content from remote URLs my preferred implementation
would be a ProxyCacheService that just requests the URL from a proxy
that does the actual caching for a cluster of portal servers.
For obtaining the user PSML I'd prefer a SessionCacheService that holds
the PSML tree in the session.
Others might have other preferences and make different choices.
>
> 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)
I found this in the web at http://www.webdav.org/: "WebDAV stands for
'Web-based Distributed Authoring and Versioning'. It is a set of
extensions to the HTTP protocol which allows users to collaboratively
edit and manage files on remote web servers." Do you mean this one ?
> 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.
Sounds very reasonable. Basically, this means you have a proxy that does
caching for all your portal servers, right ? What do you mean by
coordinating access to resources ? If you have a proxy that does caching,
wouldn't it coordinate access to resources on the web ?
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
--
--------------------------------------------------------------
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]
