On 6/9/01 11:35 AM, "Aaron Smuts" <[EMAIL PROTECTED]> wrote:
> 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.
It makes most sense to put the base package in the commons as your
caching system could be used in a wide variety of systems. Like you
say, it would be easy to make turbine service wrapper around
your caching system.
> 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 don't know if it's a problem, I just wanted to make sure there
wasn't any GPL code in there.
> 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.
Cool, you might want to wait a couple of days. The new refactored
services code will be landing in the repository soon.
> 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 won't have time to play with it until next week. But if you are
going to place it in the commons you will eventually need an extensive
set of unit tests. I can help you with that if you like.
See what the response is like in the commons, if no one bites than
we'll figure something out. I'm sure there will be interest in
the commons.
> 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]
--
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]
