On Tue, Oct 5, 2010 at 7:41 PM, Andrew Purtell <[email protected]> wrote:
> With that said, I expect Gary is already working to address this concern > specifically: > > > Looking at some of their names, they are generic sounding > > and it's not clear to me without digging in that they are > > part of coprocessors. Is it possible to move CP stuff into > > client.cp packages and the like? Or prefix with CoProc > > > or some way to keep this stuff separated? > > I'll have a patch with clarified naming and tweaks for other review comments ready tomorrow morning. For what it's worth, while I agree that we can't anticipate all client needs without some real world examples, I think what we have is basic and flexible enough to be a decent first start. We could delay release to continue to experiment with what we have for our own goals, but I don't think that gets us much closer to anticipating or meeting all end-user needs. This is about end-user extensibility and practically I don't think we'll get broad enough exposure for different enough end-user usage without a release. The client and RPC functionality is mostly an additional path for the CoprocessorProtocol invocations, and really should not be disruptive of existing functionality. As for what can be invoked, well you're free to define your own methods, so there's a lot of flexibility there. For coprocessors, sure there were quite a few changes from the initial patches to actually using it to implement security, but a lot of that amounted to paring it down to a core usable scope. It will doubtless not address all use cases, but I think that will remain true whether it's included in 0.90 or 0.92. Obviously I'm biased but I see those changes more likely as an extension of the API than a wholesale reworking of it. Just a thought, but doesn't Hadoop use annotations to identify level of stability of interfaces? Maybe some like experimental is warranted here, not least of all because you'd be running user code in your regionserver. --gh
