►
From YouTube: OpenFeature - Project Meeting, December 8th, 2022
Description
Meeting notes: https://docs.google.com/document/d/1p...
OpenFeature website: https://open-feature.github.io/
A
A
B
A
E
B
E
D
D
D
If
you
don't
mind
just
adding
yourself
to
the
participants
list
and
then,
if
you
have
any
agenda
items
feel
free
to
add
them.
Let
me
probably
go
ahead
and
get
started,
and
thanks
Pete
for
volunteering
to
be
the
Scribe
and
remembering
do
we
have
any
volunteers
for
next
one
we
that
one
may
be
subject
to
cancel
it
to
being
canceled.
You
know
because
it's
pretty
close
to
the
holidays,
but
you
know,
as
of
now
it's
scheduled.
So
if
there's.
B
D
D
C
C
Looking
at
the
spec
of
open
feature
at
the
moment
it
seems
like
it
has
been
primarily
focused
around
sort
of
like
back-end
development
and
back-end
Integrations
to
feature
Flags.
So
I've
got
experience
in
creating
my
node
clients
with
feed
flags
and
I'd
say.
The
current
spec
is
like
really
really
well
suited
to
sort
of
like
back-end
development,
but
in
front-end
development,
seeing
not
just
flagsmith
but
the
way
the
other
front-end
clients
work.
C
I
would
say
it's
quite
fundamentally
different
to
the
way
people
interact
with
feature
flags
from
a
back
end,
integration,
perspective
and
I
guess.
My
first
sort
of
question
was
around
whether
there
was
a
consideration
to
try
and
have
the
spec
be
the
same
for
front
end
client
for
clients
versus
server
or
whether
we're
trying
to
sort
of
combine
both
of
them
into
one
that
that's
the
sort
of
like
main
topic.
I
I,
don't
know
whether
I
should
continue
or
start.
We
should
start
having
a
discussion
about
that.
E
I
think
we
we
have
talked
about
it.
It's
come
up
a
few
times
in
the
past
and
I.
Think
there's
my
my
my
my
take
on
like
or
my
kind
of
interpretation
of
the
past
discussions
is
kind
of,
like
basically
I
guess
what
just
Justin
said
is
like
that.
There's
definitely
like,
like
you,
said,
like
totally
totally
agree
with
you.
E
Carl
like
most
of
the
existing
vendors
or
mostly
most
of
the
kind
of
like
vendors
that
are
out
there
tend
to
have
a
different,
a
different
like
SDK
and
a
different
API
for
the
for
the
front
end
and
the
back
end,
but
it
would
be
awesome
if
we
could.
You
know,
one
of
the
whole
kind
of
goals
with
open
feature
is
to
kind
of
like
avoid
kind
of
repeating
and
kind
of
rebuilding
stuff
for
each
kind
of
platform
Etc.
E
A
My
thinking
is
that,
without
having
seen
this
thread,
that
you're
talking
about
and
so
willing
to
be
wrong
here,
is
that
we
can
probably
come
up
with
an
SDK
that
is
consistent
across
client,
client
device
usage
and
servers.
But
the
providers
are
going
to
be
very
different,
like
an
individual
vendor
is
going
to
have
different
providers
because
there's
different
caching
needs
and
a
bunch
of
other
stuff
like
that,
and
so
I
think
that's
where
I
would
I
would
personally
like
to
head.
B
B
Common
sdks
is
I
think
what
we've
spent
a
lot
of
time,
talking
about
a
common
SDK
between
clients
and
and
back
end
is
I.
Think
what
we've
been
talking
about
and
I
I
agree
with
Justin
and
I
think
I
think
it's
a
good
thing
to
shoot
for
and
I
I
think
it's
possible.
I
also
agree
with
Pete
that
I
don't
think.
We've
arrived
at
that
yet,
and
so
that's
kind
of
the
next
stage,
where
yeah
I
think
it
I
think
it's
I
think
we
should
shoot
for
a
common
SDK.
G
C
G
I
haven't
made
it
I,
I,
think
one
of
the
things
that
is
important,
I
think
there's
different
things
that
need
to
be
prioritized
here,
and
so
one
of
the
things
that
we
should
try
and
prioritize,
in
my
opinion,
is
the
the
behavior
of
open
feature
when
changing
providers
like
doesn't
change
in
a
completely
ridiculous
way,
like
I
think
there
could
be
a
tendency
to
just
go
well,
we'll
just
let
the
provider
figure
that
out
and
if
that's
like
completely
different,
then
that's
not
open
features.
Responsibility
like
where
that
line
is
drawn.
G
I
think
it's
kind
of
difficult
to
know
and
I
think
it
would
be
a
shame
if
it
was
like
you
know,
because
kind
of
the
the
one
of
the
goals
is
to
one
of
the
main
goals
has
been
to
prevent
vendor
locking
if
you
were
to
just
make
it
so
that
the
behavior
was
radically
different
amongst
providers
now,
I
there's
not
there's.
Definitely
not
a
planet.
There's,
definitely
not
a
solution.
Right
like
that's,
not
possible.
That
works
in
a
perfect.
G
How
much
of
a
Delta
there
is
between
those
two
you
know
I
do
think
there
is
a
common
ground,
and
this
is
much
more
complicated
on
the
front
end
as
well.
Right,
like
I,
think
this.
This
is.
This
is
much.
This
is
a
much
simpler
channel
to
to
sort
of
thread
through
on
the
server
side.
On
the
client
side,
it's
a
little
bit
more
fraught
and
a
bit
a
bit
more
opinionated,
but.
G
Just
my
that's
just
my
thoughts
is
like
there's.
There's
definitely
I
think
you
know
the
the
people
who
are
between
the
people
who
are
involved.
It's
definitely
enough
sort
of
brain
power
to
try
and
come
up
with
a
nice
common
denominator
that
satisfies
core
stuff
and
doesn't
just
offload
it
to.
Are
we
using
that
provider?
None
of
that
works?
It's
all
know
what
blah
blah
blah
right.
I
do
think,
but
I
do
I.
Do
think,
there's
quite
a
lot
of
work
in
front
of
that.
C
C
A
E
I
think
that's
true,
except
for
the
the
the
JavaScript
thing
right,
because,
like
the
biggest
the
the
thing
that
that
the
current
spec
does,
that
makes
it
really
hard
well,
the
current
SDK
does
that
makes
it
look,
means
that
you
basically
can't
it's.
That
makes
it
hard
to
look
like
the
thing
that
Carl's
describing
is
those
those
evaluations
are
erasing
right
and,
and
you
can't
make
in
most
languages,
you
can
make
it
look
sync,
because
you
can
just
have
a
blocking
call,
but
you
can't
in
JavaScript,
like
you
just
can't.
E
E
B
B
We
also
have
the
experimental,
the
experimental
node
version
that
has
some
basic
Eventing
I
I,
believe,
honestly,
that
that
basic
Eventing
can
be
used
to
solve
that
problem.
You
could
basically
just
await
an
on
ready
and
a
provider,
maybe
not
I'm
interested
in
hearing
Pete's
feedback,
but
the
thing
that
I
I,
still
don't
quite
understand,
is
why
the
it's
important
that
that
evaluation
is
synchronous,
I
mean
whether
or
not
you've
pulled
everything
down
and
put
it
into
a
local
hash.
Fantastic
just
do
promise.resolve
from
whatever
you
retrieve
from
the
hash.
B
C
Can
I
can
definitely
sort
of
explain
that
with
an
example,
I
guess
that
could
be
the
next
set,
but
essentially
I
I
feel
like
if
it
was
async,
it
would
kind
of
be
unusable
in
the.
What
you
want
to
do
is
have
like
at
the
app
Root
it'd
be
async
and
that's
totally
fine
and
you
can
show
a
loader
while
that's
happening,
but
in
components
of
components,
pages
and
in
function.
Calls
that
are
happening
inside
like
renders
and
mounting
you.
You
kind
of
need
them
to
be
synchronous,
because
otherwise
they
would
be
sort
of.
C
You
would
have
to
handle
pretty
much
fake,
immediate
sort
of
loads,
and
you
would
have
to
show
a
loader
whilst
that
async
function
is
calling
back.
So,
for
example,
you
fetch
all
of
your
facts.
You
initialize
your
flags
at
the
app
Root
and
then
in
your
index
page
or
maybe
a
sub
component
of
the
index
page.
If
it
was
asynchronous,
you
would
have
to
do.
I
mean
like
hooks
aside.
C
If
you
develop
some
like
wrap
hooks,
you
would
have
to
do
the
equivalent
of
like
use
effects
and
set
state
to
ready,
as
true
straight
after
that
asynchronous
call,
and
it's
just
not
that's
that
isn't
very
suitable
like
what's
way
way
easier
to
work
with,
is
like
you're
just
doing
like
flagprovider
dot
get
Boolean,
and
it's
there
immediately.
So
you
don't
have
to
show
loaders
or
yeah
all
of
your
sub
components
like
they
render
immediately
and
there's
no
sort
of
like
flickering
I
guess
within
all
of
your
components.
E
Why
can't
you
just
like,
if
you're
a
react,
developer
like
you,
can
use
like
use
effect
or
a
promise
or
whatever
like
what's
like
just
learn
to
program
dude
like
I,
think
it's
got
to
be
like
there's
a
I,
think
there's
a
there's.
Definitely
a
reason
why
to
Kyle's
Point,
there's
a
reason
why,
like
all
of
the
apis,
have
have
done
this
is
because
they've,
if
they
didn't
originally
build
it,
that
way
they
had
a
bunch
of
devs
that
were
trying
to
use
the
thing
and
saying
like
like.
Why
do
we?
E
F
Great
discussion
I
am
using.
We
are
using
open
feature
with
launch
Darkly
on
the
client
side
in
the
code
base
that
I
work
on
and
it
does
work,
but
it
is
also
very
clunky,
so
you
can
definitely
do
the
hacky
things.
The
use
effects
the
custom
hooks
to
make
it
happen,
react
contacts
whatever
that
looks
like,
but
it
also
feels
unintuitive
and
more
difficult
than
it
should.
So.
Those
are
both
true
from
my
perspective
that
it
is
possible,
but
it
is
also
a
little
bit
clunky.
G
Talking
about
is
the
server-side
sdks,
don't
have
a
concept
of
like
multi-threadness
and
the
front
end
sdks
that
we're
talking
about
you
know
they.
They
they
want
to
grab
the
flags
asynchronously
off
a
separate
thread.
It
doesn't
impact
UI
and
then
you
know
asynchronously
react
to
that
response.
Coming
back
right,
like
that,
that's
the
Paradigm
that
Android
clock,
managing
and
Swift-
and
you
know
even
like
react
to
react
native
use
right
like
that's-
is
that
the
sort
of
essence
of
the
thing
boiled
down
as
a
problem.
B
E
Sorry,
I
think
that's
that's
like
that's
a
hundred
percent
I
think
I.
Think
a
lot
of
the
Assumption
is
that
the
reason
front
end
apis.
Have
these
synchronous.
Things
is
because
it's
like
you
can't
block
the
UI
or
because
it's
easier
I
actually
think
it's,
because
they
have
the
luxury
of
not
having
to
do
actual
flag
valuations.
You
can
go
to
the
go
to
the
the
source
of
Truth
and
say
for
the
current
context.
What
flag
should
I
show
and
basically
keep
that
static
almost
for
like
the
length
of
the
of
the
app?
E
If
you
want
to
be
fancy,
you
can
stream
in
changes.
So
you
can,
like
you
know,
turn
features
on
or
off
for
like
a
long
running
session
with
back
end
is
the
opposite
where
you
can
happily
block
while
you
go
to
like
you
like,
while
you
go
to
like
a
make
a
network
call
or
whatever,
but
you
can't,
but
you
can't
like,
like
every
single
request.
The
context
is
is
different.
E
If
we
talked
to
most
of
the
vendors
I,
keep
on
meaning
to
do
this,
but
I
haven't.
They
would
say
that
this
whole
thing
of
evaluating
all
the
flags
and
just
giving
it
to
the
to
the
JavaScript
developer
is
a
huge
pain,
because
now
they
don't
know
which
flags
are
being
evaluated
and
they
don't
have
any
analytics
on.
F
C
Synchronous
what's
happening
in
the
background
is
when
you're
saying
get
flag
value
it's
in
the
background,
rather
than
accessing
that
state
directly
and
I
I'd.
Imagine
that
would
be
the
case
with
all
of
them.
Really
there
there's
Getters
to
to
sort
of
get
the
flag
values
and
the
analytics
would
be
happening
in
the
background
and
I
I.
Don't
think
you
would
have
to
worry
about
that
with
the
providers.
I
think
that
would
be
happening
in
the
background
by
the
scene.
E
Yeah
I
think
that's
kind
of
true
that
I
think
there's
some
there's
some
implementations
where,
for
historic
reasons
they
they
just
have
that
as
like
a
dictionary
and
and
and
you
have
to
call
a
method,
I
think
split.
Does
it
that
way,
for
example,
but
like
you're
I
think
you're
right
that,
like
it
like,
whenever
we
get
around
to
doing
the
analytics
piece,
we
should
just
I
think
it's
easy
enough
to
support.
E
You
just
need
to
never
just
give
someone
that
raw
bag
and
give
them
like
a
synchronous,
a
thing
with
some
synchronous
methods
that
they
that
they
can
call.
But
the
thing
is
that
does
still
make
it
hard
for
like.
If
you
talk
to
a
team
at
like
a
big
company,
that's
like,
like
the
ideal
I
think
for
most
companies
like
oh
all,
of
our
teams
are
using
launch
directly
or
whatever
right,
but
if
you're
like
uber
and
you
have
like
a
million
feature
Flags
or
whatever
ridiculous
number,
they
have
in
their
mobile
app.
E
C
C
Ideally
you
don't
want
the
re-renders
to
happen
unless
only
the
flags
you
care
about
change,
if
that
makes
sense,
so
yeah
like
when
thinking
about
event
handling
one
thing
that
would
be
nice
is
to
be
able
to
say:
I
want
to
listen
to
Just
when
this
one
flag
changes
so
you're
not
doing
a
load
of
yeah
re-renders,
that's
especially
true
and
like
react
native
like
where
it's
quite
sensitive,
to
sort
of
performance
yeah.
So
that's
true,
not
only
just
for
what
you
just
said,
but
yeah
events
as
well.
B
B
It's
kind
of
the
same
concern,
Kyle,
I,
I,
think
there's
a
couple
things
as
corollaries
that
we
need
to
realize
if
we,
if
we
just
to
put
it
out
there,
if
we
want
to
go
down,
maybe
having
multiple
apis
or
additional
apis
for
the
front
end,
it
means
that
a
lot
of
things,
especially
in
JavaScript,
have
to
change
like
hooks.
If
we
want
to
implement
them,
the
client
can
no
longer
be
async.
They
now
have
to
be,
or
they
have
to
that.
B
We
need
to
think
about
that,
because
right
now,
they're
expecting
to
be
able
to
return
a
promise
that
probably
won't
work
we'll
need
to
make
them
synchronous
or
at
least
support
some
of
them
being
synchronous
and
understand
the
drawbacks
of
that.
Like
maybe
there's
some
that
you
want
to
not
await
and
just
fire.
You
know
asynchronously,
but
there's
some
that
you,
if
they're
mutating
the
context,
you
can
no
longer
await
them
right,
so
that
becomes
a
little
bit
tricky
same
with
the
provider
contracts.
D
E
C
I
do
have
this
actually
has
brought
up
a
question.
I
I.
Do
wonder
whether
the
client,
sdks
of
all
of
the
providers
would
easily
the
web
ones
and
all
the
client-side
ones
would
easily
support
the
current
spec
as
well
or
whether
they
would
have
to
be
yeah
like
I.
Think
flagsmith
fronten
long
would
have
to
be
sort
of
altered
quite
a
bit
to
support
that
that
core
spect
affects
individual
Flags,
because
it's
just
not
it
just
wouldn't
do
it
doesn't
really
have
a
use
case
for
doing
that.
G
I
think
I
think
the
essence
of
the
thing
here
is:
do
you
want
the
provider
to
keep
the
state
of
the
flags
between
get
flare?
Calls
right,
that's
literally
it
is
that.
Is
it
I,
don't
think,
there's
anything
more
than
that
like
no
as
always,
not
always,
but
almost
always
client
sdks
grab
all
their
Flags,
not
a
good
Uber
and
store
them
for
the
duration
of
that
session,
and
then
they're
just
grabbing
from
memory.
We
actually
don't
I
think
we
don't
expose
that
map
right
like
we're
in
Facebook.
It's
like
get
my
Flags.
G
G
E
I,
don't
think
it
I
think
that
it's
not
it's
not
exactly
that
simple
for
all
of
the
potential
providers,
because
of
like
the
dynamic
like
like
evaluating
rules
right
like
evaluating
rules,
mate
like
basically,
if
we,
if
we
allowed
like
a
synchronous
version
of
the
API
for
JavaScript
we'd,
basically
be
saying
like
you
have
to
do
all
of
your
all
of
your
rule.
Evaluation
statically,
like
at
the
very
like,
like
basically
you
have
to
you,
can't
use
like
a
like
a
web
worker
or
something
like
that
to
run
the
rules.
E
You
have
to
have
like
it
all
living
on
the
client
and
maybe
there's
no,
there
aren't
any.
Maybe
that
would
work
for
all
the
existing
provides
I
bet.
There's
a
provider
out
there
that
expects
that
it
has
to
make
a
network
call
like
at
boot
to
like
to
go
off
to
some
server
somewhere
or
some
web
worker,
or
something
that's
not
asynchronous.
Javascript
call
and
say:
hey
in
the
current
context.
Give
me
what
the
what
the
tell
me
what
the
flag
should
be.
B
Well,
well,
yeah
I
mean
flag,
D
works
that
way,
for
instance,
but
but
what
you
could
do
is
evaluate
those
asynchronously
all
initially
using
a
static
at
a
context.
That's
assumed
to
be
static
at
the
beginning
and
then
emit
unready
once
you've
evaluated
all
of
those,
and
that
kind
of
goes
back
to
your
your
point,
Pete,
where
we
could
maybe
take
the
current
API
and
and
hide
it
behind
a
synchronous
API
in
a
way
and
with
the
Assumption
on
how
that
operates,
would
would
be
I.
B
Think
is
that
at
startup
at
boot
you
get
a
context.
You
have
a
statically
configured
context
that
is
going
to
be
for
some
defined
amount
of
time
valid.
You
evaluate
everything,
taking
into
account
rules
that
you
want
that's
going
to
be
an
asynchronous
process.
Probably
it
would
be
pulling
down
rules
in
some
cases,
and
then
you
maintain
that
state
somewhere
and
then
just
act
like
allow
access
to
that
state.
Until
such
a
point,
it
becomes
invalid,
which
we
may
need
mechanisms
for,
and
then
you
have
to
do
kind
of
do
it
again.
B
B
C
Like
yeah,
there
is
definitely
a
confusing
thing
as
to
when
the
initial
asynchronous
initializations
should
resolve
around
caching
around
default
Flags
around
default
Flags.
If
you
don't
have
network
access
like
I've,
got
a
rough
idea
that
does
apply
with
flagsmith
and
I
think
it
seems
like
it
would
in
most
cases,
but
yeah
that's
going
to
be
quite
yeah.
Quite
complex,
I
wouldn't
I
wouldn't
be
surprised
if
a
lot
of
the
different
providers
act
in
totally
different
ways
are
like
resolving
around
that.
B
Pete
I'm
interested
in
at
some
point,
I,
was
mentioning,
maybe
that
we
could
leverage
the
proposed
event
apis
that
were
that
were
poc'd
for
for
kind
of
that
initial
asynchronous
load
and
I.
Think
you
shook
your
head,
so
I
don't
know
if
we
ever
came
back
to
that,
but
I'd
like
to
get
your
take
on
that.
E
Yeah
I
mean
I,
I
was
thinking
of
the
evaluation
context
thing
of
just
it's
it's
more
than
just
because
the
current,
because
the
current
async,
the
current
API,
assumes
that
at
any
point
you
can,
you
can
pass
it
in
a
new
evaluation
context.
I
think
that's
like.
Actually
the
fundamental
hard
thing
is
the
difference
between.
Is
this
evaluation
context
going
to
change
every
time
or
can
like
basically
yeah?
That's,
that's
the
that's
the
main
difference
in
the
Paradigm
there's
all
this.
E
This
other
difference
around
you
know
like
what
capabilities
are
able
on
a
different
platform
and
like
how
expensive,
Network
calls
are
and
stuff
like
that,
but
I
I,
really
I
really
think
like.
Actually
the
core
difference
is.
Do
we
need
to
like
support
a
different
valuation
context,
which
might
mean
like
actually
like
reevaluating
the
facts
and.
B
Be
honest,
I
think,
I
think
it's
a
waterfall
of
different
conclusions
that
come
from
whether
or
not
we
how
we
go
on
that
point.
I
agree
with
you,
so
I
think
that
is
important.
I
think
we
we
need
to.
We
need
to
look
at
it
in
terms
of
that.
Like
do,
we
want
to
treat
evaluation
context
differently
in
the
client,
because
I
think
the
the
question
and
there's
a
lot
of
data,
that's
going
to
feed
back
into
the
answer
and
then
the
the
answer
we
choose
there
is
going
to
have
consequences.
B
E
B
E
Where
is
I
think
we
can
take
that
part
on
and
do
that
inside
of
this,
like
like
layer
inside
of
the
SDK
and
and
allow
the
providers
to
just
give
some
like
core,
like
the
core
kind
of
like
fundamental
kind
of
like
functionality,
that
we
need,
like
the
adapters
and
and
and
so
and
solve
that
problem.
I
think
it's
I
think
it's
I
mean
maybe
I'm
I'm
kind
of
just
super
naive
about
it.
But
I.
C
D
B
B
B
D
A
D
As
like,
a
follow-up
then
get
us
started,
and
then
there's
obviously
a
lot
of
interest
in
this
so
like
make
sure
to
put
it
in
the
channel
and
try
to
get
it
there,
and
we
can,
you
know,
schedule
a
dedicated
meeting
to
this
one
if
we
need
to
or
definitely
follow
up
on
the
next
one,
but
yeah
probably
need
to
move
on
to
a
few
other
topics
quickly.
So
Perfect
all
right,
but.
B
I'm
next
so
I
mean
I,
don't
think
this
is
going
to
take
too
long.
I
have
a
board
that
is
currently
hidden
in
GitHub,
which
I'm,
which
I
did
a
quick
review
on
with
a
couple
people,
but
I
think
I'm
going
to
make
it
public
really
soon
and
all
it
does
is
kind
of
what
you
see
right.
There
establishes
a
security
Baseline
for
repositories
so
kudos
to
mostly
Justin.
B
To
be
honest,
because
I
think
that
basically,
everything
we
have
here
is
already
implemented
in
the
Java
SDK
there's
a
few
I
think
the
only
exception
is
SAS
scanning,
which,
especially
in
the
case
of
java
I'm,
not
sure,
is
extremely
valuable
because
we
have
things
like
flying
bugs
or
spot
bugs,
or
you
know
whatever.
It
is
now
and
check
style,
Etc,
I,
there's,
there's
free
options
for
SAS.
Getting
so
I
might
give
it
a
shot,
but
I
think
just
about
everything
else.
Here
is
implemented
in
the
Java
SDK
I.
B
Think
as
we
go,
we
have
what
we
have
1.
those
of
three
other
sdks
and
I
think
we
need
to
kind
of
bring
them
up
to
that
level
and
there's
a
varying
level
of
compliance
across
all
these
different
things.
So,
I'd
like
to
document
these
and
I'm
going
to
be
taking
some
time
myself
to
implement
them
in
a
lot
of
repositories.
B
A
B
Somebody
could
feel
free
to
correct
me
if
I'm
wrong,
there's
Alpha
support
and
six
store
for
it,
but
I
don't
want
to
adopt
an
alpha
thing:
I
digress
but
anyway,
so
there's
that
I'm
going
to
make
it
public
I'd
like
to
do
this.
If
anybody
has
a
huge
problem
with
this
proposal,
let
me
know,
but
yeah
we
can
have
discussion
when
I
convert
it
to
an
issue.
I'll
put
a
comment
in
the
channel
about
it.
Any
comments
right
now.
B
B
It
could
involve
things
like
disclosure
information
and
who
to
reach
out
to
if
there's
a
vulnerability
found
or
something
like
that,
if
you
guys
have
any
thoughts,
I'd
just
like
to
review
it
that
there's
nothing
formal
here,
I
just
yeah.
If
there's
anything,
anybody
thinks
we're
we're
missing.
That
really
needs
to
be
added
there,
I'd
like
to
do
it
so
I,
don't
know
if
there's
thoughts
on
that.
B
D
D
Yeah
I
think
that's
what
we'll
probably
end
up
doing.
Okay,
so
Justin.
Can
you
just
bring
that
up
in
the
governance
meeting,
then
I'll
make
sure
we
we
get
that
address.
Then
thanks
cool
next
one,
this
one's
kind
of
a
cool
update,
and
it's
probably
the
longest
well
PR
that
I've
ever
been
a
part
of.
To
be
honest,
it
was
almost
like
nine
ten
months
worth
of
back
and
forth
for
probably
like
five
lines
of
code
changed,
but
basically
it
was
adding
symante
convention
to
the
hotel
spec
for
feature
flagging.
D
This
applies
to
events
on
a
span
and
logs
so
they're.
Basically,
the
the
same
convention
can
be
worked
on
either
what
you
know
piece
the
kind
of
interesting
part
from
that
second
part
about
the
the
logs.
It
does
mean
that
if
a
vendor
wanted
to
just
you
know,
add
in
like
kind
of
lightweight
support
for
this,
you
could
just
basically
have
support
for
a
log
message
that
follows
this
convention
as
well.
You
wouldn't
have
to
pull
in
libraries
or
anything.
D
Having
said
that,
open
feature
has
a
couple
issues
open
for
for
the
1.0
sdks
right
now.
To
basically
add
a
hook
for
that,
it's
it
should
be
incredibly
simple
like
it's
it.
You
know
it
can
be
done
in
a
few
lines
of
code
and
it
would
basically
just
add
you
know
if
a
span
is
available.
It's
just
going
to
add
this.
This
basically
event
onto
it
in
a
certain
format,
so
those
are
all
open
and
available.
D
Docs,
there's
just
a
couple
right
now:
there's
one
for
Java
and
one
for
JavaScript.
There
is
some
feedback
from
Pete
that
I
still
need
to
take
care
of
where
we
want
to
have
JavaScript
in
typescript,
so
you
can
kind
of
toggle
between
it.
I
haven't
done
that
one
yet,
but
I'm
gonna
go
ahead
and
knock
that
out
and
also
have
some
kind
of
like
follow-ups
like
next
steps.
So
those
things
are
haven't
been
done
yet
but
they're
on
my
to-do
list,
but
there
are
open
items
for
other
sdks.
D
B
D
D
But
for
now
it's
it's
basically,
just
like
the
the
hello
world
example
of
feature
flagging
essentially
and
then
the
last
one
I
did
kind
of
choose
is
the
last
one
I'm
not
probably
going
to
give
a
demo
I
didn't
really
get
a
chance
to
dive
into
it
too
much
further.
I
think
the
next
step
may
be
just
like
in
ofap,
basically
to
kind
of
describe
the
goals
here
and
get
some
feedback,
but
but
at
a
really
really
high
level
and
Justin
kind
of
was
the
inspiration
for
this
originally.
D
But
if
we're
able
to
define
the
feature
Flags
somewhere
in
your
code
and
then
pass
that
into
the
sdks,
you
can
basically
leverage
well
the
compiler
for
one,
but
also
like
you
know
some
like
intellisense
type
stuff
in
your
Ides
to
like
autocomplete,
valid
flag
keys.
I
have
a
proof
of
concept
in
typescript,
which
is
pretty
cool.
Like
it's
aware
of
like
the
default
response
type,
so
it
only
shows
up
in
the
appropriate
methods.
D
Things
like
that,
I
really
like
it,
but
it
requires
you
know
a
little
bit
of
you
know,
work
and
I'm,
not
sure
how
it
would
apply.
You
know,
broadly
across
other
languages
or
if
it
even
needs
to
I,
also
don't
think
it
necessarily
requires
a
spec
change
to
do,
because
it's
just
like
another
way
of
passing
in
you
know
a
flag
key
and
default
value.
So
I'll
try
to
create,
like
a
at
least
an
initial
issue
there.
D
D
I
mean
I,
don't
like,
and
that's
something
we
can
talk
about,
I,
don't
think
it
would
require
any
kind
of
spec
change,
necessarily
it
could
just
be
in
the
sdks
and
we
could
basically
provide
the
mechanism
to
say
like
if
you
know
your
flags
ahead
of
time.
You
throw
it
in
this.
Actually
I'll
just
share
my
screen
real
quick,
keep
in
mind.
This
is
incredibly
rough,
but
basically
the
idea
is,
you
could
do
something
sort
of
like
this,
where
you'd
have
some
kind
of
like
fly.
D
Configuration
I
had
to
put
it
behind
this
method
here
for
for
typescript
to
basically
do
the
type
enforcement
piece,
but
that
would
allow
you
you
know,
because
this
is
the
key
and
and
the
default
value
and
then
basically,
depending
on,
like
the
method
here
and
I'm
I'd
have
to
look
at
why
this
is
not
fully
working,
it
must
have
a
typo
or
something
I
wasn't
fully
prepared
to
show.
Oh,
this
is
the
reason.
D
Basically
here
you
can
see
that
now
the
system,
you
know
we're
creating
a
client.
That's
like
feature
flag,
aware
now,
it's
like
literally
in
here
it
will
like
auto
complete.
You
see
that
six
isn't
in
there,
because
it's
a
string
value
and
we're
looking
for
booleans
and
stuff
like
that,
so
that
was
kind
of
the
idea.
Now
I
get
rid
of
this
up
here
and
all
of
a
sudden.
B
This
I
believe
Justin
and
I,
like
at
a
really
high
level,
talked
about
how
we
might
do
this
in
Java
and
I
believe
very
similar
things
are
possible,
I
mean
it
really
just
involves
some
additional
type
arguments,
so
the
compiler
can
help
you
with
some
of
the
stuff,
but
but
I
kind
of
agree
with
Mike
that
I
don't
think
it
needs
to
be
specked.
It's
just
a
nice
feature
we
can
add
into
sdks.
In
my
opinion,.
E
I
would
I
if,
if
there
was
some
magical
way
that
we
could
have
the
type
safety
extend
to
like
generics
for
the
method,
so
that
you
don't
have
to
say
Boolean
value,
string
value
that
has
been
driving
me
crazy
in
like
trying
to
in
like
playing
with
the
SDK
but
I,
but
I
also
get
that
it's
pretty
hard
to
do.
I.
D
A
A
D
F
A
B
D
You
include
that
in
the
doc,
so
Justin
I
think
that
is
it
because
the
the
at
least
at
the
very
least
the
structure
of
the
ofaps
are
kind
of
painful.
You
know
if
it's
I
think
we
can
yeah
look
at
how
other
tools
are
doing
it
successfully
and
see
what
we
can
do
there
and
then
maybe
once
they're
merged.
If
we
have
the
table
structure
easy
to
publish
somewhere,
you
know,
could
either
live
in
in
the
official
docs
or
in
just
the
repo
that
we
could
link
to
so
I.
D
D
Yeah
anyone
else
have
any
thoughts
on
that
I
think
it
makes
sense
it's
just
priority,
and
if
someone
has
a
chance
to
to
kind
of
work
on
earth
a
specific
details,
you
know
that
we're
looking
for
and
maybe
just
an
issue.
You
know
Justin.
If
you
want
to
create
one
or
something
we
can.
We
can
share
it
and
kind
of
chat
through
that
there,
but
yeah
I'm
up,
for
it
makes
sense.
F
D
D
Well,
I
think
it
probably
does
make
sense
based
on
Justin's
recommendation,
we'll
probably
just
cancel
like
the
regular
meeting
next
time,
and
if
we
want
to
use
that
for
something
client-side
specifically
could
if
we
want
to
do
a
client-side
some
other
time.
I
do
think
that's
a
big
Focus
over
the
next.
You
know
a
little
bit,
though
figuring
out
the
client-side
pieces
is
obviously
a
massive
part
of
feature
flagging
and
it's
something
that
we
hadn't
really.
D
B
Yeah
that'd
be
appreciated,
I
was
I,
was
thinking,
maybe
I'll
set
up
a
poll
in
in
the
channel
and
we
can
like.
We
can
just
assume
the
same
time.
I
don't
know
if
we
just
did
the
same
time.
Would
it
be
good
for
everybody
here?
Maybe
it's
not
necessary
to
a
poll
to
talk
about
client
stuff,
or
should
we
move
it
around
because
it's
going
to
be
on
the
22nd.
D
F
D
Want
to
change
the
data,
otherwise
we'll
just
plan
on
that
and
then
I
think
just
the
prep
work
would
be
the
issue
that
Todd
will
create
so
like,
let's,
let's
take
advantage
of
that.
So
we
go
into
that
meeting
with
a
lot
of
you
know
specific
questions
we
want
answered
and
hopefully
have
some
like
tangible
output
from
that
that
meeting.