►
Description
Meeting notes: hhttps://docs.google.com/document/d/1pp6t2giTcdEdVAri_2B1Z6Mv8mHhvtZT1AmkPV9K7xQ/
OpenFeature website: https://open-feature.github.io/
B
C
A
C
A
I'm
not
sure
what
the
turnout's
gonna
be,
but
we'll
I
guess
we'll
do
our
best.
I
think
Todd's
got
quite
a
bit
of
stuff
to
kind
of
talk
through
and
and
kind
of
demo.
I.
Think
honestly-
and
you
know
I
guess
I'll,
let
him
and
get
started
I
guess
we
can.
We
can
go
and
if
we
have
to
recap
I
Stillman
joins.
We
can
certainly
do
that.
I'll.
You
know
I
think
we
still
have
the
notes
here.
So
we
might
as
well.
A
A
Just
post
the
the
meeting
notes
again,
this
is
just
our
special
client
client
side
focused
meeting
today,
so
we
just
decided
since
we're
so
close
to
the
holidays,
that
we
would
just
do
a
a
more
focused
one.
Client-Side
was
a
very
Hot
Topic
at
the
last
community
meeting,
Todd
Todd
and
Pete
has
done
quite
a
bit
of
research
over
the
last
two
weeks
or
so
and
have
a
lot
of
I
think
we
have
a
lot
to
talk
about
a
couple
questions
that
we
would
like
to.
A
You
know
kind
of
chat
through,
and
then
you
know
if
we
come
to
some
kind
of
consensus,
we
could
start
working
on,
like
you
know,
finalizing
the
offeps
and
the
spec
changes
required
to
kind
of
bring
it
to
life.
So
I
think
that's
where
we're
at
I
think
we
probably
have
enough
to
kind
of
get
going,
though
so
I
think
hand
it
over
Dave.
C
A
B
A
B
B
I
I
wanted
to
quickly
go
over
like
a
little
proof
of
concept.
I
had
based
on
the
open
issue
in
the
spec
I
will
link
that
right
now
we
kind
of
have
basically
an
issue
in
progress.
I'll
put
it
in
the
in
the
chat
and
then
maybe
like,
if
you
want
to
add
that
to
the
doc.
So
this
is
kind
of
this
is
kind
of
a
an
in-progress
look
at
some
of
the
decisions
we've
we've
made
thus
far,
and
that
we
think
we
might
need
to
make
in
notes.
B
B
C
Maybe
we'll
we'll
get
into
the
details,
but
like
I,
definitely
be
interested
in
figure
and
like
digging
into
that
as
to
like,
like
where
we
draw
that
line,
and
why
we
wouldn't
what
like,
what
what
we
mean
by
considering
it
versus
supporting
it
all
that
kind
of
stuff.
But
I
don't
want
to
derail
you
yeah.
B
Well,
I
mean
no,
that's,
okay,
I
think!
That's
what
the
purpose
of
this
meeting
is
to
talk
about
that
kind
of
thing.
So
my
my
concern
my
concern
really
is
that
I
don't
think
we've
had
a
lot
of
input
on
on
mobile
and
I'd
love
to
get
more.
It
looks
like
that
may
be
changing
with
with
spotify's
involvement
that
they
they
have
a
swift
client.
So
that's
you
know.
Maybe
that
could
change,
but
I,
don't
see
so
far.
C
I've
never
heard
anyone
talk
about
that,
but
it
totally
makes
sense
and-
and
you
have
to
be
more
aware
of-
like
the
possibility
of
no
network
connection
at
all,
but
like
yeah,
okay,
I
feel
like
yeah,
I,
guess
I'm
on
the
same
page.
To
do
that
like
we
can
be
pretty
confident
but
not
100,
confident
that
it's
like
we're
covering
off
the
mobile
use
case.
I
guess.
B
B
So
I've
split,
basically
the
JavaScript
SDK
into
a
server
and
client,
and
this
is
mostly
just
to
avoid
having
to
re
like
redefine
every
single
interface
and
only
redefine
the
ones
that
that
were
impacted
here
with
this
change
and
I'm,
not
sure
if
this
is
how
we
want
to
do
it
long
term,
I'm
not
proposing
I'm,
not
opening
a
PR
with
this.
This
is
really
just
for
experimental
purposes.
B
Sort
of
set
context
on
the
open
feature:
SDK
is
now
asynchronous,
so
it
returns
a
promise.
This
isn't
something
that
I
think
we
necessarily
need
to
spec
I
mean
there's
existing
sdks,
that
that
do
async
evaluation
and
some
of
the
do
sync
evaluation,
but
I
think
for
the
case
of
JavaScript.
What
we've
seen
is
that
every
single,
every
single
vendor,
SDK
we've
looked
at,
has
done
synchronous
evaluation,
so
we
don't
want
to
kind
of
be
out
of
phase
with
that.
It
makes
things
like
react,
hooks
much
easier
to
write.
B
It
reduces
the
amount
of
loaders
and
Spinners.
You
have
to
do
all
over
the
place,
as
you
kind
of
await
responses
and,
and
the
other
thing
is
again,
because
we're
kind
of
working
in
the
context
of
a
single
user
there's
not
really
a
need
to
do
as
much
Dynamic
evaluation
with
whatever
source
of
Truth
you're
concerned
about.
You
can
kind
of
do
that.
B
Evaluation,
given
a
particular
context
up
front
store,
all
those
flag,
values
and
then
just
return
them
synchronously
from
a
from
basically
a
map,
and
that's
you
know
at
a
really
really
high
level.
That's
how
a
lot
of
sdks
kind
of
work
so
again,
as
a
consequence
of
that
you
have
this.
This
idea
that,
like
a
context,
is
more
or
less
static
for
a
client
SDK,
so
that
the
context
would
you
know,
might
be
a
user.
B
But
when
that
context
is
updated,
then
you
have
to
do
a
kind
of
fetch
or
a
resync
right.
So
if
I
added
a
new
attribute
or
I
logged
out,
that
means
I
have
to
mutate.
My
current
understanding
of
my
context.
It
may
involve
calling
a
back
end
and
then
getting
all
those
flags
again.
So
the
way
that
I've
kind
of
proved
Out
handling,
that
is
by
on
the
provider,
adding
this
additional
kind
of
kind
of
hook.
B
This
Handler
called
on
context,
change
and
so
on
context,
change
basically
says:
okay,
I
see
that
the
context
has
been
changed,
so
my
users
changed.
The
new
attribute
has
been
added,
whatever
I'm
going
to
do
some
action
to
reconcile
that
with
my
back
end.
So
in
the
case
of
the
launch
Darkly
provider
fpoc,
that
means
calling
identify
with
with
the
flag
Smith
the
flagsmith.
You
know
POC
I've
done.
It
means
calling
set
traits
or
identified
on
their
SDK,
so
that's
kind
of
what
re-synchronizes.
B
You
know
the
current
evaluated
flags
with
the
new
context,
so
I
can
show
you
what
that
looks
like
in,
and
a
provider
I
just
you
just
want
to
start.
Like
I
said,
I've
I've
been
able
to
implemented
three
providers
here.
So
there's
a
launch
dark.
We
want
a
flag,
Smith
one
and
and
a
flag
D1,
but
you
can
see
what
actually
happens
here
is
I've
implemented
this
on
change
on
context,
change
function
and
basically
we
call
this
dot.
Client
dot
identify.
B
B
On
certain,
with
certain
events,
so
this
is
like
the
log
out
click
I
set
my
context:
I
remove
some
properties
same
with
on
login.
You
know,
I
set
my
context
now.
This
is
all
you're
not
using
any
kind
of
like
higher
order,
react
SDK
or
something
like
that.
It's
all
pretty
low
level
JavaScript,
but
you
can
see
that
I
can
now
await
this
context,
set
it's
asynchronous
and
it
is
associated
with
doing
some
kind
of
mutation
in
the
back
end.
So
this
is
a
potentially
expensive
operation.
B
It's
also
in
terms
of
I
o.
It's
also
not
one
that
you
would
want
to
call
all
over
the
place
and
it
does
kind
of
set
the
state
kind
of
it
sets
your
context
kind
of
globally
a
concept
we
already
have
it
just.
Does
it
associated
with
a
promise
now,
so
I
can
quickly
quickly
demo
how
this
stuff
works.
What
it
looks
like.
B
B
So
here
we
have
flag
D,
you
know,
I
can
choose,
I
can
change
a
value
here,
and
this
is
kind
of
doing
the
same
kind
of
bulk
evaluation.
We're
talking
about.
You
can
actually
even
see
it
in
the
Network
console
just
refresh.
So
we
do
a
resolve.
All
that
resolves
all
our
flags.
You
can
see
all
the
flags
that
are
coming
back
in
the
response
here
and
then,
basically
anytime.
B
Actually,
no,
we
didn't
hear
sorry
what
was
this,
so
you
can
see,
there's
no
more
call
to
resolve
all
because
I've
already
resolved
all
of
the
flag
values
for
this
particular
context.
So
then,
if
I
log
in
and
my
context
is,
changed,
doesn't
really
matter
who
I
log
in
here
is,
but
this
is
going
to
change
my
user's
context.
You
can
see
now
things
turned
turned
yellow
and
that's
because
my
context,
I'm
now
logged
in
you-
can
see
this.
B
B
B
The
same
kind
of
thing
has
has
happened
here
with.
Oh,
this
is
like
flexible,
not
launch
directly,
but
I
I.
Think
you
get
the
idea,
so
basically
we've
every
time
we
log
in
as
a
user,
we
kind
of
reevaluate
the
flags
and
and
get
the
flags
for
that
particular
context.
Then,
when
we
log
out
we
again
kind
of
clear
those
flags
and
and
fetch
them
again,
so
this
this
kind
of
Paradigm
works
fine
with
both
flagsmith
and
launch
Darkly.
B
C
B
B
B
The
last
thing
I
guess
to
mention
is
we
also
implemented
closure,
so
there's
a
closed
function
that
the
open
feature
now
Expo
the
open
feature.
Api
object
now
exposes,
and
this
shuts
down
a
lot
of
the
listeners
and
stuff
associated
with
a
particular
provider,
so
I'm
I'm
doing
a
whole
bunch
of
console
debugging.
B
So
in
the
case
of
flagsmith,
you
can
see
you
know
we're
getting
this
change
event
every
few
seconds
because
of
the
way
we
set
up
the
polling
to
to
get
changes
in
the
API
and
when
I
switch
to
flag
D,
for
instance
those
all
stop,
and
that's
just
because
I've
now
called
the
on
close
at
the
API
level
I.
Actually,
in
this
case
the
I
didn't
explicitly
call
it.
B
This
is
especially
important
for
the
clients,
because,
because
of
the
way
they
work
with
events
and
with
storing
context,
it's
really
important
to
shut
down
shut
down
any
of
those
listeners,
yeah
I
think
that's
kind
of
what
I
wanted
to
demo
at
a
high
level.
You
know:
does
anybody
have
any
questions?
I've
tried
to
outline
all
of
the
changes
and
I
know
that
was
pretty
fast.
B
That's
synchronous,
I
I
struggled
a
little
bit
in
making
that
choice
and
I
mean.
Obviously
it's
not
final.
It's
just
a
POC,
but
the
only
reason
why
I
didn't
make
it
async
was
because,
at
least
in
all
the
use
cases
I
was
looking
at
it
didn't
seem
like
you'd,
be
too
interested
in
knowing
when
it
was
finished
or
being
sure
that
it
had
finished,
but
maybe
I'm
Maybe
I'm
Wrong
on
that.
For
me,
it
seems
like
mostly
fire
and
forget
concerns.
B
C
I
mean
have
you
made
it
and
that's
and
that's
and
that's
it
if
it's
never.
If
it's
not
going
to
return
a
value,
then
it's
I
like
it
seems
like
it
leaves
more
options
for
the
implementer.
If
you
make
it
a
promise
and
then
if
they
want
to
do
if
they
want
to
do
something
thoughtful,
they
can
and
if,
like
it
kind
of
just
seems
like
it
gives
more
options
and
it
doesn't
cost
anything
yeah.
B
D
Yeah
and
I
mean
I
know
it
was
just
you
know,
I
know
from
ours,
I
think
it's
asynchronous,
but
I
actually
don't
know
the
trade-offs
there
either
I
know
what
it
does.
It's
like
at
the
implementation
level,
it
flushes
the
events
but
I
also
don't
know
of
a
specific
use
case
where
you're
really
that
worried
about
it.
C
D
A
A
D
C
Until
I
got
I,
don't
know
if
this
is
something
you've
you've
kind
of
thought
about,
but
one
of
the
things
that
I'm
wondering
about
is
like
what
is
the
semantics
around
like
that?
Are
waiting
for
the
context
for
selling
context
like
what
like
would
we
want
to
kind
of
Define?
What
the
like
at?
What
point
that
promise
returns
like?
B
I
think
I
see
your
point.
I
I
think
the
really
what
the
what
making
that
asynchronous
does
is
it.
It
allows
us
to
await
that
hook
in
the
provider.
So
then
the
provider
can
decide
when
he,
when
you
know
they're
done
right
so
yeah
in
a
way
we're
pushing
that
decision
down
to
the
provider.
I
mean
it
could
return
immediately.
C
You
know
one
of
the
goals
for
open
features
to
kind
of
is
to
kind
of
essentially
abstract
over
the
different
providers,
and
so,
if
we
don't,
if
we
leave
the
semantics
totally
loose,
then
it
could
be
that
you
know,
like
you,
you,
someone,
someone
who's
actually
using
open
feature
would
be
like.
Oh
if
you're
you
know,
if
you're
integrating
with
launch
Darkly
you've
got
to
be
careful
because,
like
the
the
context
thing
will
actually
return,
but
in
Germany
like
if
the,
if
it's
not
I,
don't
I.
C
C
I
mean
I
think
that
was
I've
I'm,
pretty
sure
I
remember
at
least
one
provider
out
there
that,
like
some
open
sourcing
or
something
that
just
did
all
the
evaluation
in
process
and
in
that,
in
that
case
it
could
return
synchronously
but
I.
Think
that's
okay,
right
like
it,
then
it
can
just
return.
The
promise
immediately
or
you
know,
resolve
return.
B
But
that's
not
really
that's
I.
Don't
think.
That's
really
that's
a
little
bit
orthogonal
to
the
on
change
or
on
context,
change
Handler
because
use
there
is
still
there.
There
would
still
be
in
this
world
since
the
the
other
thing
that
happens
here
is
we
removed
context
from
the
since
we've
removed
context
from
the
evaluation
methods,
the
there
is
still
a
need
for
a
hypothetical
cloud-based
provider
to
kind
of
maintain
a
state
of
that
context
itself
and
then
feed
that
into
its
individual
evaluations.
B
C
B
B
I
mean
you're
right
like
that,
would
be
the
point
of
the
this
method
in
the
spec.
We'd
have
to
very
explicitly
say,
like
the
whole
point
of
this
method
is
before
it's
executed,
you're
in
one
context
and
you're
evaluating
you
know
these
these
you're
doing
these
evaluations
in
the
context
of
this
user,
even
though
contacts
aren't
really
necessarily
users
and
after
this
method,
returns,
you're
doing
it
in
the
context
of
the
next
user.
A
C
D
Just
something
I
know
from
like
event,
at
least
from
the
launch
directly
side.
We
don't
have
the
concept
of
style
in
that
case
like
if
it's
the
flags
that
are
there,
that's
what
it
knows
about
in
memory
and
when
it's
identified,
it's
called
like
to
the
SD.
We
don't
have
apparently
have
any
ways
that
we
expose
it
like
to
a
public
API
saying
you
know
you
called
context,
but
these
are
still
the
old
Flags.
It's
either
the
old
Flags
or
they're
overwritten
in
memory
with
the
new
Flags,
so
that.
C
B
Yeah
I
think
I
think
that's
not
a
bad
and
not
a
bad
point.
I
think
that's
something
we
should.
We
should
probably
dig
into
a
little
bit
more
because
I
agree,
I,
think
those
semantics
are
probably
different
provided
to
provider
and
I
think
this
is
also
that
particular
issue
is
also
going
to
be
very
relevant
for
mobile
sdks.
Where,
again
you
don't
have
an
internet
connection,
yeah.
B
So
there's
two
things:
there
was
two
things
I
wanted
to
well,
one
thing
I
wanted
to
highlight,
and
one
thing
I
wanted
to
specifically
ask
about
the
implementation
I
have
here.
So
one
of
them
is
as
a
as
a
as
a
really
kind
of
interesting
and
potentially
problematic
corollary
to
the
whole.
Here's
your
context
and
you
set
it
and
then
it
causes
some
potential
side
effect
in
the
provider
defined
by
this
unchange
Handler.
B
B
C
I,
don't
I,
don't
think
we're
going
to
have
a
choice.
I
think
we're
gonna
have
to
do
it
globally,
because
I
think
that's
going
to
be
providers.
That
can't
is
like
the
either
can't
or
would
have
to
basically
rewrite
there
their
entire
kind
of
like
SDK,
for
a
given
platform
to
support
the
idea
of
like
different
contexts
for
different
things
and
I
yeah.
E
Yeah
I
think
it's
even
conceptually
the
same,
because
more
or
less
even
with
that,
like
the
context
we
set
it
for
one
run
time,
and
in
this
case
we
just
have
millions
of
runtime
so
technically
setting
the
context
for
like
one
execution
and
the
entire
runtime
on
the
front.
That
is
conceptually
the
same.
B
E
I
think
so
either
you
remove
it
or
that
just
does
pretty
much
the
same
thing
so
one
or
the
other
one
or
the
other
way.
What
Michelle
didn't
say,
because
it's
even
setting
in
a
node.js
application.
Yes,
I'm,
sending
it
for
all
users
who
use
those
node.js
applications,
but
it's
still
on
the
per
runtime
basis,
and
it's
pretty
much
the
same
with
a
browser
that
it's
just
a
million
runtimes
and
the
two
are
equally
the
same.
C
E
B
So
you
can
you
can
you
know
if
you
had
that
instantiate
five
clients,
one
for
each
component,
like
you're
saying
how
do
you
reconcile
those
individual
contexts
with
the
Singleton
context
that
is
basically
represented
by
you,
know:
flagsmith's
state
or
launch
Darkly,
State
or
flag
D
the
flag,
D,
client,
state,
I
I,
don't
think
you
can
reconcile
it.
It
seems
like
I.
A
Mean
one
way
that
we
were
talking
about
how
you
could
potentially
look
at
it
is
like
server
in
a
lot
of
cases
is
like
multi-context
mode.
If
you
will
or
something
like
that-
and
it
makes
sense
to
have
these
like
different
levels
of
like
merging
context
because,
like
it,
just
it
behaves
differently
and
the
client
it's
like
single
context
mode,
essentially,
and
maybe
only
allowing
it
to
be
modified
in
one
place,
makes
the
most
sense.
A
I
can't
really
think
of
any
like
limitations.
To
that
I
mean
there
could
be
a
few
benefits
to
doing
it
at
the
client
side,
but
I
think
the
benefits.
You
know
the
the
perceived
benefits
there.
Don't
really
make
it
worth
that
the
additional
headache
that
we'd
have
to
take
on,
but
I'm
not
sure
how
everyone
else
feels
about
that.
D
D
D
To
me,
I
mean
it
gets
back
to
the
same
concept
of
like
I
mean
at
least
from
The
Lunchbox.
These
you
know
Centric
point
of
view
of
that.
Rather,
is
that
if
it
would
be
the
same
as
it's
not
providing
that
set
context,
API
people
are
going
to
be
changing
it
all
over
and
especially
if
it's
in
different
parts
of
like
a
front-end
application,
you're,
probably
going
to
be
in
for
a
bad
time.
C
I
mean
I
think
that
even
beyond
the
performance
impacts
like
if
you've
got
like,
let's
say
you,
you
subscribe
to
like
an
event
stream
for
like
this
context
like
I,
think
there'd
be
cases
where,
just
like
the
SDK
is
that
for
the
providers
it's
like
well,
we
can't
subscribe
to
like
we
don't
support,
subscribing
to
like
multiple
event,
streams
like
we
don't
have
like
a
way
of
demoxing
these
event
streams,
or
we
don't
have
a
way
of
like
doing
multiple
like
identify
calls
for
different
contexts.
At
the
same
time,.
B
C
B
Basically,
you
you
don't
like
for
this,
for
this
to
work
in
launch
directly
or
flagsmith,
or
even
the
flag,
D
SDK,
that
we
have,
you
basically
need
to
be
able
to
have
different
states
like
the
only
way
to
make
this
work
would
be.
If
launch
directly
said
you
can
have
multiple
users
logged
in
and
here's
how
you
identify
them,
which
I
think
is,
would
be
a
mess
and
I
don't
know
of
any
SDK
that
supports
that
we.
D
Kind
of
our
direct
SDK
doesn't,
but
we
do
have
I
guess
that
we
just
have
to
implement
our
provider
multiple
times.
So
we
have
a
number
of
customers
that
do
use
a
multiple
projects
on
a
single
front
end,
especially
if
you're
talking
micro
front
ends,
but
that
to
me
would
still
be
the
one-to-one
kind
of
mapping
so,
and
that
would
be
supported.
Today
is
my
understanding.
C
E
Think
yeah
I
think
what
we
really
need
to
do
here.
I
mean
we
are
about
this,
like
smaller
group
discussing
it,
but
as
this
affects
every
provider
out
there
I
think
this
deserves
an
offep
and
we
should
actively
ask
all
providers
all
providers
to
comment
on
whether
this
is
going
to
work
for
them
or
not.
I
think
this
is
such
a
substantial
decision.
E
C
B
Think
this
one
deserves
its
own
effect,
though
I
think
like
I
was
saying
the
same
thing
to
Mike
earlier,
like
that
this
particular
thing
we
need
to
I
think
have
a
dedicated
discussion
on
and
some
kind
of
consensus
I
am
of
the
opinion
and
it
I
I
didn't
I,
haven't
heard
much
disagreement.
I
I
think
I
I
heard
mostly
consensus
here
that
we,
we
probably
want
to
have
a
more
opinion.
B
Opinionated
take
on
on
this,
and
the
client
and
say
you
know,
context
is
global
context
is
global
and
it's
only
Global
and
there's
no
client
context,
and
you
know,
there's
a
one-to-one
between
the
global
static
kind
of
context
and
the
state
maintained
and
client-side
providers,
but
yeah
I
want
to
have
that
vetted
by
the
community.
Like
Eloise
is
kind
of
saying.
A
B
A
B
B
You
see
the
same
thing
in
flagsmith,
for
instance,
because
that
identified
call
is
expensive
that
one
that
kind
of
sets
you
know
who
the
user
is
the
end,
because
it's
asynchronous
that's
kind
of
what
I've
abstracted
behind
this
asynchronous
Global
set
context
so
from
an
API
perspective
and
a
usability
perspective
having
one
like
a
top
level,
async
call
that
you
know
on
a
login
or
on
a
logout.
You
call
to
set
your
context
and
change
your
user,
and
then
you
await
that
if
you
want
to
whatever
does
that?
B
D
From
what
I've
seen
of
it,
that
API
makes
sense
to
me,
I
mean
because
we
have
to
expose
at
some
point.
The
people
can
change
the
context,
because
there's
loud
reasons
to
I
think
from
our
perspective,
we
just
always
wanted
to
be
intentional.
You
know
so
that
we
can
then
talk
to
users
around
that
like
when
you
do.
This
is
you're
saying
you
know
it's
I,
oh
yeah,
we're
flushing
events
we're
getting
new
Flags
like
there's
performance
associated
with
it,
so
there's
gonna
be
certain
times.
D
D
A
C
C
I
was
gonna,
ask
about
like
whether
we
wanted
to
be
set
context
versus
update
context
and
have
some
kind
of
like
merging
thing,
but
maybe
set
context
is
good
because
it
kind
of
forces
it
kind
of
it
implies
more
of
like
this.
Is
this
kind
of
big
heavyweight
thing
you
don't
want
to
just
kind
of
like?
Oh
something
changed.
Let
me
just
throw
it
in
the
context
or
something
else
change
you
want
to
kind
of
like
make
it
a
more
kind
of
like
comp,
not
complex,
but
you
know
a.
D
Heavy
I
was
looking
it's
kind
of
like
the
HTTP
methods.
Almost
it's
like
a
patch
versus
a
pipe.
You
know,
put
you're
just
overwriting
everything,
that's
kind
of
what
that
is
to
me
for
that.
Like
so
yeah,
you
know
you're
wiping
out
everything-
and
this
is
a
bigger
thing
than
just
updating
you're
like
well
I'm,
just
incrementally
adding
info
to
it.
A
E
We
can
do
it
another
meeting
as
well,
so
just
to
make
sure
that,
but
now
that
we
will
be
speaking
about
it,
we
have
filed
the
initial
request
going
to
cncf
incubation
that
is
out
there.
There
is.
There
are
some
topics
to
fill
out
on
the
proposal.
You
can
see
the
proposal,
some
bits
and
pieces
are
missing
and
we
are
still
looking
for
volunteers
to
support
this
activity
or
parts
of
it.
A
B
A
A
Yeah
I
mean
I
I.
Not
none
of
these
are
super
super
important
but
they're
all
kind
of
related
to
client-side.
So
the
more
I
kind
of
thought
about
this
topic,
the
more
I
was
like
we've,
been
calling
it
client-side
for
a
long
time.
Maybe
that's
fine,
maybe
that's
the
terminology
that
kind
of
the
industry
expects
and
understands,
but
really
it
to
me.
It
seems
like
we're.
A
Almost
thinking
about
it
is,
like
kind
of
you
know,
multi-context
mode,
which
is
typically
server
and
like
single
context
mode,
which
is
typically
client,
but
you
could
definitely
you
know
in
some
situations
maybe
want
you
know,
maybe
like
even
PHP,
with
like
Tom's
example
about
you
know,
it's
like
basically
the
context
lives
for
a
single
request.
That
request
is
looked
up
every
time.
Maybe
that
wants
to
do
like
kind
of
a
bulk
evaluation
at
the
beginning
of
the
request
and
then
just
have
access
to
synchronous
methods.
A
You
know
things
like
that,
so
I'm
just
kind
of
wondering.
If
maybe
we
wanted
to
think
about
think
about
it
in
a
different,
a
different
way
and
it's
just
kind
of
a
maybe
a
thought
experiment.
It's
not
something
we
need
to
commit
to
or
anything,
but
just
maybe
a
way
to
look
at
it.
Maybe
that
also
helps
when
we
Define
the
spec
it's
like
in
this,
you
know
context
or
mode.
A
A
Yeah
you're
right,
I,
mean
and
I
think
that's
probably
the
reason
to
stay
with
that
terminology,
but
maybe
even
just
for
us
thinking
internally
about
like
the
problem
itself
is
more.
That's
that's
the
thought
process.
It
doesn't
really
matter
like
you
could
have
like
a
a
client
like,
even
if
looking
at
launch
directly,
they
have
client-side
stuff
and
then
they
make
very
special
notes
like
this
is
node
in
client
mode.
A
D
Could
be
so,
as
you
can
say,
it's
probably,
it
could
even
be
a
good
idea
overall,
like
I
agree
with
that
I
mean
we
do
have
a
lot
of
call
outs
of
trying
to
explain
single
versus
multi-context
I.
Just
think
it's
you
know.
We
got
to
figure
out
the
documentation,
part
in
keeping
everything
in
sync
sure.
B
A
B
Is
dependencies
especially
with
with
extensions
like,
like
so
say,
you
implement
some
kind
of
hook
or
something
if
that
hook
calls
browser,
Primitives
or
browser
native
functions?
It's
only
going
to
work
like
you
probably
want
to
say
this
is
compatible
with
the
web.
Sdk
saying
that
it's
compatible
with
the
single
user,
SDK
doesn't
kind
of
implicitly
tie
it
to
certain
runtime,
artifacts
and
apis,
which
I
think
is
you're.
Gonna
have
to
do
to
anything.
C
Yeah,
maybe
it's
more
kind
of
like
a
separate
thing,
though,
like
a
certain
like
because
yeah
I,
I,
think
I,
don't
know,
I,
don't
I.
Think
that's
like
a
a
separate
thing
of
like
the
which
I
guess
maybe
is.
Your
point
is
like
it's
to
distinguish
between
this
is
like
client-side
like
it
uses
a
browser-based
Thing
versus
client-side
like
it
operates
in
the
kind
of
single.
B
Exactly
because
that
dependency
is
going
to
have
to
Target
either
the
JS
SDK
or
the
web
SDK
right
like
it.
So
then
you
know
you're
you're,
choosing
you're
choosing
one
dependency
to
use
and
it's
gonna.
It
has
a
different
API.
And
then,
if
that
dependency
has
local
storage,
I
mean,
like
I
said
you
can't
use
the
J
like
to
use
the
jsdk,
it's
kind
of
not
going
to
work
because
then
somebody's
going
to
try
and
implement
it
in
their
node
app
and
it
just
won't
work.
C
C
B
B
I
I
did
send
a
proposal
or
like
not
a
proposal,
I
sent
like
a
quick
blurb
to
Mike
earlier.
That
was
like
well
what,
if
we
just
had
in
the
jssdk
openfeature.get
single
user
client
and
that
single
user
client
had
these
apis
on
it.
You
know
no
evaluation,
context
per
evaluation,
synchronous
evaluation,
I
mean
yeah,
I
mean
I
I,
don't
necessarily
think
that's
the
right
way
to
go,
but
it
was
it's
an
interesting
thing
to
think
about.
C
Yeah
I
I
think
again,
I.
Don't
think
it
would
be
possible
because
of
the
kind
of
like
the
fact
that
some
of
the
providers
are
kind
of
global
terms
and
they're
like
I,
I,
yeah
I,
don't
think
it'd
be
possible,
but
I
I.
My
my
head
hurts
a
little
bit
trying
to
think
of
like
how
you
would
support
the
idea.
A
It
could
be
like
a
factory
but
yeah
I
mean
that's
kind
of
what
split
does
like
they
have
like
a
a
factory
and
you
could
spit
back
a
synchronous
or
async,
but
it
doesn't
I,
don't
know
you'd
have
to
kind
of
play
around
with
it.
It
may
actually
be
easier
to
maintain
and
stuff
that
we're
able
to
have
two
separate
ones
that
share.
You
know
like
the
the
implementation
pieces,
but
like
the
the
interfaces,
are
kind
of
clearly
separated,
maybe
maybe
nice
but
yeah
I.
B
C
D
A
C
It
would
be
neat
if
there
was
some
way
for
us
to
still
allow
a
provider
to
be
like
a
universal
provider
and
not
kind
of
force
every
like
every
job.
Everyone
who
supports
JavaScript
to
have
to
provide
two
different
JavaScript
things
like,
even
if
it
was
just
a
different
set
of
method,
calls
or
something
I,
don't
know.
B
C
I
think
I
mean
I.
Think
all
of
the
the
on
clothes
would
be
that
like,
if
you,
if
you're
thinking
about
like,
if
you
really
do
care
about
those
analytics
events,
then
on
clothes,
would
be
helpful
for
processes
being
shut
down,
particularly
if
you're
you
know
we're
a
cloud
native
doodad
and
Cloud
native
things
get
shut
down
all
the
time.
Yeah.
B
You're
right,
there
is
definitely
sorry
go
ahead.
Well,
I
was
going
to
say
the
other
thing.
I
didn't
actually
explicitly
call
out
too,
because
it's
been
there
for
a
while,
it's
the
event
handling,
so
the
event
handling
is
also
valuable
for
the
server.
So
I
didn't
explicitly
show
you
that,
but
like
the
way
that
this
this
works
in
terms
of
like
we
made
a
change
in
the
back
end
and
then
the
UI
is
updated,
is
you're.
Subscribing
to
events,
that's
also
totally
valid
in
both
the
client
and
the
server
to
change
events.
C
I
think
it
there
is
also
I
think
it
would
be
pretty
rare,
but
there
is
definitely
scenarios
where
the
server
contacts
would
be
static.
Right,
like
if
you're
not
doing
anything,
you
user
based
and
you're
just
doing
like
infrastructure
level,
like
you
know,
like
Canary,
releasing
on
a
like
across
a
fleet
of
servers
or
something
something
like
that.
Then
you
still
want
feature
Flags.
A
Yep,
all
right
so
we're
getting
pretty
close
to
the
end
of
the
hour.
I
did
want
to
mention
real
quick
that
I
did
create
like
a
high
level.
Client-Side
feature
flag
issue.
It's
on
the
roadmap,
I
believe
I
put
it
in
the
dot
GitHub
repo,
which
is
kind
of
weird,
but
I
I
thought
that
that's
a
good
like
org
level
place
for
it,
and
then
we
can
obviously
link
to
all
of
the
other.
You
know
repos
that
need
to
have
you
know,
Associated
work.
E
A
It
I
think
Todd
is
going
to
basically
go
through
what
we
talked
about
today
and
make
sure
all
those
op-ups
that
are
later
up
to
date
and
I
think
probably
throw
them
in
like
the
slack
Channel
or
something
once
they're
ready,
I'm
going
to
make
it
a
little
bit
more
yeah
get
people
give
some
awareness,
I.
Suppose
people
have
a
chance
to
look
at
it.
I
would
expect
the
contribution
level
to
probably
be
a
little
little
low
over
the
next
week
week.
E
A
D
A
If
we
could
basically
yeah
in
January,
especially
if
we,
you
know
make
sure
that
everyone
has
their
their
chance
to
get
their
last
kind
of
say
in
there,
we
can
get
those
things
merged
and
move
on
to
the
spec
and
then
implementation.
So
I
think
you
should
move
relatively
quickly.
There's
not
a
ton
of
open
questions.
I
think
and
you've
proven
that
we
can
make
it
work
across.
You
know
multiple
sdks
and
it
seems
to
work
pretty
well
and
fit
into
a
lot
of
the
existing.
A
C
Well,
I
think
we
might,
we
might
end
up
pushing
it
out
a
little
later
because
because
the
the
dates
aren't
going
to
work
for
Todd,
I,
think
and
I
think
it
would
be
when
you
get
Photon
to
be
there,
so
it
might
be
in
the
new
year.
It
might
need
to
push
it
out
to
the
new
year
before
we
talk
to
them
and
I'm
still
trying
to
line
up
calls
with
We've
split
and
Cloud
B's
and
well.
Oh
yeah.
We're
going
to
talk
to
Thomas,
go
50
flags
too,
but
yeah.