Re: [jbosscache-dev] JBCACHE-471 - Handling JGroups MERGE
On 19 Mar 2008, at 19:26, Brian Stansberry wrote:
Manik Surtani wrote:
> On 19 Mar 2008, at 17:26, Brian Stansberry wrote:
>> Bela Ban wrote:
>>
>> <snip/>
>>
>>> I don't think we have thought hard enough about all use cases we
>>> might implement, or at least consider for the design of the
>>> interface. Maybe we need to brainstorm about this at our next
>>> clustering conf call ?
>>
>> Where is this on our priority list? Is this something we are going
>> to actually do over the next 3-4 months? Or are we discussing
>> something that's not going to happen for a long time?
> I'm thinking if we can come up with a valid interface quick enough
> (over the next week or two) I'd put it in 2.2.0 along with the
> "easy" implementations (evict, shutdown). The more interesting
> implementations of MergeHandlers can (a) come later, or (b) be
> implemented by the client if they are in a rush for it.
> If we can't come up with a satisfactory interface in the next 2
> weeks I'll defer this for 3.x.
OK, I'll start thinking more about this then. I've been just vaguely
following this thread until my name started popping up.
What's your gut feel on whether this will happen for 2.2?
I think it's possible if that's where we set our sights. At the end
of the day, we'd include an interface and an adapter with no-op
methods, and if people stick to using the adapter, the interface in
question can later be enhanced for 3.x if need be with more
sophisticated overloaded callbacks, to create more sophisticated
handlers.
In terms of my preference, I'd *like* to get it out for 2.2 to give
the community more time to play with it, write handlers, etc., and
help shape a more formal interface in 3.x. Perhaps it could be marked
as a "preview" feature, prone to change/enhancements in 3.x?
In any case, I only see us writing the 2 simplest handlers in the
first go, with more complex, intelligent merging to come later.
Cheers
--
Manik Surtani
Lead, JBoss Cache
manik(a)jboss.org