I don't think it's bikeshedding and it is a fair question. I try to avoid that because this is part of the point of KIPs -- avoid extra pain around usability, documentation, maintenance, and compatibility and deprecation by just trying to get things right on the first go around.
It's obviously just my preference, but I would rather name it what we ultimately want and document limitations while we fill in the gaps. This is a case where I really don't know whether we'll want to extend it to effectively duplicate some of the behavior of an existing tool for the sake of consistency, so I raised it for discussion. -Ewen On Tue, Sep 12, 2017 at 10:51 AM, Gwen Shapira <g...@confluent.io> wrote: > > > > > > > * re: naming, can we avoid including 'source' in the command name? even > > if > > > that's all it supports today, I don't think we want to restrict it. > While > > > we only *require* this for source offsets, I think for users it will, > > > long-term, be way more natural to consider connect offsets generally > and > > > not need to know how to drop down to consumer offsets for sink > > connectors. > > > In fact, in an ideal world, many users/operators may not even > > *understand* > > > consumer offsets deeply while still being generally familiar with > connect > > > offsets. We can always include an error message for now if they try to > do > > > something with a sink connector (which we presumably need to detect > > anyway > > > to correctly handle source connectors). > > > > > > > ack > > > > > Sorry about bikeshedding, but: > I think a general name for something that has limited functionality is very > confusing (and we've seen this play out before). Why not name the tool to > describe what it does and change its name if we change the functionality? > > > > > >
