►
From YouTube: Spec 3.0 Meeting
Description
C
Yeah,
that's
true
no,
but
he
said
he
couldn't
make
it,
but
we
offered
to
just
take
a
poke
at
it
and
start
the
discussion
and
then
bring
it
up
again.
Next,
okay,
on
the
next
meeting,
yeah
all
depending
on
how
it
goes,
I
guess
but
yeah
welcome
everyone
for
another
spec
3.0
meeting
before
getting
started.
Does
anyone
of
you
want
to
say
hi
introduce
yourself
before
we
jump
into
the
agenda.
D
I
would
say
hi,
but
I
don't
have
my
headsets,
so
I'm
I'm
in
I'm
staying
in
a
public
place.
So
I'm
just
listening
to
you
guys
thanks.
C
A
C
The
problem
is
that
when
we
do
reusability
of
these
schemas,
it's
not
possible
to
define
what
the
schema.
C
What
the
schema
format
is
outside
of
the
message
object.
So
this
means
that
you
cannot
within
the
components
where
you
define
your
custom,
schema
with.
Whatever
format
you
choose
to
define
it
with
it's
not
possible
to
define
it
with
it's
currently
not
possible
to
define
it
with
anything
other
than
the
async
api
schema
object,
so
you
cannot
define
it
with
avro.
You
cannot
define
it
with
json
schema
drive,
whatever
we
have
or
any
other
types,
and
the
reason
is
that
the
schema
itself
cannot
define
this
schema
format
property.
C
C
What
this
introduces
is
the
ability
to
reuse
different
schema
formats
within
one
async
api
file,
because
now
you
can
reference
this
specific
schema
and
it
already
knows
what
exactly
the
schema
format
is.
So
this
means
you
can
have
avro
defined
within
components.
You
can
have
all
of
the
other
possibilities.
C
Now
I
haven't
read
his
proposal
in
full
to
be
able
to
explain
the
knitty
details
of
all
of
the
different
all
of
the
different
perspectives.
C
A
C
A
C
Let
me
paste
the
issue
or
the
pull
request
as
well,
so
you
can
follow
along
all
right,
so
I
posted
it
on
youtube
as
well
all
right.
So
he
introduces
this
new
keyword,
a
custom
schema
and
which
should
belong
to
the
schema
object
and
described
by
the
custom.
Schema
object,
not
sure
what
that
is.
Okay,.
C
C
Instead
of
removing
it,
I
guess
entirely,
which
I'm
not
so
sure
it
makes
sense.
But
all
right
this
puzzle
was
alongside
custom.
A
C
A
It
says
it's
deprecated,
but
this
is
targeting
version
three
right,
so
we
should
probably
just
completely
remove
it.
You
know
like
instead
of
deprecating
it.
That
makes
more
sense.
To
me
I
mean,
since
it's
a
major
version
bump
right.
C
A
A
So
that
is
so.
I
think
it's
unnecessary
to
repeat
the
word
schema
and
also
not
just
for
schema
format,
but
for
schema
definition
right
and
that's
why
I
think
it
was
from
another
call
that
we
came
up
with
this,
or
maybe
it
was
a
one-on-one
with
him.
I
can't
remember,
but
that
we
talk
about
it
about
having
you
know,
like
format
and
the
definition
of
the
schema.
A
C
A
I
wonder,
though,
one
thing
just
to
I
want
to
mention
that
it
says
definition
and
I
am,
for
instance,
with
async
api
schema
object
and
with
json
schema,
which
is
almost
essentially
the
same.
A
C
You
think
it's
confusing
when
it
is
a
json
schema,
that's
being
if
the
format
is
json
schema,
then
the
definition
keyword
doesn't
make
much
sense.
C
A
C
A
It's
a
definition,
so
that
is
correct
but
yeah.
Maybe
it
can
be
misleading.
That
is
the
definition.
People
can
think
that
this
is
the
definition
of
the
data,
but
it
is
not
the
definition
of
the
data.
It
is
the
definition
of
which
I
yeah
never
mind.
I
think
we
we
should
work
on
this
at
some
point
like
we
should
just
like
get
rid
of
this
and
maybe
create
a
vocabulary
for
code
generation.
Something
like
that
and
that's
the
that's
the
vocabulary
we
will
use
for
code
generation
and
that's
it
and
yeah.
A
C
A
Yeah
the
concept
itself
like
I
may
have
a
bunch
of
validation
rules
that
says
nothing
about
the
type
right.
Yes,
so
yeah.
So
what
about
the
yeah?
The
structure
like
I
may
want
to
validate
that
something
is
a
number
but
it
doesn't
say
which
kind
of
number,
if
it's
just
if
it's
an
integer,
a
double
of
load
or
or
what
right
or
or
a
bigger
one
right.
So
I
don't
know
so
so
yeah
anyway,
not
not
for
this
issue,
so
yeah.
C
C
I
think
this
is
the
custom.
Schema
object,
custom
schema,
so
I
think
he
wants
to
wrap
the,
or
at
least
the
proposal
is,
but
I
don't
see
why
it
can't
be
a
part
of
like
within
this
object
right
here.
So
basically
just
moving
those
into
this
right.
E
C
All
right,
so,
let's
see
what
else
there
is
model
using
nested
custom,
schemas,
okay,
so.
C
A
Not
sure
I
like
this,
I
think
this
is
gonna,
add
a
huge
complexity
to
the
schema
land
that
it's
probably
unnecessary.
So.
A
And
it's
interesting
yeah
yeah,
but
but
I
have
to
feel
it
that
this
is
gonna
add
not
the
feeling.
This
is
for
sure,
gonna
add
a
lot
of
complexity
to
all
the
schema
stuff
right,
so
so,
building
tooling
around
it
will
be
super
complicated
super
complex
because
you
can
expect
any
kind
of
schema
in
any
of
the
child
properties.
A
C
I
think,
as
soon
as
you
start
defining
something
within
a
specific
format,
it
doesn't
make
sense
to
mix
it
with
other
formats.
Yes,.
A
A
A
I
think
I've
never
found
this
case
to
be
honest,
like
I,
I've
always
seen
people
using
avro
or
jason
schema
or
protobuf,
but
never
they
never
told
me.
I
want
to
mix
them
all
right,
so
so
yeah.
So
I
think
it
it's
funny.
It's
it's
interesting
from
my
engineering
point
of
view,
but
is
it
solving
a
real
problem.
B
A
C
C
Is
but
I
think
he
has
and
okay,
he
doesn't
never
mind.
I
might
have
been
jumping
the
conclusion.
No,
it
was
because
he
has
some
protobuf
examples
in
his
issue,
where
I
I
had
a
feeling
that
he
wanted
to
introduce
it.
So
you
can
reference
non-json
and
yaml
files,
so
you
can
externally
reference
a
protocol
file,
for
example,
if.
A
That,
if
that's
the
case,
I
already
explored
this
alternative.
There
is
an
issue.
I
think
that
it
still
it's
already
closed,
but
it's
there
I'll
try
to
find
it,
and
there
is
a
problem
with
the
json
pointer.
You
know
like
the
json
pointer
is
the
last
part
that
you
added
at
the
end
of
the
url
on
dollar
ref.
A
You
know,
like
the
hashtags
last
components,
blah
blah
blah
this
this
syntax
is.
This
is
json
pointer,
syntax.
This
is
there's
another
rfc
for
this,
so
it's
a
it's
a
standard
and
and
that
it's
meant
to
work
only
with
jason.
A
I
can
imagine
you
could
yeah
yeah
it's
a
hack,
it's
not
meant
to
be
for
for
non-json
formats
right
and
yaml.
It
works
with
yaml,
because
yaml
is,
you
know,
translatable
to
json
at
least
the
subset
of
yaml
that
we
accept,
because
we
don't
accept
fully
ml
right,
so
so
yeah.
So,
that's
why
we
accept
to
point
to
yaml
because
yeah
it's
json
in
another
format,
so
in
another
language,
yeah
but
yeah.
A
I
wouldn't
go
that
far:
introducing
a
replacement
for
dollar
ref
or
something
like
that
at
least
not
in
the
same
usual
pr,
because
that's
a
lot.
C
That's
that
is,
that
is
his
proposal,
so
I
guess
we
already
discussed
it
as
we
as
we
went
so
does
anyone
else
have
any
questions
any
anything
they
want
to
add
to
the
discussion.
E
A
C
A
Whatever
2.8
2.10
whatever,
then
we
can
still
release
one
more
two
point,
something
with
deprecations.
If
that
makes
sense,
I
don't
know.
C
E
A
C
A
Not
sure
that's
possible,
because
we
will
have
format
and
definition,
keywords
and
those
format
and
definition
keywords
will
be
part
of
json
schema
object
that
you're
trying
to
define
that's
a
problem
because
json
schema
is
not
strict
about
these
things
like
you
can
use
whatever
keyword
you
want,
it
doesn't
have
any
meaning,
but
you
can
use
whatever
you
want
there.
A
A
A
No
because
that
that
would
be
that
that
would
be
what
we
were
complaining
before
that
then
even
some
properties
could
just
have
their
own
custom
schema
format,
because
yeah,
no,
no,
no,
no,
okay,
never
mind
too
complicated
for
for
nothing
nobody's
asking
for
it,
so
so
yeah.
Let's
do
it.
C
C
This
one
is
to
be
determined
based
on
so
for
3.0.
It
doesn't
make
sense
to
duplicate
it,
it
should
just
be
removed,
but
we
can
look
into
whether
it
makes
sense
to
deprecate
it
for
two
point.
Whatever
version
we
are
at,
whenever
we
release
version
3.
C
C
I
don't
think
I
have
anything
for
the
agenda
as
well.
None
of
those
things
does
anyone
else
have
anything
they
want
to
introduce
or
ask,
or.
A
Sorry,
I
can't
multitask
with
this.
It's
too
much
I'm
trying
to.
A
A
A
Schema
format
on
v2
and
something
once
we
have,
I
don't
know
once
we
have
three
and
zero
out
or
or
about
two
now,
once
we
have
three
zero
out
once
we
have
the
real
alternative.
Otherwise,
so
that's
a
consider.
The
freaking
schema
format
and
why
is
schema
as
a
custom
schema?
A
Neither
and
there's
something
else.
There's
a
schema
format
and
you
know
like
being
able
to
mix
and
match
different.
A
A
A
Okay,
so
yes
sure
let
me
share
my
screen,
I
guess
I
will
be
able
to
share
my
screen.
A
Okay,
okay,
cool,
so,
as
you
can
all
see,
I'm
just
playing
around
this.
This
files,
don't
even
have
a
name
yet
because
I'm
just
playing
around
with
an
idea,
and
just
before
I
continue
developing
the
idea.
I
wanted
to
know
what
you
think
so,
on
version
three,
so
I've
been
I've
been
playing
with
the
idea
that
I'm
already
changing
version
three
right.
So
so
I'm
seeing
where
version
three
is
going,
and
I
was
like
wait.
Maybe
we
can
still
improve
it
before
we
get
to
create
a
pull
request.
A
So
when
you
see
remains
the
same
is
remains
the
same
as
we've
suggested
so
far,
not
that
it
remains
the
same
as
v2,
so
so
yeah.
So
what
I'm
doing
here
is
I'm
introducing
the
concept
of
a
new
concept
here
which
is
domains
I'll
talk
about
later.
Let
me
just
focus
on
something
that
I
think
it's
more
interesting
for
now,
so
I'm
changing
the
way
servers
are
defined
and
there
should
be
the
possibility
to
do
something
like
this
and
then
I
don't
know
I
installed.
A
I
installed
github
compilot
and
it's
bothering
me
damn
it.
I'm
just
gonna
get
used
to
this.
That's
so
so
yeah,
let's
say:
let's
see,
let's
say
that
we
do
something
like
this.
I
don't
know
damn
it.
A
Then
compile
it,
so
we
should
be
able
to
have
something
like
this,
that
we
we
define,
servers
two
different
kinds
of
servers:
okay,
if
we
don't
use
this
syntax
and
we
use
some
other
kind
of
syntax.
What
I'm
not
worried
here
is
about.
The
syntax
is
about
the
concept
itself,
so
this
concept
is
not
new
we're.
A
We
already
talked
about
it
like
we
should
have
local
servers
and
remote
servers,
so
remote
servers,
usually
being
brokers
or
other
apis
that
we
might
call
right
so
so
yeah
and
local
servers
is
usually
an
http
or
a
websocket
server.
Not
usually
it
cannot
be
other
thing
as
far
as
I
know,
so
it's
an
http
or
a
websocket
server
that
my
application
is
is
exposing.
So
I
my
application
is
a
server
right.
So
so
that's
why
I'm
calling
it
I'm
calling
it
local.
A
Nevermind,
we
can
call
it
whatever
you
want,
but
yeah
local
as
interfaces
server
interfaces
that
my
application
is
exposing
right.
So
so
say
seeing
this
let's
say
we
we
can
fairly
say
that
local
servers
can
only
be
http
and
web
circuit.
A
So
there
is.
There
is
a
a
cool
thing
about
it
and
it's
like.
If
it's
a
http
server
or
websocket
server,
then
it
means
that
the
server
definition
can
be
exactly
the
same
as
an
open
api
server,
except
for
the
support
of
websocket
and
bindings,
of
course,
because
they
don't
support
web
sockets
or
bindings.
That's
something
from
from
async
api.
But
well.
That
is
something
that
we
can.
A
We
can
push
on
open
api,
so
they
support
web
sockets
and
then
it's
just
a
little
bit
a
little
bit
easier
right
and
and
then
or
at
some
point
we
can
just
or
what
we
can
do
is
that
we
support
open
api
server
definitions
on
async
api
because
they
will
be
a
subset
of
our
server
definition.
Local
server
definition
right,
so
so
they
will
be
compatible,
and
so
that
is
that
is
one
thing
and.
A
Yeah,
so
why?
Why
am
I
splitting
this
into
two
kind
of
things
like
local
and
remote
and
domains?
So
when
I
did
this,
I
was
thinking
more
about
who's,
the
owner
of
things
right
who's,
the
owner
of
the
server
right.
So,
if
I'm,
if
I'm
having
here,
let's
not
call
it
production
but
call
it
my
websocket
api
server
right,
this
is,
is
a
the
the
owner
of
this
server
is
my
application.
A
This
application
is
the
owner
of
the
server
actually
calling
it
like
my
websocket
api,
because
it's
a
traditional
api,
but
just
using
web
sockets
instead
of
http,
but
it's
a
client
server
model.
So-
and
I
am
the
server
here
so
this
application
is
a
server,
so
this
is
my
server.
This
is
me
this
is
on
by
me
right
cool.
So
then
mosquito,
for
instance,
which
is
a
broker
right
or
kafka
here
or
whatever
you
want
to
to
use.
Am
I
the
owner
of
this?
A
No,
the
application
is
not
the
owner
of
the
of
the
broker.
The
application
is
just
connecting
to
the
broker,
but
the
owner
of
the
broker
is
a
company,
a
division
of
the
company,
maybe
yeah.
We
don't
know
for
sure
it's
not
the
the
application.
The
application
is
not
the
owner
of
a
broker
of
a
remote
server
right.
A
So
that's
why
I
was
concerned
that
maybe
we
shouldn't
be
defining
these
things
here,
right
and
and
going
a
little
bit
forward
so
channels
same
concept
like
should
we
be
able
to
define
channels
that
our
application
is
not
exposing,
because,
like
I'm
saying
here,
these
channels
are
now
only
the
channels
exposed
by
these
applications,
so
web
socket
channels,
socket.io
channels
or
even
rooms
or
whatever
you
want
to
call
them
or
workspaces
as
well
or
http,
servers
and
events.
A
But
you
know
like
I
am
the
server
I'm
exposing
these
communication
channels,
and
I
am
the
owner
of
these
things.
So
this
is
my
application
definition.
I'm
gonna
define
the
channels
that
I'm
exposing
myself
and
that's
why
they
are
defined
here
in
this
file,
because
I
am
the
owner
right,
so
so
yeah.
That
is
one
of
the
the
thoughts
so
that's
it.
Then
I
had
to
introduce
something
here
which
is
like
what
I
call
domain
right
and
and
domains
are,
for.
A
You
know
like
global
assets
or
for
if
you're
doing,
domain
driven
designs.
This
is
your
domain
stuff
right
your
domain
assets
except
the
applications.
You
know
like
messages,
channels
servers,
meaning
probably
brokers
right
in
this
case,
so
so
yeah.
I
decided
that
maybe
it's
a
good
time
that
we
split
these
two
definitions
in
two
different
specs
right,
because
yeah,
let
me
go
back
one
more
time
here
to
the
application
definition
in
version
three,
as
I
proposed
in
my
solve,
publish,
subscribe,
confusion
and
so
on
and
so
on.
A
A
Well,
that
kind
of
polyform.
How
you
call
this
poly
polymorphism
polymorphism.
A
Feels
really
weird
to
me
like
an
and
an
async
api
file,
depending
on
this
apparently
innocent
keyword
here,
operations
might
mean
a
thing
or
might
mean
another
thing:
the
whole
file
right,
so
I
was
like
I'm
not
sure
like
this
will
be
going
this
way,
it's
a
little
bit
weird,
because
this
is
this
is
the
application
definition
and
and
if
we
remove
the
operations,
is
a
menu
of
all
the
things
in
the
in
the
organization
or
in
a
specific
domain.
A
A
So
it's
it's
that
menu
right.
It's
that
what
we
used
to
call
menu
of
of
channels
and
brokers
and
all
the
stuff.
So
here
I'm
introducing
the
concept
of
brokers,
servers
channels
right
everything
except
operations,
so
you
cannot
have
operations
in
a
in
an
async
api
domain
file
because
and
they
think
it
because
it's
defining
it's
not
defining
an
application.
E
C
A
That's
okay!
It's
a
lot
of
change,
but
yeah
yeah.
It's
a
lot
of
change.
It's
a
whole
new
spec
by
the
way.
So
actually
this
is
a
new
spec.
It's
based
on
the
other
specs,
but
but
yeah,
so
so
yeah.
So,
as
you
can
see,
brokers
here
can
now
be
called
brokers.
We
don't
have
to
call
them
servers
anymore,
so
and
they
can
have
the
form.
The
async
api
server
format,
which
is
url
protocol
protocol
version,
blah
blah
blah
all
this
stuff
right
and
servers
are,
can
only
be
http
or
websocket
servers.
A
So
there's
no
way
that
you
have
something
here
that
is
not
http
or
websocket.
We
can
even
just
allow
having
url
now
protocol
or
protocol
version.
A
Maybe
protocol
version
is
fine,
but
no
protocol
and
the
protocol
is
here
in
the
url
and
we
can
restrict
by
the
beginning
of
this
right,
like
you
can
only
start
with
http,
https,
ws
or
wss
right,
so
so
making
things
a
little
bit
more
compatible
with
with
open
api.
In
this
case,
and
here
the
channels
are
exactly
the
opposite,
as
in
the
application.
This
channel
here
are
the
channels
in
the
broker.
A
So
these
are
usually
broker
topics
commonly
known
as
broker
topics
broker
cues.
You
know
all
this
kind
of
things,
and
so
this
is
defined
for
the
broker.
A
A
I
I
was
reluctant
to
introduce
this
new
kind
of
file
in
the
beginning,
but
I
I'm
I'm
afraid
we
don't
have
any
better
option,
because
we
we
started
acing
api,
as
you
know,
as
a
clone
of
open
api
for
other
protocols
and
messaging
and
so
on,
but
as
opposed
to
open
api,
where
the
communication
is
point
to
point.
There
are
only
two
actors
involved:
the
client
and
the
server
here.
A
There
are
multiple
nodes,
multiple
actors
involved
right
and
there's
no
server,
they're
all
clients
or
there
might
be
servers
and
clients,
as
well
aside
from
the
broker,
which
is
a
shared
thing.
So
I
have
to
fill
in
that
we
cannot
continue
restricting
ourselves
to
a
single
application
definition
file
because
yeah
another
another
thing
that
I
was
thinking
is
that
if
we
place
everything
here
in
channels,
then.
A
What
is
the
application
file
that
should
contain
these
channel
definitions
in
this
server's
definition,
which
one
like
you
have
10
or
10
or
or
100
applications,
all
of
them
subscribing
and
publishing
to
a
broker,
which
one
is
the
one
containing
the
channel's
definition?
Why
not
all
of
them?
Obviously,
because
you
don't
want
to
repeat
yourself
right,
but
then
what
we
usually
recommend
is
like
no,
you
have
to
extract
the
definitions
and
then
in
each
of
the
files
in
each
of
the
in
each
of
the
applications.
A
If
we
give
it
a
structure,
we
give
it
a
name,
then
we
can
create
tooling
to
take
advantage
of
this,
like,
for
instance,
with
this.
With
this
file
with
the
domain
file,
we
could
draw
a
graph
of
available
brokers,
available
servers
available
channels.
You
know
all
this
all
the
messages
that
are
flowing
there.
We
cannot
draw
who's,
publishing
and
who's
subscribing,
because
we
don't
have
this
information
in
this
file,
but
at
least
we
can
set
the
stage
like
hey,
so
here
here's
the
broker.
A
This
is
the
channels
contained
in
this
broker.
This
file
can
be
used
for
discovery.
Basically,
we
can
even
create
discovery
systems
like
hey.
I
need
to
find
a
topic
channel
that
contains
a
message
that
contains
the
user.
Email
right,
you
start
typing
and
you
get
the
information
filtered.
So
here
are
the
topics
or
channels
that
contain
this
information
so
for
discovery
this
will
be
super
cool.
So
that
is
an
a
a
use
case
for
this
right,
and
that
is
what
people
have
been
asking
actually
dale.
A
So
yeah
so
yeah,
it's
because
I
don't
know
if
I
can,
while
I'm
sharing
the
screen,
I
don't
know
if
I
can
see
people
without
camera
or
I
don't
know
anyway,
he
will
see
the
recording
so
so
dale
when
I
had
my
first
conversation
with
dale
on
thinking
out
loud.
This
was
exactly
the
use
case.
Ibm
was
looking
for
having
having
a
file
where
to
define
all
the
channels,
all
the
messages,
all
the
servers
and
so
on.
They
were
not
interested
at
all.
A
If
it's
a
publisher,
if
it's
a
subscribe,
they
don't
care
because
they're
not
looking
to
define
an
application.
They're
looking
to
define
a
domain,
it
can
be.
The
whole
company
domain
can
be
just
a
subset
of
it
right.
So
that's
up
to
the
arc,
the
architect
or
the
architects
to
to
define
so
so
yeah.
That
is,
that
is
what
the
domain
is
for.
Let's
say
right
so.
A
So,
as
you
can
see
here
here,
I'm
referencing
servers
that
are
defined
so
this
this
local
servers
don't
have
to
be
defined
on
the
on
the
domain
right.
This
servers
so
say
for
instance,
this
is
a
a
server
right,
a
websocket
api,
but
we
can
create
a
websocket
client
right.
So
if
we
create
a
websocket
client,
it
will
be.
You
know
remote
server.
A
This
is
just
from
my
client
definition.
I
can
make
a
ref
direct
reference
to
my
server
definition.
A
It's
coupling
both
it's
coupling,
the
server
and
the
client,
but
the
server
and
the
client
are
usually
coupled
anyway,
so
so
that
shouldn't
be
a
problem.
A
But
if
it's
a
problem
and
that's
why
I
was
doing
this-
you
can
move
this
definition
to
the
domain
right
and
then
the
client
and
the
server
will
reference
the
definition
on
the
domain
right
on
that
third
file
that
we
were
talking
about,
that
is
already
there.
It's
already
existing.
Just
people
are
putting
whatever
structure
they
prefer
there
and
yeah.
Any
questions
so
far
looks
like
it's
the
first
time
you
hear
it
jenna.
C
B
C
Is
it
the
application
like
which
application
is
owning
this
channel,
for
example,
yeah
or
where
do
you
define
it,
and
where
should
you
reference
it
and
some
post
them
out
into
a
specific
file
for
this?
The
same
that
you
have
now,
but
you
just
called
domains
instead,
which
is
for
the
broker
itself,
where
it's
like.
I
define
everything.
That's
within
this
specific
set
of
domain,
whatever
that
is,
and
then
you
have
one
one,
and
then
you
have
one
reference
to
that
domain
from
each
application
and
says:
well,
it's
part
of
this
domain.
C
It's
it
has
this
message
definition
this
topic,
here's
the
definition
for
it
right
and
in
that
sense
it
makes
it
makes.
A
You
know,
like
people
are
already
doing
that
and
we're
recommending
that
like
extract
the
common
definitions
to
another
file
and
reference,
this
file
for
from
all
the
applications
we're
just
giving
that
third
file
a
name
and
a
format,
and
so
we
can
take
advantage
of
it
right,
but
this
is
already
happening
like
I
don't
know
anyone
using
async
api
for
broker-based
architectures.
Of
course.
A
A
A
A
Okay,
so
if
we
have,
if
we're
doing
a
websocket
api,
then
we
have
the
servers
here.
We
have
channels
which
is
cool
components,
messages
post
like
blah
blah
blah,
and
then
this
channel
yeah,
if
you're
not
using
any
broker
at
all
right
if
you're
not
using
any
broker
at
all,
you
can
just
have
a
common
api
file
without
domains
or
anything,
because
you
don't
need
it,
you
don't
need
any
domain.
It's
everything
is
contained
in
your
application
definition
and
if
you
have
a
a
client,
you
can
make
a
direct
reference
to
your
server.
A
A
And
since
we
don't
have
so
much
time,
I'm
gonna
go
fast
through
this,
and
this
is
now
what
I'm
going
to
talk
about
now
is
completely
separated.
So
I
think
this
is
a
proposal.
This
is
something
that
we
might
want
to
consider
and
there's
another
thing
so
just
just
to
clarify.
A
It's
not
indonesia,
I
I
just
wanted
to
share
typo,
so
you
can
give
me
thoughts
but
I'll,
since
there
are
not
much
people
in
in
the
call.
I
will
probably
paste
this
into
an
issue
and
and
get
feedback
there
as
well,
so
yeah
so
I'll
do
that.
But
for
this
this
one
is
another
thing.
So
I'm
now
talking
about
something
else,
and
this
is
extra
stuff
for
after
3.0.
A
I
want
to
make
it
clear
so,
since
people
are
requesting
that
we
support
also
http
as
a
first
class
citizen,
so
they
can
define
rest
apis
and
and
message
oriented
message
driven
architectures
in
the
same
place
we
could
instead
of
offering
this
http
binding
with
lots
of
potential
right.
A
We
could
instead
ex
be
accepting
the
paths,
object,
forum,
open
api
in
the
root
of
s,
financing
kpi
file,
not
perfect
solution,
but
it's
it
opens
a
a
possibility
right.
So
this
is
something
that
we
are
right
now
discussing
we're
thinking-
and
I
can't
remember
the
issue
but
yeah
there's
an
issue
on
the
bindings
about
about
it
about
the
http
binding,
supporting
multiple
methods
right.
A
So
if
you
can
paste
the
link,
that
will
be
that'll
be
cool,
and
so
that
means
that
we,
this
object
here.
This
whole
object
paths.
This
is
defined
by
open
api,
not
by
us,
but
there
are
a
few
things
here
there
are.
One
of
them
is
that
this
schema
definition
is
different.
It's
using
a
different
version
than
the
one
that
we
were
using,
so
that
is
probably
something
we
will
have
to
solve,
or
we
pair
with
open
api
and
we
upgrade
to
the
same
version
they're
using
right.
A
I'm
reluctant
to
do
it
soon.
I
mean
well,
as
I
said,
this
is
for
after
3.0,
so
we
have
time,
but
I'm
reluctant
to
do
it
now,
because
this
json
schema
version
doesn't
have
really
good
tolerance
support
so
so
yeah.
If
we
don't
have
tool
support,
we
have
nothing
basically
so
so
yeah
and
another
reason
why
I
may
be
reluctant
to
do
this
as
it
is
here,
as
in
this
example,
is
that
we're
mixing
operations
here.
A
You
know
like
request
reply
and
so
on
right,
so
so
yeah
that
might
be
a
a
little
bit
chaotic,
but
it's
going
to
be
useful
for
most
of
the
users.
Nevertheless
right.
So
so,
yes,
anyway,
something
to
think
about
it
in
the
future
and
also
mentioning
that
it
might
open
the
door
for
linking
to
graphql
schemas
and
jrpg
schemas
as
well
or
protobuf,
and
not
product
your
pc,
so
so
yeah.
A
It
opens
the
possibility
to
expand
to
all
these
things
that
are
mentioned
in
the
in
the
roadmap,
right
that
we
we
become.
We
we
become
like
the
the
number
one
specification
to
to
define
all
the
all
the
kind
of
apis
right,
so
so
yeah
it
doesn't
mean
that,
but
without
reinventing
the
wheel
right,
so
integrating
existing
specs
like
open
api
like
graphql
like
your
pc,
it's
just
that
from
amazing
kpi.
You
should
be
able
to
have
like
a
reference
to
existing
files,
so
you
don't
have
to
worry
about
it
and
yeah.
A
A
C
C
You
can,
for
example,
reuse
references
between
async,
api
definitions
and,
what's
defined
elsewhere,
it
it
also
creates
kind
of
clash,
so
the
devil's
advocate
or
the
opposite
view
of
what
you're
proposing
here
is
kind
of
outlined
it
in
the
issue
that
I
I
posted,
but
it's
it's
provide
better
tooling
for
converting
from
whatever
else
specification.
There
is
two
async
api
yeah,
but
it's
it's
also
kind
of
the
extreme
way,
especially
if
you
are
used
to
open
api
and
still
want
to
use
it.
So.
A
That
that's
definitely
one
way.
The
thing
is
that
if
we
do
this,
if
we
create
another
syntax
for
defining
http,
apis
or
rest
apis,
then
we
are
reinventing
the
wheel
and
I
don't
know
I
don't
think
people
will
be
happy
with
this,
but
the
people,
people
already
have
many
people
already
have
open
api
files
and
they
just
want
to
use
them.
A
Gateways-
or
you
know
like
exactly
like
gateways
or
or
or
the
like,
that-
only
support
open
api.
This
third
third-party
services,
don't
support
this
in
kpi.
Yet
so
they
need
this
open
api
file
and
they
will
want
to
to
keep
iterating
on
the
open
api
file
so
and
and
they
will
want
to
keep
iterating
on
the
async
api
file.
So
at
some
point,
so
it's
not
as
easy
as
converting,
because
then
you
will
be
overwriting
the
async
gpa
file
right.
So
it
is
more
than
that
you
will.
A
You
somehow
need
to
merge
the
two
changes
in
both
documents,
complicating
things
a
little
bit,
but
that's
not
just
that
like
we're,
assuming
that
people
have
ci
pipelines
and
many
banks
and
and
and
big
companies,
don't
have
ci
pipelines
and
or
at
least
don't
they
don't
make
a
lot
of
usage
of
it,
and
this
is
something
that
may
maybe
one
team
can
start
doing,
but
not
the
whole
company
at
the
same
time.
So
so
yeah
it
is,
it
is
high.
A
A
So
you
need
to
be
scanning
all
the
repos
in
your
company.
You
know
searching
for
open
api
files
to
convert
them,
so
so
it
increases
the
I
mean
everything
is
possible.
A
Everything
is
doable,
but
what
we
the
benefit
that
we're
providing
doesn't
outweigh
the
the
difficulty
and
the
time
it's
gonna
take
to
do
it
right
so
and
that's
the
problem
like
people
will
not
feel
encouraged
to
migrate
because
it's
too
much
and
it's
not
providing
enough
value
for
them
to
do
it
right
so
so
having
tooling
to
migrate
from
one
person
to
another
is
cool
which
will
happen.
This
will
have
it,
but
it's
not
the
final
solution
right,
so
we
should
probably
be
integrating
more
seamlessly
so
like
like.
A
I
was
just
mentioning
now,
like
maybe
just
referencing
an
external
open
api
file
and
that's
it
and
you
can
keep
working
on
both
if
you
want
and
and
that's
it
and
we
make
it
clear.
Whatever
is
on
the
open
api
file,
it's
of
less
importance
than
what
you
have
on
the
operations,
so
whatever
you
have
on
operations
is
overwriting.
What's
on
the
open
api
file,
something
like
this
just
in
case
they
clash,
you
have
an
order
of
preference.
C
And
it's
all
about
finding
bad
balance
between
what's
usable
and
what's
long
term
makes
more
sense.
Yes,
in
in
case
of
not
over
complicating
everything
and
also
just
to
highlight
like
we
are,
or
we
have
reinvented
the
wheel
already
with
http
bindings,
because
nothing
is,
as
I
understand,
based
off
of
open
api
right.
A
C
A
But
yeah
it's
a
matter
of.
We
need
to
think
about
keeping
keeping
a
balance
of
a
well-defined
spec
versus
something
that
is
immediately
useful
for
the
user
right.
So
having
open
api
support
will
be
immediately
useful
for
the
user.
It
might
create
some
edge
cases,
then.
Maybe
the
only
thing
we
have
to
do
there
in
the
spec
is
define
those
edge
cases
and
say
and
and
and
define
how
tolerance
will
behave
in
these
cases.
Right.
A
Anyway,
that's
just
the
thought
just
I
thought
it
would
be
interesting.