I'm very happy to hear that you are interested. There is talk of a separate
cache project in the commons. If it is acceptable when I get it a little
more flexible, then it should go wherever it makes most sense. You tell me.
I thought the jgl libraries were some form of lgpl. At least in 96 they
were. If not I'll just rewrite whatever we are using.
http://www.objectspace.com/products/voyager/libraries.asp
I'm probably not using javaclass.jar. I need to clean up. It is not
necessary. The sun jars should probably not be distributed with this
application.
It shouldn't be a problem to put a turbine service wrapper around it. I'll
look into it.
A few things, if you are going to be testing it. The lateral distribution
is not optimized, to put it mildly. I only use it for invalidation for non
remotely configured caches. If necessary some sort of multicasting or tcp
socket server with success messages and retries could be added fairly
easily.
I'm talking about making it into a pluggable framework, but there are some
issues. Mainly, you can't control the behavior of elements by element
properties if you don't know what will be there. The plugins would have to
be typed neatly. If multiple plugins were provided, the majority of the
control would move to the region -- specifying what types of lateral
distribution, remote stores, etc. to use. The element attributes would then
be behavior type description: whether the element is eligible for any type
of lateral distribution or disk spooling or remote storage and retrieval. .
. .
There are basically 4 types of caches, memory, disk, distributed (1 way ),
and remote ( distributed 2 way ). Each of these could be a plugin and there
could be as many of each as the programmer wanted. The last two could
function similarly, the search access sequence could just exclude those that
do no searching and the implementations could just return null for those
methods.
The necessary conjunction between memory and disk is difficult to break.
Perhaps the disk cache could be treated as a runoff cache. There could be
stores, replicators, and runoffs.
Talk to you later.
Aaron
-----Original Message-----
From: Jason van Zyl [mailto:[EMAIL PROTECTED]]
Sent: Saturday, June 09, 2001 1:53 AM
To: [EMAIL PROTECTED]
Subject: Re: working version of an attribute driven cache
On 6/8/01 4:00 PM, "Aaron Smuts" <[EMAIL PROTECTED]> wrote:
>> Aaron,
>> Have you talked to the guys in the commons project about the stuff they
are
>> doing on caching?
>> James
>
>
> Not really. They were talking about a cache project in the commons and
> there was interest in the turbine group, so I'll send this to both places.
> Sorry about the spam, but the topic overlaps.
>
> I updated the zip and added some java-docs with uml.
> http://www.psoft.net/~asmuts/
>
> Since a few people emailed me directly, I'll give a rough overview of the
> caching system.
>
That is quite the beast :-) Looks incredibly comprehensive!
I see in the lib/ you have several jars. Are all of these used,
and if so what are the licenses that apply to each of these
JARs? I don't know the fine details of the Sun JARs and I
have no idea what the license is with JGL. JavaClass, or what
is now BCEL is fine, and so are the rest.
This would be a fabulous addition, were you thinking of
implementing this as a Turbine service? This would be fantastic
timing because I have separated out the service framework from
Turbine. It's almost fully decoupled which means if you add your
service to Turbine it will soon be available to a much wider
audience, I hope :-)
I would definitely like to play with this next week sometime
so I can give you some useful feedback.
--
jvz.
http://tambora.zenplex.org
http://jakarta.apache.org/turbine
http://jakarta.apache.org/velocity
http://jakarta.apache.org/alexandria
http://jakarta.apache.org/commons
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
