►
From YouTube: 2023-01-25 meeting
Description
cncf-opentelemetry meeting-2's Personal Meeting Room
B
B
C
A
A
When
we
have,
we
have
two
meetings.
We
have
one
on
Tuesday,
one
on
Wednesday,
oh
okay
and
the
Tuesday
one
is
kind
of
more
this
working
group.
It's
more
focused
on
the
browser
stuff,
oh
okay,
so.
D
A
Of
I
think
I
think
most
most
of
our
work
recently
has
been
on
just
finalizing
the
events
API
spec
and
starting
to
implement
it
in
JavaScript,
so
back
to
logs
API,
logs
SDK
and
events
API
and
then
semantic
conventions
for
browser
events,
which
is
I.
Think
at
some
point
we'll
want
to
start
working
on
mobile,
but
we'll
need
more
more
expertise
from
other
people.
There.
A
C
F
A
So
I
mean
just
a
quick
update
for
anyone
who
doesn't
know
like
what
I've
been
working
on
is
in
the
JavaScript
SDK.
A
A
But
the
goal
is
the
goal
is
to
get
this
merged
work
on
the
log
SDK,
which
there's
a
there,
is
a
draft
PR
open
already
and
then,
after
that,
once
the
log
SDK
is
done,
then
we
can
create
events,
SDK
that
uses
to
log
SDK
and
then,
after
that
we
can
start
start
prototyping
instrumentation
that
uses
the
events.
Api
events.
D
A
So
there's
just
like
a
few
steps
that
needs
to
happen,
but
that's
you
know.
One
work,
that's
happening,
I
think
we
also
have
the
semantic
conventions,
discussions
for
browser
and
I.
Don't
know
where
that
is
exactly.
E
Yeah,
that's
in
a
draft
stage.
I
haven't
traced,
PR.
E
Yeah
yeah,
with
respect
to
the
browser
semantic
conventions,
yeah
I,
haven't
raised
an
epr
against
the
spec
repo.
Yet
I
was
you
know,
I
I
was
gonna,
do
it,
but
I
I
thought.
Maybe
if
the
events
API
and
SDK
are
coming
close,
then
maybe
we
could,
you
know,
build
some
prototypes.
You
know
that
way
we
can
demonstrate.
You
know
how
those
semantic
conventions
will
be
used.
E
So
I'm
that
is
my
plan.
Martin
are.
Is
that
okay
yeah?
That's
that's
fine
yeah,
but
otherwise
yeah
it
is.
It
is
kind
of
ready
for
further
reviews
within
the
shorter
team.
Let
me
put
those
links
in
the.
E
E
E
And
Bryce
I
think
we
will
need
something
similar
for
the
mobile
case.
Also
I
think
we
discussed
about
it
in
the
Swift
sick
some
time
ago.
If
you
see
my
screen,
I
have
you
know
a
document
where
I
have
listed,
how
the
different
events
are
going
to
look
like
coming
from
the
browser
instrumentation.
There
are
a
bunch
of
events
and
the
first
one
has
an
example.
E
There
is
a
key
difference
from
the
past
where
the
payload
is
is
in
an
attribute
called
event.data.
E
It's
that
so
the
API,
you
know
we
will
be
changing
to
accommodate
this
Martin
I.
Think
today,
in
the
log
say,
you
know
I'm
going
to
bring
up
a
few
things
about
Cloud
events,
how
you
know
we,
it
doesn't
affect
us,
but
we
are
in
some
ways
you
know
close
to
how
they
represent.
E
You
know
their
data
and-
and
therefore
you
know
we
we
might
continue
to
you
know-
do
so
and
continue
to
use
their
terminology
as
well,
so,
which
means
that
you
know
there
will
be
two
types
of
you
know:
data
in
an
event
you
know
one
is
the.
E
You
know
what
they
call
as
the
the
data
or
the
payload,
which
is
which
is
inside
an
attribute
called
Data,
and
then
all
the
you
know
other
attributes
at
the
top
level
they
call
as
context
attributes
and
they
have
explicitly
defined
each
one
of
them.
There
are
about
four
mandatory
ones
and
a
few
other
optional
ones,
so
those
will
be
at
the
top
level.
You
know
in
our
case
it
is
name
and
domain.
So
far
in
in
Cloud
events
case
you
know
it
is.
The
name
is
equal
to
type.
E
They
have
a
source
which
corresponds
to
our
resource
and
they
have
an
ID.
Every
event
has
a
unique
ID.
E
That's
all
and
there's
a
spec
version,
which
is
a
fixed
1.2,
so
to
match
with
that
our
event
API.
Today
it
takes
a
name
and
a
bunch
of
attributes
which
currently
you
know
they
go
at
the
top
level,
but
we
would
be.
You
know
changing
that.
To
take
two
types
of
arguments
you
know
one
is
the
payload,
the
attributes
that
go
into
the
you
know
payload,
which
is
that
event.data
and
another
set
of
attributes
that
that
go
at
the
top
level,
which
at
the
moment
we
don't
have
too
many.
E
E
Is
is
never
there
on
the
call,
I
I
think
just
joined.
He.
E
E
So
now
the
question
is
you
know?
What
is
the
reason
we
have?
You
know
data
in
a
separate
attribute,
called
event.data.
H
G
C
Oh
I
see
so
the
the
the
the
root
attribute
field
is
for
like.
If
a
if
a
customer
is
making
an
event
and
then
they're
adding
attributes
on
there,
then
it
then
it
will
go
into
the
I
guess
which,
which
group
would
that
go
into
you.
E
C
Like
a
developer
wants
to
make
an
event
and
they
have
like
an
attribute
field.
Are
there
going
to
be
two
attribute
fields
for
them
like
one
for
event,
data
and
one
for,
like
the
you
know,
the
main
attributes
on
the
log
record
or
are
there
going
to
be?
Is
there
just
going
to
be
one
I
guess
I
couldn't
go,
look
at
the
API
yeah.
H
So
event.data
is
just
an
attribute
so
because
login
vested
attribute
it's
a
case
of
when
we
say
domain
name
is
Right
page
view,
then
effectively.
All
the
data
associated
with
page
view
is
in
data
and
then
the
user
is
free
to
go
and
add
any
other
attributes
that
they
may
or
may
not
want.
H
G
E
E
Let's,
let's
look
at
some
examples
of
Cloud
events
right,
so
he
so
for
for
cloud
events.
You
know
this
is
how
an
object.
An
event
looks
like
you
know:
there
is
a
data
and
then
there
are
these
four
fields
that
are
mandatory,
the
bottom
four
and
content
type.
You
know
it
indicates
that
the
data
is
a
plain
text,
so
this
top
level
Fields.
They
are,
you
know
their
metadata.
They
don't
contain
facts
about
the
event
right
well,.
E
In
in
general,
too,
so
all
the
so
if
the
customers
customer
tributes,
you
know,
are
part
of
the
event
data,
then
they
should
go
inside
the
event
data.
They
are
not
metadata.
No.
H
The
weather
data,
then
you
have
clashes
with
without
data,
and
if
you,
if
you
look
at
the
specification
for
Cloud
events,
you'll
actually
see
they,
they
also
specify
that
users
can
add
their
own
events
at
the
top
level,
not
if
not
in
data.
C
E
So
my
understanding
is
even
when
people
add
at
the
top,
they
are
for
extensions,
so
the
the
the
core
data
of
the
event
is
still
in
the
data,
but
how
to
interpret
that.
You
know
how
to
annotate
that
you
know
any
connotations.
You
know
those
you
know
go
into
the
top
level
attributes,
so
the
top
level
attributes
themselves
will
will
continue
to
be
considered
as
metadata.
E
Yeah,
but
the
context
attributes
are
are
only
metadata.
They
they
give
you
the
context.
They
don't
give
you
actual
event
content.
G
H
We're
defining
we're
requiring
an
event
and
over
all
the
fields,
all
the
general
Fields,
so
search
where
that
event
are
in
event,
data
yeah.
If
the
user
wants
to
create
their
own
custom
event,
then
they
would
have
their
own
custom
event
and
if
they
want
to
make
it
look
like
an
event,
it
would
also
be
in
event
data.
If
they've
got
additional
attributes
that
they
want
to
add
to
any
existing
event
that
we've
defined,
then
they
don't
put
it
in
event,
data
they
put
it
at
the
top
level.
E
So
is
so
there
are
two
different
cases
right,
a
customer.
E
You
know
creating
their
own
event
entirely.
You
know
our
new
event
versus
you
know.
They
are
extending
one
of
the
events
that
the
instrumentation
emits
they're,
adding
to
an
existing
event
right.
So
in
the
first
case
they
will
just
use
the
event
API
and,
and
then,
whatever
you
know,
format
the
event
API,
you
know
enables
the
event
to
go
on
the
wire.
You
know
that
will
happen
yep,
but
for
the
other
case,
yeah
I
think
you
will
need
some
semantic
conventions
that
any.
E
How
will
that
happen,
though?
How
will
the
event
API
facilitate,
adding
to
an
existing
event.
E
Yeah
but
the
you
know,
how
would
you
call
it
twice
like
first,
the
instrumentation
will
generate
an
event
and
then,
let's
say
the
customer
through
a
a
processor.
You
know,
catches
hold
of
that
event
and
then
he
wants
to
add
things
to
it.
So
what
API
would
you
would
he
use?
In
that
case,.
H
Like
in
the
cloud
of
Inspector
further
down
the
page,
there's
an
extension
context,
attributes
that's
really
the
same
thing
and
defining
extensions.
So
one
thing
we
haven't
talked
about
is:
do
we
want
to
define
a
placeholder
or
the
user
to
find
their
own
events?
So
in
the
case
of
application
insights
we
have
our
own
data,
but
then
we
have
a
general
properties
bag
that
people
could
throw.
E
Thinking
that,
even
in
our
case,
we
should
just
Define
one
field
inside
the
data,
you
know
where
it
could
be
very
dependent
on
the
context.
Yeah
yeah.
A
I
have
I,
have
a
I
have
like
just
I,
think
that's
gonna
get
pushback
from
the
from
the
log
sick
because
we're
even
more
deviating
from
from
how
other
signals
handle
attributes.
Then.
H
Yeah,
which
is
why
I
was
saying
we
just
drop
it
at
the
the
top
level,
because
otherwise,
if
we're
saying
we're
going
to
have
a
special
field
inside
event,
data,
then
we're
definitely
pushing
you
know
in
the
nesting,
because
it
would
be
event,
data
properties
and
that.
E
How
does
all
any
of
our
existing
systems
work
in
this
case
like
extending
an
existing
object?
What
conventions
do
you
have
today.
E
No,
let's
say
application
insights.
H
Let's
say
we
have
a
top
level
field
which
effectively
is
just
properties.
What
we
actually
call
it
there
you
go
internally,
but
so
effectively.
We
have
a
definition
that
says
for
a
remote
dependency.
We've
got
all
these
fields
and
then
every
event
yeah.
H
Has
a
bucket
to
drop
in
you
know
application
or
user-defined
Fields
so
that
they
make
their
way
to
the
back
end.
E
H
G
E
Okay,
yeah,
in
that
case,
maybe
why
not
you
know
we
Define
a
similar,
a
sibling
to
event.data.
You
know,
which
is
also
an
estate
attribute
yep.
F
And
how
they
operate
now
there
you
can,
just
you
know,
create
if
you
have
four
custom
properties,
all
four
of
them
are
at
the
same
level.
You
know
individual
and
not
packaged
into
a
bucket
or
anything
like
that.
Why
are
we,
you
know
doing
Special
casing
for
clients
I
think
we
have
a.
We
need
to
have
a
good
reason
right.
Isn't
that
what
we're
taking
money.
E
Yeah
actually
Nev.
Let
me
give
you
one
more
a
piece
of
info
to
answer
that
question.
So
in
so
I
had
a
discussion
with
the
cloud
events
team,
I
initially,
you
know,
spoke
to
them.
You
know
how
do
we
identify
the
overlap
so
that
we
can
align
our
specifications
and
the
discussion
I
realized
that
you
know,
even
though
they
have
a
format?
E
You
know
like
this.
You
know
this
is
their
they.
They
have
a
structured
mode
in
the
binary
mode
in
a
structured
mode.
You
know
they
have
this
Json
format,
which
is
what
you
see
here
in
the
binary
mode.
You
know,
depending
on
the
you
know,
transport
protocol.
You
know
they
have
defined
that
protocol
specific
headers,
the
context
attributes
go
in
the
headers
and
then
the
body
is
just
the
data
right.
So
you
know
we
cannot.
You
know,
make
our
payload
our
event.
E
Payload
look
like
this,
so
there
is
no
way
you
know.
Our
events
will
will
just
fit
into
the
Cloud
events
format
so,
which
means
that
in
future,
if
anyone
wants
to
send
our
events
to
a
to
a
to
a
broker
who's
based
on
cloud
events,
an
example
of
that
is
in
a
k,
native
Eventing,
you
know,
I
was
reading
about
it
yesterday,
so
K
native
Eventing
is
is
entirely
based
on.
E
You
know
the
events
that
confirm
to
the
cloud
events
spec.
So
in
that
case
you
know
they.
You
need
an
adapter
which
translates
our
events
to
Cloud
events,
which
means
you
will
need
to
come
up
with
a
mapping.
You
know
what
goes
where
like
they
have
mappings
for,
let's
say
kubernetes
event
and
for
for
S3
you
know
they.
Let
me
show
you
that
they
have
an
adapters
here
right
so,
let's
say
an
S3
event
how
our
SNS,
you
know
different
some
of
these
events.
E
You
know
what
goes
where
you
know
they
have
this
mapping.
So
similarly,
we
need
to
have
a
mapping
in
future.
If
that
need
arises,
in
which
case
it
will
be
simpler,
if
only
one
attribute
maps
to
data
in
event.data.
So
that's
why
I
was
considering
that
even
the
user
data,
if
it
goes
inside
the
data,
it
would
be
easier
for
this
mapping
in
future.
H
Yeah
so
I
think
in
my
event,
data
spec
I'm
just
trying
to
find
a
link
to
it.
I
actually
gave
what
one
or
two
possible
ways
of
defining
this.
So
one
is,
we
say
our
event.data
is
equivalent
to
Cloud
events.data.
So
therefore,
we
would
need
a
data
content
type
that
was
going
to
happen.
The
other
way
would
be
we
say,
the
domain
is
cloud
events
and
the
name
is
whatever
and
then
event
data
is
just
a
cloud
event
object.
E
No
I
think
the
question
was:
if
we
have
you
know
additional
attributes,
go
you
know
in
a
different
another
necessary
attribute.
Then
we
are
deviating
from
you
know.
Other
signals.
H
That's
the
case
of
so
if
you've
got
a
a
field
with
like
a
event,
dot
user
data
or
app
data
or
whatever,
that
can
just
be
a
bucket
that
people
can
dump
in
whatever
they
like.
Likewise,
they
could
also
just
dump
in
you
know,
following
existing
semantic
conventions
like
HTTP
attributes
or
some
other
attributes
at
the
top
level
like
and
that's
not
going
to
collide
with
our
event,
data
that
that's
the
whole
reason
that
event
data
is
up
on
its
own.
So.
G
E
H
Defining
the
specification
to
say
a
page
view
need
these
things:
it's
a
bit
like
a
trace
event,
nothing
stopping
users
from
adding
their
own
attributes.
Today,
we're
just
defining
and
saying.
If
you've
got
a
page
view
event,
then
these
are
the
fields
that
that
the
back
end
should
expect
if
there's
additional
Fields
there's
additional
Fields.
But
this
is
is
how
the
back
end
needs
to
interpret
those
Like,
We,
Can't,
Stop
users
and
say:
oh
no,
I
can't
accept
that
page
view
of
it,
because
it's
got
additional
attributes
like
there's
nothing
in
open
Telemetry.
H
H
I
would
prefer
to
be
able
to
say
it
is
just
a
flat
object,
but
that's
not
going
to
happen
anytime
soon.
I,
don't
think,
or
we
could
say,
event.data
is
a
serialized
Json
string
as
well
in
the
log
event,
regardless
whether
it's
a
log
event
or
a
span
of
it,
but
right
now
we're
identifying
it
as
saying
event:
data
has
these
fields
as
far
as
otlp
is
concerned.
The
only
way
to
send
those
fields
is,
as
Mr
average
like
what's
on
the
screen
today,.
I
I'm
asking
just
to
see
if
I
I
guess
backhands
will
have
to
accommodate
to
this
nested
objects.
The
external
attributes
yeah.
H
Logging
today
supports
net
attributes,
which
is
why
we're
using
logging
as
transports
the
yaml
tools,
don't
currently
support,
defining
that
I
believe
the
collector
supports
forwarding
that
I
don't
know
how
back-ends
would
handle
that
today,
because
the
reason
that
tracing
doesn't
have
that
attributes
is
because
Prometheus
and
Zipkin
and
stuff
like
that.
Don't
support
nested
attributes,
so
they
have
to
be
unrolled
somehow.
H
I
And
answer
one
more
question
was:
was
a
a
prefix
consider
for
this
like
like
instead
of
nested
attributes,
just
all
of
the
attributes
that
you
guys
want
to
leave
for
events
will
all
start
with
event.data,
because
I
think
I've
seen
something
similar
for
other
signals.
Yeah.
H
Other
circles
had
to
do
that
because
there
was
no
necess
attribute
support.
One
of
the
reasons
we
are
against
that
notwithstanding
the
bloke
that
otlp
supports
is
because
of
the
additional
size,
so
in
fact
you're
repeating
a
bunch
of
you
know,
event
or
whatever
that
prefix
is
for
for
every
single
element.
So
if
you've
got
I,
don't
know
the
page
view
performance
can
have
up
to
was
it
12,
ish,
Fields,
so
effectively,
you've
got
like
event,
dot
repeated
multiple
times,
so
the
my
PR,
defining
the
shape
by
introducing
event.data
is
still
open.
H
I
do
plan
to
get
back
to
that
this
week.
Well,
I've
had
a
couple
of
things
get
in
the
way
of
that
to
try
and
get
that
through,
and
these
are
the
sorts
of
discussions
that
we'll
have
on
that.
Pr
is
why
not
you
know
why
Define
it
this
way,
but
really
it's
a
case
of
trying
to
Define
an
event
to
say
an
event
consists
of
domain
name
and
data.
So
therefore
any
back
end,
regardless
of
how
it
supports
it.
H
H
So
that
way,
what
any
event
we
Define
in
terms
of
open
Telemetry
is.
Is
that
way
in
any
user
event
they
can
go
into
find
their
own,
so
their
own
that
have
their
own
domains.
You
can
have
the
domain
of
your
AWS
or
Azure
or
Etc.
You
know
and
then
go
to
find
your
own
custom
events,
but
as
long
as
you
say
that
name
and
data,
and
then
data
is
just
effectively
the
list
of
attributes
which
will
be
defined
purely
by
that
domain
name.
H
Combination
back-end
can
handle
it,
let's
say
to
make
sure
back-ends
can
handle
at
the
moment
it's
going
through
logs.
So
it's
going
to
be
in
this
nested
structure.
Pro
TLP
in
a
binary
format,
will
look
better
than
this,
but
yeah
that.
H
D
H
So
we
haven't
had
that
discussion.
I
think
we've
alluded
to
it
a
few
times
now
spreadsheet
conversations
and
stuff
like
that,
because
I
know
internally
I
deal
with
a
lot
of
teams
that
have
a
lot
of
data,
a
lot
of
their
own
user-specific
data
and
yeah,
including
it
with
data
I.
You
know,
I
I,
don't
think
that's
the
right
place.
It
really
is
you
know,
user
data
or
app
data
or
custom
data
or
Properties,
or
you
know.
A
Something
because
my
yeah,
my
only
concern
with
this
is
that
we're
basically
saying
now
it
would
be
saying
that
there
should
not
be
any
other
attributes
top
level
than
than
just
the
ones
that
are
defining
semantic
conventions,
and-
and
at
that
point
like
it
almost
seems
like
we.
We
need
a
new
signal.
H
Automatic
inventions
have
a
couple
of
things
like
I,
think
Azure
AWS
have
a
prefix.
So
if
it's
prefixed
with
that,
then
that
is
defined
for
that
application.
So
effectively
we
yeah
we
can.
We
can
do
this
a
try
and
introduce
a
general
one
for
apps,
so
that
open
Telemetry
says
anything
prefects
with
this
prefix
X
is
purely
user,
slash
application
specific
or
we
can
say
we
want
to
introduce
an
event
user
data
or
whatever,
and
you
just
drop
it
in
there.
H
A
A
H
If
it
really
is
this
a
new
single
way
just
leveraging
logs
as
the
transport
yeah
yeah,
I
I,
you
know,
I,
don't
think
we
want
to
go
and
try
and
Define
an
event
transport
mechanism,
that's
just
a
waste
of
manpower
as
well
as
connections
and
resources,
and
all
the
rest
yeah
like.
Ideally,
it
would
be,
would
have
been
nice
to
be
able
to
do
this
as
a
as
a
trace.
Likewise,
it
would
be
nice
to
have
logs
go
down
as
a
Trace.
H
At
the
end
of
the
day,
everything
goes
down.
Everything
is
defined
by
the
otlp
protobus.
So
technically
you
could
have
the
same
thing,
but
they
are
actually
different
connections
today
and
when
we've
had.
The
argument
before
like
Santosh,
has
got
a
an
open
issue
or
it
was
open.
I,
don't
know
if
it's
still
open
about
defining
a
single
transport.
The
argument
comes
back
is
HTTP,
solves
this
by
effectively
reusing
the
same
connection,
so
rather
so
devices
don't
have
to
have
multiple
connections
out
the
door.
So
if
you
get
different
back
ends,.
H
If
we
had
a
signal
field
that
says
the
log
type
is
event,
then,
instead
of
saying
event,
name
event.name
event.domain,
we
could
just
say
name
domain
and
data
yeah
that
doesn't
exist
today,
which
is
why
we
have
event.name
event.domain
and
event.data.
H
I
Sending
yeah
because,
as
you
guys
are
saying
like
if
it
is
like
a
it's,
a
different
signal
or
a
signal
of
its
own,
it's
kind
of
redundant
to
to
have
to
add
a
bit
event
every
time,
yep
yeah
every
time
yeah.
So
maybe
in
that
case,
just
a
single
parameter
will
you
know,
show
the
back
end
that
it's
an
event
and-
and
maybe
there
doesn't
have
to
be
different
trees
of
attributes
to
to
know
that
if
you
will
so.
E
So
the
only
difference
you're
suggesting
is
to
drop.
You
know
this
prefix
right
but
keep
the
rest
of
the
structure.
D
E
A
Then
you
can't
really
separate
the
ones
that
are
in
the
schema
from
the
user
events,
if
you
had
them
or
at
the
top
level,
yeah
and
I
think
you
know
one
of
the
one
of
the
drivers
for
this.
If
I'm,
if
I'm
not
mistaken,
is
that
we
wanted
to
be
able
to
validate
the
you
know
like
the
the
actual
event
attributes
that
are
defined
by
the
schema
right
back.
H
E
So
it
goes
back
to
you
know
how
the
the
the
cloud
events
have
their
example.
Let
me
show
you
an
example.
E
So
so
they
have
a
top
level
attribute.
You
know
called
data
schema
I.
Think
it's
not
there.
In
this
example,.
G
E
H
Yeah,
so
I
would
really
really
like
to
do
that,
but,
okay,
so
here's
I'm
going
to
put
in
the
chat
my
event,
data
and
in
terms
of
in
the
description
I
actually
say
that
event.dating
is
the
cloud
events.
Data.
E
So
Ted,
you
might
also
be
wondering
why
you
know
we
are
bringing
in
Cloud
events
into
the
discussion
at
all.
There
is
no
strong
reason.
Only
thing
is
you
know.
Cloud
events
seems
to
be
like
standard
for
exchanging
events
going
forward.
It's
an
abstraction
and
you
know
one
description.
I
liked.
Is
you
know
these
these
three
statements?
If
you
read
quickly,
you
know
you
you.
Basically
you
pick
VMS
because
you
you
want
to
pick
Hardware
later.
E
You
pick
kubernetes
because
you
want
to
pick
the
provider
later.
Similarly,
you
pick
Cloud
events
because
you
want
to
pick
your
protocol
later.
So
a
cloud
events
enables
protocol
agnostic
event
representation
so
that
tomorrow
the
cloud
events
can
be
consumed
by
you
know
any
like
whether
it
be
Kafka,
IBM
mq.
You
know
anything.
You
know
you
can
easily
translate
across.
You
know
different
message:
Brokers
message
providers,
so
so
in
case
in
future,
our
events
need
to
be
consumed
by
the
different
messaging
providers.
E
Then
you
would
need
to
convert
our
events
into
Cloud
events.
So
to
facilitate
that
conversion,
you
know
we
are
considering
keeping
it
close
to
Cloud
events,
but
you
know
you
can
call
it
a
stretch
at
this
point
because
there's
nobody
asking
for
cloud
events,
compatibility-
and
that
is
perfectly
fine.
H
E
So
now
what
I'm
thinking
is
I
think
we
should
before
we
discuss
in
bits
and
pieces
I
think
it'll
be
good
to
complete
your
PR
with
more
information
yep,
make
it
a
complete.
H
Easy
to
contribute
yeah,
like
there's
already
a
lot
of
comments
on
there,
so
I
had
planned
on
getting
back
to
that
this
week,
the
sandboxes,
taking
a
little
bit
longer
because
of
tests
that
I
talked
about
yesterday
when
there
was
an
internal
issue
that
came
up
yesterday.
That
currently
got
my
attention.
That's
probably
going
to
take
today
as
well.
So,
okay.
G
Let
me
go
do
that
now,
so
we
can
just
put
together
well,
I
have
had
issues
with.
G
E
So
yeah
this
is
still
work
in
progress
and
you
know,
let's
see
what
the
log
Sig
folks
in
log
6
say:
I'll
I'm
going
to
talk
about
it
there
today.
H
Yeah
I
know
there
was
a
discussion
at
times
about
effectively
collapsing
event,
data
and
name
back
into
a
single
field
where
the
domain
was
prefixed.
I,
don't
remember
where
that
landed,
I
think
it
got
left
open.
As
part
of
we
went
down
the
path
of
splitting
up
the
log,
API
and
event
API,
so
I
don't
know
if
we
want
to
raise
that
again
as
well.
H
Because
the
combination
of
domain
in
name
is
really
just
so
we
have
a
definition,
so
we
could
do
the
same
thing
with
the
prefix
on
the
event
name
as
well,
which
brings
us
closer
to
I.
Think
it
says,
I
was
saying
about
having
a
single
field
like
if
there
was
a
log
type
field.
A
I
just
know
that
secret
has
been
is
like
against
thinking
of
events,
a
separate
signal,
like
he
already
thinks
of
them
as
the
same
I'm
curious.
What
he's
going
to
think
about.
H
Well,
he
does,
but
he
doesn't
that's
why
he
wanted
to
pull
out
the
event
API
yeah
but
yeah.
Let's,
let's
see
what
his
view
is
today.