►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
A
A
A
B
Last
time
we
finished
off,
we
had
finished
reviewing
all
of
the
sort
of
core
abstractions
and
we
were
moving
on
to
the
http,
client
and
other
ancillary
apis
that
were
added
for
this.
A
B
Yep
right
in
the
middle,
oh
yeah,
so
I
I
realized,
while
implementing
this-
that
I
duplex
pipe
does
not
have
any
concept
of
like
releasing
resources,
so
we
need,
if
you're,
creating
something
for
a
vibe.
We
also
need
a
way
for
someone
to
release
resources.
So
I
added
overloads
here
of
taking
disposables.
C
Itself,
you
complete
those
individually
but
the
overall
I'm
trying
to
grok
what
you
would
pass
in
a
disposable
like
what
would.
C
Would
you
release
yeah
okay,
so
cory
mentioned
this
to
me
yesterday,
so
like
in
casual?
We
wouldn't
use
this
because
the
transports
get
shut
down
with
the
server
right.
B
C
A
C
C
Way
to
know
that,
like
the
socket,
is
fully
closed
by
just
closing
the
pipes.
So
if
you
want
to
use
the
eye
connection
or
the
connection,
sorry
as
an
abstraction
to
represent
like
the
lifetime
of
the
socket
and
so
forth,
and
then
you
back
it
by
a
pipe,
it
becomes
weird.
B
B
C
David
yeah,
as
far
as
the
overloads
you
want
to
delete,
is
it
all
the
front
pipe
overloads
or
just
the
ones
that
take
I
disposable
disposable
ones,
and
I
think
it
like
if
you
wanted
to
do
that,
you
would
implement
the
connection
yourself
right.
Just
don't
have
a
convenient
wrapper
right
over
it.
B
B
B
B
C
C
So
you're
saying
like
in
style
like
connection
middleware,
would
we
use
front
pipe
we
don't
have
to?
But
if,
if
there
was,
if
there
wasn't
one
built-in,
we
would
use
from
from
streamer
from
pipe
right
to
take
a
stream
to
take
the
current
stream
wrap
it
get
a
new
stream
back
and
then
wrap
that
wrap
that,
in
a
connection
in
a
convenient
way,
that's
right
well,
because
we
use
ssl
stream
we'd
use
from
stream.
C
But
assuming
we
had
like
ssl
pipe
or
something
right,
then
we
could
probably
use
that,
but
it
would
again
it
works
in
cash
flow.
Get
special
special,
like
I
do
kind
of
agree
with
cory
here,
and
this
is
about
trying
to
observe
just
like
rock
again.
This
is
about
trying
to
observe
when
someone
called
dispose
from
the
outside.
E
E
Your
lexical
scopes
like
what's
the
what
state
is
going
on
here,
is
the
connection
supposed
to
be
the
whole
state
or
is
it
part
of
some
other
state.
C
So
in
kestrel,
if
you,
if
you
wanted
to
observe
the
completion
of
a
socket,
you
could
using
the
connection
close
token.
But
again
it
just
doesn't
kind
of
integrate
with
dispose
the
way
it
would
probably
on
the
on
a
client
that
owned
the
socket
or
something.
B
E
B
E
Do
pipe
as
I
disposable
and
if
it's
high
disposable,
then
you
dispose
it,
but
now
we're
back
to
you
want
the
booleans,
because
every
time
we
ever
do
a,
we
assume
we're
taking
ownership.
Someone
somewhere
wants
us
not
to
so
like,
but
if
it's,
if
the
expected
call
for
the
the
two
that
take
a
disposable,
is
you
pass
the
same
value
in
the
first
two
parameters,
then
that
seems
like
we
should
just
do
a
runtime
as
check.
C
C
E
Arbitrarily
well,
leave
state
arbitrarily.
I
don't
know
if
I
understand
what
you
mean
by
that
that
you
have
the
pipe
that's
backed
by
a
disposable
thing,
but
the
pipe
doesn't
know
it's
backed
by
a
disposable
thing
and
it
could
get
disposed
out
from
under
it.
E
B
In
this
case,
the
idea
is
that
the
connection
is
the
resource
and
you
call
like
connection.pipe
to
get
access
to
the
pipe
for
the
connection.
So
it's
trying
to
make
this
easy
convenience
method
that
somehow
implements
that
expected
behavior.
Why
can't
pipe?
Why
can't
the
connection
call
pipe.reader.
D
C
D
C
C
It
seems
arbitrary
that,
like
you're
passing
this
extra
argument,
just
in
case
the
thing
has
a
resource
that
that
is
tied
to
it
before
we
do
the
the
eye
disposable
cast.
There
should
be
like
an
actual
I
duplex
pipe,
that's
disposable
in
practice
anywhere,
which
I
don't
think
is
true.
The
issue
is
like
it's
the
same
thing
we
spoke
about
a
long
time
ago,
like
interfaces
being
disposable,
it's
kind
of
a
hack
right.
C
The
interface
wait
yeah
I
mean,
what's
as
good
as
an
ass,
cast
the
the
interface
itself
being
disposable,
trying
to
basically
assume
that
every
single
implementation
has
to
be
disposable.
It's
like
stream,
you
do
it
because
some
are
not
because
most
are
all
right
like
memory
streaming.
Disposes
is
a
no-op,
but
it
happens
to
be
there
because
it's
convenient
for
direct
classes
to
maybe
be
disposable.
C
B
B
C
C
C
I
mean
we
have
it
for
stream
too,
like
for
stream,
you
have
the
same
problem
that
that
is
kind
of
the
couple
from
from
like
who
calls
dispose,
isn't
the
same
thing
as
as
well.
I
agree
it's
not
unique
to
pipe.
It's
the
same
issue
for
pipe
and
stream.
If
we
do
the
high
duplex
pipe
might
be
disposable
thing.
B
B
C
C
C
C
E
B
Well,
I
I
use
the
stream
level
when
I
implemented
this
in
smtp
client,
but
I
mean
it
could
have
been
done
through
a
connection.
It
just
doesn't
seem.
It
didn't
seem
right
to
me.
E
D
D
C
We
can
just
expose
the
non-disposable
stream
stream
implementation
in
the
bcl
and
then
just
get
rid
of
we've
opened
forever
yeah.
D
B
C
C
B
C
B
Yeah,
I
I
would
be
worried
about
an
as
cast,
but
if
we're
adding
a
leave
open
parameter
that
does
kind
of
slightly
hint
to
the
user
that
something
else
is
going
on,
so
I'd
be
fine
with
it
or
we
could
do
a
from
pipe.
C
A
I
said
you
can
constrain
to
multiple
interfaces.
Yes,.
D
C
E
If
you
overload
like
that,
the
only
time
it'll
call
the
generic
one
is,
if
you
explicitly
specify
the
angle
brackets
because
to
a
callable
con
to
a
lossy
conversion
on
a
callable.
C
E
So
if
you
don't
have
the
angle
brackets,
assuming
that
I'm
recalling
the
resolution
order,
which
last
time
I
looked
at,
it
was
like
three
five
like
a
c
sharp
four,
it
would
be.
Non-Generic
methods
are
evaluated
if
it
finds
any
candidate
at
all
that
one
wins
and
if
it
didn't,
then
it
tries
generic
inference.
C
B
Fun
all
right,
so
one
from
pipe
overload
that
has
a
leave
open
and
add
a
leave
open
to
the
stream
as
well.
Yeah.
E
E
Yeah,
I'm.
I
will
mention
that
there
are
an
awful
lot
of
default
parameters
on
this.
E
Does
it
does
it
make
sense,
in
this
case,
to
add
the
overloads
that
don't
have
any
defaults,
or
do
you
think
that
it's
simply
that
people
will
generally
specify
two
of
the
optional?
You
know
two-ish
of
the
optional
things,
but
no
one
will
agree
on
which
two
they
want.
B
So
I
I
was
thinking
of
users
of
like
http
client,
if
you're
using
that
with
this,
like
we
have
a
a
plain
text-
filter
property
that
we'll
get
to
later.
You
don't
need
to
specify
any
of
these
properties,
so
I
never
would.
It
would
really
only
be
for
people
composing
composing,
some
some
connection
factory
for
some
other
purpose.
E
Yeah
well,
this
is,
we
have
a
with
optional
parameters.
We
have
like
a
consider
adding
a
simplified
overload
that
doesn't
use
any
optional
parameters
to
because
it
makes
intellisense
prettier
as
long
as
you
don't
actually
want
any
of
the
optional
parameters,
and
but
if
it,
if
generally
people
are
going
to
need
to
specify
at
least
one
of
the
optional
things,
then
that
wouldn't
really
make
sense.
E
E
E
I
would
say
typically,
the
leave
open
is
the
last
parameter,
but
they're
all
optional,
so
I
don't
have
a
strong
opinion
as
to
where
it
goes.
Really.
It's
just
a
question
of
what
do
you
think
the
most
common
call
pattern
would
be
because
if
people
want
to
skip
that
one
like
if
you
think
that
they
would
really
specify
stream
properties,
endpoint,
endpoint
and
then
let
whatever
else
is
off
the
screen
here
be
defaulted,
then
it
would
go
last.
E
If
you
think
that
it's
going
to
be
the
most
most
commonly
tweaked
parameter
than
going,
the
first
default
seems
correct.
So,
whatever
you
think
the
right
ordering
is.
B
Yeah,
I
I
don't
really
imagine
this
being
called
without
god.
What's
it
name
without
naming
the
parameters
explicitly
because
well,
it's
possible
that
you'll
need
all
of
them,
but
I
imagine
properties
is
going
to
be
pretty
rare.
B
C
C
Yeah
and
if
you
get
rid
of
the
disposable
interface
it'll
pick
the
non-generic
it's
pretty
cool.
This
is
generics
hack.
E
B
E
B
Better,
all
right
can
we
move
on
from
these
methods
any
objection
to
what's
on
the
screen.
A
B
When
quick
apis
are
ready,
we
will
have
a
multiplexed
connection.
I
see
so
this
will
come.
A
B
B
It
may
be
better
named
tcp
connection
factory,
because
the
quick
one
will
probably
be
called
quick
connection,
factory
yeah
and
then
the
the
plain
text
filter
is.
If
someone
wants
to
filter
a
connection
at
the
plain
text
level
before
it
gets
encrypted,
because
the
connection
factory
will
always
see
encrypted
bytes.
B
C
I
don't
think
it's
tcp,
then
right,
it's
it's
kind
of
sucking,
because
if
you
did
the
main
sockets
that
also
works
with
the
socket
the
socket
abstraction.
B
B
E
A
E
C
Well,
like
in
kestrel,
it's
mostly
two
different
pipelines,
for
example,
right
because
one's
a
multiplex
connection
and
one's
like
a
stream
and
it's
just
different
concepts.
I
assume
that's
what
you're
trying
to
get
at.
B
I
mean
they
wouldn't
have
to
be,
but
it
could
very
easily
be
right.
E
Because
my
my
assumption,
when
you
said
you
were
adding,
another
property
is-
and
my
question
of,
can
they
be
the
same?
Is
that
if
one
of
them
is
not
null
the
other
one
is
null,
but
if
they
can
both
be
non-null,
then
obviously
life
is
complicated.
E
Oh
right
on
this
is
http
specific,
not
sockets
at
the
bottom.
So,
okay,
that's
the
the
comment
of
tcp
makes
a
lot
more
sense.
Once
I
noticed
the
middle
couple
letters,
I
thought
this
was
socket
connections,
not
http,
socket
connections,
okay,.
E
B
E
B
One
of
the
requests
for
this
feature
was
to
use
http
over
domain
sockets,
so
you
would
generally
assign
a
connection
factory
here.
If
you
didn't
want
to
use
tcp,
there
are
other
reasons,
but
but
that's
one
of
the
one
of
them,
and
so
maybe
naming
it
tcp
isn't
correct,
but
I
can't
really
think
of
a
a
better
way
to
say,
like.
B
C
B
B
D
B
That
is
left
up
to
the
implementation
like
by
the
default.
One
we're
just
gonna
call
socket.connect,
which
will
resolve
it
for
you.
But
the
expectation
is
is
that
you
will
know
that
your
connection
factory
needs
to
support
dns
endpoint,
because
you're
assigning
it
to
a
socket's
http
handle.
E
Yeah,
so
if
there's
any
word
that
you
can
put
on
connection
factory
now
to
help
disambiguate
it
from
quick
later
and
ideally
not
use
the
word
quick
and
whatever
you
need
for
quick,
that
that
would
be
my
feedback.
But
I
certainly
don't
have
words.
So
I
can't
I
like
connection
factory.
C
Multiplex
connection
factory
like
what
we
were
calling
simplex
earlier,
which
I
looked
up.
Apparently
it's
a
geometry
term
yeah
I
feel
like
that,
can
be
assumed.
I
don't
know.
E
Yeah
I
mean
it
would
require
just
hoping
that
we
can
think
far
enough
in
advance,
and
you
know
certainly
the
the
creation
of
something
like
quick,
probably
invalidated,
a
bunch
of
assumptions
that
we
already
had
for
how
things
worked
previously
and
that's
when
you
end
up
with
bolt-ons.
But
it
would
be
nice
if
quick,
two
didn't
need
a
second
bolt
on
if
it
just
got
to
fit
in
the
same
slot
as
quick.
One.
Good
luck.
A
E
E
E
A
Yeah
having
two
having
at
least
two
is,
I
think,
nice,
but
I
also
can't
think
of
better
terms.
I
mean
that's.
The
other
problem
is
that
we
look
at
these
things
here,
like
I
think
you
want
to
avoid
a
hierarchy
that
is
super
messy
and
to
me,
sockets,
http,
connection,
factory
kind
of
looks
messy,
because
it's
so
many
terms.
A
B
A
C
B
D
B
Yeah
in
hindsight,
but
we
are
where
we.
E
B
Yeah
so
connection
factory
and
multiplex
connection
factory,
I
think
work.
If
we
wanted
to
be
super
safe,
we
could
call
it
tcp
connection,
factory
and
quick
connection
factory.
I
mean
it's
possible
that
let's
say
quick,
two
does
come
out
and
our
abstraction
does
work
for
it.
Maybe
you
want
a
separate
connection
factory
for
it
anyway.
E
B
Oh,
what
yeah
they
would
I
mean
if
you
let's
say
you
want
to
let's
say
you're
in
a
reverse
proxy
scenario,
and
you
want
to
handle
requests
for
all
the
http
versions
that
are
possible
and
you
want
to
inject
some
sort
of
you
know
diagnostics,
information
in
between
all
your
connections.
You
would
absolutely
have
all
of
these
be
done.
B
A
B
B
Yeah,
you
are,
you
could
technically
override
it,
but
generally
you
would.
You
would
use
the
sockets
http
connection
factory.
Only
if
you
wanted
the
default
tcp
implementation,
you
would
override
it.
If
you
just
wanted
to
shim
like
some
tcp
options
onto
the
socket
or
something.
C
B
E
Yeah,
I'm
just
trying
to
avoid
the
world
where
we
have
quick,
three
connection:
factory,
quick,
two
connection,
factory,
speed,
e7
connection,
factory
and
connection
factory,
and
then
it's
like.
I
don't
know
what
this
last
one
is.
It's
just.
E
C
E
E
C
E
B
C
E
E
What
do
I
do
like?
How
do
I
use
this
from
you
know:
net
eight,
when
dot
net
nine
introduced
the
the
concept
of
supporting
some
other
protocol
man,
it
would
have
been
nice
if
we
had
some
nice
abstraction
so
that
I
can
just
handle
things.
But
if
it
doesn't,
if
it's
a
completely
new
abstraction,
then
it's
completely
new
abstraction
so
or
we
could
do
a
factory
factory.
B
E
B
E
Would
make
sense
in
a
later
version,
so
I'm
like
anyway,
that
I
think
it
would
be
nice
if
we
can
put
some
sort
of
adjective
on
this
thing.
A
Do
we
do
we
envision
that
these
connection
factories
actually
expose
net
new
apis,
except
for
the
constructors,
or
do
they
just
override
the
base.
B
B
B
A
E
But
if,
if
there's
going
to
be
a
new
because
there's
the
multiplex
connection,
so
if
it's
going
to
be
a
multiplex
connection
factory,
then
that
explains
why
it's
a
new
property,
because
it's
incompatible
with
the
previous
one.
But
if
it's.
If
it's.
B
A
E
A
A
I'm
just
talking
about
the
so
what
I'm
envisioning
is.
Basically
you
have
connection
factory,
which
is
what
they
all
derive
from
right
and
and
sorry
yeah,
which
they
all
derive
from.
Then
you
have
sorry,
they
have
a
static
type
called
connection
factory.
A
Then
connection
factory
becomes
connection
factory
of
t,
the
static
type,
just
houses,
the
extension
at
the
sorry,
the
the
the
factory
methods
to
actually
create
the
different
ones,
and
then
you
know
create
quick
connection,
gives
you
back
connection
factory
of
t
and
then
on
sockets,
http,
handler
or
other
other
place
where
you
wanna,
you
know,
expose
different
factories.
A
A
So,
like
we
just
talked
about
the
noise
or
the
the
the
complication
in
the
architecture
where
we
have
all
these
different
types
floating
around.
If,
if
the
types
themselves
are
only
used
to
expose
constructors,
then
why
have
them?
Why
not
just
have
factory
methods
somewhere
and
then
corey
said
well.
One
of
the
reasons
is
because
connect
async.
A
Their
own
and
that's
fine,
they
can
just
directly
derive
from
connection
factory
of
t
right.
I
mean
that's
what
we
do
in
the
implementation
right
I
mean
they
can
do
that
publicly,
but
we
don't
have
to
give
like.
Is
there
any
value
for
a
customer
to
derive
from
sockets
http
connection
factory?
Probably
not
right.
So
why
are.
A
B
A
Fair
enough,
like
I
mean
like
if
yeah,
if
you
envision
that
people
that's
what
I
was
asking
like,
it
sounds
like
yeah.
Basically,
the
new
virtuals
you
defined
on
the
socket
hp
connection
factory
is
kind
of
what
I
meant
earlier.
It's
like
do
you
expect
new
apis
and
the
answer
is
yes.
Gotcha.
B
C
C
B
B
C
For
managing
our
connection
factories-
and
I
I
have
a
generic
like-
I
basically
have
I
connection
listener
of
t
it's
the
same
concept.
So
it's
somewhat.
A
Useful,
I
can
yeah,
I
mean
I
guess,
if,
even
if
we
have
derived
types,
we
may
want
to
do
that
so
that
we
don't
have
to
define
all
these
methods
we're
new.
It
might
be
cleaner,
but
genetics
also
come
with
a
price
tag.
Right
like
that's,
it
does
add
more
complexity
and
potentially
makes
your
signatures
way
more
ugly.
E
C
A
B
Yeah,
so
it
would.
We
would
only
use
that
on
the
three
classes,
the
connection
factory
connection
listener
and
connection
listener
factory
right,
but
I
don't
see
any
reason
why
it
wouldn't
work.
Yeah.
C
So
in
chat
I
linked
to
eye
connection
listener,
t
it's
internal
but
like
we
use
it
because
it's
somewhat
useful.
So
the
only
reason
it's
internal,
because
eventually
we
plan
on
switching
over
to
these
types.
So
I
don't
want
to
like
introduce
yet
another
thing
new,
as
I
was
working
on
it.
B
Yeah
I
mean
I'm
torn
between
the
the
saving
on
new
apis
and
the
verbosity
of
actually
using
them,
but
I
feel
like
maybe
I
could
live
with
the
verbosity.
A
B
B
C
Generics,
instead
of
this,
so
the
helpfulness
of
generics
and
kestrel
right
was
that
we
could
share
some
of
the
logic
that
manages
like
the
lifetimes
of
like
the
quick
transport
and
the
tcp
transport.
The
other
thing
like
when
you
do
generics
you,
you
also
want
basically
a
base
connection
factory
yup
that
has
everything
but
connect
async.
So
you
can
use
it
like
in
non-generic
context,
if
you're
not
doing
connect
like
for
lifetime
for
things
like.
B
So,
that's
that's
really
the
usage
comparison.
I
don't.
I
don't
think
the
generic
is
is
really
that
bad
here
I
think
I'd
be
for
making
these
generic.
C
C
Non-Generic
variants
right,
that's
exactly
I
link
to
it
in
chat.
We
do
it
internally
in
cash
flow,
because
it's
useful.
So
if
you're
the
one
managing
connections
it's
useful
and
generally,
if
you're
using
a
factory
and
stuff,
you
are
the
one
managing
connection.
So
so,
if
you
have
shared
logic
for
managing
these
multiplex
connections
and
regular
connections,
the
generics
do
help
a
little
remove
duplication.
C
C
B
A
I
mean,
I
would
say,
generics
are
like
pepper
right
like
if
you
use
them
right,
it
can
make
a
meal
amazing,
but
if
you
use
them
in
the
wrong
places,
it
becomes
very
quickly
very
awful
so
like.
If,
if
you
don't
see
key
gains
by
using
them
yeah,
I
would
agree
or
fall
out
just
just
cut
it
but
like
at
the
same
time,
if
you
find
we
have
to
do
a
lot
of
like
protected
virtual
new.
C
But
now
we
have
on
what's
that
thing
called
covariant
return
type,
so
hopefully
that'll
help.
B
I
don't
I
don't
know
that
this
would
actually
be
viral
feller.
I
think
it
would.
The
usage
difference
would
be
exactly
what
I
have
in
my
comment
in
the
chat
like
no
one's.
C
Over
this
yeah,
it's
not
viral
and
kestrel.
The
code
that
it
saves,
basically
having
like
in
this
case,
would
be
like
a
connection
factory
base.
That
would
work
for,
like
both
quick
and
tcp.
C
B
C
C
Factory
yeah,
I
was
going
to
say
that,
like
having
it
being
a
connection,
factory
of
like
connection
versus
connection
factory
or
multiplex
connection
is
helpful,
but
now
you
think
about
it
more.
It's
not
much
better
than
just
multi-place
connection
factory.
B
Leads
all
right,
so
the
the
the
property
name
on
sockets
http
handler
http,
one
and
two
connection,
factory
or
tcp
connection
factory.
D
B
C
C
C
B
E
E
Better,
okay,
let's
move
on,
seems
fine,
all
right,
plain
text
filter,
I'm
sorry,
future
developers.
B
E
B
B
E
B
B
E
Yeah
I'm
so
it
seems
like
a
reasonable
name
to
me
and
I'm
just
understand,
trying
to
make
sure
the
semantics
to
make
sure
that
the
name's
reasonable
and
it
seems
like
it-
is.
A
B
A
All
right,
then,
future
corey.
This
was
the
day
where
you
went
wrong.
B
All
right,
sockets,
http
connection
factory:
this
is
just
our
default
implementation.
B
Essentially
it
just
creates
a
socket
and
sets
no
delay
on
it,
but
you
can
override
create
socket
if
you
want
to
set
socket
options,
pre-connect
and
if
you
want
to
do
some
funky,
like
you
know,
custom
dns
resolution
or
something
like
that,
you
could
override
establish,
connect,
connection
async
and
do
that
there.
A
A
B
B
E
Mean
I
know
that
you
would
use
it
with
the
sockets
http
handler
as
the
default
connection
factory
if
one
were
inclined
to
build
such
a
thing.
But
what
about
it
relates
to
the
sockets
http
handler,
because
is
it?
Is
this
generically
http?
Is
this
generically
yeah,
because
it
the
fact
that
you're
dealing
with
http
request
message
seems
like
it's?
It
could
just
be
an
http
connection:
factory
yeah,
that's
actually
a
great.
B
Point
kind
of
I
mean
the
so
we
are
you
notice
these
overloads.
They
pull
out
a
request
message
to
get
that
we
insert
a
property,
we
call
connect
async
with
a
property
that
is
an
internal
type,
two
sockets
http
handler.
So
this
wouldn't
be
usable
by
like
a
third-party
http
message,
handler
implementation.
E
A
B
Handler
well,
the
socas
http
handler
you
give
to
http
client
like
today.
What
you
would
do
is
you
would
call
connection
socket
handler
dot
connection
factory
equals
new
sockets,
http
connection
factory.
A
E
E
B
Yep
I
mean
again
similar
to
before
we
have
two
property
bags
to
work
with
here,
one
within
the
message
and
one
within
the
connection
properties,
so
we're
safe
for
expanding
this
later
it
may
not
be
clean,
but
we
have
we've
had
a
property
bag
forever
and
we've
never
actually
used
it.
So
I
suspect
that
we
probably
won't
need
to
add
more
here.
B
E
E
B
Yeah,
if
you're
overwriting
well
connect
async
that
pulls
out
like
the
property
bags,
it
doesn't
make
sense
to
overload
that
essentially,
the
the
benefit
like
we
could
even
get
by
saying,
don't
have
established
connection
async,
but
the
benefit
there
is
that
we
pulled
out
the
the
message
for
the
user
already.
So
it's
slightly
easier
to
implement
this
in
the
hd
context.
E
E
B
E
E
B
It
saves
us,
it
saves
us
well,
the
established
connection
async.
This
whole
type
saves
us
having
to
expose
an
additional
api
of
like
a
http
connection,
properties
that
stores
the
http
request
message:
okay,.
B
Well,
both
of
these
are
actually
very
small.
Create
socket
currently
is
like
a
two-liner
and
established
connection.
Async,
I
think,
is,
is
like
20,
maybe
yeah,
and
I
suspect
most
people
who
would
override
this
type,
like
very
few
people
will
most
of
them
will
just
want
to
set
a
socket
option
yeah.
So.
E
C
C
E
B
All
right,
sockets
connection
factory.
This
basically
does
the
same
thing
as
the
sockets
http
connection
factory,
except
it
doesn't
set
the
http
specific
options,
so
you
can
say
like
what
type
of
socket
you
want
and
connect.
Async
just
calls
connect
on
the
socket
with
your
endpoint.
B
Similarly,
you
can
override
create
socket
if
you
want
to
set
some
options
but
not
have
to
implement
your
entire
new
connection.
Factory
type,
there's
also
a
create
stream
and
create
pipe.
If
you
want
to
customize
that,
like
I
know,
pipe,
has
a
whole
bunch
of
options
on
it
like
buffer
sizes
and
memory
pools,
and
things
like
that,
so
it
was
primarily
added
for
the
pipe,
but
I
figure
for.
E
B
E
B
Although
I
mean
I
suppose
it
could
be
sealed
if
you,
if
you
really
wanted
to
override
the
connect,
async
method,
you're,
basically,
that's
where
all
the
functionality
is
in
this,
so
it
wouldn't
make
sense.
Well.
E
Yeah
I
mean
it's:
would
it
ever
make
sense
that
someone
would
want
to
because
you
could
overwrite
it
to
filter
the
end
point
or
or
something
else,
but
if
there's
another
place
that
you
could
have
that
you
could
get
that
information,
then
it
then
you
wouldn't
necessarily
need
to
do
it
there.
C
E
B
E
B
B
B
B
B
Well,
like
the
example
I
said
of
dns
resolution,
you
get
a
dns
endpoint.
The
default
behavior
is
whatever
socket.connect
does
with
a
dns
endpoint.
Maybe
you
want
to
use
a
smarter
thing
like
a
dns
cache
or
something,
but.
B
B
B
C
Maybe
it
should,
if
it's
being
called
by
connect
async,
it
could
right
like
connect.
Json
could
say
I'm
delegating
the
creation
of
the
socket
and
connecting.
B
E
Yeah
I
mean
if
there's
enough,
if
there's
working,
connect
async,
that
someone
will
want
to
customize
being
an
open
override,
is
sensible
and
yeah,
but
it
if
it's
that
they
may
want
to
change
like
one
line
of
code,
then
it's
maybe
that's
a
place
that
we
want
a
different
abstraction.
But
if
you
don't
think
that
that
exists
yet,
then
that's
then
we
don't
need
it.
E
B
E
B
Yeah,
although
well
one
of
the
things
that
we're
going
to
implement
ourselves
is
this
thing
called
happy
eyeballs
that
actually
has
parallel
connects
going
on.
So
it's
not
just
a
resolve
and
then
connect.
It's
a
resolve,
launch
a
whole
bunch
of
connections
and
then
pick
one
whatever
connects
first,
so
just
having
a
resolve
wouldn't
allow
someone
to
implement.
That
I
mean
resolve
is
just
the
first
thing
that
I
I
could
think
of
here.
I
feel
like
this
is
kind
of
open-ended
enough
that
I
wouldn't
be
comfortable,
saying
we
could
seal
this
off.
E
B
Yeah
I
mean,
if
they're
replacing
tons
of
it,
then
absolutely,
although
this
yeah
this
does
remove,
you
could
call
base.connect
async
and
remove
a
whole
bunch
of
boilerplate
for
yourself
still.
E
C
C
C
Cancellation
or
something
else,
no
throwing
if
you
access
one
and
then
you
access
that
behavior
we're
doing
that
right.
I
hope
you
are
throwing,
yes,
I
hope
not
so
I
hope
before
we
throw
we
like
implement
this
everywhere
and
then
try
using
it,
because
I
have
this,
I
mean
I
don't
even
know
how
how
this
would
work
in
castro,
because
we
we
start
with
a
stream.
Sorry,
we
I
mean,
I
guess,
we're
all
piped
there.
C
C
Right,
so
so
what
so?
What
ends
up
happening
right
if,
if
somebody
uses
the
socket
connection,
battery
or
listener
and
then
they've
used,
the
ssl
is
that
in
here,
are
you
talking
about
the
peaking
scenario
where
you
want
to
peek
at
the
handshake
yeah,
you
pick
out
the
handshake.
Look
at
some
bites
par,
some
things
using
pipes
and
they.
B
C
C
Okay,
so
so
the
behavior
is,
if
you
read
the
pipe,
you
should
just
create
create
a
new
connection
just
in
case,
if
you
want
to
backtrack
like
basically,
if
you
want
to
like
reset
to
where
it's
not
about
tracking.
If,
if
the
stream
is
a
view
over
the
pipe,
then
you
always
have
the
right.
The
right
view
right.
So
if
you
want
to
read
something
and
then
allow
some
further
things
to
read
something
using
either
the
pipe
or
the
stream,
it's
gonna
have
to
be
basically
a
fresh
connection.
C
C
That's
why
you
don't
like,
so
I
think
I
think
I
think
it
would
be
fine
to
have
that
behavior
by
default.
If
the
component
throwing
could
not
possibly
know,
but
if
the
component
made
it
sense
that
the
pipe
was
the
main
thing
and
then
the
stream
was
wrapper
over
the
pipe
that
works
fine.
I
like
that
idea.
E
E
B
E
B
E
D
C
No,
no,
I
I
need
to
call
the
next
thing
in
the
chain
and
the
next
thing
in
the
chain.
Maybe
you
may
be
looking
at
the
stream
after
I've
already
used
the
pipe
internally
right
yeah
we
can
make
that
work
and
it's
easier
than
what
we
already
do
in
kestrel,
because
we
don't
have
to
deal
with
setters
on
the
pipe
and
stream
exactly
so
it's
actually
not
as
bad
as
I
was
originally
thinking.
C
Yeah,
so
if,
if
pipe's
the
source
of
truth,
then
there's
no
reason
that
you
can't
go
back
and
forth
between
using
the
two.
It's
true.
So
as
long
as
that's
possible
I'll
be
happy,
so
the
ap
design
should
allow
for
that.
B
E
C
The
issue
is,
the
issue
is,
if
you
grab
a
component
off
the
shelf,
that
is
pre-written
and
you
plop
in
a
pipeline.
This
is
where
you
have
the
issue.
It's
not
it's
not
about
authoring
yourself.
It's
about
not
knowing
what
hap
what's
happening
in
between
the
layers,
and
I
think
is-
is
okay
to
throw
if
you
know
for
a
fact
that
this
can't
work.
C
But
if
someone
did
the
actual
due
diligence
to
wrap
the
thing
properly
and
expose
the
right
properties,
then
it
seems
like
it
should
work
right
and,
and
you
and
you
could
argue
you
know
if
you,
if
you
touch
one
one
property,
wrap
the
whole
connection
and
call
next.
That's
how
you
do
this
whole
thing
right,
but
that
seems
expensive.
If
you
don't
need
to
do
it
that
way.
B
C
B
B
B
C
C
But
the
concrete
snare
like,
like
I
think
of
right
here
is
a
cell
stream
exists
in
the
bcl
right
and
for
the
sl
component.
You,
you
have
the
stream
and
you
get
a
new
one
and
you
get
a
new
connection
about
based
on
that
stream
code
can
run
before
that.
That
can
look
at
the
bytes
peek
at
the
bytes
just
to
find
the
handshake.
Imagine
we
didn't
have
the
new
feature
in
ssl
student
that
expose
that
feature.
You
parse
it
you
parse
the
the
payload.
C
C
We
could,
of
course,
make
that
work
by
right
and
like
if
we're
going
to
be
the
ones
yeah
I
mean
that's
exactly
it
all
right.
I
I
have
to
build,
but
that
I
mean,
if
wrapping
the
connection
is
the
way
to
go.
Then
we
tell
people
that
if
you
touch
the
stream
wrap
the
component
and
then
carry
it,
carry
on
right.
If
you
read
and
you're
passing
the
connection
to
something
else
that
might
use
the
stream,
then
yeah
exactly
or
or
right
for
that
matter,
but
yeah
yeah.
C
B
C
E
B
E
You're,
you
are
a
connection
and
you've
read
the
underlying
connection
that
went
into
you
and
you're.
Only
exposing
one
of
the
or
someone
can
only
access
you
in
one
of
the
two
modes.
You'll
only
access
the
thing
that
you're
wrapping
in
one
of
the
two
modes,
everything
will
stay
consistent
because
you're
you
either
get
the
pipe
stream
or
the
stream
pipe.
If
you
crossed
parity
but
you're
not
going
to
access
the
same
underlying
source
in
two
different
modes,
I
super
agree.
It
just
kind
of
works.
C
C
B
Right
factory
yep,
it's
basically
the
same
thing
as
sockets
connection
factory,
except
it
has
bind
instead
of
a
connect.
There's
an
override
there
that
isn't
shown.
A
E
Is
the
is
the
class
abstract
and
then
is
the
override
sealed
same
as
the
previous
question.
B
Yeah,
so
I
mean
in
this
case
it
it's
doing
significantly
less
like
there's
no
dns
resolution
type
scenario
when
you're
a
listener
and
just
accepting
something
new,
so
I
could
see
us
making
it
sealed
in
this
case.
B
What
what's
sealed
sockets.
B
I
that's
a
typo
that
it
should
not
be
extending
that
I'm
sorry,
okay,
it
should
be
extending.
E
B
E
E
C
It's
it's
kind
of
the
same
as
like
overriding
connect.
Async
right,
like
I
don't
think
so,
maybe
like
oh
here's,
a
reason
throttling,
probably
right
like
what,
if
you
want
to
do
connection
throttling
at
the
transport
layer
yeah,
why
not.
B
C
Not
on
bind
sorry
sorry
about
accept
you're
talking
specifically
about
buying
changing,
I
suppose.
B
All
right,
so
I
just
updated
it
with
the
override,
so
we
understand
that
it's
using
bind
yeah,
so
so
it
would
be
bind
basically
you'd
have
to
re-implement
connectionlistener
yourself
in
that
case,
so
it
kind
of
makes,
I
feel,
like
you,
would
just
implement
your
own
listener
factory.
C
I
feel
like
that
could
be
made.
You
can
make
that
case
for
anything
that
we're
sealing
right,
like
even
with
the
sockets,
like
you
know,
hp
connection,
factory
kind
of
stuff
like
where
we
decide
that
we're
going
to.
Let
you
override
connect
async
like
to
allow
you
to
change,
endpoints
and
stuff,
like.
B
The
behavior,
the
code
in
sockets
listener
factory,
is
basically
new,
socket
and
dot
bind
and
then
new
connection
listener,
like
it's.
It's
the
shortest
type
in
here,
so
we're
not
saving
the
users
anything
by
making
this
overwriteable.
C
Maybe
I
mean
the
the
way
I
feel
is
for
take
connect
async
on
the
you
know,
sockets
hpv
connection
factory
like
you
could
decorate
that
and
that'd
be
really
short
implementation
like
if
we
sealed
connect
async,
and
you
wanted
to
create
your
own
factory
that,
had
you
know
your
own
connect
async
that
changed,
endpoints
and
stuff
like
we
were
talking
about
earlier.
You
just
have
like
an
inner
socket,
http
connection,
factory
and
it'll
also
be
very
simple,
so
I
don't
see
how
that
argument's
any
different.
B
C
But
you
could
turn
the
like
big
invitation
to
a
one
liner
by
decorating
right
like
to
get
that
same
functionality.
So
you
could
still
connect
async
and
it
would
still
be
like
really
simple
to
sure.
C
B
B
B
E
C
I
just
wish
we
had
like
a
better
bright
line
between
sealed
and
unsealed,
rather
than
like
developer
effort,
especially
when
for
the
stuff
that
we
basically
left
virtual.
The
scenarios
for
it
wouldn't
be
much
more
difficult
if
they
were
sealed,
like
with
the
decorator
pattern.
So
I
I
feel
like
the
the
code.
Cost
argument
is
a
weak
one
as
far
as
ceiling
or
unsealing.
B
Well,
I
don't.
I
don't
necessarily
know
that
I
care
about
consistency
and
sealed
and
unsealed
in
these
two
different
apis,
but
I
don't
really
mind
keeping
this
unsealed,
I'm
just
saying
like
I.
I
don't
think
it
would
be
useful
for
someone
to
override
it.
E
Yeah,
the
biggest
so
we
I
was
like,
I
know
that
we
have
something
about
sealing
with
overrides
in
the
guidelines,
consider
sealing
members
that
you
override
and
then
the
justification
is
think
about
it,
but
basically
it
seems
to
be
suggesting
of
if
you're
overwriting,
multiple
things
and
it
wouldn't
make
sense
so
like
if
you're,
a
stream
class
and
you've
overridden
a
couple
things.
You
know
how
they're
interacting
with
each
other
and
it
wouldn't
make
sense
for
someone
to
override
part
of
that
behavior
anymore.
Then
then
seal
it.
B
C
B
Yeah-
and
maybe
it's
not-
there
are
certainly
other
factors
too.
So,
okay,
any
other
comments
on
this
type.
C
B
All
right,
ssl
connection
stuff-
these
are
very
the
connection
factory
and
listener
factory
are
both
very
trivial.
It's
just
a
constructor.
The
quote.
Api
surface
is
actually
exposed
through
the
property
bags,
so
it's
really
more
of
a
and
a
need
for
documentation
there.
The
main
thing
to
consider
is
this
ssl
connection
properties
type.
B
We
technically
would
only
need
this
ssl
connection
properties
type.
If
we
wanted
to
support
third-party
ssl
implementations
like
if
someone
doesn't
want
to
use
ssl
stream,
they've
got
their
own
thing.
I
know
we've
had
requests
to
use
like
open
ssl
on
windows.
B
This
would
be
an
escape
hatch.
If
someone
really
wanted
to
do
that
but
like
if
we
wanted
to
trim
the
api
surface,
we
could
easily
say
you
know
what
we're
gonna
expose
the
ssl
stream
and
that's
how
everyone
is
going
to
get
their
ssl
properties.
E
B
If
there's
something
I'm
not
an
expert
in
what's
right
or
wrong
on
this
one,
so
if
you
think
there's
a
some
better
things
that
we
can
expose
and
not.
E
Yeah
I
mean
the
like:
it's
just
it's
weird
because,
like
the
the
key
exchange,
I
think
it's
at
least
like
the
key
exchange
algorithm
is
usually
wrong
because
it'll
say
like
rsa,
but
if
it
was
using
perfect
forward
secrecy,
the
answer
is
actually
ecdhe.
E
Rsa
was
simply
the
server
certificate
algorithm
and
and
it's
that
these
properties
were
the
breakdowns
of
what
ssl,
2
and
ssl
3
cipher
suites
looked
like,
and
and
so
it's
the
trying
to
it
was
a
thing
that
s
channel
did.
Therefore,
ssl
stream
did
transparently
to
just
try
and
be
like
here's,
some
data
about
how
we
connected
without
you
needing
to
understand
how
this
protocol
actually
works,
and
then
they
made
it
complicated.
Where
now
you
get
something
like
you
know,
aasgcm.
E
Well,
what's
the
hash
algorithm?
Well,
there
wasn't
one
because
we
didn't
use
external
hashing
on
the
thing
we
use
gcm,
because
it's
a
it's
a
self
modification,
detecting
cipher
and
like
so.
We
didn't
need
the
mac,
and
so
I
feel
that,
like
I,
don't
know
what
the
state
that
they're
actually
in
anymore,
I
just
know
that
they
were
a
hard
thing
for
us
to
map
from
in
the
linux
pal
and
the
in
the
apple
pal.
E
We
actually
had
to
just
write
a
thing
that
understands
every
cipher
suite
and
then
just
expands
those
the
data
so
that
we
can
fill
in
the
legacy
properties,
but
I
think,
in
contrast,
I
don't
know
that
we
actually
know
the
cipher
suit
on
windows.
E
B
E
E
E
B
Yeah
I
mean
I
would
suspect
most
people
probably
don't
have.
I
honestly
don't
know
what
you
would
use
that
for
other
than
like
diagnostics,.
E
B
E
My
my
feedback
would
be
based
on
my
understanding
of
what
goes
into
this
data
and
how
inaccurate
it
can
be,
plus
the
fact
that
it
means
that
we
have
to
keep
modeling
things.
As
you
know,
new
new
concepts
of
an
exchange
algorithm
type
gets
added
that
if
you
can
drop
everything
above
local
certificate,
which
would
be
if
tls,
cipher,
suite
or
sorry
negotiated,
cipher
suite
gets
populated
correctly
on
windows,
then
I
would
drop
all
the
breakdown
fields.
B
Okay
and.
B
B
B
E
Okay,
I
mean,
like
you,
say
that
you're
exposing
this
this
way
in
case
someone
ever
wanted
to
write
a
different
tls
provider,
and
it
would
all
plumb
in
with
the
new
stuff
correctly,
but
is
that
even
a
thing
that
someone
could
build
in
a
third-party
implementation
like?
I
don't
even
know
what
that
type
is
true.
E
E
E
E
I
understand
local
certificate,
because
that
tells
you
what
got
used
after
sni.
I
understand
remote
certificate
like
each
of
those
tell
you
what
actually
happened,
negotiated
cipher
suite
is
what
actually
happened.
Application
protocol
matters
if
you're
doing
that
stuff
and
alpn-
that's
what
it's
called,
and
so
I
can
understand
those
the
the
sort
of
middle
bottom
ones.
The
rest.
I
just
I
wonder
if
you
can
get
rid
of,
at
least
in
this
version.
C
C
Yeah
we
do
like
log
some
of
this
stuff
in
castrol
and
exposes
the
feature.
C
E
All
right
so
as
an
offline
activity,
see
what
what
you
can
trim
for
checking
in
because
I'm
pretty.
E
Exchange
algorithm
and
key
exchange
strength
are
no
longer
relevant
once
ssl
stream
supports,
or
actually
it
should
already
be
true
with
the
gcm
things
that
the
hash,
algorithm
type
is
probably
nonsense
and
the
hash
strength
is
going
to
be
nonsense.
E
The
only
thing
that
really
might
make
sense
is
cipher
strength,
but
but
yeah
I
just.
I
know
that
we
ended
up
with
a
bunch
of
trying
to
figure
out
how
things
actually
were
being
returned
by
windows,
because,
of
course,
ssl
stream
on
windows
doesn't
know
what
any
of
these
things
means.
It's
just
returning
properties
from
s
channel
which
documents
them
as
the
name
of
the
thing.
E
Yeah
returns
the
algorithm
used
for
key
exchange.
Okay,
so
our
documentation
says
returns
the
algorithm
used
for
key
exchange
and
and
for
once,
tls12
came
along.
I
think
that
it
was
in
many
of
these
things
returning
unmapped
values,
because
windows
that
added
new
values
that
just
no
one
had
tests
for,
and
then
we
had
to
go
figure
out
what
the
magic
constants
were
on
linux.
B
Okay?
If
because
we
are
kind
of
running
up
closer
to
a
deadline,
if
we
did
not
have
time
or
just
couldn't
complete
the
work
to
kind
of
do
that
research,
http
client
would
be
fine,
leaving
those
off.
Stefan
do
you
would
kestrel
still
be
able
to
use
this?
If,
if
those
were
not
there.
C
We
we
might
have
to
like
road
that
would
be
tough
like
because
I
wouldn't
want
to
like
break
people
who
are
currently
logging.
This
stuff
we
might
have
to
like
put
in
dummy
values
like
I
I
don't
know
like
we'd-
have
to
talk
to
barry,
but
if
they're
already
nonsense,
then
maybe
we
can
throw
in
like
a
dummy
value
or
something.
If
it's
not
available,
you
know
I
don't
want
to
have
to
like
continue
using
our
own,
like.
B
C
Okay
yeah,
I
would
say
that
it's
not
like
the
most
heavily
used
like
features
in
asp.net,
so
we
might
be
able
to
make
some
breaking
changes
there,
but
yeah,
probably
not
this
late
for
5.0
to
make
like
we'll
see,
maybe
but
right.
B
B
It
is
at
the
bottom,
well,
there's
one
more
class
beneath
that,
but
it's
just
the
ssl
listener
factory
that
is
just
as
empty.
E
Because
the
constructor
is
not
named
the
same
as
the
type
whoops
and
I
think
there
was
just
a
refresh
that
changed
it
from
a
listener
factory
back
to
a
connection
factory.
So
that's
weird
yeah.
It's
going
back
and
forth.
B
B
B
Stream
and
calling
yeah.
B
B
Are
those
will
get
passed
in
through
the
connection
properties.
C
C
Yep
right-
and
this
is
necessary,
like
you,
can't
be
a
constructor
or
anything
unless
it
was
callback
based,
and
you
wouldn't
want
that.
I
think
this
is
good.
E
E
B
Jeremy,
like
at
least
with
the
sockets
connection
factory,
there
is
an
argument
of
like
maybe
you
want
to
change
the
address
family
on
a
per
connect
basis.
Dual
mode
sockets
generally
remove
the
need
for
that,
but
yeah.
It
could
be
a
thing.
E
I
mean
you
could
always
add
a
default
constructor
to
that
one
later
and
that
that
one
ends
up
reading
it
out
of
the
property
bag
instead
of
building
it
itself
from
constructor
parameters,
but
but
okay,
so
these
are.
These
are
public.
I
want
the
implementation
that
this
does,
but
they
didn't
need
to
expose
custom
api
because
they're
just
the
implementation.
B
E
D
B
One
of
one
of
tobe's
comments
on
this
type
was
that
he
would
prefer
to
not
put
these
ssl
things
in
there.
If
kestrel
and
http
client
weren't
going
to
use
them,
we
could
easily
get
away
with
not
having
this
in
both.
I
think
if
we
really
wanted
to
so,
if
we
aren't
sure
about
it,
we
could
just
say
no
wait
for
done
at
six,
but.
B
Mainly
be
we
would
be
sharing
implementation,
but
it
wouldn't
really
be
like
huge
between
the
two.
This
would
mainly
be
for
users
who
want
to
compose
connection
factories
and
insert
tls
in
their
own
thing.
B
E
Okay,
so
they're
they're
still
going
to
have
to
do
complicated
work
and,
if
you're
doing
either
ftps
or
sftp,
whichever
one
is
tcp
or
tls
on
the
outside
you
you
could
use
this,
but
if
we
don't
make
it
public,
it's
like
20
lines
of
code.
C
B
E
Yeah
so
given
yeah,
given
that
we
are
out
of
time
and
we're
a
little
iffy
on
the
structure
of
the
property
thing,
I
I
would
hold
back
the
the
tls
specific
things
for
another
version.
B
E
E
The
property
type
and
and
maybe
these
factories
so
that
you
can
get
the
implementation
from
it,
and
somebody
needs
to
provide
an
alternate
implementation
of
tls
and
show
that
everything
works
happy
with
that
all
the
ssl
stream
options
are
all
that
they
need
to
connect
to
their
thing,
and
that,
like
that,
you
really
do
have
plugable
tls.
At
that
point,
and
I
don't-
I
don't
know
that-
there's
time
enough
left
to
prove
that
that
is
correct.
E
B
I
think
the
main
argument
for
this
is
if
someone
wants
to
like
layer,
ssl
stream
inside
of
like
in
between
other
connection
factory
things,
they
would
then
have
to
implement
this
type
themselves.
E
Yeah,
it's
just
a
question
of
like.
If
this
is
only
really
like
20
lines
of
code,
then
then
that's
easily
a
blog
post
and
then,
if
nothing
changes
between
this
release
and
next
release,
then
it
becomes
a
public
class
and
because
it's
again
the
question
is,
is
it
a
viable
sample
at
this
time
or
does
it
need
to
be
a
public
type.
B
E
B
C
E
All
right,
I
think,
I
think
we're
finally
done.
A
Everyone
for
sticking
through
this
so
you've
updated
the
api
wave
through
the
meeting
right.
So
if
I
just
copy
and
paste
all
of
this
in
that
will
work
right.
A
E
A
E
E
E
I
was
gonna,
say
github,
detects
that
and
renders
it
just
fine,
but
I
can't
believe
your
notes
thing
would.