►
From YouTube: 2022-04-20 meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
C
Sure
so
the
the
latest
login
collection
library
is,
is
integrated
into
the
collector.
So
basically
the
changes
are
there.
There
is
one
exception
to
that
which
I
have
a
pr
which
I'll
link
in
there,
which
is
basically
with
the
observed
time
stamp
because
of
that
change
in
behavior.
C
The
way
it
was
handled
was
to
sort
of
emulate
the
previous
behavior
temporarily,
until
all
of
the
exporters
that
needed
to
take
that
behavior
into
account
could
be
updated,
and
so
this
pr
updates
the
exporters
and
removes
that
temporary
conversion
behavior.
That
was
that
was
inserted
temporarily.
So
so,
basically.
C
Anyway,
we
can
discuss
in
the
pr.
I
think
there
just
aren't
that
many
log
exporters
is
what
it
comes
down
to.
C
Sure
so,
once
that's
merged
in
theory,
I
believe
everything
is
up
to
date
and
then
I
think
it's
a
question
of
how
much
time
do
we
want
to
give
for
issues
to
expose
themselves
of
you
know
through
usage.
B
Yeah,
we
should
probably
wait
for
the
next
release
after
that
and
maybe
wait
another
week
couple
weeks.
Maybe
I
don't
anticipate
any
problems
there.
To
be
honest,
I
don't
know
if
you
do
what's
your
opinion.
B
Okay,
thanks
all
right:
let's
move
to
the
next
mike.
I
think
you
posted
this.
The
abbreviation
prefixes.
D
Yep
this
is
just
following
up
from.
I
brought
this
up
on
the
last
sig
meeting
for
anyone
that
missed
it.
There's
currently
for
like
attribute
mapping,
for
you
know,
company-specific
fields
in
the
logs
data
model.
It
recommends
using
like
a
fully
qualified
like
com,
dot,
google
dot
whatever,
so
I
brought
up
trying
to
you
know,
carve
out
some
exceptions
for
that
for
like
cloud
providers,
so
instead
of
com.google
for
everything
we
could
do
with
just
gcp
dot
and
there's
already
some.
D
So
I
just
wanted
to
put
this
issue
in
here
to
draw
attention
to
it
in
case
anyone
wants
to
throw
in
some
feedback
or
guide
it
a
little
bit,
I'm
still
a
little
new
to
the
project
and
kind
of
figuring.
This
out
as
I
go.
But
if
you
know
all
it
takes
is
just
updating,
you're
opening
a
couple
prs
to
update
those
specifications
to
you
know,
change
those
examples
and
spell
that
out
for
the
cloud
providers,
I'd
be
happy
to
do
that,
just
putting
it
here
to
get
some
eyes
on
it.
B
I
don't
anyway,
I
think
the
issue,
it's
good,
that
we
have
the
issue
there.
It
would
be
probably
useful
to
also
bring
up
the
topic,
maybe
in
the
next
specification
segmenting,
the
the
bigger
one,
not
just
the
log
sig
and
maybe
just
a
submit,
a
pull
request
to
show
what
it
looked
like.
If
you
would
do
all
these
renamings,
where,
where
do
we
have
this?
Is
it
just
in
the
example
mapping
for
the
log
data
model
or
elsewhere?
Do
we
have
it
elsewhere
anywhere
in
the
specification.
D
Yeah,
that's
part
of
what
I
would
have
to
dig
into.
I
know
that
it
was
based
on.
You
know
that
general
recommendation
for
the
spec,
but
I
don't
know
if
it
shows
up
in
other
examples
but
yeah.
I
agree
that
you
know
getting
more
circulation
on.
It
is
a
good
idea.
This
isn't
a
huge
pressing
issue,
it's
just
something
that
came
up
and
you
know
I'll
bring
it
up
at
the
specification
meeting
too.
If
you
think
that
would
be
good.
B
A
Yeah-
and
I
I
was
reading
this
attribute
naming
section,
because
I
think
that
this
is
the
module
event
in
the
specification
for
for
that,
this
recommendations
for
application
developers
and
the
one
that
actually
suggests
using
a
fully
qualified
domain
name.
I
think
it
it.
Its
intention
might
not
have
been
this
case
that
we're
discussing
here
with
the
cloud
providers.
Essentially,
I
think
that
the
intentions
might
be.
Let's
say
that
there
is
some.
I
don't
know.
A
Let's
say
that
sumo
logic
has
some
library
that
someone
can
use
and
the
and
then
like
the
the
idea
is
that
it
should
be
publishing
it
attributes
as
com.small
logic
and
etc.
But
then,
in
this
recommendations
for
application
developers,
there's
also
the
third
bullet,
and
it
says
that
the
name
might
may
be
generally
applicable
to
applications
in
the
industry,
and
I
think
that
for
cloud
providers,
this
is
very
much
true.
A
This
is
like
a
public
service
that
many
organizations
will
use,
and
in
that
case
it
considers
submitting
a
proposal
so
essentially
using
something
that
is
easier
to
use
some
abbreviated
names
and
etc.
So
I
think
that
it
might
be
not
even
with
the
conflict
with
the
with
the
semantic
conventions
or
the
specification,
it
might
just
need,
maybe
a
clarification.
What
are
what
are
the
use
cases
for
each
of
these
bullet
points.
B
E
So
in
the
couple
weeks
ago
I
mentioned
about
the
need
to
have
an
api
for
events,
and
you
suggested
that,
let's
have
it
both
for
logs
and
events
like
a
unified
api,
so
I
came
up
with
this
based
on
you
know,
reading
the
documentation
on
the
traces
and
the
metrics
and
just
wanted
to
get
your
thoughts.
So
so
the
terminology
I
you
know,
might
be
slightly
different
from
what
is
in
the
sdk.
Today,
logs
sdk,
you
used
logger
emitter
provider,
I
used
logger.
E
I
think
you
mentioned
that
in
one
of
your
comments,
but
as
essentially
start
with
the
logger
provider,
get
a
logger,
get
the
log
record
object
and
then
the
bunch
of
set
methods-
and
you
know
to
set
the
different
parameters
and
then
name
and
additionally,
there
are
a
couple
of
convenience
methods,
a
set
event,
and
this
corresponds
to
the
add
event
method.
That's
present
in
the
span,
if
we
want
to
define
a
transition
from
you
know
the
events
in
the
span
to
the
events
using
lock
records.
E
B
So
we
have
the
the
structure
that
we
have
for
traces,
a
similar
structure.
Here
we
have
tracer
provider,
we
have
tracer,
we
have
the
span
so
the
the
the
equivalency,
our
logger
provider-
logo
low
breaker.
I
think
that's,
that's!
That's!
That's
good!
The
consistency
is
good.
I
don't
remember
if
we
have
setters
on
a
span.
F
B
E
It's
not
yet
yeah
that
is
new,
so
that
I
only
added
as
a
convenience
method,
helper
method.
For
a
couple
reasons,
I
think
the
are
wherever
you
know.
We
we,
wherever
this
api,
used
for
the
purpose
of
events.
B
I
I'm
still
not
sure
that
the
set
event
reflects
the
intent
here,
maybe
maybe
as
an
alternate,
you
could
call
it
like.
They
could
have
a
method
on
the
logger
and
call
it
create
event
like
logger
could
have
two
two
methods
create
log
record,
which
would
be
a
generic,
empty
log
recorder,
essentially
or
or
a
create
event
which
would
populate
that
attribute.
Maybe,
but
it's
just
just
just
an
alternate
proposal,
I'm
not
sure
which
one
is
the
better
way
here.
E
You
know
in
in
some
ways
that's
good,
but
the
problem
is
there.
Are
these
other
methods
like,
for
example,
for
events?
We
don't
want
people
to
set
the
body.
Let's
say
we
agree
on
that
that
this
body
is
only
for
the
original
purpose
meant
only
for
the
locks.
B
E
E
Yeah
yeah.
No,
I
meant
that
if,
if
you
were
to
have
another
method
at
the
logger
level,
saying
create
event,
what
would
we
describe
as
the
purpose
of
these
two.
B
B
B
Yeah,
okay,
yeah.
I
think
it
does
make
sense.
We
have
jack
here
in
the
call
check.
What
do
you
think
you
implemented
the
api
in
java?
Any
thoughts
on
this.
F
So
on
introducing
a
logs
api
yeah,
you
know
I
I
have
the
same
kind
of
concerns
that
others
have
voiced
in
the
past.
I
think
that
led
to
the
original
omission
of
a
logs
api,
which
is
that
you
know
it's
just
another
logs
api
to
compete
against
the
other
ones
in
a
framework
other
frameworks
that
already
exist
with
that
said
that
it
doesn't
feel
intuitive
to
create
events
through
the
existing
ap
existing
log
apis
that
are
available
in
java,
for
example.
F
B
I
think
well
I
mean
we
can
justify
the
existence
of
our
competing
log
api
if
we
show
that
it
is
how
it
is
different
and
why
the
existing
ones
are
are
not
good
enough.
In
this
particular
case,
for
example,
you
can
have
structured
attributes
right
and,
as
far
as
I
know,
in
most
of
the
logging
apis,
the
attributes
are
like
playing
key
values
where
the
values
are
primitives
right
and
you
can't
have
like
nested
values
in
the
attributes,
whereas
here
we
could
allow
that
and-
and
there
probably
maybe
are
real
use
cases.
F
I'm
thinking
from
the
perspective
of
like,
let's
say,
you're
instrumenting,
a
a
major
framework
in
your
ecosystem.
Let's
say
for
some
reason
spring
would
want
to
adopt
open,
telemetry's
apis
to
emit
kind
of
native
telemetry,
so
if
they
definitely
have
to
do
logging
type
stuff
already
and
and
maybe
they
want
to
start
emitting
some
events
as
well,
do
they
use
sll4j
for
the
more
traditional
logs
and
then
use
our
events
api
for
things
that
are
definitely
events
where
would
they
like
adapt
our
api
for
all
the
things.
F
Yeah,
so
what
they,
so,
I
think
they
probably
use
slf
for
j,
because
you
can
choose.
B
B
B
In
that
case,
I
guess
there
is
no
expectation
that
they
would
change
anything.
They
will
continue
using
that,
if,
for
whatever
reason,
they
discovered
need
to
emit
events
or
log
records
which
are
impossible
to
emit
using
the
sla
4g
apis,
then
maybe
they
can
start
also
using.
In
addition
to
that
also
our
api,
and
I
think
that
that
should
be
a
supportive
use
case
where
you
use
both
like
one
or
the
one.
Should
they
shouldn't
be
kind
of
mutually
exclusive
right.
B
F
Yeah
so
there's
more
traditional
logging,
where
you
log
like
a
message,
but
then
I
imagine
there
are
use
cases
for
doing
things
that
look
look
like
events
where
they
they're
primarily
defined
by
having
a
name
and
a
type
or
like
you
know,
a
name
space
and
a
type
and
then
a
series
of
attributes
and
no
kind
of
just
general
string
body.
F
And
if,
if
some,
if
a
library
wanted
to
provide
that
type
of
instrumentation,
so
they
could
do
it
with
one
of
their
existing
log
libraries,
but
it
would
be
kind
of
like
a
square
peg
and
a
round
hole.
Not
like
not
super
intuitive
on
how
to
do
that,
and
I
guess
an
idea,
like
I
thought,
that's
coming
to
my
mind,
is
like
if
we
introduce
a
log
api
like
this.
B
The
level
of
configurability
I
would
expect,
would
be
the
same
as
we
do
for
for
traces.
Essentially,
right,
you
can
define
processors,
you
can
define
exporters,
you
choose
the
destination,
the
same
that
you
do
for
for
traces.
Essentially,
I
wouldn't
expect
this
to
be
any
any
different
for
logs,
just
just
for
consistency
purposes.
F
Yeah,
that's
what
I
would
expect
as
well
and
then
so
all
of
a
sudden
library
authors
have
to
you
know
if
they're
considering
using
our
log
api,
they
have
to
consider
that
their
users
won't
be
able
to.
You
know
just
like
take
those
logs
and
log
them
out.
You
know
using
the
the
appenders
that
they're
used
to
like
if
they're.
B
I
don't
know
what
the
answer
to
that
is.
Maybe
maybe
the
default
behavior
should
be
that
if
you
emit
something
using
open,
telemetry
logging
apis
and
you
don't
specify
the
destination
or
an
exporter,
then
it
goes
to
whatever
is
your
currently
configured
blogging
library?
I
don't
know
if
that's
possible
even.
F
Maybe
yeah,
I
think,
that's
kind
of
what
was
drawing
me
towards
the
idea
of
just
having
like
an
event
focused
api
specifically
because
then
you
don't
have
competing
concerns.
You
use
the
standard
logging
apis
for
doing
the
traditional
logging,
and
if
you
want
to
extend
those
log
use
cases
into
things
that
are
more
event-like,
then
you
adopt
our
event.
Api.
B
F
Yeah-
and
it's
it's
not
entirely,
you
know
it
doesn't
avoid
confusion
to
get
all
together
because
at
the
suppose,
you
use
both
log
for
j
and
our
events
api,
both
of
those
result
in
logs
being
sent
over
the
you
know
over
through
the
open,
telemetry
log
sdk
and
wherever
you
end
up
exporting
them.
So
you
know
you
still
have
to
grapple
with
the
fact
that
logs
and
events
at
some
point
get
kind
of
merged
and
are
one
thing.
B
B
Let's
imagine
a
situation,
I
have
an
application
which
uses
some
framework
spring,
for
example,
which
already
emits
its
own
logs
using
sla4j
or
whatever
library
it
uses,
and
then
in
my
own
application
code,
I
start
using
open
telemetry
api
open,
telemetry
logging.
Api
technically
like
these
are
both
logging
apis.
E
System
isn't
that
an
existing
problem,
as
in
like
people
can
always
use
lock4j
and
slf4j
in
the
same
application,
and
you
know
if
the
configuration
for
each
of
them
is
different.
If
the
configuration
is
different.
That's.
B
B
F
And
furthermore,
instrumentation
authors
so
folks
that
are
instrumenting
their
libraries
if
they
are
trying
to
choose
what
the
log
api
they
should
use,
they
have
to.
You
know,
make
this
decision,
so
we
could
use
the
open,
telemetry
log
api
and
then
our
users
wouldn't
have
as
rich
of
configuration
options
as
what's
available
with,
like
you
know
this,
the
the
more
popular
frameworks
of
the
language
log
for
j
and
log
back
or
they
could
choose
to
use
a
mixture
of
two
apis.
F
They
could
say
you
know
we
want
to
use
the
slf4j
api
for
most
traditional
log
type
things,
but
then
we
also
want
to
emit
some
specific
events.
And
you
know
the
open,
telemetry
api
is
better
suited
for
that
and
it's
it
would
be
weird
for
them
to.
You
have
to
make
the
decision
to
choose
the
open,
telemetry
api
and
give
their
for
everything
and
give
their
users
less
options.
E
Yeah,
so
that
part
is
true
that
you
know:
if
we
add
this
api,
we
will
have
to
support
all
the
common
configurations
that
other
apis
support,
which
is
pretty
huge.
C
Just
to
throw
out.
B
C
Here,
if
we
had
this
api
for
events,
could
we
just
basically
wrap
other
logging
libraries
right
in
a
sense
like
like
we're
just
giving
you
the
the
method,
signature
that
looks
like
an
event
method,
signature,
but
then
we're
just
calling
slf
for
j
and
and
doing
it
in
a
certain
way
that
maps
to
the
data
model
we
expect,
and
then
we.
C
B
C
If
they
felt
comfortable
with
it.
I
guess
we
just
sort
of
do
the
mapping
for
them
and
then
and
then
we
don't
have
to
implement
much
except
a
very
surface
level.
Implementation.
C
B
It
may
not
be
possible
to
implement
the
functionality
that
we
we
can
expose
in
our
apis
through
the
apis
of
existing
logging.
Libraries
like
for
attributes,
we
support-
let's
say
arbitrary
nesting
of
the
values
right,
and
I
don't
think
particularly
the
java
logging
libraries
allow
this.
I
think
they
are
primitive
values
only
for
the
attributes.
If
I'm
not
wrong.
E
Actually
I
had
listed,
you
know
here
a
few
reasons
why
the
existing
logging
library
interfaces
cannot
be
used
for
events.
A
Yeah,
I
I
think,
like
this
logging
libraries
versus
using
let's
say,
open,
telemetry,
lock
api.
This
really
serves
different
purpose
and
the
way
I
think
about
it
like
we
want
to
have
open,
telemetry,
lock
api.
If
I
want
to
use
attributes
like
have
all
this
richness
of
the
open,
telemetry
data
model.
Access
to
that,
so
I
can
like
set
the
attributes
of
the
different
levels
with
different,
complex
structures
and
whatnot,
and
and
to
me,
I
I
would
define
with
having
let's
say,
two
parallel
ways
in
certain
scenarios.
A
So
someone
is
having
this
log4j
or
whatever
else
is
being
used.
There
may
be
python
logging
or
something
else
that
goes
to
standard
output,
and
maybe
it
goes
via
some
appender
to
open
telemetry
as
well,
and
if
someone
wants
to
emit
locks,
then
they
have
access
to
this
open,
telemetry,
lock,
api
that
has
maybe
different
means
of
the
transport.
B
D
B
To
being
recorded
to
the
to
the
standard
output
for
the
for
the
built-in
vlogs.
A
Yeah,
so
I
think
that
not
even
that,
I
think
that
it's
like
up
for
the
anyone
using
that
to
to
decide
what
they
want
to
do,
because
maybe
they
want
to
put
it
on
the
understand
that
output-
and
maybe
they
just
want
to
let's
say,
use
fire
lock
collection
to
pull
this
to
open,
telemetry,
collector
and
so
on.
But
events
might
have
a
different
path
for
for
whatever
reason
that
they
that
they
are
like
much
more
structured.
A
We
have
like
all
these
attributes
and
in
java
you
can
maybe,
for
example,
use
mdc
to
to
push
attributes
with
logs,
but
you
have
limitations
of
what
kind
of
structure
you
could
push
there,
and
this
brings
a
lot
of
complexities
and
we
and
maybe
use
json
or
something
else
to
to
to
include
complex
values
there,
and
I
think
we
don't
even
need
to
think
about
that.
We
just
need
to
think
about
two
different
streams.
One
is
like
for
for
log
api.
A
B
G
If
we
just
say
we
have
an
events
api
and
we
have
an
implementation
that
happens
to
use
the
open,
telemetry
log
api
by
default,
and
then
we
say
that's
what
we've
got,
but
we
also
have
a
potential
slf
for
j
or
log
for
j
version
where
effectively
the
events
api
just
generates
it,
and
then
just
you
know
drops
it
out
to
wherever
you
want
it
to
go
and
they
just
configure
it
rather
than
trying
to
massage
it
and
have
it
going
out
through
having,
rather
than
saying,
okay
we're
going
to
have
the
the
events
api,
it's
going
to
go
through
slf,
j
or
whatever
logging
mechanism,
which
is
then
going
to
be
come
back
through
the
appender.
G
To
that
just
adds
up
to
convoluted.
I
think
we
just
say
we
have
an
events
api,
it
happens
to
use.
You
know,
hotel
logging
under
the
covers.
G
It
is
a
blog
provider
that
it's
playing
with
to
go
and
like
set
the
attributes
and
whatever
else,
and
you
can
change
it
if
you
want
to
and
that
way
effectively
the
the
app
is
using
slf
for
jay
for
its
own
stuff
and
then
the
events
api
for
the
events
and
if
they
want
those
events
to
drop
out,
then
they
just
configure
it
to
do
so.
F
That
that
makes
sense
to
me
so
it
kind
of
tracks,
with
our
decoupling
of
apis
and
sdks
in
general,
we
have
an
events
api
and
we
have
a
like
a
log
sdk,
which
is
you
know,
the
implementation
of
the
events
api
and
but
you
could
substitute
out
different
implementations
of
the
events
api,
like
you
suggested
that
would
route
to
other
logging
frameworks.
F
B
B
B
E
Yeah,
I
think
it
would
require
defining
how
you
will
flatten
the
structure.
G
If,
if
someone
wants
to
to
have
a
flattened
and
go
out
to
sls
for
j,
then
that's
effectively
a
separate
thing
that
we
don't
necessarily
need
to
do,
because,
if
they're
flattening
it
they're
sending
it
probably
to
the
console
or
they're,
not
yeah,
we
don't
want
that
to
come
back
through
open
telemetry
anyway
through
the
appender,
because
we're
going
direct.
E
E
If
we
restrict
to
restrict
the
api
to
just
for
events,
then,
are
you
worried
that
the
original
definition
weakens
that
logs
and
events
are
the
same.
G
I'm
just
going
to
quickly
jump
in
there.
I
I
don't
think
it
weakens
it.
I
think
it's
a
case
of
we're
saying
the
events.
Api
is
a
helper
method
on
top
like
we're
using
logs
as
transport,
because
when
you
have
events,
events
and
logs
conceptually
are
the
same
thing.
We're
just
saying
we're
going
to
have
a
an
event
api
that
happens
to
shape
an
hotel
log
for
us.
G
Yeah,
I
agree.
The
events.
Api
is
what
you
call
it
here:
convenience
api
under
the
covers
it
is
generating
hotel
logs
so
that
it
still
goes
down
the
back
down
the
same
path,
and
we
don't
have
yet
another
transport
mechanism
here,
because
I
think
we
need
it.
E
Then
the
reason
for
calling
it
an
events-
api
is
only
to
you
know,
discourage
people
to
use
it
for
the
original
logging
purposes.
Locks
purposes.
Is
it.
B
It
probably
would
result
in
some
sort
of
discouragement,
but
is
that
what
we
want
to
do,
I'm
not
so
sure
about
that
right
is
that.
Is
it
the
right
approach,
some
ways?
I
guess
if
it
solves
the
problem
that
a
check
raises,
then
maybe
I
guess
that's
that's
a
good
approach,
maybe,
but
I'm
not
so
sure
that
it
does
solve
actually
a
problem.
B
Yeah,
I
don't
know
if
we're
going
to
be
able
to
have
answers
to
all
of
these
questions
in
this
call
yeah.
Maybe
it
would
be
great
if
you
could
record
this
as
issues
and
then
we
could
also,
I
mean,
maybe
even
in
this
document,
there's
open
questions
or
something
and
then
we
can
discuss
offline,
I
mean,
but
ideally
we
would
want
to
have
the
answers
before
we
go
ahead
and
start
the
actual
additions
to
the
to
the
spec.
E
I
can
update
this
talk
and
and
also
create
an
issue
pointing
to
this
talk,
so
that
more
people
can
comment
yeah.
These
are
places.
B
Yeah,
please
do
update
the
talk
up,
maybe
an
open
question
section
with
what
we
were
discussing
and
let's
see
if
we
can
find
some
good
answers
to
to
those
questions.
Okay,.
E
I'm
not
entirely
clear
on
on
all
the
questions,
maybe
jack.
You
know
if
you
could
also
add
your
thoughts
in
this
document.
I'll
share
the
link
with
you.
If
you
could
add
your
comments,
it
will
be
great.
B
B
So
yeah
you
posted
the
link
there
right
so
guys
if
you
have
any
thoughts
any
opinion
on
this,
please
do
review
the
document.
Yeah,
add
your
comments,
your
thoughts
there.
It
will
be
very
useful.
E
A
minor
topic,
I
think,
never
also
brought
up
in
another
call,
so
in
general,
in
hotel
there
are
many
of
the
apis
are
using.
The
builder
pattern
right
is:
was
there
a
reason
for
choosing
that
pattern.
B
E
Okay,
because
in
case
we
go
down
the
route
of,
I
mean
we
decide
that
we'll
use
it
for
logging
purposes
too.
You
know
I
in
in
the
existing
lock
4g
slf
4g
apis.
E
They
don't
have
this
emit
at
the
end
right,
you,
you
just
say
lock
dot,
debug
and
then
provide
everything
in
one
shot.
So,
whereas,
with
the
builder
pattern,
you
know
you
you
you
you
get
to
define
when
you
want
to
freeze
the.
B
Object
creation:
the
specification
generally
tries
to
stay
away
from
the
specifics
of
the
languages
it.
I
think
we
somewhere
in
the
spec.
We
say
that
the
languages
can
choose
whatever
is
idiomatic
way
of
representing
this
api,
but
the
api.
The
wording
in
the
specification
is
intentionally
kind
of
more
generic.
It
tries
to
stay
away
from
that.
Doesn't
use
the
things
like
builder
or
whatever.
B
The
patterns
are
right,
it
tries
it
kind
of
is
more
more
english,
more
trolls
in
a
sense
right,
some
ways
it
maybe
makes
it
less
precise,
but
the
reason
is
that
different
languages
make
different
choices
here
about
how
exactly
to
map
this
the
logical
api,
as
it
is,
describing
to
the
particular
implementation
in
this
this
language,
okay,
actually.
E
B
E
Consideration
here,
which
is
in
a
in
the
case
of
a
tracing,
you
start
the
span,
and
then
you
say
end
span
because
end
you
know
is,
is
required.
It's
it's
happening
separately
in
the
meter.
There
is,
there
is
no
end
marker
right.
I
think
you,
you
create
the
meter
and
then
there
is
a
separate
meter
reader,
which
is
you
know,
asynchronously
in
a
separate
thread,
maybe
grabbing
your
your
current
values
of
those
meters.
That.
E
You're
right
it's
different
yeah,
but
basically
for
for
a
meter
builder,
I
don't
see
an
end
or
a
you
know,
emit
concept
right,
whereas
for
logs
you
know
do
we
want
to
have
that
emit
it
it.
It
seems
to
be
needed
only
if
you
follow
the
builder
pattern,
but
if,
let's
say
every
individual
method
emits
the
you
know
record
right
away,
you
know
that
would
be
one
approach
so
so
in
that
case
the
spec
could
say
that
you
know.