Good points, some comments in line
On May 25, 2010, at 8:40 AM, Taylor Gautier wrote:
> 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
Yep, sort of. We want these kinds of people to mostly be using our products not
the toolkit.
It's more about framework developers who don't want to go too low level.
> 2) Framework developers that want low-level access to Terracotta features
Yes, this does exist because it is us, field people and gang like sergio
>
> 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.
>
> To 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".
I don't love the idea of naming it that way. There is still code in weblogic
called T3 because they can't change it.
> 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.
This is enticing but this is a painful path if we don't choose to implement the
whole interface in the way it's specified in the JDK.
> 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.
I'm on the fence as to whether to make this true in the toolkit or in the tools
built on the toolkit.
Exactly what you described below works but the value needs to be serialized if
it isn't a literal type.
That's a touch annoying in the first few seconds for sure. But what about
those who want to do custom serialization,
those who want to cluster queues and locks (i.e. things you don't want
serialized).
The question becomes:
- Does the toolkit make it's classes auto serialize things or...
- Do we build higher level products on top of the toolkit that does such things.
I could go either way or maybe have the toolkit have both varieties.
We could have ReferenceClusterMap and ValueClusterMap
>
> 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:
Can't hurt to look at other API's to learn what works and doesn't
>
> Audience 1: The end-user who wants clustering but doesn't want or know how to
> deal with classloading and identity issues: perfect match.
99 percent of these people should use the products we built on the toolkit over
the toolkit itself I think?
> 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.
This person is us internally.
>
> 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
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
