+1 .. let's bite the bullet now rather than later.
On Thu, Sep 20, 2012 at 2:49 PM, Jonathan Hsieh <[email protected]> wrote: > I don't know the finer details of the implementation -- does this proposed > breakage break coprocessors (requires recode, or requies recompile) or is > this change just the wire level? Sounds like things would need to be > recoded. > > Since Coprocs are relatively new and evolving, I lean towards biting the > bullet and breaking compat at 0.96. The longer we wait, the more CP > clients out there we break, and we'd need another singularity. There are > folks building platforms on top of hbase using coprocessors -- the longer > we wait the harder it will be to make the change. > > Jon. > > On Thu, Sep 20, 2012 at 12:08 PM, Andrew Purtell <[email protected]>wrote: > >> On Thu, Sep 20, 2012 at 12:02 PM, Gary Helmling <[email protected]> >> wrote: >> > Now that HBASE-5448 is in trunk, we have support for defining >> > coprocessor endpoints as protocol buffer based Services, using PB >> > serialization for the endpoint RPC calls. This is accomplished via a >> > new set of HTable methods (HTable.coprocessorService*). As part of >> > the initial implementation, AccessControllerProtocol was converted to >> > a PB-based Service, and individual JIRA issues have been opened to >> > convert the remaining CoprocessorProtocol-based implementations that >> > we ship. >> [...] >> > Given that 0.96 has been dubbed "the singularity", with some >> > acknowledgement that we will be breaking backward compatibility, >> > should we make an exception to the normal deprecation process and >> > completely remove the CoprocessorProtocol-based support in 0.96? This >> > would allow us to drop Writable support from coprocessor endpoint >> > RPCs. Or should we leave CoprocessorProtocol support deprecated, to >> > be removed in 0.98? >> > >> > On the one hand, coprocessors and CoprocessorProtocol RPC have been >> > described as an experimental feature with an evolving interface. On >> > the other hand, the switch over from CoprocessorProtocol to PB Service >> > implementations for anyone developing their own endpoints will be >> > semi-painful, with a new requirement to define a .proto file, compile >> > with protoc, and very different client usage exposing the PB >> > interfaces. >> > >> >> It seems inevitable that any users of CoprocessorProtocol now will >> suffer this pain eventually. Given that coprocessors are in an >> experimental state and we are still iterating toward a stable design >> -- I think a reasonable expectation is for that CP API design >> stability somewhere in the neighborhood of 0.98 or 1.0 -- doing it >> earlier rather than later is the better course of action. There can >> only be more users of CoprocessorProtocol as time goes on, until it is >> removed, either at the 0.96 "singularity" or after a >> deprecation-and-removal cycle into 0.98. >> >> -- >> Best regards, >> >> - Andy >> >> Problems worthy of attack prove their worth by hitting back. - Piet >> Hein (via Tom White) >> > > > > -- > // Jonathan Hsieh (shay) > // Software Engineer, Cloudera > // [email protected]
