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(a)jboss.org
--
Bela Ban
Lead JGroups / Clustering Team
JBoss - a division of Red Hat