►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
Alrighty
so
today
we
have
one
networking
issue,
one
obsoletion
and
then
one
spec
review
who
wants
to
give
us
the
honors
here
jeffrey.
Do
you
want
to
do
that.
B
Yes,
I'd
be
happy
to
do
it,
so,
as
some
of
you
probably
remember,
we
not
too
long
ago
decided
to
remove
the
system.net.connection
stuff
from
5.0.
B
B
The
proposed
api
is
pretty
straightforward.
It's
it's
virtually
the
same
as
what
the
connection
factory
used
to
provide,
except
with
a
couple
exceptions.
One
is.
It
returns
just
a
plain
stream
instead
of
a
connection
object.
Another
is
that,
instead
of
a
property
bag,
so
the
old
api
took
dns
endpoint
property
bag
cancellation-
token,
if
I
remember
correctly,
and
that
the
request
message
was
passed
as
part
of
the
property
bag.
Now
we
just
passed
the
hp
request
message
directly.
B
B
If
you
don't
hook
it,
you
get
default
behavior.
If
you
do
hook
it
it's
up
to
you,
you
can
do
pretty
much
anything
you
want
as
far
as
returning
a
stream
that
that
and
sockets
hp
handler
will
use
it.
I
think
the
one
question
that
we
should
discuss
is
just
the
naming.
Do
we
like
connect
callback?
B
B
No,
I
think,
the
net
with
net
connections
in
the
future.
We
will
well
first
of
all,
we
we
won't,
allow
you
to
set
both
this
and
a
connection
factory,
because
they,
you
know,
do
the
same
thing,
but
the
the
the
old
property
was
called
connection
factory.
B
So
I
don't
think
there's
any
problem
with
having
the
two
aside
from
some
duplicativeness
in
the
api,
but
we
can
live
with
that.
D
E
And
another
point
is
that
the
connection
callback
is
much
simpler
to
use.
So
I
expect
that
the
I
don't
know
we
had
like
five
six
seven
eight
issues
on
github
that
actually
needed.
Basically
just
the
connection
callback.
Instead
of
going
into
the
full-blown
abstractions
of
the
connection
factory,
they
would
probably
prefer
to
go
through
simplicity.
That's
my
expectation
even
going
forward.
B
As
far
as
new
parameters,
hp,
request,
message
does
have
its
own
property
bag
on
it.
So
that
gives
us
at
least
some
escape
here,
in
the
sense
that,
if,
if
there's
information
that
people
want
to
flow
through,
they
can
set
it
on
their
hp
request
messages
and
the
and
they'll
be
able
to
see
it
in
the
connection
callback.
B
C
B
Currently,
no,
we
could
add
something
like
that,
but
it's
the
amount
of
code
necessary
to
to
just
do
the
socket
connect
is
not
that
great.
D
D
So
one
thing
we
did
on
the
in
the
initial
apis
was
we
exposed
like
a
static
method
on
sockets
handler.
It
was
like
the
default
connect
method
so
that
users
could
override
behavior
or
just
call
the
default
or
or
maybe
they
just
want
to
change
dns
around
or
something
and
call
the
default
connect
method
there.
D
I
realize
that's
more
work,
maybe
maybe
we
don't
have
time
or
confidence
enough
to
do
that,
but
usability
would
be
improved.
There.
B
D
B
B
That
right
or
no,
I
think
it
would
be
good,
like
I
said
I
think,
it'd
be
good
to
have
that.
I
don't
think
it's
mandatory
for
5.0,
okay,.
A
I
mean
the
static
one.
Doesn't
give
you
a
chaining,
though
right,
because
it
basically
just
means
that
if
you
only
have
one
default,
you
can
expose
aesthetic.
But
if
you
have
like
you
know,
party,
a
hooks,
the
event
party
b
hooks
the
event
party
c
hooks
the
event.
If
you
actually
pass
in
the
previous
one,
then
you
know
they
all
get
chained
nicely.
B
Yeah
yeah
there's
no
there's
no
chaining
ability
here.
It's
just
simply
you've
got
one
hook
and
you
can
plug
in
whatever
you
want.
H
Yeah
yeah
an
event
has
kind
of
like
built-in
support
for
multicasting,
whereas
a
regular
property
is
just
like.
We
expect
a
single
setter
along
those
lines.
Is
it
typical
that
we
would
use
funk
with
four
different
generic
variables
here,
rather
than
just
defining
a
custom
delegate
type.
A
Right,
no,
not
a
custom
delegate,
but
you
could
have
a
context.
You
know
obstructed
basically
a
funk
of
connect,
context
and
then
comma
radio
task
or
stream
right.
D
I
mean
yeah,
I
mean
it's
going
to
be
called
from
an
internal
code,
so
I
mean,
I
guess
users
could
call
it
too,
but-
and
I
don't
know
if
an
optional
parameter
gets
this
much
here
anyway,
yeah
that's
fair
yeah,
because
you
call
it.
C
D
H
H
B
It
is
locked
on
first
use,
in
other
words,
once
you
start
using
the
hp
client.
We
prevent
you
from
modifying
this
further,
which
is
the
same
as
all
the
properties
on
saga's,
ishbi
handler
or
any
handler.
A
A
Yeah,
so
I
think,
I'm
generally
fine
with
using
regular
properties
for
callbacks.
I
mean
that's
a
pattern
that
we
have
used
elsewhere,
because
events
come
with
a
lot
of
other
baggage
right,
it's
not
just
the
add
or
remove
it's
also
the
naming
convention,
the
event
handler
vane
handler
of
t
signature,
and
that
seems
not
super
useful
here.
A
My
only
concern
really
is
with
the
parameters,
because
every
time
we
say,
oh,
we
only
ever
need
four
parameters.
It's
it
tends
to
not
hold
very
well
over
time.
B
A
B
A
D
Yeah,
I
think,
that'd
be
fine.
I
mean
there
were
some
other
things
we
identified
like.
Maybe
a
user
would
want
to
see
what
host
name
they
were
connecting
to
if
it
was
a
proxy
versus
non-proxy
things
like
that,
and
we.
B
D
G
C
D
I
mean,
I
guess
it
depends
on
if
we
want
to
support
this
like
say
system,
net
connections
ends
up
happening
for
success.
Yeah
it
will,
I
assume
we'd
just
you
know-
maybe
not
obsolete,
but
at
least
stop
updating.
This
api.
B
B
G
I
was
going
to
say
if
it's
a
class,
then
the
visibility
of
mutations
on
cancellation,
token
and
value
task
change,
because
they're
now
passed
by
reference.
B
D
I
think
the
worry
is
that
in
the
past,
when
we've
tried
passing
a
struct,
we
often
end
up
making
it
into
a
class
behind
the
scenes
and
just
have
the
struct
forward
to
the
class.
So
this
kind
of
avoids
some
messiness
there.
D
I
yeah.
I
haven't
seen
convincing
argument
that
we
should
do
that,
but
a
dns
point
endpoint
would
kind
of
lock
us
into
the
current
decision.
Rather
than
opening
us
up
to
you
know,
unix
domain
socket
endpoint
or
something.
C
D
Yeah
I
mean
the
so.
The
the
current
thought
is:
it's
an
http
client,
it's
totally
valid
for
us
to
grab
the
hostname
from
the
url
and
say
this
is
a
dns
endpoint.
You
do
your
thing
with
it,
but
users
end
up
kind
of
having
to
work
around
it
like
they'll.
If
they
need
to
open
up
a
unix
domain
socket,
they
have
to
somehow
take
their
unix
path
and
put
it
inside
the
hostname
or
pass
it
in
through
the
property
bag,
and
it
gets
kind
of
messy.
C
D
D
C
Well,
but
anybody
who
wasn't
using
the
new
api
would
now
see
the
question
mark
in
the
reference
assembly
and
true.