►
From YouTube: Spec 3.0 meeting (May 11th, 2022)
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
Yeah,
like
the
only
problem,
is
that
we
probably
live
stream
now
with
thinking
out
loud
label.
B
A
A
E
There
must
be
a
better
way
to
do
this
right
or
maybe
not
yet,
but
there
should
be
a
better
way
to
do
this,
like
to
have
like
a
like
a
different
project
inside
restream
right
with
different
with
channels
where
you
want
to
publish,
and
so
I
can
customize
it
myself
without
altering
other
projects.
They
have.
They
have
something
like
projects,
but
they
don't
respect
the
destinations.
I
think
I
don't
know,
I
wonder
if
it's
a
back
on
there.
F
B
G
B
G
B
Actually,
these
two
again
is
more
or
less
in
the
same
scope
and
these
these
questions
kind
of
came
from
friends
thinking
out
loud
with
laurent,
I'm
probably
butchering
that
name
but
sorry.
B
One
of
one
of
the
the
things
they
discussed
was
it's
quite
unclear
what
exactly
the
scope
of
are
facing
apis,
in
the
sense
that
now
we
have
a
suggestion
about
changing
the
meanings
of
how
you
define
an
api.
E
Yeah,
so
it's
changing
from,
let's
say
pure
api
concept
to
behavior
like
what
is
it,
what
it's
doing?
What's
what
is
the
application
doing
so
yeah,
it's
still
an
api.
You
define
an
api
because
you
have
to
define
the
interface
where
you're
publishing
or
where
you're
subscribing
and
so
but
but
yeah.
It's
not
the
typical
api
point
of
view,
which
is
from
the
consumer
or
from
the
external.
As
you
said
right,
I
think
externally
defines
it
quite
well
external
to
the
application,
so
so
yeah.
B
E
E
So
it's
always
the
same
constraints,
always
the
same
assumptions.
So
this
is
clear:
there's
no
room
for
interpretation
like
in
the
case
of
facing
kpi,
so
so
yeah.
What
we
have
right
now
is
inherited
from
open
api.
We
knew
it
when
I
launched
it
version
two.
We
knew
it.
We
were
about
to
change
it,
but
we
didn't
in
the
end,
because
there
wasn't
any
agreement
on
what
to
do
and
if
I,
if
I
left
I
was,
I
was
like.
E
If
I
changed
it,
there
was
some
people
complaining
that
I
changed
it
and
and
if
I
don't
change
it,
there
were
some
other
people
complaining.
So
I
decided
to
leave
it
as
it
is,
as
it
was
in
version
one
like,
don't
touch
it
in
version
two,
because
it's
not
clear
yet,
but
I
release
version
2.
E
and
now
I
think,
we're
more
clear
what
we
want
to
do,
because
we
reorganize
the
whole
spec
to
accommodate
to
a
new
to
new
meanings.
Let's
say
to
new
semantics
and
I
think
now
it
makes
sense
to
define
behavior
because,
especially
because
we
also
defined
somewhere.
I
can't
remember
where,
but
we
have
to
probably
make
it
more
prominent
that.
E
E
E
So
so
people
don't
really
complain
a
lot
about
it,
but
but
yeah.
So
so
we.
What
we're
suggesting
in
version
three
is
that
we
create
one
definition
for
server
and
one
definition
for
the
client
in
this
case
is
the
kind
in
the
case
of
client
server
in
the
case
of
brokers.
So
then
you
define
one
satbag
file
per
application,
which
is
per
client
per
broker
client,
so
so
yeah.
E
So
that's
that
eliminates
the
problem
altogether,
because
the
problem
was
always
like
yeah
but
from
one
point
of
view
you
have
this
and
then,
from
the
other
point
of
view
you
have
that
okay,
so
that's
there's
only
one
point
of
view:
now
you
cannot.
E
G
E
But
it
moves
the
problem
to
the
user
a
little
bit
which
is
like
you
have
to
create
two
asynchrony
files,
one
for
the
server
and
one
for
the
client,
and
that
is
not
a
problem.
But
it's
yeah.
It's.
It's
always
cool
to
have
just
one
open
api
file
right
and
you
generate
the
server
and
the
client,
and
so
it
was
cool
to
have
one
async
paint
file
and
generate
the
server
and
the
client
as
well.
E
G
F
I
have
questions
about
that,
so
we
will
describe
the
client
by
the
publish
and
subscribe
send
the
names
yeah,
but
you
know
that
from
the
server
perspective,
so
then
the
send
and
receive
will
change.
That's
the
meaning
of
the
up
in
the
inside
operation.
E
F
E
It's
always
a
client,
I
mean
it's
always
yeah,
that's
what
we're
trying
to
avoid
not
having
clients
or
servers
or
anything.
So
we
eliminate
the
problem
of
the
perspective.
It's
just
an
application.
We
don't
care
what
the
application
is
doing.
If
it's
a
client,
if
it's
a
server,
it
can
be
a
mix.
If
you
think
about
it,
an
application
can
be
a
rest,
api
server
and
receiving
a
request
and
then
publishing
the
message
to
a
broker.
So
it's
a
it's
a
server
and
a
client
at
the
same
time.
E
It's
a
server,
it's
a
rest,
rest
server
or
http
server
and,
let's
say
not,
you
don't
publish
to
a
broker,
but
you
call
another
http
api
somewhere
when
you
receive
a
request,
you're
a
client
and
a
server.
At
the
same
time,
your
server
serv
your
server,
accepting
requests
but
you're
a
client
making
requests
to
other
servers.
E
E
E
That's
the
thing
for
for
simple
use
cases
like
creating
just
a
rest
api
or
just
a
broker
client,
or
something
like
that
that
works.
But
the
moment
you
have
something
that
is
not
simple,
but
it's
pretty
common
that
you
receive
a
request
and
then
publish
a
message
to
a
broker,
something
like
that.
Then
it
doesn't
work
anymore.
E
E
E
B
Does
hope
have
any
questions
regarding
this
perspective
or
change
of
perspective,
something
they
want
clarified
or
something
that
doesn't
make
sense
to
them
by
the
way
I
can't
see
chad
and
linkedin
twitter
such
I
don't
know.
If
you
can
look.
G
A
F
A
E
A
B
E
I
don't
know,
I
think
there
are
many.
There
are
many
as
you
call
like
ways
to
look
at
it
right.
So
when,
when
you
scope
something
you
can
scope
it
in
different
in
in
different
dimensions.
That's
what
I
was
trying
to
do
to
find.
E
So
what
you
can
do,
for
instance,
what
you
mentioned
like,
I
think
the
scope
for
reason,
kpi
right
now,
it's
pretty
clear!
It's
the
application
right!
This
is
for
a
single
application.
At
least
I
think
it's
defined
in
the
spec,
but
if
not,
we
should,
but
that's
only
for
the
application.
E
That's
why
you
have
the
id
field
on
the
root,
because
it's
the
application,
id
and
so
on
right,
because
you're,
defining
an
application
but
yeah
at
the
same
time
is
an
application
mixed
with
with
some
api
with
some
api
in
the
sense
of
interface
right.
So
so,
even
I
remember
a
guy
from
ing
bank
can't
remember
now
yeah,
so
he
he
he
was
mentioning
that
he
wanted
to
create
an
api
definition
with
async
api,
not
the
application,
so
he
wasn't
defining
the
application.
E
He
was
defining
an
api
and
then
his
application
will
implement
this
api.
This
interface
so
pretty
much
the
concept
of
interfaces
in
premium
languages
like
in
java
interfaces,
for
instance,
where
you
can
have
an
interface
and
then
you
have
a
class
implementing
an
interface
so
the
same
thing,
so
the
class
will
be
his
application
and
and
the
cpa
file
will
be
the
definition,
the
interface
definition
and
he
might
not
even
just
have
one
application
implementing
this
interface,
but
multiple
applications,
different
applications
of
different
origins
and
and
sources
to
implement
this.
E
This
api,
this
interface
or
even
more
implementing
multiple
interfaces
right,
multiple,
as
in
kpi
files.
So
that
is
an
interesting
concept,
but
the
reality
is
that
I
will
say
it's
too
granular
right,
it's
too
much
and
and
people
are,
I
will
say,
like
people
are
always
expecting
the
the
simple
the
simplest
solution
right.
I
said
I
want
to
create
my
api,
like
with
open
api
I
want,
or
with
the
graphql.
E
E
So
it's
just
the
interface
definition
and
yeah.
You
can
compose
your
your
application
of
multiple
inter
interface
definitions,
but
yeah,
I'm
not
saying
that
we
cannot
do
it
but
like
assuming
that
an
snkpi
file
or
an
opening
file
is
not
an
application.
It's
just
only
the
interface
definition.
E
It
can
be,
it
can
be
tricky
for
some
people,
because
some
people
are
not
so
well
versed
in
apis
and
they
only
just
want
to
generate
documentation
or
code
or
whatever
and
you're,
just
being
a
smart
smart
test
there
with
them
telling.
I
know
much
more
than
you
that
I
know
how
to
do
interfaces
and
all
this
stuff
and
how
to
split
all
this
in
in
different
concepts
and
and
in
the
meantime
the
developer
is
just
like
off
like
just
let
me
generate
the
talks
or
the
or
the
code.
E
Don't
bother
me
with
this.
I
have
an
application
and
I
want
to
define
it
so
so
yeah
or
I
have
a
whole
system
or
I
have
a
broker
with
a
lot
of
topics,
and
I
want
to
define
them.
So
don't
bother
me
about
this.
We
can,
of
course,
provide
mechanisms
for
people
who
want
to
to
do
this,
but
I
don't
think
it
should
be
the
default
to
be
honest.
So
anyway,
what
I
was.
E
E
Is
it
to
define
the
broker
or
what
or
is
it
to
define
just
the
interfaces
yeah
we
have
to
define.
We
have
to
define
it
what
it
is
about.
I
would
say
it's
for
an
application.
E
That's
what
it
is
you
might
like
it
or
not,
but
that's
what
it
is
or
that's
what
it's.
What
has
been
so
far
with
version
3,
I
introduced
a
new
thing
which
is
like:
if
you
don't
provide
operations,
then
it's
not
an
application.
It's
a
list
of
channels.
E
Maybe
it's
not
a
good
thing,
because
then
it
the
whole
document
mutates
the
meaning
just
because
it
has
or
doesn't
have
a
key.
I'm
not
happy
with
this
solution
as
well,
but
but
yeah.
I
think
it's
easy
like
you
just
don't
define
operations
and
and
then
it's
not
an
application
and
then
it's
a
something
else.
E
I
don't
know
kind
menu
menu
of
channels
and
if
it's
menu
of
channels
then
operations
field
is
not
allowed.
Then
you
have
like
different
specs
right.
You
can
separate
even
separate
them
in
different
specs
and
evolve
them
separately,
because
you
have
like
different
kind
of
documents,
not
just
one
asynchronous.
You
don't
have
an
asynchronous
argument.
E
You
have
different
types
of
documents,
then
it's
could
be
an
option
and
then
but
then
we'll
it
complicates
things
a
little
bit
because
then
on
tooling,
you
will
have
to
be
clear
that
it's
not
this
tool
doesn't
support.
This
support.
Sizing
kpi,
is
nothing.
It's
not
clear.
Enough
supports
is
in
kpi
what
the
applications,
the
menu
of
channels,
which
kind
of
documents
it
support,
all
of
them,
some
of
them.
You
know
what
I
mean
so
so
yeah
it
has
trade-offs
as
well.
E
So
maybe
a
way
to
do
it
is
that
we
keep
async
api
as
what
it
is
as
an
application
definition,
and
then
we
can
create
another
spec,
simply
respect
which
is
just
for
many
of
channels,
and
then
we
call
it
something
else
like
not
asking
kpi
at
all.
The
async
api
is
not
even
in
the
name
just
to
avoid
confusions,
and
then
it's
like.
I
don't
know.
E
We
have
the
async
api
spec,
we
have
the-
I
don't
know
channel
definition,
spec,
something
like
that
whatever
and
then
a
tool
can
just
support
channel
definition,
spec.
That
will
be
completely
fine
or
just
basic
api,
but
it
doesn't
support
the
channel
definition
spec
or
they
can
support
both.
E
That
also
eliminates
a
lot
of
a
lot
of
pressure
from
tooling
vendors,
because
I
don't
have
to
support
everything,
but
I'm
not
so
concerned
about
pulling
vendors
here.
I'm
more
concerned
about
the
user
and
for
the
user
can
be
a
little
bit
more
chaotic
that
there
are
different
kinds
of
documents
and
especially.
G
B
My
main
concern
is:
how
do
we
get
to
that
step
where
it's
well
defined,
because
if
lauren
is
saying,
if
we
take
that
question
off
like
have
it
questioning
what
exactly
async
api
is
because
I
think
we
heard
this
a
few
times
before
as
well,
that
that
either
the
scope
is
not
well
defined
or
well
written
down
in
a
way.
That's
what
can
you
say
like
that?
B
Yeah,
well,
they
expect
something
different
and
I
guess
we
I.
I
can
even
give
an
example,
for
example,
and
it's
not
to
to
say
anything
bad,
but,
for
example,
json
schema
is
being
used
for
code
generation.
Yeah
json
schema
is
not
for
code
generation
at
all.
You
shouldn't
even
be
doing
it,
but
the
problem
is,
you
can
do
it
in
a
shitty
way,
but
you
can
do
it.
B
Specification
when
it's
not
supposed
to
support
that
specific
use
case
yes,
and
that
creates
confusion,
a
lot
of
it
actually
yeah.
So
so
I
just
wanted
to
see,
if,
like,
how
can
we
be
more
structured
in
that
way
or
give
something?
That's
expected
like
what
you
can
expect
so.
E
They
just
wanted
to
appear
in
a
in
a
documentation
in
an
html
documentation
or
something
right,
because
they
just
want
to
see
the
documentation
there
and
the
application
is
called
the
broker
right.
So
so
it's
not
an
application.
It's
a
broker,
and
so
they're
hacking
as
an
kpi
to
to
make
it
work
with
their
own
purpose.
But
then,
when
they
have
to
generate
code,
it
suddenly
makes
no
sense
they
because
yeah
well.
First
of
all,
it
doesn't
make
sense
to
generate
code
for
a
list
of
channels
on
the
broker.
E
G
E
Because
there's
it
doesn't
make
sense
right
on
a
broken
level,
but
if
they
try
to
generate
code
from
this
document,
they
will
get
an
application
that
is
publishing
or
subscribing
to
something.
And
it's
like
what
the
this
is
not
what
I
expected
right
so
yeah.
So
that's
why
we're
providing
this
other
alternative
that
you
are
able
to
define
a
list
of
messages
without
any
operations
right,
we
still
have
to
figure
out
if
the
best
way
to
do
it
is
is
on
the
you
know
like
mutating
the
the
meaning
of
the
document.
E
Just
because
you
have
operations,
so
you
don't
have
operations
or,
like
I
said,
creating
a
separate
spec
with
another
name.
That
is
just
for
that
specific
use
case,
and
then
you
don't
use
async
api
you're
using
yada,
yada,
yada,
yeah,
so
async
device
just
for
the
application,
which
still
makes
sense
to
keep
it
for
this,
because
it
has
api
in
the
name
right.
E
It
will
still
be
a
specification
on
the
racing,
kpi
organization
and
so
on,
but
but
yeah
or
the
other
alternative
is
that
we
call
the
existing
so
the
application,
the
application,
the
specification,
that
is
to
define
an
application,
we
call
it
the
async
api
application
spec
and
the
other
one
is
the
async
api
broker
spec,
or
something
like
that.
Whatever
and
and
then
we
can
clearly
say
like
we
support
the
application.
This
tool
supports
application,
spec
or
this
tool
supports
only
the
brokers
back
or
both
or
whatever
right,
so
so
yeah.
How.
B
E
So
my
my
advice
is
that
you
I
mean
any
of
you
can
be
myself
as
well.
Take
a
decision
and
write
it
down
like
it's
a
this
is
my
pr
here
is.
E
I
took
the
decision
to
make
it
like
this,
and
this
is
when
you
scare
people,
and
then
people
start
complaining
and
then
you,
you
gather
the
responses
and
the
ideas
and
so
on
right
and
because,
if
you,
if
you're
trying
to
just
create
an
issue
and
wait
for
people
to
give
you
feedback,
people
will
not
give
you
feedback
most
of
most
of
the
times,
because
nothing
urgent.
But
if
there
is
fear
that
something
is
gonna
break
their
use
case,
and
it's
almost
there
almost
is
about
to
get
merged.
E
You're
going
to
get
a
comment
in
your
pull
request
instantly
right,
so
so
yeah.
So
that's
one
way
I
suggest
just
go
with
something
and
and
then
yeah
and
expect,
and
you
leave
it
there
for
a
while
to
receive
as
much
feedback
as
possible
and
and
that's
it
and.
B
E
Maybe
in
the
dogs,
something
like
that,
you
can
clearly
explain
this
but
or
a
non
non-normative.
I
think
it's
the
name
non-normative
section
of
the
spec,
which
is
like
documentation
inside
the
spec.
That
is
not
not
normative,
so
it
doesn't
define
any
rules
yeah.
But
it's
just
for
you
to
to
get
informed
that
about
something.
So
that
would
be
a
probably
good
use
case
on
how
not
to
use
a
spec
and
but
yeah.
I
think
that's
the
that's
the
role
of
documentation
right!
E
Yeah,
but
I
agree
that
some
people
might
skip
going
to
documentation
when
they're
reading
the
spec,
which
I
honestly
don't
think
so,
but
if
they're
reading
the
spec
they
will
they
will.
It
will
be
cool
if
they
find
some
references
like
how
not
to
use
it
and
then
just
a
link
to
to
the
documentation
right
or
maybe
in
the
readme
or
something
like
that.
E
Yeah
create
the
issue
like:
let's
follow
the
the
useful
process
create
the
user.
Leave
it
there
for
a
while
to
see.
If
we
get
feedback,
then
get
the
pull
request
for
a
while
to
get
feedback
and
so
on,
and
that's
it.
If
nobody
complains,
then
it's
either
they
don't
give
a
or
or
they
like
it.
So
in
any
case,
you
should
continue.
E
Right
or
they
are
they're,
not
even
they
don't
even
know
that
it
exists,
so
that's
also
but
yeah.
That's
why
we're
leaving
it
there
for
a
while,
and
we
will
put
it
on
twitter
and
I
can
talk
about
it
on
thinking
out
loud,
and
so
we
give
it
visibility.
I
mean,
I
think,
we're
doing
a
lot
of
effort
too,
for
people
to
understand
that
we're
doing
things,
and
we
cannot.
We
cannot
do
more.
I
think
as
much
as
we
can
at
least
exactly
we're
doing
talks
as
well
in
conferences,
so
I
mean
blog
posts.
B
F
B
B
I
made
a
suggestion
that,
or
let
me
clarify
in
the
bindings
repository.
We
currently
have
all
the
protocols
all
the
the
bindings
there,
but
we
also
have,
for
example,
no
maybe
take
one
that
has
kfk
that's
something
yeah,
something
that
has
json
schema
a
validation
rules
for
that
those
specific
bindings.
B
Currently,
these
are
not
exposed
in
any
way
other
than
here
on
github,
and
I,
as
far
as
I
know,
no
no
validation
tools
currently
use
them
to
validate
bindings.
So
bindings
is
it's
basically
an
extension
that
can
be
anything
you
want.
It
doesn't
validate
that
you
define
it
exactly
as
the
bindings
specify
now.
The
proposal
is
that
we
move
those
json
schema
files
to
the.
F
B
G
F
F
How
you
tell
where
you
want
to
have
that
extension
and
and
that's
it
as
I
remember
yeah,
so
it's
only
my
the
problem
so
yeah
I
mean
I
don't
have
the
problem
to
move
that,
but
yeah
we
should
discuss
how
we
want
to
make
the
validation.
Yes,
yeah.
B
F
Or
even
I
don't
know,
maybe
we
should.
You
know
something
like
that.
Someone
create
the
four
version
of
the
given
binding
yeah
for
the
given
essence,
api
version,
but
then
we
talked
okay,
but
we
have
the
new
ascent
api
version.
So
if
you
want
to
use
the
the
new
version
of
the
binding,
you
should
use
the
new
version
of
ascent
api
yeah.
So
this
is
the
so
it's
also
the
problem
for
me
how
to
handle
that.
F
E
Yeah
bindings
are
like
links,
you
know
like
links
to
another
spec,
another
yeah.
Another
thing
to
separate
spec
with
a
different
workflow
life
cycle,
so
so
putting
them
together
into
a
single
place
will
make
them
be
bound
to
each
other
and
very
complex.
It's
also
the
problem
so
yeah
and
what
what's
it
said
like?
E
Then,
if
you
want
to
use
a
previous
version
of
the
main
schema,
but
you
want
to
use
a
new
version
of
one
of
the
bindings
you
can't,
because
unless
you
maintain
files
for
all
the
versions
of
which
you
know.
E
F
A
It's
going
to
be
split,
so
that's
that's,
not
a
problem
yeah
and
the
problem
is
that
we,
like
the
bindings,
are
there
for
some
time
already
and
we're
like
we're
talking
about
this
perfect
world
of
having
it
separate,
separate
life,
life
timeline
of
development
etc,
but
like
if
we.
A
Them
in
and
integrate
with
references
and
bundle
together
like
in
the
end
json
schema.
It's
not
a
spec
right.
We
always
said
that
json
schema
is
just
a
tool,
so,
even
though
the
markdown
is
still
worked
on
separately,
so
I
don't,
for
example,
so,
for
example,
like
my
input
in
this
discussion,
is
that,
like
I've,
I,
for
example,
don't
see
a
problem
that
we
bundled
it
together
and
the
the
advantage
of
actually
starting
start
doing
it.
Try
to
bundle
it
together.
A
This
will
trigger
us
actually
do
something.
We
have
this
topic
and
in
action
of
doing
it,
we
actually
will
really
have
to
start
figuring
out
this
versioning.
How
that
should
work,
what
problems
we
have
like
really
identified
technical
problems
and
not
like
it
might
be
wrong
ma.
It
might
be
bad,
etc,
etc.
E
E
E
A
It's
all
like
again
like
I'm
so,
for
example,
if
you're
gonna
ask
me
some
like
if
you're
gonna
challenge
me
with
some
questions
like
what,
if
version
this
and
version
there
and
like
what
scenario
will
look
like,
I
don't
know,
but
what
I?
What
I
know
is
that
I
think
all
these
issues
like
again,
it's
just
my
imagination,
but
I
think
that
all
these
issues,
like
versioning
et
cetera,
all,
can
be
solved
with
references
proper,
bundling
script
and
and
proper
release
process
and
yeah.
F
F
B
E
E
I
don't
think
it's
allowed
by
the
by
the
spec.
Let
me
check,
but
the
specs
will
not
allow
custom
bindings
if
I'm
not
mistaken,.
E
That's
something
that's
an
experiment
that
is
enough,
there's
nothing
defined.
Yet
that
was
just
an
experiment,
so
that
is
not
so.
For
instance,
you
cannot
put
your
magic
binding
right,
that's
you
can
use
x,
dash
magic,
but
not
magic
inside
bindings.
You
cannot
use
custom
words
there
and
that
that
was
done
on
purpose.
Just
so,
people
don't
start
creating
their
own
bindings
that
we
will
release
in
the
future
and
then
they
don't
match
and
then
it's
a
it's
a
mess.
E
E
B
A
C
C
A
This
the
topic
will
jump
pop
up
jump
in
jump
out
and
pop
out.
I
pop
up,
I
think,
is
the
proper
word
and
we'll
pop
up
again
in
few
weeks,
because
if
one
of
the
ideas
that
I
submitted
for
asking
api
mentorship
is
actually
do
the
same
mvp
approach
with
extensions
like
again,
don't
think
only
about
this.
Like
long
term
perfect
plan,
we
have
some
plugins
whatever
no
just
take
those
extensions.
E
A
F
It's
my
last
item
when
I
worked
with
sergio
on
the
next
parcel.js
version.
F
F
Yes,
so
yeah,
and
by
this,
when
I
create
a
lot
of
methods,
I
see
why
why
on
channel,
I
can
only
define
the
descriptions
in
servers,
also
descriptions.
But
the
message
I
have
the
summary,
but
it
can
be
the
description.
Also
here
the
name.
The
name
is
exactly
for
the
code
generation,
yes,
that
you
can
generate
the
class
name,
for
example,
and,
for
example,
it
attacks
to
categorize
some.
You
know
elements
some
messages
and
operations,
but
you
cannot,
for
example,
attach
the
tags
to
their
channels
and
servers
at
the
moment.
F
Maybe
by
this
we
can
you
know
we
can
support
something
like
that
grouping
of
servers.
Yes,
that
one
times
are
here,
he'll
create
the
issue
for
that.
So
by
this
I
propose
to
the
next
version
of
essence
api
to
have
something
like
the
info
item
object
like
we
have
in
in
the
essence
api
in
the
root,
but
only
in
the
element
and,
as
you
can
see,
when
you
leona's
app
sorry
yeah
yeah
and
it's
exactly
the
shape
of
the
the
given
object.
F
F
So
so
what
do
you
think
about
that?
I
mean
it
probably
will
be
the
benefits
of
that
it's
easier
handling
in
the
tooling,
like
the
parser
js,
to
create
the
models
and
exactly
the
people
know
that.
Okay,
I
have
the
the
channel
servers
messages
operations,
so
I
know
the
shape
of
metadata.
At
the
moment.
I
always
have
looked
to
the
specification.
Okay
in
the
message,
I
can
define
the
summary
yes
or
the
name,
but
in
the
channel
servers
I
cannot
so
so.
F
Nope,
it's
only
for
the
element.
It's
only
for
the
you
know
this
for
for
element,
server,
channel
operation
to
the
message,
and
maybe
also
in
the
schema,
but
it's
I
don't
want
to
discuss
at
the
moment.
F
E
Have
I
have
two
concerns
with
this,
so
one
is
for
tooling
it
will
be
cool
because
yeah,
that
is
it's
clear,
but
for
the
user.
Look
at
the
examples,
it's
one
more
level
of
indentation,
so
it's
not
really
friendly
because
already
indented,
because
the
document
is
already
you
probably
adding
this
information
in
a
already
indented
place.
It
gets
out
of
hands,
but
so
my
question
here
will
be:
does
it
really
need
to
be
inside
the
inside
and
info
object
like
can?
E
Can
it,
for
instance,
can't
we
just
unify
all
of
this,
like
server
will
will
have
id
title
summary
description,
tags
and
external
dots,
and
that
will
be
the
same
for
all
the
the
objects.
I.
F
E
Is
that
when
you
put
the
info
there,
then
you
could
to
me
it
causes
confusion
and
actually
jonas
asked
about
it
and
does
it
have
to
does
it
have
something
to
do
with
the
info
root
info
object?
And
you
say
no,
it's
different.
So
one
more.
E
So
I
think
what
you
have,
what
you're
trying
to
achieve
here
is
for
for
the
benefit
of
the
tooling
of
the
tooling
implementation,
not
for
the
benefit
of
the
user,
and
my
suggestion
is
that
you
don't
create
an
object,
but
you
create
an
interface.
E
So
your
objects
will
implement
this
interface
and
you
can
still
extract
it
as
a
separate
interface
definition
right.
So
server
channel
message
and
whatever
is
going
to
be
included.
Can
you
can
just
say
in
the
code
implements
info
item
whatever.
E
Way
it
can
still
remain
on
the
on
the
at
the
same
level
as
the
other
thing.
So
you
don't
you
don't
force
people
to
have
one
more
object,
because
it's
in
yaml
that's
a
problem
because
it's
it
gets
crazy.
I
think
it's
crazy
how
much
you
have
to
invent
sometimes
yeah,
but.
E
D
F
E
It's
a
it's
a
preference
to
me
like
less
in
the
title,
the
less
we
indent,
the
less
we
indented
to
the
right
right,
the
the
less
confusing
it
will
be
to
read
the
document
right,
at
least
for
me,
but
that's
a
preference.
F
A
Anything
else
additional
properties
yeah,
so
the
info
for
others,
so
the
the
context.
So
in
the
past,
when
we
worked
at
sap
with
mate,
we
were
working
on
like
in
kubernetes.
There
was
this
concept
of
service
catalog,
where
you
could
just
register
that
you
have
access
to
a
number
of
applications
and
they
were
all
specified
with
the
same
schema.
A
So
people
could
easily
like
subscribe
to
a
given
application,
get
access
whatever
whatever,
and
there
was
this
concept
of
metadata,
where
something
that
we
don't
have
this
at
using
api
at
all.
So
it
was
like
you
have
some
fixed
fields,
but
you
can
also
have
how
they
called
it.
Custom.
A
They
called
it
instead
of
like
they
called
it,
recom,
not
recommendation.
A
How
do
you
say
it
in
english
that
it's
not
recommended,
but
it's
convention,
oh
yeah,
so
you
had
some
fixed
fields
that
are
required,
but
it
was
object
that
was
was
opened,
so
you
could
add
additional
new
fields
and
not
an
extension
but
like
fields
without
the
x
dash,
but
but
you
also
had
a
suggested
convention
like
best
practices,
that
you
know
that
people
use
like
documentation,
let's
say
property
or
whatever,
and
that
was
the
approach
and
they
everything
and
it
was
always
called
metadata.
That's
why
I
came
in
came
up.
E
E
But
if
it's
metadata
then
I
think
it
can
be
inside
yeah
the
object,
because
it's
or
meta
information
or
metadata
whatever
you
want,
then
it's
information
or
data
about
yourself,
then
id
makes
sense
to
be
there.
So
just
that,
like
I
was
going
to
mention
this-
that
if
it's,
if
it's
going
to
be
called
information
info
information
id
seems
to
be
off
to
me,
like
it's,
not
really
information
for
you
yeah,
as
the
user
yeah
like,
for
instance,
I
don't
know,
say
yeah.
I
understand.
E
Message
payload
right,
so
payload
is
also
information
about
the
message.
If
you
think
about
it,
why
is
it
not
inside
the
message?
The
the
info
object
right
so
where,
where
do
you
draw
the
line
to
what
is
what
what
should
be
included
inside
info
and
what
so
so
not
also
payload
is
also
probably
well.
No,
I
was
going
to
say
it's
also
metadata,
but
it's
not
it's
it's
not
it's.
E
E
Have
you
made
sure
that
have
you
made
sure
that
it
makes
sense
there
like,
for
instance,
channel
I'm
saying
that
you
have
channel
inside
channels?
You
will
have
id.
E
F
At
the
moment
here
at
the
moment
we
have
the
operation
id
and
message
id
yeah,
so
the
metadata.
F
And
also
the
server-
and
you
know
from
my
perspective,
it
can
be.
To
be
honest,
I
don't
know
how
to
use
that
in
some
context,
I
I
mean,
maybe
in
some
generation
and
we're
forcing
them
too
much.
Maybe
I.
E
It's
not
going
to
use
it
anyway,
like
say,
for
instance,
channel
right.
I
have
a
channel
and
I
my
channel
is
user,
slash,
signup
and
then
inside
I
have
metadata
or
info
or
whatever
id
id.
What
id
is
already
there
is,
which
is
the
the
the
name
of
the
the
address
exactly
here
yeah
there
is
exactly
the
address
or
and
if
it's
something
different,
then
why
is
it
different
or
in
the
new
spec
right
in
version?
E
F
Mean
the
id
it
can
be
the
different
way
I
mean
by
by
this.
I
have
the
problem,
yes
with
the
server
id
and
the
channel
id,
but
you
know
I
don't
want
to
split
or
tell
in
specification
that,
okay
for
the
message
and
operation
you
have
the
id,
but
for
the
server
and
channel
you
cannot
use
the
the
info.id
or
metadata
id.
E
It's
because
it
makes
sense
that
it
so
they
shouldn't
be
there.
I
don't
know
I
mean
I'm
just
challenging
you
with
this,
because
I
have
the
feeling
that
that
that
is
cool,
but
it
is
like
a
to
me.
It
looks
like
a
kind
of
generalization
right
like
broad
generalization
of
of
what
it
is.
Then,
if
tomorrow
we
want
to
add
something
to
this,
this
new
object.
E
So
it
is
like
you
suddenly
you're
more
limited,
and
I
want
to
understand
why
you
want
to
put
it
there,
because,
if
it's
because
of
the
code,
if
it's
because
of
tooling
and
so
on,
then
you
can
implement
interfaces
like
I
said
and
then
and
you
leave
things
as
they
are
and
some
let's
say
some
objects
might
implement
the
id
interface,
the
info
interface,
which
will
include
name
title
somewhere
in
the
description,
the
tagging
interface,
which
will
also
include
tags,
but
you
can
make
an
object,
implement
three
interfaces.
For
instance,.
B
E
But
they
can
all
be
outside
the
info
object
right
and-
and
this
way
so
it's
a
little
bit
more
flexible,
because
in
some
places
the
id
might
make
sense
and
some
others
will
not
in
some
other
it
might
make
sense
to
have
name
and
title
and
and
some
others
like
for
instance
name.
E
Does
it
make
sense
to
have
name
if
you
already
have
an
id,
because
an
id
is
a
machine
friendly,
but
sorry,
a
a
name
is
a
machine
friendly
name,
but
an
id
is
also
a
machine
friendly
name,
if
you
think
about
it,
so
it
so.
This
is
something
that
was
created
for
messages
to
uniquely
identify
messages,
because
it
was
a
problem
there.
F
F
F
E
That's
my
point,
so
it
was
introduced
because,
because
messages
didn't
have
a
way
to
uniquely
identify
themselves
right,
we
didn't
have
message
id
so
name
was
for
that
for
uniquely
identified
not
uniquely
identified,
but
to
identify
them
in
a
machine,
readable
format
so
that
you
could
generate
code.
That
was
because
that
was
the
reason
it
was
introduced,
but
might
not
make
sense
to
have
a
channel
name.
E
That's
that's
what
I'm
saying
right
or
might
not
make
sense
to
have
a
server
name
or
because
you
already
have
a
server
id,
and
if
you
want
something
more
human-friendly,
then
you
have
server
title.
You
know
what
I
mean.
E
E
Like
metadata
is
an
open
box
there,
you
can
put
whatever
you
want
and
we
only
have
like
conventions
in
our
tools.
Yeah,
absolutely
yeah,
that's
one
way,
so
you
can
also.
Then
you
can
have
conventions
like
there
are.
There
are
ids
or
titles
in
in
servers,
but
not
in
channels
or
the
other
way
around.
So
so
yeah
yeah.
B
B
B
F
F
F
B
Is
another
indentation
which
is
another
feature
for
the
specification
like
this
can
still
be
done,
and
then
you
just
have
channels
info
item
objects.
Channels.
Info
item
object
like
you
can
still
do
it
that
specific
feature,
but
you're
suggesting
a
lot
of
changes
in
one
specific
pr,
that's
hard
to
grasp
exactly
like,
as
friends
said,
I
have
no
idea
what
id
means
in
channels
does
it
all
right
path?
B
E
E
A
E
F
F
F
B
A
Yeah
yeah,
I
mean,
but
it's
just
something
that
popped
up
on
the
meeting,
but
I
guess
that
if
you,
if
just
think
about
providing
a
full
example
like
full
asking
api
example
with
intent,
so
we
see
how
they
look
like
and
then
it's
gonna
force
you
to
actually
think
about
like
channel
id
server
id.
It's
going
to
force
you
to
think
about
these
things
and
in
two
weeks
we're
going
to
see.
Maybe
you
will
just
close
the
issue.