[jbosscache-dev] JBCACHE-471 - Handling JGroups MERGE

[Bela Ban]

In general, +1, as long as we tag such an interface as experimental. 
Let's add this topic to our agenda for WED's call

Manik Surtani wrote:
>
> On 20 Mar 2008, at 04:08, Brian Stansberry wrote:
>> Manik Surtani wrote:
>>> On 19 Mar 2008, at 19:26, Brian Stansberry wrote:
>>
>> <snip/>
>>
>>>>
>>>> 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?
>>
>> That certainly takes some of the pressure off the interface 
>> discussion. :-) As long as it's "preview" in the sense of "we might 
>> change this a lot in 3.x" and not in the sense of "these 2 impls we 
>> provide are not quite production ready."  If it's the latter, 
>> probably not worth doing.
>
> Agreed.  In terms of implementation, the 2 that I hope to provide at 
> first will be production ready - they're too simple _not_ to be.  So 
> the only really hard part that we face here is pinning down the 
> interface design to something that will be continually useful in the 
> future, for more complex merge handler implementations.  And as long 
> as we caveat the interface with a "prone to change in 3.x based on 
> user feedback", we'd set an expectation that anyone who writes their 
> own merge handler now *may* have to rewrite it in 3.x.  And in any 
> case any interface changes would likely add parameters, not remove 
> any, so such a "rewrite" would be trivial.  Like I said, I'm just keen 
> to "get it out there", and let people start playing with it.
>
> And as Bela mentioned, I'm happy to brainstorm over this on the next 
> conf call, but no harm in dumping thoughts and ideas on this mail list 
> until then.  :-)
>
> Cheers,
> -- 
> Manik Surtani
> Lead, JBoss Cache
> manik at jboss.org
>
>
>
>
>
>

-- 
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat