On 20 Aug 2008, at 17:26, Brian Stansberry wrote:
Manik Surtani wrote:
> On 20 Aug 2008, at 04:28, Bela Ban wrote:
>> I added an item to our agenda for Brno, so we can discuss it there
>> (on FRI, but this will get shifted around anyway)
> Hmm, re: 3.x, I think we need to move a bit quicker than that. I'm
> holding back 3.0.Beta1 until we decide on this approach, since it
> will affect whether:
> 1. I revert to JBC 2.x interfaces
> 2. move 3.x interfaces to a new package
> 3. stick with new 3.x interfaces and rely on an adapter package.
>
> Thoughts? Anyone want to take a vote on this? :-)
Thoughts, not vote.
#2 I've gotta figure having 2 interfaces that are mostly equivalent
would have to cause problems.
#3: AIUI, that means creating a jarjar'd 3.x and an adapter jar that
exposes the 2.x API. Pro: end user apps have a stable API between
minor AS releases. Con: Hibernate and/or EJB3 integration is likely
stuck using 2.x APIs/the adapter, unless those projects are willing
to support and integration module that uses the jarjar'd 3.x
packages. TBD, after CR2 is out, since CR2 is near at hand and is my
focus.
#1, I don't know how much that screws you up.
#1 seems like the cleanest/easiest thing as far as the AS and other
API consumers are concerned, even if it does pollute JBC API. I plan
to spend a few cycles today revisiting these and seeing what can be
done to maintain compat. For the most part (Cache, Fqn, CacheFactory)
this should be ok, just would mean having a lot of deprecated methods
around, but for the Eviction and Region interfaces it could be
tricky. Could mean some sort of internal adapter.
Cheers,
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org