No invitation necessary, the connection details are here, https://github.com/open-telemetry/community#discussions
On Tue, Nov 16, 2021 at 7:35 PM 张铎(Duo Zhang) <palomino...@gmail.com> wrote: > Thanks Nick. This is also my understanding if I read your email > correctly... > > And could you please invite me into the OTEL slack channel? > > Thanks. > > Nick Dimiduk <ndimi...@apache.org> 于2021年11月17日周三 上午1:45写道： > > > > From conversations I've had over on the otel slack, it seems that all we > > really need to do is make sure that there's a "current" span when handing > > flow control over to user code. > > > > On Mon, Nov 15, 2021 at 6:15 PM Andrew Purtell <apurt...@apache.org> > wrote: > > > > > If the exposure is for/within coprocessors, I think that usage falls > under > > > the same exception we make for LimitedPrivate and other things that are > > > necessary for server internal extension but are not public API either. > > > > > > > > > On Tue, Nov 9, 2021 at 4:04 PM Nick Dimiduk <ndimi...@apache.org> > wrote: > > > > > > > Let me find some clarification on what/how might be exposed. > > > > > > > > On Tue, Nov 9, 2021 at 3:34 PM 张铎(Duo Zhang) <palomino...@gmail.com> > > > > wrote: > > > > > > > > > What does ‘expose’ actually mean here? > > > > > > > > > > I think a typical usage is that, users create a span and a scope, > and > > > in > > > > > the scope they call our client API, and our client API will make > use of > > > > the > > > > > Span in the current scope? > > > > > > > > > > So at least we need to let users know they have to use otel if they > > > want > > > > to > > > > > trace HBase calls. But do we really need to expose other things? > > > > > > > > > > Thanks. > > > > > > > > > > Sean Busbey <bus...@apache.org>于2021年11月10日 周三05:40写道： > > > > > > > > > > > If it was akin to slf4j, that integration has been relatively > smooth > > > > > > for downstream. > > > > > > > > > > > > log4j effectively being in our public api through configuration > > > > > > formats has been a maintenance nightmare. > > > > > > > > > > > > These would effectively be in our java binary API though, right? > > > Would > > > > > > we gain any meaningful isolation from trouble later on if we had > > > > > > wrapper objects around the otel stuff? > > > > > > > > > > > > On Tue, Nov 9, 2021 at 2:29 PM Nick Dimiduk <ndimi...@apache.org > > > > > > wrote: > > > > > > > > > > > > > > Heya, > > > > > > > > > > > > > > I've been kicking the tires on the OpenTelemetry tracing work > and I > > > > > have > > > > > > an > > > > > > > ugly question to present. One of the things suggested by the > otel > > > > > > community > > > > > > > is that library implementers (like us, with hbase-client) > expose > > > the > > > > > > > Span/Scope objects to callers so that they can add context > > > > > annotations. I > > > > > > > think this means adding API calls that return otel instances. > From > > > > our > > > > > > > previous experience exposing Guava objects in our API, this > sounds > > > no > > > > > > good. > > > > > > > On the other hand, log4j and SLF4j are effectively in our > public > > > API, > > > > > and > > > > > > > so maybe otel is of a similar breed. > > > > > > > > > > > > > > I have not yet attempted to implement exposure of their > objects in > > > > our > > > > > > > client API, so as of now, my position is that of speculation. > I'll > > > > > report > > > > > > > back as I make progress in this direction. If anyone else has > > > already > > > > > > > traveled this road, please speak up and share your experiences. > > > > > > > > > > > > > > Thanks, > > > > > > > Nick > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Best regards, > > > Andrew > > > > > > Words like orphans lost among the crosstalk, meaning torn from truth's > > > decrepit hands > > > - A23, Crosstalk > > > >
