PCWorld has published an article on the recent data grid JSR that I have submitted. As a follow-up to PCWorld's article, I would like to make a few comments to clarify a few things.
I don't quite understand what is meant by Red Hat's approach not being the best solution. Do people take issue with having a standard in the first place? Or is it the standards body used in this particular case (the JCP)? If it is the details of the standard itself, one should keep in mind that this has yet to be defined by an expert group!
It is unfortunate that the "others" mentioned in the article - who feel that Red Hat's approach is not the best - were not able to provide any details about their objections. I would love to hear these objections and make sure that the JSR addresses them.
The importance of a standard, to remove vendor lock-in, etc., is pretty well understood, so I won't go into too much detail here. But with that in mind, I find Pandey's comment regarding a "self-beneficial move" an odd one. A standard makes it easier for people to switch between products (which may explain why no one else may have stepped up to the plate to propose such a standard thus far). Proposing a standard makes it easier for end-users to move away from Infinispan. Yes, it may help with awareness of Infinispan, but it also means Red Hat, just like other data grid vendors, will need to work really hard to make sure their products are up to scratch. The only real beneficiary here is the end-user. In fact, I'd like to invite Terracotta to participate in this JSR, as participation can only make it stronger, more relevant and eventually even more useful to end-users.
With regards to JSR-107, I believe Pandey has misunderstood the intention in proposing a data grid JSR. I have proposed extending and building on top of JSR-107 - not throwing it away - and I have expressed this the JSR-107 expert group mailing list, of which Terracotta's Greg Luck is a member. In fact, without Pandey's actually seeing my data grid proposal blog post - PCWorld's article was written before I published details of the JSR submission, based on a high-level Red Hat press release - one has to wonder where such strong words come from! :-)
Cheers
Manik
I don't quite understand what is meant by Red Hat's approach not being the best solution. Do people take issue with having a standard in the first place? Or is it the standards body used in this particular case (the JCP)? If it is the details of the standard itself, one should keep in mind that this has yet to be defined by an expert group!
It is unfortunate that the "others" mentioned in the article - who feel that Red Hat's approach is not the best - were not able to provide any details about their objections. I would love to hear these objections and make sure that the JSR addresses them.
The importance of a standard, to remove vendor lock-in, etc., is pretty well understood, so I won't go into too much detail here. But with that in mind, I find Pandey's comment regarding a "self-beneficial move" an odd one. A standard makes it easier for people to switch between products (which may explain why no one else may have stepped up to the plate to propose such a standard thus far). Proposing a standard makes it easier for end-users to move away from Infinispan. Yes, it may help with awareness of Infinispan, but it also means Red Hat, just like other data grid vendors, will need to work really hard to make sure their products are up to scratch. The only real beneficiary here is the end-user. In fact, I'd like to invite Terracotta to participate in this JSR, as participation can only make it stronger, more relevant and eventually even more useful to end-users.
With regards to JSR-107, I believe Pandey has misunderstood the intention in proposing a data grid JSR. I have proposed extending and building on top of JSR-107 - not throwing it away - and I have expressed this the JSR-107 expert group mailing list, of which Terracotta's Greg Luck is a member. In fact, without Pandey's actually seeing my data grid proposal blog post - PCWorld's article was written before I published details of the JSR submission, based on a high-level Red Hat press release - one has to wonder where such strong words come from! :-)
Cheers
Manik
Looks like Pandey is feeling a bit defensive. And he probably should be. After all, why would anyone pay for Terracotta when Infinispan is available? He sees a free open-source solution coming, and he's scared his sales are going to fall off a cliff.
ReplyDelete@Jeff: Terracotta is also a free open-source solution (as well as a commercial paid solution for higher-end use cases) with an implementation of the "not a standard" JSR 107 so that part of your comment does not make much sense to me.
ReplyDeleteI wrote up some longer comments here:
http://tech.puredanger.com/2011/04/14/caching-jsr/
@Alex thanks for your comments.
ReplyDeleteAbout JSR-107, while this has been dormant for a while - and I criticized the fact here - there has been renewed interest among the EG and spec leads to drive this to completion in the near future. If you are interested in following it, I recommend joining the JSR-107 Google Group. So here's keeping fingers crossed. :-)
All the same though, as I pointed out, JSR-107 is not enough. It's a great start, but characteristics of distribution, JTA compatibility, etc. needs to be defined.
As to your comments on NoSQL vendors like Couch and Mongo, there is some overlap but in general I'm not entirely sure how useful a data grid JSR would be to them. I'd love to hear their thoughts though, and invite their participation.
Cheers
Manik
Hoping that the JCP reforms will help stop this from happening again.
ReplyDeleteFurther thoughts at:
http://londonjavacommunity.wordpress.com/2011/04/19/488/