This is quite interesting. I think there are two main goals (audiences) here,
as Steve pointed out:
1) Devs that want to leverage the power of a clustering solution
2) Framework developers that want low-level access to Terracotta features
I am actually a bit surprised at the direction taken with the current Toolkit.
When I first heard about it, I assumed that it would simply allow developers to
use many of the more common Terracotta features without the burden of
instrumentation, classloading issues, and in *particular* identity issues. In
other words, audience #1.
T o put it another way I assumed it was going to address the same issues for
developers needing "raw" tools like clustered maps and locks and such, that the
current express products do for developers using a framework such as Ehcache or
Quartz.
This led me to believe that you would have a very similar looking API and
behavior as Hazelcast.
However, if I understand Steve properly, the target audience is actually #2.
(Why?)
Personally, I think targeting the first set of users is much more useful, and
gives much more bang for the buck (for both sets, actually), which results in
the following answers to the questions posed:
1) the interface should be named "Terracotta". Simplest possible answer to all
questions. It's easy to remember. It's specific. It's not trying to overstep
it's bounds and be "the one clustering provider to rule them all".
2) the class instances provided should map to the interfaces already present in
the JDK where-ever possible, meaning BlockingQueue, j.u.c.ReadLock etc. Chris
Dennis already alluded to this I believe and I agree with him.
3) usage of literals and end-user classes should be dead simple and there
should be no identity issues. That means require SERIALIZABLE for user classes.
Java developers have had to deal with Serializable for many many years - it's
not a big deal. It's also a consistent answer for anyone using an Express
Terracotta product. No identity issues, no magic, just Serializable. If you
want identity, (and/or need speed and efficiency, as Sergio pointed out) the
custom Terracotta product already solves that problem.
So, I would suggest you look to Hazelcast for API inspiration. It is clean and
simple to use, and dead simple to understand. So, how well does this help the
target audiences:
Audience 1: The end-user who wants clustering but doesn't want or know how to
deal with classloading and identity issues: perfect match.
Audience 2: The framework developers: gets what he wants, but maybe not
identity. How many framework developers are willing/able/ready to deal with
identity instead of just getting some simple to use maps, locks, and cluster
membership events? This person really isn't that much different from #1 and
will definitely derive benefit from this product.
I might add a third class of "framework developer" - the one looking for
identity, but not classloading/bootjar issues. My question to you is - does
that audience really exist?
In other words, personally, I think if you can just make the following work
using *only* javac MyClass.java, start a server, and java MyClass, I think
you've solved a *huge* problem (actually, a bunch of them - no bootjar
classloader issues, all jvms should be compatible, easy for a dev to start
using right away):
MyClass.java:
import java.util.concurrent.BlockingQueue;
import org.terracotta.express.Terracotta;
public class MyClass {
public static void main(String[] args) {
BlockingQueue<MyClass> queue = Terracotta.getBlockingQueue("myqueue");
queue.offer(myClass);
myClass = queue.take();
}
}
----- Original Message -----
From: "Geert Bevin" <gbe...@terracottatech.com>
To: tc-dev@lists.terracotta.org
Sent: Thursday, May 20, 2010 10:20:29 AM GMT -04:30 Caracas
Subject: Re: [tc-dev] Toolkit and custom types for app devs
It's still harder than it should be, but maybe we're misunderstanding
each-other here, the whole discussion topic is geared towards application
developers, not framework developers. I'm working on the framework dev part :-)
On 20 May 2010, at 16:47, Steve Harris wrote:
> k, I want to make a simple sample of how to add instrumented classes to a
> sample framework I want to build but I
> was under the impression that it was hard.
>
> On May 20, 2010, at 7:44 AM, Geert Bevin wrote:
>
>> For those people there's not a real problem, they're on the right side of
>> the fence, they don't have to go through the StandaloneClusteringProvider.
>
--
Geert Bevin
Terracotta - http://www.terracotta.org
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
