►
From YouTube: OpenActive W3C Community Group Meeting / 2018-11-07
Description
A public hangout for members of the OpenActive W3C Community Group.
https://w3c.openactive.io/meetings/2018-11-07-booking-feedback
A
A
B
C
D
F
H
D
It's
my
trick
me
from
the
Football
Foundation,
so
kind
of
interested
on
this
from
reviewed
levels,
kind
of
working
prices
for
England
on
this
as
a
sort
of
a
project,
but
also
from
the
city
point
view
in
terms
of
how
use
the
contrast
size
as
dad
Dan,
was
saying
also
some
of
the
applications
such
as
up
shop,
which
is
online
monitoring
tool
and
also
pitch
finder
owl,
so
future
use
of
the
api's.
Well.
Okay,
thank.
A
I
J
A
J
This
is
just
a
proposal
after
all
and
so
jumping
into
the
content,
then,
and
the
main
question
here
is
around
leasing
for
booking.
So
when
you're
going
through
a
booking
flow,
if
you
imagine
amazon.com,
you
could
pick
the
thing
you
put
in
your
basket.
You
go
to
the
checkout
page,
you
put
your
personal
data,
then
you
put
your
payment
details
in
and
then
you
confirm
the
booking.
Now,
don't
if
you
know
this,
but
in
amazon.com,
if
there's
only
one
book
left,
someone
else
can
steal
that
from
your
basket.
J
J
That
spot
is
reserved
for
you,
so
no
one
else
can
take
that
spot
until
you
finish
the
flow
when
you
finish
filling
in
your
personal
details,
the
next
page
is
the
payment
details
and
you
get
an
extra
eight
minutes
to
do
that.
So
they
give
you
five
minutes
to
the
personal
details
and
eight
minutes
to
the
payment
details.
J
So
obviously
there's
the
different
approaches
there.
So
if
you
go
to
the
next
slide,
so
that's
the
first
bit
of
context
we'll
come
back
to
that.
Make
sense.
Okay,
nothing!
Great
okay,
second
bit
of
context
from
previous
call,
is
that
there's
two
ways
of
doing
booking
if
you've
you've
got
a
booking
system.
You
might
already
be
aware
of
this
respect.
J
Peyman,
so
there's
two-phase
commit
things
so
in
order
to
make
sure
the
booking
and
the
payment
happen,
and
that
neither
happens
without
the
other,
which
would
be
bad
need
them
both
to
go
through
and
you
have
to
do
what's
called
the
two-phase
commit,
which
means
you
have
to
say
I'm,
reserving
one
and
then
do
the
other
and
then
confirm
the
first.
So,
on
the
left-hand
side,
you've
got
a
two-step
booking,
where
you
first
reserved
the
order.
J
So
that
thing
in
your
basket,
you
then
capture
the
payment
and
confirm
the
payment,
and
then
you
book
the
order
to
confirm
the
thing
in
the
basket
on
the
second
option,
be
there
on
the
right-hand
side
is
the
other
way
around.
So
you
take
it
up
effectively,
at
least
on
a
payment.
You
confirm
the
booking,
and
then
you
go
back
and
confirm
that
payment
afterwards.
So
you
see,
if
I
mean
it's
just
like
interlocking
the
opposite
way
around.
G
J
A
summary
of
the
previous
discussion
that
we
had
and
an
input
from
a
number
of
organizations
I'm
not
sure
if
fun
I,
don't
think,
is
on
the
call.
Today,
however,
one
of
their
key
bits
of
feedback
was
that
there
was
a
lot
of
complexity
in
the
previous
version
of
the
spec
in
terms
of
the
number
of
calls
needed
to
be
made.
Another
bit
of
feedback
we've
received
from
smaller
booking
systems
is
that
it
requires
and
the
current
versions
that
requires
you
to
implement
more
than
they
necessarily
support
so
releasing.
J
This
is
the
journey
that
a
user
can
go
on
and
it's
annotated
on
the
left
and
right
hand
side.
So
just
coming
through
the
journey
before
we
talk
about.
What's
on
the
left
and
outside
the
left
and
right
side
there.
If
you
look
at
the
Select
register
a
book
and
pay,
it's
generally
the
flow
that
you
go
through
on
any
kind
of
site
or
portal.
You
select
the
thing
you
want.
You
bear
just
to
put
your
information
in
or
log
in,
and
then
you
pay
for
the
thing.
J
At
the
end,
those
three
steps,
maybe
not
all
necessary
if
you're
using
Apple
pay
and
you're
using
your
thumb,
you
might
skip
straight
to
the
end.
You
select
and
then
book
and
pay
and
register
happens
with
your
thumbprint,
but
those
three
things
tend
to
happen
and
obviously
the
question
is
at
what
point
in
that
process:
do
we
allow
people
to
reserve
the
place?
J
Really
there's
the
the
checkpoint
at
the
beginning,
where
you
say
how
I'm
interested
in
this
particular
squash
court,
then
there's
the
checkpoint
halfway
through,
where
you
say,
I'm
interested
in
a
score
score,
and
actually
this
is
my
full
name,
surname
and
email
address,
because
I've
logged
in
and
then
there's
the
finish
of.
Actually
here's
my
payment
details
I
want
to
book
it,
and
so
that's
the
journey.
J
You
and
so
before,
before
I
talk
about
technically
how
I
know
we
had
some
of
this
on
the
last
call,
but
just
for
those-
and
you
maybe
does
anyone
here
have
any
preference
as
to
whether
you
think
you
would
like
to
allow
reservations
from
the
beginning
of
this
process.
So
someone
timecard
looking
stolen
from
the
basket
at
all
or
whether
you'd,
rather
things
be
stolen
until
the
last
minute,
a
bit
like
Amazon
and
only
when
it's
paid
is
it
confirmed.
C
L
Yes,
we
did
very
definitely
get
feedback
yesterday
to
say
that
users
in
general,
wanted
to
have
the
least
supplied
as
early
as
possible.
I
think
that's
something
that
we
would
probably
need
to
implement
in
the
stage
two,
because
we're
not
the
system
itself
doesn't
support
anonymous.
Lease
is
so
a
bit
of
internal
work
to
manage
that.
So
our
first
version
of
this
it
would
only
be
checkpoint
two
that
we
actually
provide
the
lease,
but
obviously
because
the
way
this
is
structured
we'll
be
able
to
go
back
and
retrofit
that
without
any
any
changes,
the
specification.
J
Great
does
anyone
them
so
it
sounds
like
we've
got
some
everyone
so
far,
I
said
checkpoint.
One
is
the
ideal
but
checkpoint
two,
because
some
is
where
they
can
get
to
initially.
Does
anyone
think
just
and
it's
totally?
Okay,
obviously
because
it's
different
people
different
systems,
but
they
they
don't
want
to
do
any
leasing
at
all,
ideally,
is
and
just
just
have,
as
a
preference
I
mean,
rather
than
as
what's
possible
within
the
system
as
a
preference.
E
G
J
A
So
I
think
what
we
have
in
the
API
currently
is
that
if
at
least
yeah
we're
Elise
has
been
generated
that
the
time
remaining
on
that
lease
is
available
somewhere,
which
would
mean
that
you
can
then
do
implement
the
countdown
on
the
client
and
in
the
case
where
you
have
multiple
things
you
could
and
there
needs
to
be
separated,
and
you
could
still
do
that.
To
give
the
user
some
feedback.
E
L
We
have,
it
should
be
in
a
standard
or
not,
but
if
someone
is
very
slow
and
or
an
app
keeps
refreshing
the
lease
forever
could
we
provide
it?
Have
the
ability
to
just
tell
no
so
there's
you
know:
I
can
my
lease
it
for
10
minutes,
but
the
overall.
These
period
is
like
30
minutes,
and
if
you
had
past
that,
then
we
can
position
to
say
lease
abandoned,
even
though
it's
only
mean
four
minutes.
Since
the
last
attempt.
A
That's
good,
it
doesn't
say
it
seems
reasonable
to
do
that.
I
was
just
trying
to
think
through
about
how
we
might.
What
do
you
know
in
the
specification,
and
you
know
whether
we
would
kind
of
mandate
that
as
an
as
a
mechanism
or
whether
we
would
just
indicate
that
that's
an
option
that
providers
have
and
maybe
just
define
what
that
error
code
or
error
status,
would
look
like
the
nice
ending
I'd.
J
J
The
way
that
you
work
with
this
spec
is
that
you,
you
assume
that
c1
and
c2
are
implemented
because
you
won't
know
otherwise
and
because
the
difference
in
whether
they
they
lease
or
not,
is
the
thing
that's
happening
in
the
background.
So,
basically,
what
happens
is
that
you,
you
load
up
the
basket,
maybe
before
the
users
even
registered,
and
you
check
in
with
c1
to
say
great
I'm.
Keen
to
this
is
this
is
a
user.
They
want
to
look
this
thing.
J
It
returns
the
price
and
then
VA
tu
basket
details
whatever
is
included
than
that,
and
you
display
that
to
the
user
as
soon
as
that,
you
then
register
that
user.
You
then
check
in
with
c2
and
say
the
same
thing,
but
now
here's
my
user
details
and
then,
when
you
want
to
do
the
booking,
you
do
the
same
call
effectively
again.
J
But
this
time
you
include
the
payment
details
you've
taken
and
the
idea
is
that
each
time
at
c1
and
c2,
if
you
check
in
that,
when
you
check
in
it
actually
gives
you
a
lease
expiry
date
and
time.
So
you
can
check
in
with
c1,
and
it
will
tell
you.
You've
got
five
minutes
now.
I
was
a
good
question
about
whether
we
allow
someone
to
check
in
again
and
extend
it
and
I.
Think
what
you're
saying
there
is
that?
Actually,
yes,
maybe
that's
the
thing
that
we
will.
J
Let
people
do
but
then
there's
a
to
a
point
to
a
maximum,
but
within
the
scope
of
what
specified
here.
There's
no
reason
why
you
couldn't
have
a
c1
check-in
repeatedly
until
the
point
where
you
don't
get
a
lease
anymore
and
even
then
you
could
continue
to
check
in
with
c1
if
the
basket
changes
or
if
you
wanted
to
check
and
check
the
price
again
after
a
certain
period
of
time
or
whatever.
That
was
because
there's
no
cost
to
that
call
and
should
be
fairly
quick
and
there's
no
transaction
behind
it.
J
If
there's
no
lease
and
then
then
the
broker
could
continue
to
check
in
like
that
they
just
wouldn't
get
any
lease
and
the
way
this
works
is
that
there's
no
assumption
through
c1
c2
and
the
booking
step
that
Elise
has
actually
been
given
at
all.
So
you
can
continue
all
the
way
through
without
at
least
being
given
and
then
still
the
booking
succeeds
if
the
things
are
available
at
the
end,
of
course,
if
a
lease
has
been
given,
then
the
lease
will
be
used
at
the
last
step.
If
that
makes
sense,.
J
J
A
Maybe
if
I
could
just
add
something
I
think
is
important
to
highlight:
is
this
approach
with
the
broker?
Basically
defining
a
unique
ID
that
is
maintained
through
this
process
means
that
the
provider
is
on
the
server
side?
There
is
no
state
maintained
at
all
unless
there
is
a
lease
in
which
case
if
there
is
a
lease,
and
you
only
need
the
state
required
to
maintain
that
lease
minimum
it
being
the
the
UUID
unique
ID
that
the
broker
has
given
you.
L
Could
ask
a
question:
yeah,
okay,
it's
seen
here
from
from
legend
I
read
the
document
yesterday
and
I
think
what
it's
saying
is
that
you've
effectively
got
a
full
order,
so
what
you're
doing
is
you're
sending
an
older
backwards
and
forwards?
It's
not
committed.
It's
not
confirmed.
Therefore,
an
older
quote
so
you're
going
to
send
in
this
is
the
order
I
may
want
in
the
future,
and
the
UUID
is
affected
with
the
order.
Number
first
I
thought
it
was
for
the
individual
request,
but
I
think
not
I.
Think
it's
actually
for
the
whole
order.
L
So
what
you're
doing
is
you're
saying
this
is
what
I'd
like
to
buy
and
there
might
be
one
two
three
four
five,
then
you
add
a
x1
and
then
we
have
to
say:
yes,
you
can
buy
at
least
all
the
prices.
If
we
happen
to
know
who
the
orders
for
then
we
may
want
to
amend
the
prices
depending
on
memberships.
That's
a
future
thing,
but
in
potential
we
can
do
that
and
then
we
send
the
whole
order
back
with
additional
information
on
leasing
and
other
things.
L
And
finally,
we
just
at
the
very
end
say
presumably
will
include
the
UID.
So
this
is
the
order
quote
which
we
prepared
earlier.
There
may
be
changes
in
it
because
you
may
be
going
to
do
that
as
a
first
step
in
B
or
it
may
be
something
you've
gone
through
four
or
five
stages
first,
and
then
that
final
thing
is
there.
It's
kind
of
a
commitment
is
that
right?
Yes,.
A
If
that
order
has
already
been
successfully
good
place,
but
somehow
the
response
got
lost,
then
the
provider
can
indicate
an
error
or
just
provide
the
link
to
the
successful
order
and
if
it
hasn't
been
place
because
it
hasn't
been
locked,
then
it's
safety
plan,
so
it
so
becomes
an
idempotent.
At
the
end.
J
J
However,
it
does
mention
that
the
way
to
do
that
is
you
would
need,
at
least
in
order
to
guarantee
complete
the
complete
basket,
successful
failure,
because
if
you
don't
have
a
lease,
then
if
one
of
those
bookings
goes
through
conduit,
you'll
end
up
with
half
the
basket,
and
so
you
need
to
have
everybody
in
that
transaction.
Every
booking
system
influencing
at
least
see
two
and
you'll
know
that,
because,
as
you're
adding
things
to
the
basket,
you're
getting
at
least
expiry
times
for
each
one,
so
you'll
know
the
total.
J
It
might
be
worth
to
make
that
a
bit
easier,
putting
not
just
the
lease
expiry,
but
the
total
potential
lease
extension
in
there
to
because
there's
a
difference
between
it
will
expire
in
a
minute
and
actually,
as
the
inside
earlier
will
expire
in
a
minute,
and
it
won't
be
able
to
be
renewed.
So
you
have
the
basket
and
then
assuming
that
you
have
all
that
and
all
of
those
leases
in
place,
then
you
can
go
ahead
and
take
the
payment
and
then
go
and
book
them
all.
J
J
J
J
G
A
A
It
just
becomes
much
more
complex
when
you're,
basically
interacting
with
multiple
providers
behind
the
scene.
You
know
the
default
flow
here.
It
will
be
either
you'll
you'll
get
the
entire
order
booked
or
not,
but
once
you've
got
multiple
backends,
it's
difficult
to
do
that
orchestration
without
adding
a
whole
extra
layer
on
top
which
it's
not
clear.
We
need
yet
so
I
think.
So.
One
of
the
reasons
why
we've
thought
ahead
about
a
few
of
these
things
is
to
make
sure
that
we
haven't
boxed
ourselves
into
a
corner.
A
And
there's
no
required
yeah,
so
we're
kind
of
trying
to
acknowledge
that
that's
potential
future
requirement
and
test
the
design
against
it.
But
it's
not
necessary
that
were
considering
in
scope
for
this
first
release
and
it's
very
waiting.
A
broker
wouldn't
necessarily
have
to
support
she's
against
multiple
backends.
If
they
felt
that
that
was
detrimental
for
their
user
experience,
they
could
just
filter
the
user.
Through
you
know
a
series
of
I.
L
Think
from
the
provider
perspective
as
well,
even
ignore
any
commercial
implications
of
mixed
baskets
against
the
competitors,
which
probably
isn't
an
issue.
The
overhead
with
managing
this
multi
provider
basket
really
is
very
significant.
You
need
consistency
of
leases,
need
a
rollback
process.
A
whole
load
of
things.
I
wouldn't
have
thought
this
isn't
even
a
version
to
opportunity.
I
would
think
it's
you
know.
If
it
should
be
room
for
five
years
successfully,
then
we
might
think
about
it.
So,
whilst
I
recognize
it,
we
should
make
sure
we're
not
backed
into
a
corner
and
I.
A
J
And
it
might
be
worth
just
in
terms
of
the
design
and
the
back
into
corner
stuff
might
be
worth
thinking
about.
Maybe
having
this
setup
working
such
where's,
the
booking
system
advertises
whether
they
are
c1
c2
or
neither
as
part
of
the
feed,
to
make
it
really
available.
So
it's
not
just
a
case
of
trying
it
and
seeing
what
you
get
back
as
much
as
it
is
a
bit
more
of
a
robust.
You
know
what
you're
going
to
get,
so
you
know
what
to
expect
consistency.
You
know
what
you
think
about.
L
Firstly,
I:
don't
think
the
booking
system
ought
to
need
to
no
I,
don't
think
you
should
change
to
behavior
I
mean
the
whole
point
about
this
design
is
so
that
it
just
works.
I,
don't
know
what
value
that,
because
the
customer,
the
end
you
end
used
to
say,
rushed
through
this
registration.
President
wise,
you
might
lose
the
you
might
lose
the
booking
I.
Don't
think!
That's
something
you
want
to
advertise,
so
I'm,
not
really
sure
I
see
the
value
of
that.
J
J
If
you're
going
straight
to
be
broke,
ideally
you
will
take
it
from
c2.
So
you
know
it's
the
correct
amount.
You
authorize
that
payment
with
the
payment
provider.
You
then
confirm
that
at
the
booking
system,
so
you
make
that
payment
in
the
booking
system.
You
say
this
is
the
payment
it's
taken.
These
are
the
last
footages
to
the
card,
etc.
That
gets
confirmed
and
as
soon
as
that's
confirmed
by
the
booking
system,
you
then
catch
the
payment
and
authorizing
capture.
2-Step
process
is
the
one
that's
supported
by
all
payment
providers.
We've
found
so
far.
J
It
means
that
the
booking
system,
if
you
wanted
to
be
if
you
were
a
very,
very
small
booking
system-
and
you
wanted
to
do
this
as
a
very
lightweight
first
implementation-
you
don't
need
to
implement
that
small
arrow
at
the
bottom.
That
blue
arrow
and
that's
all
you
need-
is
that
one
call-
and
that
gives
you
booking
that
works
across
all
the
different
brokers,
of
course,
for
more
advanced
booking
systems.
Where
you
have
leases,
you
read
them
in
situ
and
even
see
one.
J
Would
they
give
you
the
rest
of
the
functionality
and
sounds
like
over
time?
We
want
to
really
encourage
people
to
do
that,
to
see
you
to
and
see
one
I
suppose
you
can
see.
His
point
might
be
a
few
years
before
people
see
the
value
in
implementing
those
things,
but
as
soon
as
we
show
them,
the
stats
of
basketb
and
people
may
be
annoyed
about
missing
out.
Can
there
all
comparing
people
with
leases
to
be
without
and
success
rates
and
things?
J
We
can
probably
make
the
case
that
it's
useful
things
have
the
data
as
well
to
make
it
more
competitive
when
c1
and
c2,
but
without
mandating
it
at
this
stage.
I
suppose
that's
the
key
with
all
of
this
is:
if
we
don't
mandate,
c1
and
c2
now
we
will
hopefully
get
more
people
implementing,
because
it's
gonna
be
cheaper
and
easier
to
do
so,
to
increase
the
volume
of
data
available
overall
and
then
over
time.
We
can
look
together.
The
experience.
J
F
Just
a
bit,
so
that's
from
our
single
page
process,
so
we've
implemented
something
that
does
effectively
c1
c2
and
then
that
final
b
payment
that
b
order.
Sorry
so
to
the
both
order,
quotes
in
the
order,
but
currently
on
our
public
site
were
just
doing
the
b
payment,
the
simple
one
so
be
authorized.
Then
we
make
the
order
and
then
we
captured
payment
and
were
actually
got
both
running.
So
some
people
are
receiving
the
c1
c2
UI,
which
is
slightly
different.
That's
that's
I!
That's
the
UI
from
the
other
one,
but
it's
been.
F
A
J
A
A
That
was
gonna,
be
my
next
question
so
currently
in
the
AP
a--
in
the
booking
api.
It
says
that
providers
should
be
it.
You
should
be
able
to
do
a
get
request
on
the
the
ID
from
you've
got
for
an
item
in
the
feed
and
that
the
get
request
on
that
will
return.
You
current
availability,
so
you
suggesting
that
we
don't
need
that
anymore
or
that
is
just
us
of
supports
or
separate
things.
We
can
be
border
quite
pinpoint.
A
J
We
don't
need
what
was
there
as
a
get
request
anymore,
because,
although
that
won't
be
useful,
it
probably
forms
part
of
the
opportunity
api,
which
is
that
you
can.
You
can
make
and
rather
than
having
the
booking
api,
require
one
component
of
the
opportunity
api
and
have
some
kind
of
next
actually
separate
to
so.
This
flow
works
and
time
independently.
With
these
two
endpoints,
they
can
be
separately,
authenticated,
cetera
and
then
the.
J
Opportunity
a
bi
whether
we
keep
in
option
or
whether
we
want
to
still
recommend
that
and
so
that
we
can
have
that
final
check.
I
think
the
main
difference
to
flag
is
an
order
quote
we'll
give
you
a
basket
response.
I
want
by
these
three
items:
cost
as
this
and
I
can
the
other
thing
to
adequate
checks
is
I.
Can
book
them
together,
because
you
might
have
a
table
tennis
court
and
a
badminton
court
in
the
same
physical
space,
and
you
put
them
in
the
basket
you
might
find
they
don't
actually.
J
That's
what
they
build
ability,
the
basket,
availability
and
the
price,
as
well
as
the
lease
the
availability
check,
which
is
the
thing
that
we
had
before
there's
something
slightly
different.
So,
instead
of
a
basket
of
three
items
and
checking
all
those
things
around
it,
the
availability
check
is
for
a
single
item.
One
of
the
options
I
have
available
to
me
availability
and
offers
so
at
all
junior
senior
and
some
events
that
might
be
Tuesday,
Wednesday,
Thursday
Friday.
J
A
I
was
going
to
lean
in
the
same
way.
I
kind
of
know,
Nick's
point
that
there
is
a
kind
of
opportunity
API,
which
is
really
kind
of
dug
into
in
great
detail.
Yet
that's
where
that
end
point
wouldn't
actually
live,
but
it
could
move
to
that
spec
later
yeah,
we
issue
a
new
release
or
the
booking
thing
we
just
we
just
build
on
that
spec.
A
A
F
I
think
for
me,
I
guess
the
question
is:
if
I
say
I
was
say
we
say
we
were
opening
up
our
marketplace
and
we
wanted
people
to
be
able
to
get
the
opportunity
information
do.
Would
we
want
that
end
point
as
part
of
the
specifications
for
it
to
be
for
us
to
fully
implement
it
and
I
think
in
the
other
spec
we
wouldn't
want
it
unless
we
were
looking
at
booking.
L
L
Yeah,
so
I
I
think
there's
gonna
be
some
challenge
of
implementing
this,
so
that
you
don't
keep
going
to
the
backing
system
and
say
retrieving
the
order
finding
out
what
the
current
state
of
everything
is
and
so
on
so
having
something
which
is
very
lightweight
just
says:
what's
the
current
price?
What's
current
availability,
that
may
well
be
a
valuable
precursor
to
doing
more
heavyweight
things.
L
My
concerns
are
more
clickable
when
there's
multiple
icicles
at
the
basket
and
there's
certainly
clickable
when
we,
you
know
if,
if
we're
guessing
very
high
volumes
through,
we
she's,
probably
not
where
this
API
is
aim
for.
If
we
get
if
we're
trying
to
make
10,000
bookings
in
a
few
minutes
and
it's
coming
through
this
process,
that's
cadet
and
I
think
that
will
either
certain
significant
overhead
to
what
we
would
normally
do.
We're
just
adding
individual
items
to
the
basket,
but
that's
that
I
don't
leave
thats
a
nickel
or
if
it's
a
real
problem.
J
Things
that
was
because
the
all
the
quote
itself
doesn't,
but
it
might,
in
the
back
end,
just
be
maintaining
a
basket
if
it's
called
every
time.
A
new
items
added,
really
all
you're
doing,
is
you're
dipping
against
what
you've
got
and
you're,
adding
and
removing
items
until
the
basket
matches
what
it's
asking
for
and
giving
it
back
again.
So
I
suppose.
J
In
the
case
where
people
are
adding
things
to
the
basket,
you
would
probably
be
calling
all
the
quote
each
time
that
call
added-
and
it
would
probably
be
a
very
similar
call
to
add
item
and
it
just
wouldn't
as
before,
wouldn't
require
the
state
to
be
stored.
If
what
you
were
doing
was
getting
was
just
checking
whether
those
two
things
are
in
the
same
course
or.
A
A
All
of
the
state
is
being
maintained
on
the
client
because
a
basket
assuming
that's
what's
being
offered
to
the
consumer,
but
the
reason
option
as
an
optimization
step
for
the
server
side
to
maintain
some
state
that
was
useful
because
they
have
you
have
a
shared
key
between
both
sides.
So
that
is
a
kind
of
step
that
could
be
implemented.
It
just
wouldn't
necessarily
be
required
by
the
specification.
It
could
just
be
a
note
for
implementers
valid
to
do
this,
that
we
reduce
the
process
overhead
for
some.
J
So
I
guess
I'm
checking
there
is
it,
so
it's
got
to
just
drop
that
and
ran
away,
which
is
fair
enough
and
to
do
anything
that
ants
are
blocking
concern.
This
one
figure
out
is
that
something
that
we
are
worried
about?
What
do
you
think,
as
you
say,
with
that
different
place,
and
that
shared
state
in
place
effectively
you're
looking
at
the
same
call
same
tools
and
and
potential
latency
anyway,.
F
I,
don't
I,
don't
see
it
as
a
locker
I
think
that
you
said
it.
It
shouldn't
be
too
hard
an
operation
to
work
out
what
the
state
change
in
a
basket
is
and
if
you're
running
leases,
then
you're
going
to
have
to
be
a
stateful
system
anyway,
and
if
you're
not
running
leases,
and
it
makes
no
difference
and
if,
if
you're
gonna
have
to
do
the
call
at
some
point,
so
it
all
you're
doing
is
pushing
down
the
light.
F
If
you're,
not
if
you're,
not
wanting
to
make
the
checks
that
you
can
book
tennis
hand,
I,
don't
know
football
or
whatever.
It
is
at
the
same
time,
because
they
share
the
same
core.
If
you're
not
doing
that,
say
it's
stage
c1
and
you're,
leaving
it
to
stage
B
well,
then
you've
still
got
to
make
the
same
process
in
the
same
call
you're
just
pushing
that
work
down
for
further
down
the
line,
so
you're
going
to
end
up
with
a
very
heavy
B
call
on
the
server
side.
F
If
you
don't,
if
you
don't
open
the
user
to
do
it
and
they
draw
and
you're
just
going
to
increase
the
failure
which
is
not
gonna,
be
a
particularly
pleasant
for
experience
for
anybody,
not
the
broken
or
the
nor
the
customer
and
the
booking
system
is
going
to
find
that
they
don't
get
as
many
bookings.
So
for
me,
it's
it
feels
like
it
should
be,
something
that's
maintained
and
a
check.
That's
done
through.
A
Against
people
to
try
it
wicked,
and
so
it
looks
like
we're
just
about
out
of
time,
I
think
we'll
defer
the
description
about
kind
of
webhooks
until
next
time
before
I
wind
up
the
call.
Is
there
anybody
else
that
wanted
to
rate
shipping
any
comments
on
this
discussion
or
raise
any
other
issues?
I
won't
go
around
everyone,
but
just
just
speak
up
now.
If
there's.
H
J
C
J
B
B
B
The
big
question
that
probably
we
still
need
to
answer
is
whether
it
should
be
a
one,
big
call
or
how
multiple
calls-
and
that
seems
to
be
it's
a
it's
a
it's
a
big
back
and
forth
I'm
in
favor
of
several
calls,
but
I
can
see
that
from
a
volume
point
of
view
that
that
not
might
not
be
feasible
or
or
lightweight
so
not
dealing
with
we're
not
dealing
with
that
side
of
things
at
the
moment.
So
I
can't
comment
more.
D
All
make
sense
to
me:
we
like
that
idea.
The
Lisa's
I'd
be
really
in
favor
of
the
several
little
calls
at
times
and
scale
have
the
scale
on
the
back
and
handle
those
and
then
deal
with
the
resource
issues.
If
he
needs
it
will
ya
all
seems
good
to
me
and
if
I
was
going
to
build
something
like
this,
this
was
probably
the
way
they'll
do.
J
D
Yeah
yeah
I'd
be
doing
a
lot
of
little
things
just
to
keep
updating
the
basket
as
a
need
to
just
to
even
even
maybe
something
like
king
keeping
the
client
in
sync
in
terms
of
the
least
time
so
stuff
I
have,
but
that
I
guess
you
could
keep
you
could
go
either
way
depending
on
what
the
implementer
wanted
to
do.
They
could
actually
really
specify
all
my
little
that.
J
J
J
A
I
J
I
Well,
I
guess
so
the
tricky
thing
is
that,
from
a
good
point
of
view,
is
how
do
you
pick
the
right
price
for
a
slot,
depending
whether,
in
the
case
that
they
have
like
a
different
machine
schema
on,
they
have
different
prices
for
depending
on
whether
you
have
cents
above
the
machine.
So
that's
really.
Yes,.
A
So
we
we
haven't
allowed
for
that
in
this
version
of
the
spec
okay.
We
know
that.
That's
that's
a
future
requirement,
but
I
think
it
fits
in
because
at
the
point
where
you
provide
you
submitting
a
quote
for
a
known
user,
you
may
also
have
additional
information,
membership
numbers
or
something
that
you've
already
certified
and
that
the
proctor
pricing,
the
quote,
can
also
be
updated.
Based
on
that,
it's
also
a
reason
for
maybe
having
a
separate
availability
check
that
gives
you
a
updated
set
of
offerings
for
members
and
non-members.
I
That's
that's
one
of
the
things
that
we've
biggest
from
in
so
far
my
local
page.
So
when
we,
when
we
are
sending
submitting
a
book
in
to
a
system,
we
have
no
way
we'd
have
to
do
that
on
behalf
of
a
member
ID
or
any
stereo
or
wherever,
so,
ideally
that
in
red.
If
we
could
build
the
system
in
the
way
that
this
information
is
sent
to
provide
that
transparent
and
means
that
they
cannot
figure
out.
What's
a
member
ID
for
that
user,
without
we
have
it
deposit
information
on
so
I
think
so.
A
If
it
vision,
one
I
think
will
be
will
be
saying
that
you
can
be
required
fields,
but
there
could
be
additional
optional
fields
and
if
broker
and
a
provider
want
to
you
know
just
pricing
based
on
other
data,
that's
provided
by
user
than
us.
That's
fine!
You
wouldn't
necessarily
dig
into
the
detail
of
that
in
version
one.
H
J
J
J
But
there
was
also
discussion
to
remember
whether
you
would
want
to
use
some
heuristics
to
match
to
existing
members.
If
you
want
to
pick
one
of
the
analysis
from
the
family
and
link
it
to
that
conclusion,
was
at
this
point
maybe
just
have
a
separate
table
of
third
parties,
and
I
mean
if
we
need
to
do
some
heuristic
matching
later.
F
Just
as
a
thought
on
gdpr,
if
you've
you,
if
you're
receiving
a
request
like
this
there's,
no
way,
you
could
hear
a
sickly
match
to
unassociated
records
unless
the
broker
is
definitely
associating
the
account,
because
otherwise,
if
legend
were
to
associate
to
records
without
the
customers
consent,
that's
breach
of
gdpr
I.
Think
so
that's
just
one
thing
to
be
aware
of:
on
the
on
the
provider
side.
F
So
is
it
that
kind
of
things
actually
quite
dangerous
to
do,
especially
just
for
account
like
for
the
validity
of
your
data,
but
even
if
two
bookings
were
made
by
two
people
that
using
the
same
email
address,
it
doesn't
matter
if
they
share
an
email
address.
If
they're
two
different
people,
then
they'd
have
to
give
direct
consent
that
the
accounts
can
be
linked,
otherwise
you're
making
an
assumption
on
their
behalf
and
then
potentially
sharing
information
about
what
the
separate
individual
is
delivering.
F
C
C
J
Even
if
they
had
an
existing
membership
already
so
that,
because,
if
they're
coming
to
a
channel
says
my
local
pitch
or
such
as
one
of
these
many
apps
that
are
available,
they
would
be
coming
to
a
third-party
channel
not
expecting
their
membership
prices
to
be
quoted.
Whereas
if
they've
come
through
the
website
different
story,
because
they
would
expect.
C
J
J
Imitation
questions
in
that,
so
we
could
we
could,
but
if
you
wanted
to,
we
could
enough
information
is
match
them
against
a
member
but
Ken's
point.
If
we
do
that
consumer
side
matching
that
requires
another
flow
of
associating
accounts
and
user
permissions,
so
it
might
be
something
that
we
need.
Should
they
come
in
the
next
conversation,
I
wonder:
yeah.
D
A
Well,
let's
continue
that
discussion.
Offline
I
think
that
that
mechanism
can
still
layer
on
top
of
the
basic
workflow
here
just
might
require
a
bit
more
information
being
passed.
A
couple
of
points,
so
I
am
going
to
wind
up
the
call
now
so.
Thank
you,
everyone
for,
as
always,
it's
a
way
to
give
some
feedback.