Alex,
if you're referring to the Tim-Pipes approach when talking about
decoration, I agree with you: I think it was good for implementing
"serializing" pipe, but it doesn't suit the more generic Toolkit
needs.
On Wed, May 26, 2010 at 8:28 AM, Alex Snaps <asn...@terracottatech.com> wrote:
> Don't mean to hi-jack this thread, but I wanted to continue on custom
> Serialization mechanism to go beyond Java Serialization capabilities,
> that we discussed in this meeting:
> I didn't like the decorated data structure approach so much, for the
> same reasons as Chris mentioned.
> Thinking slightly more about it, I'd much rather like some JCE kinda
> mechanism, where one could register Serialization mechanism
> cluster-wide. When data get serialized it would also be signed so that
> the proper strategy to deserialize the stream can be automatically
> selected.
> Now that raised the question about the default mechanism to use and
> possibilities to override it depending on the data structure's
> instance or even usage.
> So I guess instance-wise, a constructor argument could register the
> strategy with the mechanism and with the global registry (unique
> identifier).
> If there is a requirement for usage-based strategy (different
> strategies in the same instance), we could fall back to decorating
> e.g. the Map, so that all entries added through that decorated
> instance would use another serialization mechanism... Now, would we
> need to track (instance- or, for maps, key-based) what strategy to use
> overtime?
> This all of course doesn't answer the question when this Serialization
> is to happen.
> Something in that direction could then also probably ease version
> transitions on stored Object.
>
> Just wanted to get this out of my head and shared, even though I think
> this is less relevant now, given how I understood the discussion
> ended.
> Alex
>
> On Tue, May 25, 2010 at 7:45 PM, Steve Harris <st...@terracottatech.com>
> wrote:
>> 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-...@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
>>
>>
>
>
>
> --
> Alex Snaps <alex.sn...@gmail.com>
> Senior Software Engineer - Terracotta
> http://twitter.com/alexsnaps
> http://www.linkedin.com/in/alexsnaps
> _______________________________________________
> tc-dev mailing list
> tc-dev@lists.terracotta.org
> http://lists.terracotta.org/mailman/listinfo/tc-dev
>
--
Sergio Bossa
http://www.linkedin.com/in/sergiob
_______________________________________________
tc-dev mailing list
tc-dev@lists.terracotta.org
http://lists.terracotta.org/mailman/listinfo/tc-dev
