►
From YouTube: CNCF Serverless WG Meeting - 2019-05-02
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
A
A
All
right
now,
during
any,
we
have
no
updates
for
SDK
B
I'm.
At
a
meeting
for
the
demo
for
coop
con
Europe
the
it's
coming
along
fairly
nicely.
We
are
getting
more
more
than
one
participant
involved
now
that
we
have
the
basic
flow
settle
down.
The
document
here
is
up
to
date
with
the
message
flows.
If
you
guys
want
to
participate
this
one
just
give
you
guys.
Heads
up
is
quite
a
bit
more
complicated
than
ones
we
did
in
the
past.
A
So
it
would
be
beneficial
if
you
do
want
your
company
to
participate
to
get
involved
as
quickly
as
possible,
not
only
because
there's
more
coding
on
your
site.
That
needs
to
be
done,
but
there's
a
very
good
possibility
are
bugs
in
the
system
and
we
need
to
have
a
flag
those
as
soon
as
possible,
because
there's
a
lot
of
moving
pieces
in
this
one,
so
you'll
want
to
get
those
things
ironed
out
relatively
quickly,
but
all
the
information
you
need
he's
either
in
the
proposal
doc
here
or
in
the
demo
select
channel.
A
So,
oh
and
we
do
have
meetings
after
this
call
at
1:00
p.m.
Eastern
to
talk
about
anything
coop
correlated
so
presentations
or
demo
related.
So
you
want
to
join
that
feel
free
to
do
that,
all
right,
any
questions
or
comments
about
the
demo
or
koukin
in
general,
okay,
I
guess
I
should
say
for
cuca
in
general.
The
slide
decks
are
out
here.
So
the
links
are
all
in
this
section,
I'm,
honestly
I,
don't
think
most
of
them
have
a
whole
lot
of
content.
A
But
of
course
people
tend
to
wait
to
the
last
minute
anyway,
but
please
do
your
reviews
sooner
rather
than
later.
If
you,
if
you're
interested
in
sort
of
monitoring
that
and
again
we
will
have
a
call
phone
call
after
this
one,
you
want
to
join
that
conversation.
Any
questions
about
that
all
right,
cuckoo,
Connie
China.
We
do
have
a
35
minute
session
for
cloud
events
and
35
minutes
for
service
I
personally
will
be
there.
I
suspect
Kathy
might
be
there
since
that's
close
to
WA,
but
anybody
else
going
to
be
there
who's
interested.
A
B
A
B
B
A
That's
true:
okay:
there
you
go
what
else!
Oh
yeah,
so
you're
the
review
next
week,
I'm
gonna
be
here
a
presentation
to
the
TOC
on
how
we're
doing
cloud
events.
While
the
presentation
is
there,
there's
nothing
in
there,
so
don't
bother
looking
yet,
hopefully
before
end
of
the
weekend.
I'll
have
something
there
for
you
guys
to
review
and
I'll.
Send
that
a
note
for
you
guys
to
comment
on
it.
A
I
think
May
7th
is
Tuesday,
so
there's
not
a
whole
lot
of
time,
but
I
will
always
send
it
out
before
the
end
of
the
weekend,
for
you
guys
take
a
look
at
it.
I
don't
expect
it
to
be
anything
controversial.
So
hopefully
it's
not
a
big
deal
and
with
that
I
think
we
can
jump
into
pr's.
Unless
there
are
other
topics,
you
would
like
to
bring
up
that
I'm
forgetting
about.
A
E
A
A
D
A
D
A
Would
be
good
to
know,
that's
very
good
point
cuz
worst
case
scenario
is
they
say,
end-user
means
end-user
a
product,
that's
using
cloud
events,
and
if
you
already
have
end
users
using
it
and-
and
we
can,
you
know
confidently
say
that
that
that
they're,
real
and
they're
not
just
made
up
and
I'm,
not
sure
that
that
actually
have
to
have
names,
then
yeah.
We
could
probably
satisfy
that
requirement.
So
if
you
have
that
information,
send
it
to
me
and
I'll
I'll
definitely
include
that
as
part
of
the
discussions
going
forward.
A
A
A
So
this
one
a
couple
of
things.
This
is
strictly
a
reordering
of
the
spec
I
noticed
that
the
attributes
we
had
were
in
sort
of
a
random
order.
They
weren't
even
alphabetical
or
required
for
us,
or
anything
like
that
and
I
mean
so
my
discussions
I'm
having
with
some
people
relative
to
supporting
cloud
events,
I
thought
it'd
be
useful
if
we
grouped
the
required
attributes
together
just
so
that
there's
a
section
that
says.
Basically,
you
know
here's
the
bare
minimum.
You
need
to
support
to
become
a
cloud
event
and
that's
the
required
attributes.
A
Then
I
create
an
optional
attribute
section
and
put
all
they
had
their
attributes
in
there
in
alphabetical
order,
obviously
excluding
the
data
section,
which
has
it
through
the
day
attribute
which
has
its
own
section,
because
I
was
always
pulled
out.
I
did
not
make
any
other
type
of
graphical
changes
whatsoever
or
definitely
not
Samantha
cakes,
either
I
just
reordered
things
around
and
created
two
new
sections.
F
A
F
Okay,
so,
in
order
to
later
on
come
up
with
this
other
PR
or
regarding
the
immutability
of
event,
context
I
felt
that
I
need
some
more
terms
like,
for
example,
the
intermediary
to
better
achieve
this
so
and
then
I
stepped
over,
maybe
also
need
a
consumer.
Then
I
saw
that
sauce
and
producer
are
not
really
defined.
I
mean
sauce.
F
The
attribute
is
defined,
but
you
know
in
many
places
of
the
document
talking
about
producer,
but
it's
not
really
defined
so
far,
and
what
I
came
up
with
was
that
distinction
between
sauce
and
producer,
so
that
the
producers,
the
entity
that
actually
puts
together
this
data
structure
or
data
record
that
is
then
put
on
the
wire
transporting
the
event.
While
the
sauce
is
more,
the
the
logical
source
of
the
event
like
could,
for
example,
be
a
business
process
or
I.
F
Don't
know
a
lot
of
things
later
on,
then
some
others
in
the
call
step
of
a
logical
inconsistency,
so
that
this
source
definition
does
not
really
fit
to
the
source
attribute
and
there's
some
some
discussion.
What
exactly
source
is
and
then
producer
I
think
the
attribute
is
defined
as
the
sauce.
As
describing
the
producer
so
basically
defining
sauce
by
referring
to
something
else
that
hasn't
been
defined
yet
yeah,
so
there
were
some
discussions.
F
What
exactly
a
sauce
can
be
if
it
exactly
is
something
very
specific
like
a
process
or
I
don't
know
or
if
it
really
is
something
logical,
as
I
have
put
it
here
and
what
then
is
the
producer?
So
I
mean
I
also
have
done
some
research.
There
is
a
book
available,
I,
think
it's
been
processing
in
action
or
something
on
meaning.
They
also
define
terms
like
producer
and
sauce
and
that's
again
a
bit
different.
So
I
don't
know
I.
C
Like
the
decision
you
make
here,
because
the
source
might
really
be
a
different
system,
that's
emitting
some
some
event.
That
is
not
yet
in
cloud
events
form
and
then
the
cloud
event
is
produced
by
the
producer.
But
if
you
have
some
kind
of
device,
that's
talking
what
bus
or
something
that's
probably
the
source,
and
then
you
have
the
producer
like
truly
and
then
you
have.
The
producer
is
the
one
that's
creating
the
cloud
event.
A
F
I
think
there
was
something
some
clarification:
I
I'm
still
still
supposed
to
make
wondering
where
it
was
somewhere
about
an
external
producer.
I
think
it
was
I
didn't
do
it
yet,
because
I
think
that
the
whole
definition
was
under
discussion,
so
I
didn't
at
that
single
word.
I!
Think
even
put
it
into
in
the
comments
above.
F
E
A
G
Wouldn't
change
was
yeah,
just
external
producer
creates
the
cloud
event
that
was
suggested
by
me
last
week.
The
big
thing,
the
bigger
thing
was
something
I
realized
while
I
was
writing
a
comment
on
PR
3
and
9
1
I,
don't
even
remember
what
it
was
about
now.
I
think
the
change
to
event
ID
and
source
or
something
I
know
it
was
changed
to
the
actual
attributes,
two
distinct
to
get
some
clarification
or
the
Eventide
the
uniqueness
anyway.
The
problem
is
pretty
well
spelled
out
in
my
comment
on
this
beer.
G
If
you
can
pull
it
out,
yep
a
lot
a
sec,
the
basic
gist
of
it
is
that
source
is
now
oops.
Sorry,
fine,
here
differently
from
how
it
is
used
as
an
attribute.
So
the
attribute
is
defined
as
having
both
identifying
information
about
the
organization
and
the
component
omitting
the
event,
but
also
some
unique
IDs,
for
example,
for
a
file
container
in
a
cloud
storage
solution.
So
but
this
document
is
that
defines
source
as
a
logical
system,
so
that
would
be,
for
example,
behold
to
me.
G
That
implies
the
whole,
for
example,
cloud
storage
solution
program
instead
of
the
individual
file
container.
So
when
someone's
talking
about
a
source,
it
now
feels
on
an
ambiguous
as
to
which
what
they
are
referring
to
the
value
of
the
source
attribute
or
into
the
source,
as
defined
in
this
terminology
and
I
find
that
they
are
in
conflict
and
I
gave
multiple
examples
in
this
comment.
G
A
F
Ok,
so
in
the
book,
I
think
they
also
had
producer-consumer
and
an
additional
processor,
and
the
source
was
then
always
that
entity
that
actually
created
the
event.
So
in
a
consumer
producer
was
at
the
edge
of
the
event
processing
system,
how
they
call
this
and
a
processor
was
part
of
that
event.
Processing
system
and
both
could
in
tech
resources.
So
that's
how
they
put
it,
but
that's
again
a
different
view.
So,
oh
ok,
so
well.
G
G
F
A
A
What
you're
thinking,
but
from
a
spec
perspective,
do
all
the
various
roles
matter
now
I
understand
that
when
we
talk
about
things,
it's
useful
to
have
common
terminology
just
so
we're
on
the
same
page,
but
does
it
matter
whether
the
producing
side
of
a
cloud
event
is
one
entity
versus
10
different
entities
and
we
actually
need
to
give
names
to
everything,
or
should
the
spec
be
a
little
bit
more
abstract
and
just
say
something's
going
to
produce
something
on
a
transport?
And
this
is
what
that's
something
needs
to
look
like.
F
Well,
we
had
this
discussion
about
the
event
context
and
the
immutability
and
I
must
think
some
strong
feeling
that
at
least
middle
way,
I
shouldn't
just
drop,
for
example,
optional,
attributes
and
then
and
that,
on
the
other
hand,
if
you
consume
an
event
and
really
produce
a
new
one,
then
you're,
of
course,
free
to
do
whatever
you
like.
So
that's
what
led
me
to
this
distinction.
A
Yeah,
but
do
we
actually
need
to
call
out
as
detailed
the
distinction
is
that,
for
example,
in
the
case,
where
there's
a
piece
of
middleware
that
may
or
may
not
be
modifying
things?
Could
we
not
just
say
that,
if
that,
if
there's
a
component
that
takes
in
a
cloud
event
and
then
generates
a
cloud
event
depending
on
what
it's
doing,
it
may
or
may
not
modify
the
think
the
the
data
in
there
and
whether
that's
okay
or
not?
G
So
one
example,
I
was
thinking
of
related
to
this,
and
also
the
definition
of
source
attribute
is,
for
example,
ingesting
application.
Specific
events
into
a
larger
system
as
the
source
allows
and,
in
my
opinion,
must
allow
application
specific
identifiers
which
might
not
be
globally
unique.
You
might
actually
have
to
have
a
middleware
that
augments
the
source
to
include
a
let's
say,
a
DNS
component
or
DNS
DNS
unique
role
into
the
source,
for
which
was
they
can
be
composed.
The
source
was
previously
application,
specific
unique
enough
in
a
global
context.
Let.
H
C
And
also
open
tracing
like
this
hole,
tracing
stuff
is
basically
morphing
changing
the
the
content
of
the
the
tracing
attribute
as
it
passes
through
infrastructure.
So
there
there's
stuff
that's
being
modified
on
the
way
where
you
want
to
preserve
most
of
the
source
event.
But
then,
as
it
flows
through
multiple
layers
of
infrastructure,
there
is
stuff,
that's
being
added
or
or
changed.
I.
H
Think
tracing,
maybe
I,
haven't
looked
at
the
implementation
of
open
tracing,
but
racing
may
be
an
example,
but
it
seems
like
in
most
of
these
cases
you
care
whether
it's
been
transformed
by
the
middle
way
or
not.
So
in
some
sense,
if
you've
got
the
original
event
instead
of
the
inning
enriched
one
you'd
be
upset.
C
Yeah,
the
tracy
think
of
think
of
tracing
as
annotations.
They
here
this
isn't
becoming
as
clear
as
it
is
in
some
other
mappings
of
the
tracing
stuff,
like
an
in
keep
you
make
it
pretty
clear,
but
it's
like
the
the
way
how
open
tracing
works
is
basically
that's
a
that's
an
ongoing
annotation
as
you
go
from
hop,
hop
hop.
C
C
You
would
be
upset
if
you
would
be
upset
if
you
would
materially
change
the
event
semantically,
and
in
that
case,
I
agree.
I,
agree
that
that
should
cause
a
different
event
being
created.
That
is
then
somehow
coupled
traced
back
to
whatever
the
original
event
is,
and
that
might
there
might
be
a
rule
that
you
have
to
go
and
refer
to
include
whatever
the
original
event,
but
not
one,
not
one
that
we
have
to
go
into
fine
here,
because
that
starts
to
then
go
into.
That
would
be
too
complicated
for
me
for
my
taste,
so.
I
A
G
Because
then,
then,
the
event
ID,
no
the
event
source
attribute
definition
no
longer
holds
because
it
says
that
you
must
set
a
distinct
source,
attribute
value
for
each
distinct
producer,
and
that
would
be
in
conflict
with
the
definition
of
producer
here
at
the
moment.
I
guess,
if
you,
if
you
remove
the
current
definition
of
producer
in
this
PR,
also
gather
and
just
define
what
define
the
value
of
the
source
attribute,
and
this
producer
has
the
same
thing.
G
J
Yeah
I
share
the
same
thought:
I
think
we
have
two
fields
like
stores
and
producer.
If
we
find
two
right,
I
have
to
clearly
define
you,
know
the
difference
and
how
to
represent
them.
I
think
if
we
define
one,
is
clearer
in
not,
for
example,
the
producer,
it's
very
clear
what
we
mean
and
then
we
can
also
I
think
we
also
need
to
add.
You
know
the
type
for
the
producer,
how
we
represent
it
in
the
in
the
other
section
same
for
consumer
under
intermediate
ring
intermediary.
F
So
I
think
around
sauce
there's
some
perceived
uncertainty.
I
also
realized
that,
while
discussing
that
in
the
Canadian
registry.
J
I'm
thinking
you
know
if
we
want
to
different
post
produce
and
store
so
point
dear
sir
I
think
he's
very
clear,
at
least
to
me
what
it
means
right
and
consumer
your
you
have
a
consumer.
You
have
a
producer,
so
what's
the
use
of
the
source,
what
purpose
does
it
serve
with
even
each
one,
and
then
we
need
to
clearly
identify
the
difference
between
producer
and
the
source,
so
in
which
case
we
need
this
source.
If
we
have
a
scenario
say
in
addition
to
producer,
we'll
also
need
these
source
attribute.
J
A
Cathy
I
wanna,
make
sure
and
Sarah
you're
saying.
Are
you
suggesting
that
maybe
we
don't
actually
have
source
as
a
standalone
term?
Rather
as
part
of
the
definition
of
producer?
We
talked
about
how
the
producer
is
the
creator
of
a
cloud
event
for
an
event
source
and
just
leave
it
almost
like
that
and
not
actually
try
to
define
it
as
a
separate
entity.
J
Yeah
I'm
thinking,
yeah
I,
think
that's
right,
so
I'm
thinking
we
unless
we
can
clearly
define
source
and
I
didn't
find
you
know
it's
it's
it's
a
needed
field
to
serve
some
specific
scenario.
I
think
a
producer
I
feel
it
is
it's
enough,
it's
good
and
we
can
clearly
define
what
that
producer
mean.
Then
there's
a
there's,
a
producer.
There
will
be
a
consumer
right
hold
on
it.
We're
going
to
define
the
consumer,
then
I
think
the
producer
was
that
source
for
what,
sir,
what
purpose
does
it
serve?.
K
Yes,
the
I
work
with
gs1
on
their
event
format.
That's
is
mostly
for
location,
tracking,
a
product
and
they're
extending
into
sensors,
and
so
they
have
two
two
elements
where
the
source
could
be
the
identifier
of
the
sensor.
You
know
in
IOT
and
then
the
Gateway
would
be
the
producer.
There
would
be
semantically
and
annotating
what
the
sensor
produced.
A
Tipene
am
I
correct
that
it
is
this
short
sentence
here
that
I've
highlighted
is
really
the
problem
sentence.
Yeah
I
think
that
that
is
the
problematic
piece
I
agree.
So
if
we
were
to
do
the
equivalent
that
basically
kill
that
sentence
and
maybe
do
a
little
bit
of
words,
nothing
on
the
rest
of
it,
it
sounds
like
also.
G
A
G
C
The
thing
that
matters
here
is
really
the
source,
which
means
the
context
for
the
event
and
what
what
that
event
really
is.
The
context
of
the
event
describes,
because,
ultimately,
what
source
means,
if
the
producer
doesn't
play
much
of
a
role
really
other
than
being
the
one?
That's
formulating
the
event
and
then,
in
the
case
of
middleware
having
a
relationship
with
you
know
the
first
publishing
point,
but
that's
really
all
rolled
that
it
has
so
in
our
in
our
specification
per
se.
C
C
G
But
also
these
so
so
the
whole
definition
is
actually
but
from
what
Clem
has
just
said:
propose
that
or
something
along
the
lines
of
not
talking
biological
systems
but
actually
be
context.
What
you
talked
about
Clemens,
that's,
actually,
what
makes
sense
I
want
the
attribute
that
what
the
attribute
that
we
have
describes.
It
describes
the
context
in
which
the
event
happened
with
bracket
and
everything.
So
these
terms
should
just
be
redefined
us
what
we
use
as
the
source
attribute.
G
J
Yeah
I'm,
just
you
know,
unless
we
can't
clear
it,
you
find
these
two
maybe
another
way
we
can
combine
them.
You
know
and
put
that
you
know
context
or
whatever
we
want
to
you
find
the
source
into.
You
know
for
the
mean
by
them,
so
so
that
people
would
not
be
confused.
Well,.
G
A
Slightly
different
in
our
for
the
demo
cause
is
more
like
a
related
to
ID.
More
than
anything
else,
it's
not
really
the
source
of
the
event
per
se.
It's
which
other
cloud
event
is
this
one
related
to.
So
it's
slightly
different,
but
I
can
understand
why
you
can
kind
of
view
it
that
way.
So
we
heard
technically
I
think
out
of
time
on
this
one
cuz
I
did
try
to
tell
on
a
time
box.
This,
however
I,
do
think
at
the
end
there
we
may
have
actually
come
to
a
possible
direction.
F
A
J
J
G
Just
because
I
can't
come
up
with
any
reason,
I
would
want
to
know
the
actual
running
machine
that
produced
the
event.
I
just
want
to
define
the
producer,
but
I
don't
actually
care
about
it
after
I
had
that
event,
I
care
about
the
source,
but
I,
don't
care
about
which
machine
actually
created
the
event
that
should
be
handled
by
tracing
or
something.
A
Okay,
but
well
think
about
that
Kathy
and
you
think
of
some
use
cases
where
it
might
be
useful,
then
I
think
it'd
be
an
interesting
discussion
to
have,
but
within
the
context
of
this,
I
do
feel
like
we
have
a
possible
direction
to
go
forward.
So
Klaus
you,
okay,
with
taking
another
passage
to
the
changes
here.
Yes,.
F
G
Oh
I,
don't
think
there
are
many
uses
outside
the
source
attribute
for
the
term,
so
in
that
sense,
I
think
it
should
be
consolidated.
But
if
you
can
just
like
search
through
the
spec,
where
are
we
using
the
term
source
and
if
there's
a
lot
of
uses,
then
it
should
be
defined
separately.
I
think
as
well.
A
Okay
and
I
think
with
that
another
call
time
in
their
way
we're
15
minutes
do
anything
else
say,
is
to
address
Mark's
comment
earlier
about
making
sure
we
get
alignment
with
the
primer
and
other
documents
I'm
assuming
we
can
do
that
as
a
follow-up
piece
of
work.
Once
we
get
this
definition
nailed
down,
so
I,
don't
think
you
can
all
in
class.
You
have
to
do
everything
at
once.
I
think
we
can
do
it
in
stages.
A
Okay,
all
right
with
that.
Let's
move
forward
to
optional
event:
ID
I!
Don't
believe
this
is
from
Allen
right,
yeah,
I,
don't
believe.
Allen
is
on
the
call
and
I
don't
think
he
can
make
it.
However,
the
general
idea
here
is:
he
wants
ID,
that's
right,
yeah!
He
basically
wants
ID
to
be
optional
because
he
has
some
systems
that
do
not
need
it
and
it's
very
costly
for
him
to
actually
produce
it
in
all
cases.
So
I
wanted
to
bring
up
the
discussion
here
and
see
if
there's
a
general
direction.
A
The
group
can
agree
upon
in
particular,
and
we
get
his
last
comments.
If
we,
because
Clemons
made
a
made,
an
argument
for
keeping
it
because
we're
actually
operating
on
a
different
level-
and
here
was
Allen's
response
back
to
that
I'll,
let
you
guys
read
that
very
quickly,
but
Tim
I
would
tend
to
agree.
I
believe
that
Allen
was
saying
that
in
some
cases
for
him
anyway,
you
do
IDs
are
not
cheap.
I.
Just
don't
know
whether
who
to
believe
on
that
one.
To
be
honest,.
A
E
A
A
I
C
Because
it's
like
I,
don't
understand
the
case
where
you
would
not
want
to
make
it
unique
like
there's
a
it
seems
like
Allen
tries
to
make
a
case
where
there
is
a
case
where
you
would
explicitly
not
want
to
make
it
unique,
which
is
a
little
strange
to
me,
and
then
there
was
another.
There
was
an
arc.
Another
argument
made
that
is
in
the
bug
that,
where
this
comes
from
well,
it's
like
it
might
be.
There
might
be
sufficient
information
inside
the
event
to
make
it
unique
and
I
agree
with
that
that
there
might
be.
C
But
the
point
is
to
further-
and
that
was
the
counter-argument
that
you
know
we
want
to
have
a
neutral
way
of
insuring
uniqueness
and
that's
by
introducing
that
field.
So,
even
if
you
have
four
fields
that
take
them
together,
you
know
create
uniqueness
and
then
the
way
how
to
make
this
interoperable
is
to
put
the
concatenate
them
and
put
them
into
a
field
where
everybody
can
go
and
pick
them
up,
because
the
duplication
was
is
kind
of.
C
The
guiding
scenario
seems
like
that
was
made
in
this
thread,
but
there
are
also
cases
where
you
want
to
go
and
take
a
bunch
of
events
and
store
them
in
a
database.
So
you
can
go
in
and
and
look
at
them
later
and
for
that
you
need
to
have
at
least
a
primary
key
in
addition
to
whatever
AG's
wants
for
lookup
and
and
that
is
the
combination
of
source
and
an
event,
IDs
will
be
identified
for
that.
C
Time
was
another
factor
that
was
suggested
and,
of
course,
clocks
are
terrible
and
you
do
great
things
in
parallel
and
there's
time
a
resolution,
and
if
you
compensate
for
clock
skew,
then
your
clock
may
actually
go
backwards
after
etc.
So
that's
not
a
good
question.
Not
gonna
wait,
not
a
good
way
to
go
and
eat
this,
and
as
Tim
Rhodes
you
you,
IDs
are
cheap,
so
I
I'm
not
sure
what
the
what
the
problem
is.
Okay,.
A
G
C
A
A
G
A
B
right,
that's
what
I
was
hoping
I
didn't
want.
I
didn't
want
to
just
close
this
without
giving
him
a
chance
to
speak
for
himself
as
in
real
time
as
opposed
to
through
comments,
because
I
think
he
does
feel
passionate
about
this
and
I.
Don't
want
to
miss
out
something
if
there's
something
he
hasn't
said
in
the
comments
there.
So,
okay,
let's
do
that
and
see
if
we
can
come
to
the
call,
otherwise
I,
don't
think
it's
worth
our
time
dwelling
on
it
here,
since
we
all
seem
to
be
in
agreement,
I!
Think,
okay!
A
So
let's
get
to
this
one
now
did
it
as
of
right
now,
just
refresh
everybody's
memory,
a
basically
source
plus
ID,
defines
uniqueness
and
Scott.
You
are
still
there
right,
yes,
Scott
I
believe
on
last
week's
call.
You
were
gonna,
go
off
and
think
about
some
of
the
discussions
you
had
last
week.
It
in
terms
of
whether
you
were
coming
around
to
saying:
okay
ideas,
sufficient
for
uniqueness.
Are
these
for
the
mask
of
a
producer?
Have
you
had
a
chance
to
think
more
about
that.
A
Okay,
give
him
a
sec
I,
look
forward
to
see
what
the
next
issue
is
for
its
annexation
law
Scott
as
well.
You
think
ID
is
okay.
Okay!
Is
there
anybody?
Okay?
So
in
that
case
it
sounds
like
we
need
to
go
back
and
just
review
Alan's
PR
here,
because
I'm
blurry
I'm
pretty
sure
this
PR
pretty
much
just
says:
source
plus
ID
needs
to
be
unique
and
because
we're
so
sorry
I'm
sorry
you're
good.
A
So
I
don't
want
to
try
to
close
this
one,
because
I
think
enough
people
have
kind
of
ignored
this
one.
While
we
went
back
and
forth
on
whether
ID
is
sufficient.
That
I
want
people
to
have
another
week
to
review
this,
but
otherwise
this
PR
I
believe
is
ready
to
go
and
I
do
believe.
That's
a
good
I
was.
H
A
H
H
A
H
A
A
J
J
A
F
E
A
A
Yeah,
okay,
anyway,
I
think
if
you
guys
can
make
your
comments
on
on
the
examples
in
here,
I
think
we
can
make
some
progress
and
maybe
only
get
this
one
resolved
next
week.
Cuz
I,
don't
think
really
all
headed
in
different
directions.
I
think
we
all
go
our
head
in
the
same
direction.
It's
just
minor
tweaks
of
this
plane.
A
A
Don't
use
quotes,
don't
use
God,
okay,
I
did
you
want
to
talk
about
anything
proposals
severed
because
you
made
some
changes
in
here
and
I?
Think
you
I
aren't
necessarily
too
far
off
in
the
sense
that
ignoring
maps
for
a
minute
for
pretty
much
all
other
attributes,
I
think
you
and
I
are
both
saying
treat
everything
as
a
string
right.
A
Right,
not
data
and
I'm,
not
even
missing
maps,
yet
just
the
other
areas
exactly
right,
and
so
what
to
quickly
get
a
sense
from
the
group
as
whether
you
guys
think
that's
an
okay
direction
to
go.
I
believe
right
now,
integer
is
the
only
other
type
that
we
actually
define
in
the
inside
of
respect.
So
I
think
we
basically
end
up
dropping
the
entire
notion
of
types
and
then
figure
out
to
do
with
Maps
later,
but
everything
basically
just
says
it's
a
string
and
and
and
to
sterilize
it.
A
A
A
A
Okay,
in
that
case,
you
guys
are
free
to
go
unless
you
want
to
join
the
coup
Connie.
You
slash
demo
talk
immediately
following
this
one
in
three
minutes,
but
thank
you
guys
very
much.
I
know
we
don't
deep
on
some
issues,
but
I
think
it
was
all
good
discussion.
So
I
think
that
made
some
progress.
Okay,.
M
A
C
I
A
A
Okay,
let's
do
the
easy
stuff,
first
relative
to
coop
con
itself
for
the
presentations
and
stuff
I
know
that
some
people
been
putting
in
some
slide
information.
Are
there
any
topics?
People
want
to
bring
up
there?
Many
questions
concerns
you'll
have
it
was
just
a
matter
of
finding
time
to
fill
out
that
yeah
the
slide
deck
yeah.
A
C
A
C
A
A
A
Yeah:
okay,
although
I
don't
wanna
waste
your
time,
I'll
find
it
offline,
but
there
is
a
you're.
The
real
PowerPoint
then
I'll
send
that
to
you
and
then,
if
you
can
get
that
set
up
I,
don't
mind:
switching,
that's
fine,
okay!
So
anything
else
relative
to
the
slide.
X4
kuqali!
You
don't
want
to
talk
about.
Please.
N
Look
over
my
concept
example,
but
still
think
I
think
it's
a
bit
too
small,
but
then
again
initially
was
bigger
and
I
spend
like
15
minutes
of
the
15
minutes.
I
had
explaining
it,
and
that
was
not
fun.
So
I
really
want
to
start
working
on
it
this
weekend.
So
I'll
need
a
couple
of
eyes
on.
It
is
basically
a
blonde
with
tracing
done
by
honeycomb,
which
is
going
to
be
putting
an
extension.
N
N
N
Proof
of
concept:
bad
Ram.
It's
basically
gonna
wait
for
two
events
to
come.
The
events
come
their
process
and
some
kind
of
gate.
They
go
through
a
lambda
that
deploys
she
cashes
in
helm,
because
those
needs
compliance
and
you
can
be
really
nice
stuff
with
lambda
and
ETS.
Did
you
the
way
AWS
does
authentication
the
cloud
even
thing
here
is
again
saying:
hey
glad
you
guys
are
here:
they're
boring,
use
them
and
I'm
gonna
be
using
extensions
for
Honeycomb
contacts
propagation
again.
K
A
Alright,
so
Doug
do
I
want
to
quickly
ask
you
the
question
I
asked
through
slack
I
know
you
responded
by
having
a
chance
to
read
it
yet.
My
biggest
question
was
just
the
this.
This
is
a
good
example,
alright,
so
the
trigger
for
someone
to
know
whether
they're
supposed
to
do
something
or
not.
Is
they
look
at
the
source,
the
type
which
are
both
cloud
event
attributes,
but
then
here
they
have
to
actually
go
into
the
data
to
figure
out
whether
it's
Atlanta
they
care
about.
Would
it
be
horrible
if
we
were
to
create?
A
K
Not
if
you
separate
them
into
two
additional
elements,
if
you
put
tried
to
put
it
into
type,
then
it
would
break
the
model
because
they're
three,
you
know
you
know,
there's
the
attribute
value
pairs
that
are
currently
in
the
data
attribute
and
if
you
just
separated
it,
if
you
took
the
attribute
identifier
which
is
tied
to
you,
know
the
semantic
model
and
he
put
that
into
its
own
element.
You
know
call
it
attribute
or
property,
and
then
you
left,
he
left
data
to
just
be
the
value
of
that
attribute.
K
A
So
wait
do
I,
I
think
maybe
some
confusion
here.
I,
don't
know
whether
it's
on
your
side
or
my
side.
Let
me
ask
you
a
question
about
this
field.
Right
here:
type
equals
order.
A
K
K
K
It
should
be,
you
know
the
type
of
class
which
would
be
you
know,
room
or
order,
and
then
the
the
subject
or
object,
which
would
be
101
or
one
two,
three
four
and
then
the
and
then
the
attribute
which
would
be
temperature
or
you
know,
order
status.
So
it's
it's
trying
to
take
those
components
of
that
statement.
That's
reacted
to
and
and
separate
them
into.
You
know
a
distinct
cloud
event
elements
I've
been.
A
What
what
I
guess,
I'm
trying
to
wonder,
is
whether
we
have
whether
whether
the
cloud
event
attributes
like
type
are
duplicating
data
and
duplicating
information
from
data
or
whether
we
are.
We
have
pulled
information
out
of
data
and
now
only
use
the
cloud
event
attribute
for
it
and
the
reason
I'm
asking
this
is
because,
in
my
mental
model
of
car
events,
they
should
not
be
modifying
the
original
event
itself
right
cloud
events
is
all
about
adding
information
to
the
event
to
make
processing
easier.
A
A
So
it
should
be
type
:
order
inside
here
that
way,
we
can
modify
this
to
be
anything
we
wanted
and
it
doesn't
break
the
accros
model,
because
this
is
only
used
by
the
cloud
event:
routing
processor,
it's
not
used
by
the
business
logic,
which
cares
about
type
equals
order.
I,
understand,
I'm,
trying
to
say.
A
K
A
So,
in
my
model,
the
the
component
that
it's
actually
gonna
process,
this
event
should
only
ever
for
the
most
part,
look
at
what's
inside
data,
the
fact
that
there
are
cloud
event
attributes
should
almost
not
be
known
to
the
processing
function
itself,
because
the
fact
that
this
was
sent
using
cloud
events
should
almost
be
oblivious
to
it.
Grace
be
it
shouldn't
matter
to
it
and
that's
why
I'm
wondering
whether
we
made
a
mistake
in
pulling
out
some
business
logic,
attributes
like
type
and
only
put
them
out
here.
E
K
I
mean
or
you're
putting
order
in
there,
which
is
obviously
that
that
in
the
the
semantic
model
is
the
class,
so
you
want
to
say
order
released,
but
what's
missing
in
there,
you
had
the
class
and
you
have
an
enumeration
of
an
attribute.
You
know,
including
the
attribute
you're
saying
order,
release
like
there's
a
direct
relationship.
I
mean
there's
only
one
status
of
or
one
attribute
of,
an
order
right
order
got
released,
and
what
really
it
is,
is
its
order
status,
released.
A
A
Because
I
was
I
was
bothered
by
the
fact
fits
that
yeah
I
advertise
cloud
events
to
people
as
we're,
adding
metadata
to
help
routing
right
in
and
you
can
send
any
events
you
want
and
all
we're
doing
is
adding
a
couple.
Actual
HTTP,
headers
and
life
is
great
well,
as
I
was
coding.
This
up
and
you
come
across
things
like
this
trigger
line
where
he
says:
okay,
how
do
I
know
as
a
retailer
with
I'm
going
to
process
this
or
not?
Well,
I
can't
just
look
at
the
source
and
type
anymore.
A
C
E
A
E
A
The
source
Feliz
retailer
dot,
the
retailer
in
question
type
is
order,
and
then
what
are
not
status
is
order
released.
So
in
this
before
case,
should
this
is
it
okay
that
the
receiver
I
need
to
look
inside
data
to
know
whether
I
need
to
process
this
or
not,
or
is
that
just
part
of
the
business
logic,
and
sometimes
business
logic
is
and
I'm
not
gonna?
Do
anything?
Okay,.
C
For
me,
the
question
is:
are
there
are
there
cases
where
the
the
you
raising
the
order
events
and
so
the
the
order,
the
type
order
event,
and
that
only
differs
in
terms
of
what's
the
order
status
is
like?
Do
you
because
that's
a
question
like
it?
Should
there
be
a
order,
dot
order,
released
events
and
an
order
or
order
completed
events?
C
That
is
because
this
seems
like
if
I,
if
I
draw
the
parallel
here
to
the
the
blobstore
favor
right,
then
the
tie,
if
the
type
is,
if
the
type
is
just
blob,
and
then
you
have
a
blob
status
that
is
created
and
deleted
and
amending
whatever
that
makes
dispatch
really
hard.
So
I
think
the
type
should
really
go
and
fully
fully
enclose
and
incorporate
all
the
information
between
from
this
pouch.
K
So
so
the
idea
here
was
a
tie
cloud
events
to
a
semantic
model
that
provided
semantic
interoperability
as
well
as
Interop
bility
within
the
syntactic
sand
tactics
of
an
event.
And
so,
if
you
look
in
looked
at
what
schema.org
has
right,
they
have
a
semantic
identifier
for
a
type
or
class
called
order,
and
in
there
you
an
order
has
certain
attributes
and
their
semantic
identifiers
for
each
of
those.
And
then
that
attribute
has
values
that
are
enumerated.
Then
it
defined
each
of
those
enumerations
as
a
semantic
identifier.
K
And
so
the
idea
was
is
that
if
everybody
was
if
cloud
events
included
those
identifiers
and
everybody
was
adhering
to
dismantle
schema.org
model,
then
everything
would
be
understood
inherently.
And
if
you
so
that,
and
that's
how
that's
how
you
know
the
demo
has
been
laid
out
thus
far
to
adhere
to
that.
If
you
go
and
put
in
type
something
that
is
different
than
that
that
model
you
know
you're
putting
in
something
that
you're
making
up
just
for
routing,
then
in
that's,
that's
not
tying
everybody
to
the
same
to
a
common
semantic
model.
It's
assuming
you're.
E
K
K
C
Then
the
event
type
is
really
order,
dot
order
released
because
you
are
reporting
out
the
status,
change
and
you're
reacting
the
to
a
particular
status
so
within
within
the
order
within
that's
also
what
you
just
described
within
the
within
the
type,
the
overall
type
order.
There
are
some
multiple
events
that
can
be
raised.
E
C
But
when
you
map
that
fail
out
events,
then
the
type
that
shows
up
in
the
in
the
cloud
event
is
not
the
type
that
the
the
semantic
model
type
that
you're
referring
to.
But
it's
really
referring
to
the
the
the
status
change
event
that
you
have
so
it's
kind
of,
but
nothing
it's
not
direct
from
the
business
scope,
type
to
the
event
type.
But
really
it's
from
the
event
that
just
happened
inside
of
inside
of
your
business
object
to
the
cloud
event.
C
K
D
K
C
Let's
see
that's
what
we're
doing
what
we're
doing
phrases
in
in.
Let
me
let
me
map
this
to
something
we
do
in
Azure
right.
You
can
have
a
in
in
Azure
in
the
bluff
store
right.
We
have
a
concept
called
blog
and
you
can
go
and
create
a
blog.
You
can
delete
a
blog,
you
can
go
and
amend
the
blob,
and
you
can,
you
know,
change
the
properties
of
the
blog,
but
let's
stick
with
to
delete
and
create
because
it's
easy,
the
the
create
event
is
the
create
event
really
elite.
C
Events
are
distinct,
distinct
events
that
applications
are
interested
in
separately
and
mostly
all
of
the
apps
rise
to
crate.
So
we're
presenting
this
presenting
this
for
practically
for
practical
reasons
as
distinct
event
types
blob
created
is
it
sneak
event
types,
and
that
is
part
of
Microsoft,
that
storage
that
blob
dot
block
created.
So
it
has
a
hierarchy,
it's
kind
of
sorted
entry,
they're
generally
the
general
model
of
yeah.
This
all
belongs
to
blob.
So
that's
part
of
the
type,
but
really
it
goes.
C
It
scope
down
to
the
event
that
was
raised
about
the
particular
object
with
the
subject
and
the
subject
in
the
source:
it's
a
distinct,
it's
a
distinct,
a
thing
that
happened
to
me,
and
that
is
the
creation
of
it,
and
here
you
have
a
distinct
thing
that
happens
to
the
order,
and
that
is
the
release
of
it,
and
that
is
what
that
event
was
describes.
So
it
is
this.
This
type
field
here
is
about
the
event
type
and
not
about
the
type
of
object
that
the
event
is
about.
K
D
K
C
C
K
K
M
I
think
what
we're
trying
to
say
is
it's
much
more
difficult
to
not
embed
the
state
machine
of
status
inside
of
the
type
because
you
don't
know
how
to
route
the
next
state
change.
So
you
order
is
the
price,
but
order
released
is
the
state
of
that
class.
So
it's
not
arbitrary.
It's
well
defined
for
this
particular
statement.
You,
okay,.
K
What
what
if
just
just
for
kicks,
add,
add
to
other
extensions
here.
You
look
below
type
where
you
left
type
as
order,
and
then
you
put
out
it's
after
tubular
property
I,
don't
care
just
something
right
and
then
you
put
in
there
order
status.
A
C
C
C
It
is
it
is
that
the
type
here
is
really
this
distinct
type
of
this
particular
event.
If
you
were,
if
you
were
turning
this
into
an
object
model
literally,
would
have
a
class
derived
from
a
cloud
event
that
which
would
be
called
order
released
and
it
would
have
a
different
class
that
would
be
called
in
a
order
anyway.
C
So
you
would
have
distinct
events,
which
are
literally
incorporating
the
thing
that
you
want
to
tell,
which
is
the
distinct
state
change.
It
just
happened
if
you
go
and
take
a
look
at
you,
if
you,
if
you,
if
you
visualize,
if
you
visualize
the
the
this,
this
state
model
the
state
machine
for
order
processing
right,
there's
all
these
there's
these
state
transitions
that
happen
on.
If
you
imagine
in
your
head,
the
state
diagram,
then,
then
effectively
all
the
arrows
that
go
between
the
states.
C
K
But
and
that's
fine,
but
let's
just
go
back
to
how
this
model
extends
beyond
just
a
you
know
or
because
you
we
could
potentially
under
type
keep
keep
the
order.
Part
tied
to
the
semantic
identifier
of
the
of
the
order
class
within
schema.org
right
and
then
order
released,
is,
is
pretty
much
a
unique
global,
unique
enumerator
right.
K
C
You
have
an
inventory.
The
inventory,
like
every
everything
that
raises
events
is
a
state
machine
and
the
transition
and
the
transitions
of
those
state
machines
raise
events.
And
so
you
have
an
inventory
if
the
inventory
that
goes
down
to
zero,
so
you
have
an
inventory
that
has
a
count
as
a
state
machine
around
counts
and
either
you
you
raise
an
event
around
the
count
chain
or
you
have
a
effectively
in
the
large
that's
being
raised
only
when
that
count
goes
to
zero.
C
K
So
if
you
look
at,
if
you
look
at
type,
let's
just
put
it
in
there,
try
to
mate
laid
out
the
same
way,
go
ahead
and
remove
out
to
be
in
value
from
below
Doug.
No,
so
we
don't
get
that
confused
okay,
so
we
got
so
we're
gonna
model
the
inventory
level
dropping
down
to
a
below
a
threshold
as
an
event
that
recorded
that
actions
going
to
be
taken.
Yeah.
A
K
C
My
point
is:
what
were
these
are?
These
are
state
changes
that
you're
reporting
out
and
and
the
inventory
level
per
se,
that
value
is,
if
you
want
to,
if
you
want
to
raise
inventory
level,
changed,
which
means,
if
you
want
to
go
and
report
out
every
time
you
add
something
or
remove
something.
Then
that's
that's
what
you
would
do.
You
would
raise
the
inventory
level
changed
events,
and
then
you
can
go
and
and
filter
on
this
and
then
go
to
the
detail
and
find
what
the
inventory
level
is.
C
C
E
C
A
Well
so
I
before
me
say
down
the
path
of
saying
is
just
another
semantic
model:
I
don't
want
to
go
there,
but
let
me
that's
a
slightly
different
question,
because
I
still
feel
like
the
the
the
what
we're
doing
today
is.
We
are
mixing
where
information
goes,
I
feel
like
we
are
putting
business
level
logic,
sometimes
in
the
data
section
and
sometimes
in
the
category,
and
it
feels
like
that's
not
appropriate.
It
feels
like
all
the
business
level.
Logic
needs
to
go
into
the
data
section
period
and
anything
that
appears
in
the
cloud
event.
M
K
K
A
E
K
G
E
K
A
The
reason
I
added
that
was
to
make
a
point
in
the
sense
that
we
could
make
up
anything
you
wanted
here
and
I,
don't
think
it
violates
the
accros
model,
because
the
accros
model
has
total
control
over
what's
inside
and
we
and
we
as
a
as
a
as
an
organization.
If
we
could
presently
say
when
you
take
the
accros
model
and
map
it
to
a
cloud
event.
A
A
K
C
C
What
defense
do
is
they
describe
the
change
of
that
thing,
so
so
there's
a
there's,
a
natural
mismatch,
because
you
going
if
you
look
at
the
semantic
model,
you
you
really
looking
at
a
static
state
of
the
world
right
now
and
what
we're
doing
here
is
we're
actually
reporting
out
on
changes
from
some
changes
from
one
world
to
the
next
state
of
the
world,
and
that
exact
that
exact
state
change
is
the
thing
or
we're
reporting
out
here.
So.
K
And
you
could
say,
offer
dot
inventory
level,
and
that
implies
that
there
was
a
state
change
to
inventory
level
right
if
you
just
kept
it
like
that,
offered
inventory
level.
You
know
that
changed
you
can
imply
that
it
changed
and
if
you
want
to
know
what
it
changed
to
you
got
to
look
in
to
another
another
element.
You.
K
C
With
you
right
so
I
agree
with
you
for
that
particular
instance.
Here
that
actually
makes
a
lot
of
sense
so
and
for
and
for
order
that
order
status.
You
could
do
the
same
thing
so
for
the
one
below
you
could
do
the
same
thing
we
can
say
we
can
say
order,
order,
status
and
the
order
and
there's
an
order,
status,
change
and
you
want
to
go
changed.
K
C
C
Here's
a
state
change
that
just
happened
right
and
that's
agent
is
the
order,
a
little
early
state
changed
and
on
the
inventory
level.
Since
that's
a
that's
a
number,
you
probably
don't
want
to
report
out
every
every
every
potential
value
I
mean
you
could,
as
we
discussed
earlier,
but
inventory
level.
Depleted
basically
just
needs
at
that
case
it's
zero,
which
is
a
distinct
thing.
You
might
also
be
interested
in.
C
K
So
what
if
we
just
did
this
right
because,
what's
left
and
data
up
above
under,
let's
look
at
the
top
one
right,
there's
a
lot
of
things
in
there
that
we
just
used
to
facilitate
taking
action,
because
we
weren't
persisting
history.
But
let's
say
that's
the
only
the
only
thing
that
data
would
be
in
this
case.
If
you
have
offered
inventory
level
and
the
type
would
be,
the
number
would
be
the
number
zero
which
you
could
filter
on,
because
data
at
that
point
is
just
the
value
of
your
type.
C
K
A
So
did
seems
to
me
there's
a
there's,
a
high
other
question
here.
This
in
my
mind,
which
is
at
what
point:
do
we
put
all
data
into
the
cloud
event
stuff
versus
keeping
inside
the
body
right?
When
does
when
do
we
leave
the
boundary
of
routing
versus
business
logic
and
I?
Don't
want
it?
I
don't
want
us
to
convert
everything,
because
because
we
could
take
this,
take
this
type
into
offered
inventory
level,
dot,
zero,
dot,
small
right.
A
We
confirm
this
thing
and
get
rid
of
data
entirely,
but
that's
not
really
what
were
meant
to
do
here,
so
it
feels
like
it.
There's
there
has
been
line.
Sometimes
it
says
you,
you
want
classification
in
routing
information
where
you
want
to
call
it
at
the
cloud
event
level,
but
business
level
logic.
That's
that's
more
specific
to
this
type
of
event
that
stays
inside
data,
but
if
the
type
of
information.
K
It's
a
it's
got
to
be
a
balance.
You
know
you
want
to
optimize
routing
to
a
certain
degree,
but
then
you
don't
want
to
you've
got
to
be
able
to
say
okay,
I'm
gonna
route
optimally
to
this
point,
but
then,
after
that
you
know
for
those
that
did
get
get
it
routed.
You
know
you
got
you're
looking
at
that
that
it
got
routed
to,
but
they
still
don't
know.
If
they're
going
to
take
action,
some
will
some
won't.
They
got
it
routed
to
right
right.
A
K
K
No
I
the
one
below
would
be
just
again.
You
have
to
be
uniform
in
the
model,
and
so,
if
you
ordered
order
status
change,
you
know
that
that
changed,
and
so
you
would
have
to
go
in
you,
drought,
an
order
status,
change
to
those
that
were
interested
in
it
and
then
they
they
go
look.
And
today
they
see
that
to
say
that
it
was
order
released.
A
And
so
today,
cuz
that,
because
I
was
trying
to
equate
this
back
to
the
examples
you
implement
that
os3
datastore
kind
of
thing
right,
do
you
all
the
filter
on
creates
versus
deletes
and
obviously
for
an
s3
type
of
bucket
thing.
I
think
that
makes
perfect
sense,
cuz
it's
what
they
do
today,
but
maybe
in
this
particular
application,
saying
you're,
gonna
filter
on
the
order
status.
A
That's
a
business
project
thing,
that's
not
a
routing
thing
and
that's
and
I
think
that's
a
perfectly
fine
choice,
which
means,
if
we
get
rid
of
this,
then
in
order
for
someone
to
take
action,
they
still
have
to
go
to
the
body,
but
we're
going
to
mentally
say:
that's
not
a
routing
decision.
At
that
point.
That's
a
business
logic
decision.
Yes,.
D
K
A
E
A
I
A
A
A
K
K
K
A
A
C
C
C
A
K
K
F
K
A
I,
like
that,
the
consistent
pattern
I
can
live
with
that
Scott.
So
so,
in
this
particular
case
here
you
start
going
to
the
body
to
look
at
the
provider,
but
I
think
that's!
Okay,
because
that's
more
along
the
business
logic
side
of
things,
I!
Think!
Okay!
So
let's
see
so
in
this
particular
case,
this
one
would
change,
because
that's
an
enumeration
right
right
here.
A
A
K
Yep
yeah
I
mean
what
what
you're
doing
here
and
I
don't
wanna,
bring
it
out.
No,
that's
fine,
I,
just
I
think
it's
I
think
I'm,
not
gonna
I'm
good
with
this
I
got
a
little
nervous,
but
and
this
this
is
fine.
It
ties
completely
to
the
semantic
identifiers,
you're
just
and
you're,
making
you're
making
it
easy
for
routing
so
and
it's
in
it
you're
using
it
uniformly.
You
know
with
within
here.
E
A
K
K
A
Okay,
I
think
it
I
think
it
makes
a
little
bit
more
clean
model
because
I
was
having
a
hard
time
distinguishing
between
business
project
for
surviving
logic.
I
think
this
makes
it
a
little
bit
easier,
at
least
for
M
I
had
to
understand
okay,
so
we
got
two
minutes
left.
Is
there
anything
you
guys
want
to
bring
up
relative
to
the
state
of
things
ignoring
bugs
in
the
possible
code,
but
in
terms
of
the
flows
and
stuff
like
that
I
know
climb
enjoy
a
night.
She
has
to
read
it
yet.
M
M
A
A
Is
so
anyway,
okay,
anything
else,
all
right,
okay,
cool!
Thank
you,
guys,
I
appreciate
it
and
we'll
talk
again,
I
guess
on
Monday,
hopefully
between
now
and
then
more
people
will
come
online
and
we'll
get
the
demo
a
little
more.
It's
solid,
I
think
there's
still
some
bugs
in
there
I
think
the
flush-mount
all.