Why Did Commons Cache Die (II)?

It has been a while since I've posted the first part of this discussion, and I would like to complete it now.

In the post itself, you can read interesting views and thoughts from my colleagues. My personal view is basically an aggregation of these thoughts.

In my opinion, a standard Caching API would only emerge and be adopted if the following conditions are satisfied: (a) the standardising organisation needs to be technology and vertical agnostic, and needs to include different stakeholders. Key players should be users and not vendors, and (b) the caching and grid markets need to further mature.

Point (a) is easy to explain and understand.

What I specifically mean in point (b) is that there are too many players in the market (as Jim mentions), none really dominates the market, and each of them provides different functionality and address a different set of use-cases.

In addition to that, there are still significant latency and throughput differences between the various products out there. As long as these differences can be used as differentiators it is harder to envision a unified API.

When the time is right (Nati hints for mid 2008…), and the market is more mature, we will start to see more demand for such API. In my opinion, there will always be differences between the various vendors, but these will be implemented on top of the standard. As an analogy, think of SQL and JDBC, as Nati noted, (or J2EE for that sake) there is a standard and a set of basic features defined, but each vendor implements much more than the standard as its basic offering. When defined, Cache API will be just the same. We will have specs which define simple Put/Get functionality, but all the sophisticated query capabilities and scalability models will make the difference.

For these reasons, I do not think that "vendor locking" (or unlocking) will be a driver for a standard Caching API.

Regardless of me being a GigaSpaces employee, I think that GigaSpaces is well positioned, in terms of its technology offering, for a standard Caching API. GigaSpaces is based on the Linda Tuple model (aka JavaSpaces from Sun), which allows GigaSpaces to expose its data set using different APIs (I like to call them views), in a simple way. GigaSpaces provides the underlying scalable middleware, which can be accessed using different APIs and technologies. When the Caching API becomes real, it will be fairly simple for GigaSpaces to implement the API on top of the space as it does with Map, JDBC, JMS, Remoting, C++, C#, and other APIs.

The answer to Mickey's question can be concluded from the above. My question is, how long will that stage last before Caching API standardisation kicks off?

-Guy