►
From YouTube: GitHub Quick Reviews
Description
Powered by Restream https://restream.io/
A
B
A
B
B
Sensitive
mic,
I
guess:
okay,
so
we
have
the
connection
class.
Now
we
need
the
factory
to
create
it.
So
one
sort
of
issue
that
I
think
we
we
have
yet
to
agree
on
is
if
this
class,
if
this
interface
should
have
both
connect
and
bind
on
it
or
if
we
should
split
this
out
into
a
high
connection,
factory
and
I
connection
listener
factory.
B
B
D
E
D
Factory
and
had
a
property,
but
also
expose
sort
of
something
like
the
set
filter.
We've
talked
about
first
thought,
because
they
should
be
handler
where
it
could
work
purely
in
terms
of
my
connection
and
once
we
did
that,
then
it
represented
that
sort
of
does
represent
the
unified
client-server
aspect
of
this
stack,
at
which
point
you
know
whether
the
client,
the
connection
factory
or
the
connection
listener
factory,
or
that
one
of
the
same
isn't
as
big
a
deal.
That's
my
recollection.
Okay,.
B
Yeah,
it's
been
a
few
weeks.
Apologies
if
I,
don't
remember
going
off
these
notes
here.
That's
I
could
be
wrong
too,
but
that's
that's.
What
I
remembered
yeah
yeah
recall
that
in
that
case,
why
don't
we
take
this
by
connection
factory
interface
and
sort
of
build
it
out
in
the
into
the
two
interfaces
we
want.
D
D
B
D
F
F
A
D
A
A
B
G
E
D
F
E
F
F
For
this
level,
no
just
because
it's
yeah
it
wouldn't
be
a
thing
that
you'd
allocate
more
than
once
I,
don't
think
great,
but
so
Stefan
we
were
supposed
to
look
to
see
if
it
would,
it
would
be
an
issue
for
any
of
our
things,
but
I
think
it's
fine,
because
we
already
have
interfaces
today,
so
it
wouldn't
cause
any
new
problems
right
right,
like
our
entire
transport.
Abstraction
is
based
on
interfaces,
so
we're
not
already
constrained
by
needing
to
implement
some
base
class,
so
they
transport
through
that
floor.
Thinking.
F
D
F
So
casual
is
so
the
concern
I
have.
Is
we
already
have
it
these
classes
today
and
can
be
added
its
base
class
to
our
current
type
Harkey
and
not
break
anyone
I
think
the
answer
is
yes,
because
our
current
abstractions
are
our
interfaces.
If
they
were
base
classes,
it
would
be
more
problematic
what
happened?
It'd
be
a
bit
class
and,
having
aren't
thing
to
be
interfaces,
the
things
can
work
together.
Luckily,
mrs.
F
F
That
we
implement
multiple
interfaces
on
the
same
object,
but
not
the
top
level
like
transport,
Factory
and
transport.
So
yeah,
not
not
these
I
would
say:
okay
yeah
for
the
connection
itself,
that's
where
it's
more
interesting,
because
we
do
have
a
base
class
but
I'm,
hoping
that
this
fits
the
type
hierarchy.
It's
weird
it's
so,
basically,
in
the
connection,
we're
pushing
right
now
to
use
an
interface
with
what
we're
talking
about
all.
C
D
B
C
D
F
A
H
A
B
All
right,
I,
don't
know
how
long
we're
gonna
wait
for
email.
So,
let's
move
on
for
now
take
a
look
at
the
connection,
extensions
class
with
some
extension
methods
on
it.
It
currently
has
to
filter
methods.
Those
will
need
to
get
blown
out
into
for
one
for
the
connection
factory
class
and
one
for
the
connection
listener
factory
class.
B
F
H
A
It
makes
sense
all
right
because,
if
use
extension
methods,
you
have
the
least
amount
of
flexibility
right,
like
extension,
methods,
make
usually
sense
for
things
where
you
can't
add
instance,
methods
like
interfaces
or
if
you,
for
whatever
reason,
have
a
layering
problem
where
you
have
to
move
it
up
one
level,
but
instance,
members
should
be
the
default
because
you
know
that's,
it
doesn't
require
a
new
type.
It
you
know,
has
access
to
all
the
state
that
you
can
possibly
have
want
to
have
access
to.
G
A
A
G
B
H
B
B
B
D
A
B
B
B
A
A
Like
I
mean
they
see
what
I'm
asking
is,
this
is
the
right
abstraction
because
it
seems
like
this
is
a
seems,
a
bit
Palumbi
for
my
taste
and
it's
like
when
you
already
have
a
fun
with
like
three
arguments
like
yeah.
Eventually
we'll
have
four
or
five
six,
and
then
it
becomes
a
little
bit
of
a
of
a
cluster
versus.
If
you
have
it
like,
like
they
could
type
or
whatever,
like
you
know,
we
can
add
more
properties
to
it,
for
example,
so.
A
You
can
either
do
one
thing
where
you
can
just
take
some
of
the
arguments
you
pass
with
the
funk
and
just
make
them
a
context.
Struct,
for
example,
right
that
we
can
just
add
more
to
then
at
least
the
function
controls
not
quite
as
bad.
Another
option
is
to
just
literally
have
an
abstraction,
with
a
virtual
that
you
override
that
you
pass
through
the
filter
method
like
a
people,
I
mean,
like
we've,
linked,
for
example,
like
it
would
suck
tremendously.
A
If
there
would
be
types
you
have
to
derive
from
I
like
having
methods,
there
makes
sense
right
because
you
usually
have
a
one
line:
implementation,
but
well
these
things
ever
have
a
one-line
implementation.
Or
what
will
you
write
like
you
know,
a
page
of
code
in
there
because
then
it'll
end.
There
is
probably
also
not
the
best
way
to
do
it.
B
A
B
F
That's
why
we,
what
we
used
to
call
our
thing
connection
filters
that
we
ended
up,
calling
it
like
connection
middleware
I,
mean
I
and
agree
on
the
semantics
of
filter
being
a
little
bit
different,
quick
technical
question.
What
I
connection
properties
is
being
passed
into
the
filter
like
where's,
that
coming
from
a
game?
B
F
A
B
B
A
B
F
Another
thing
with
the
funk
right
is
like
if
you're
gone
with
the
filter
as
we're
calling
it
right
now,
connection
properties
is
effectively
read-only.
So
if
you
like
string
multiple
filters
together,
one
filter
as
far
as
I
could
tell
wouldn't
be
able
to
modify
the
the
properties
seen
by
the
next
Creek
right
now.
The
connections
properties
itself.
It
could
wrap
well
no
dot
for
those
Stream
wrappers,
but
never
like.
That
is
that.
A
F
F
B
F
A
A
D
B
A
A
F
A
H
A
H
A
H
F
B
B
C
E
E
B
F
B
D
I
mean
to
be
clear,
like
it's
a
lot
of
work
and
if
we
do
expect
there
to
be
these
one-liners
and
they're
really
think
that's
gonna
happen,
then
we
should
absolutely
do
it.
The
question
is:
is
for
real
use
cases?
Is
there
an
just
enough
more
complexity
that
you
need
to
derive
these
types
yourself
anyway?
At
which
point?
Is
it
just
slide
where.
E
E
F
A
C
A
Mean
my
bigger
concern
is
like
inez,
munoz
tend
to
flow
like
I
think
having
normal
virtual
behavior,
you
override
makes
more
sense
because
it
composes
nicer
right,
like
this
callback
mechanism,
basically
means
you're.
We
have
to
make
sure
that
everything
that
might
be
relevant.
You
actually
pass
in
right
and
then,
if
you
ever
add
to
that
state
set,
then
you
basically
have
to
add
another
overload
that
takes
a
different
shape
of
the
funk
versus.
If
it's
just
you
derive
from
connection
factory,
you
wrap
another
connection
factory.
You
override
the
methods
you
wanna
override.
F
B
H
That
would
really
be
up
to
whatever
any
of
the
individual
factory
types
are
right
like
if
the
if
TCP
doesn't
need
any
data,
then
maybe
there's
just
you
know:
TCP
connection
factory
dot
instance
and
it
it's
all.
Tcps
just
differ
based
on
what
you
pass
in
to
bind
and
if
that's
the
case
then
azad.
If
not,
then
they're
not
in.
D
H
A
H
I
A
F
So
when
I
call
dispose,
if
there's
like
an
ongoing,
called
it
except
async,
what
happens
for
one
do?
Does
it
like
row
returned
all
something
like
that
and
then
is
there
a
way
that
I
can
tell
the
listeners
like
abort
all
connections,
or
are
we
leaving
that
up
to
kind
of
the
user
the
listener
to
handle
themselves,
because
they
obviously
could
just
take
the
I
connections
and
abort
them
I'm
kind
of
actually
leaning
towards
the
the
ladder
on
the
last
part,
but
yeah
I?
Don't.
B
Know
if
it
would
be
appropriate
for
the
listener
to
like
own
the
connections
and
dispose
all
the
ones
that
it's
ever
created,
I'm
not
I'm,
not
sure
what
dispose
should
do
if
it
should
cancel
a
pending,
accept
or
if
we
should
ask
people
to
use
the
cancellation.
Token
I
think
that
no
or
our
own
types
we
could
use
that
very
easily.
But
you
know
anyone
implementing
this
it's.
It
can
be
kind
of
a
pain
to
implement
cancellation
logic
in
two
places.
I
have.
F
F
C
B
B
F
B
F
B
F
F
F
A
B
F
F
F
C
D
Why
you
can't
call
the
suppose,
I
think
on
the
I,
think
innumerable
while
move
next
async
is
in
flight?
That's
illegal
yeah!
Oh
man,
I
mean
it's
illegal
because
we
made
it
illegal.
We
could
make
us
do
that.
Well,
with
the
eight
with
the
state
machines
in
C
sharp
with
the
iterators
in
C,
sharp
mm-hmm.
F
A
Mean
you
kind
of
can
I
mean
like
that's,
it's
probably
half
and
the
bcl
all
the
time
right.
The
way
you
would
do
it
is
you
would
you
know
you
would
make
accept
async
the
existing
one.
You
would
move
it
from
abstract
to
virtual
and
you
wouldn't
make
it
call
the
other
one
and
then
the
new
one
is
virtual,
so
that
the
only
deal
for
this,
if
you
don't
arrive
from
it,
you
know
but
default.
You
don't
know
which
one
to
override,
but.
F
D
A
F
F
D
B
D
F
F
H
F
A
G
A
Like
there's
more
concerns
around
that,
and
you
probably
want
more
control,
as
we
said
with
dispose,
for
example,
do
you
want
to
be
able
to
tear
down
the
whole
thing
or
not
like
also?
What
kind
of
verbage
do
you
want
to
have,
except
a
sink,
probably
makes
more
sense
than
you
know,
get
all
connections
a
sink
or
something
like
that
right,
so
I
it
it's
it.
You
could
probably
model
it
as
a
nice
animal,
but
it
seems
a
bit.
You
know
either
cutesy
or
just
almost
the
wrong
vocabulary
for
the
job
right.
D
For
consumers
of
this,
is
it
always
gonna
be
the
case
that
you
choose
to
have
n
and
processing
loops,
no
more,
no
less
like.
If
you,
if
that's
the
situation,
then
you
know
you're
gonna,
spin
up
and
async
loops
sitting
there
right,
we'll
each
and
then
mate
and
wait
for
each
and
then
maybe
it
makes
sense.
But
if
you
ever
kind
of
move
that
up
or
down
or
there's,
you
know
something
where
you're
want
to
temporarily
have
an
extra
accept
or
one
fewer
accepts,
that
kind
of
breaks,
the
abstraction,
yeah
and
I'm.
F
Answer
I
am
yeah,
I
think
so,
for
the
most
common
use
case
is
basically
a
long
live
loop,
while
true,
except
in
a
loop
yeah
I
mean
it's
a
fixed
number
in
cash
flow
right
now,
based
on
like
a
number
of
cores
or
something
I
haven't
seen
anything
dynamically
change,
the
number
of
loops
that
we
don't
but
seems
possible.
I,
don't
see
why
I
would
want
to
like
do
something
that
that's
that
yeah.
F
Yes,
so
yeah,
it's
not
I,
think
like
returning
knell
for
the
four
annoying
is
ending,
always
felt
where
to
me.
I
always
wondered
like.
Should
this?
Should
this
instead
be
a
a
long
live
for
each
loop,
where
the
loop
ending
is
kind
of
like
this
thing
that
but
the
the
sequence
is
over
well
today,
is
it
yep?
F
A
The
only
benefit
of
advising
an
immobile
ax
is
that
you
can
support
these
programming
models
right
when
somebody
has
an
Rx
based
situation
right
where
you
want
to
compose
these
things
in
a
nicer
way,
with
extension
methods
or
stuff,
but
for
connections.
That
also
seems
somewhat
far-fetched
right,
like
for
the
actual
messages,
maybe
but
for
the
connections.
That
seems
a
bit
I,
don't
know.
F
A
A
F
A
The
thing
I'm
generally
not
like
I,
think
to
me
rx,
makes
sense
when
you
have
a
library
of
building
blocks
that
do
all
these
things
for
you
right.
So
the
people
basically
only
have
to
write
one
line
of
code
right
to
wire
things
together
and
I'm,
not
sure
that
necessarily
holds
for
connections
themselves.
I.
F
B
F
D
Can
I
not
know,
can
we
if
we're
all
cool
with
that?
Can
we
unblock
Cori
getting
the
PR
for
that
put
up
for
that
portion.
D
A
B
D
D
B
C
H
B
H
That
I
wanted
to
bring
it
what's
what's
the
package
layering
between
the
thing
that
will
do
open
TCP
and
the
thing
that
will
that
is
these
base
classes?
Are
they
all
in
one
package?
Are
we
extending
the
system
net
sockets
to
have
the
socket
stuff,
but
not
the
connection
stuff
like?
What's
the
what
are
the
big
building
block,
what
are
the
big
Legos
the?
What
are
the
duplos
here,
yeah.
H
H
B
H
B
A
We
should
definitely
look
at
like
the
assemblies
where
new
stuff
goes,
because
we
shouldn't
just
default
to
adding
new
assemblies,
because
that
has
other
costs
that
we
also
need
to
keep
in
mind,
and
so
it
seems
from
what
you're
saying
is
that
there's
some
inbox
dependencies
in
that
core
app
the
shared
framework?
They
will
need
access
to
those
API,
so
it
has
to
be
in
there
somewhere.
Now
we
haven't
and
then
there's
probably
some
things
like
the
concrete
implementations.
A
Clearly
I'll
live
higher
than
sockets
because
it
depends
on
sockets
and
then
there's
the
primitives
which
might
be
lower
than
that
or
at
the
same
level,
depending
on
where
you
want
to
move
this
right.
But
so
we
just
need
to
find
it
in
box
assembly
that
fits
the
bill,
and
if
there
is
none,
we
can
create
one,
but
I
would
generally
recommend
it.
It's
not
it
soon.
There's
a
new
one
because,
to
me
being,
is
a
separate
issue
that
we
can
solve
independently
of
this.
A
B
A
A
B
A
B
Okay,
so
sockets
HTTP
handler
we're
going
to
add
a
couple
ways
for
people
to
inject
their
own
connection
factory
into
this
sort
of
the
base.
For
that
is
this
connection
factory
here,
there's
no
way
or
or
you
can
get
the
the
default
factories
here
and
sort
of
wrap
them
and
whatever
way
you
want,
or
you
can
just
implement
them
all
from
scratch
and
just
call
this
connection.
Factory.
B
F
B
F
H
D
B
D
I
also
want
to
point
out
like
what
I
was
talking
earlier
and
in
previous
meetings,
like
the
sticking
point
for
me
about
having
one
thing
that
ends
up
being
like
the
preeminent
piece
of
this
whole
design
that
I've
shared
across
client
and
server
like
that
is,
and
how
every
component
that
deals,
the
you
know
that
deals
with
I
connections
needs
to
expose
something
at
that
level.
That
is
this
yep.
B
F
B
It's
kind
of
making
things
a
little
easier,
but
then
letting
you
customize
more
and
more.
So
this
is
basically
just
returning
a
basic
TCP
connection,
factory,
whatever
socket,
and
where
uses
already
all
right
this
one
here,
let's
you
just
create
the
socket,
but
otherwise
VA
is
the
same.
So
if
you
want
to
set
like
keep
TCP
keep
a
live
flag
on
the
socket.
You
can
do
that
and.
B
F
D
E
D
B
D
A
D
Forget
that
forget
the
top
six
for
a
moment:
okay,
the
entry
point
into
side.
They
should
be
hammer
to
actually
configure
what
connection
factory
it
uses,
regardless
of
where
came
from
how
it
was
created
who
built
it.
That
is
the
entry
point.
It's
that
connection
factory
that
basically
Sasaki
safety
handler
to
use
this
yep.
B
D
B
D
H
Yeah
and
similar
to
the
questions
we
had
with
the
filter-
and
you
know
the
the
complex
func
here-
is
the
expectation
that
most
things
can
do
this
in
one
line,
or
would
it
make
more
sense
for
there
to
be
a
custom
type
and
I
think
there
is
a
custom
type
which
is
just
a
connection
factory
and
at
which
point
I?
Guess
sorry,
it's
not
that
connection
factory,
because
you
need
the
the
current
handshake
of
create
socket.
So,
like
does,
should
there
be
a
rich
type
with
an
abstract
that
you're
supposed
to
implement?
D
For
my
expectation
and
Corey
and
David
can
chime
in
this
whole
feature
set,
is
born
out
of
the
idea
that
those
would
be
one-liners
because
there's
going
to
be
a
someone
published
as
a
package
us
or
someone
else
with
a
a
logging
connection-
and
you
know
it
just
logs
everything
that
it
wraps
another
eye
connection
and
it
just
logs
everything
that
comes
across
it.
And
so
this
one-liner
is,
you
know,
I
our
new
logging
connection,
connection.
F
Yeah
I
agree
it's
the
kind
of
restate
that,
like
it's
because
I
connection
is
this:
their
shared
abstraction
between
server
and
client,
so
you're
gonna
have
these
eye
connection
wrappers,
but
they're
not
gonna
have
like
necessarily
a
consistent
way
to
hook
up
to
say,
like
petrol
and
sockets
HP
Handler.
But
as
long
as
you
have
the
wrapper
and
like
a
one-liner
to
add
it
like
these
filter
methods,
I
think
good
shape.
That.
H
D
There
needs
to
be
something
like
this
scenarios
that
are
driving
this.
The
whole
reason
this
is
wrapped
up.
Asada
handler
is
because,
like
we
have
had
outstanding
requests
for
years,
yep
that
we
have
punted
to
basically
this
issue
and
each
of
them
end
up
being
one
or
two
liners
because
of
the
top
four
or
the
top
six
methods.
If
you
remove
those
it
becomes,
you
don't
do
everything,
but
it
becomes
a
whole
lot
of
work
right,
fast,
I
guess.
A
B
So
we
kind
of
started
out
looking
at
that.
That's
how
it
was
prototyped,
initially,
I
think
the
goal
here
is
that
almost
all
of
these
cases
we
have
for
this
entire
API
set
right
now
are
focused
on
HTTP
client
and
we
wanted
to
make
those
asks
very
trivial
without
having
to
implement
all
of
these
api's.
B
So
someone
just
wanted
to
add
a
pre
connection
filter,
so
they
can
do
that
here.
We
could
have
built
it
another
way
where
they
compose
factories
and
it
figures
stuff
out,
but
this
makes
it
an
easy
one
liner.
Similarly,
we've
had
requests
to
set
some
socket
options,
but
everything
else
is
identical.
They
don't
want
to
change
anything
else,
and
this
enables
to
do
that
with
a
one-liner.
D
A
I
guess
my
concern
is
Sony.
It
seems
like
some
of
these
stuff
in
the
top.
Six
methods
is
not
really
specific
to
sockets
right.
That's
just
anything
that
goes
over
a
connection
factory
will
have
a
way
to
create
the
actual
thing
that
does
the
work
right
and
then
you
have
additional
things
you
want
to
do
with
that
right
and
those
additional
things
are
probably
generic
things
that
we
could
do
over
any
eye
connection
factory
right,
and
so
this
was
the
I
think.
D
But
you
need
to
start,
you
need
to
know
like
the
the
implementation
here
will
end
up
fishing
out
of
the
connection
properties
like
they
should
be
request
message
and
the
DNS
end
point
all
that
stuff.
So
there's
a
lot
of
boilerplate
specific
to
this
consumer.
If
so,
unless
we
want
everyone
using
these
to
write
all
that
boilerplate
and
I,
don't
think
we
do,
because
there
are
seven
or
eight
kind
of
common
examples
where
this
is
gonna
become
an
you
know,
a
primary
thing,
so.
D
Example,
life
with
it
so
German
fight
for
the
second
method.
There,
one
that
returns,
a
socket
like
we
get
requests
over
and
over
and
over
for
I,
want
to
do
everything
that
sausage
began
there
currently
does,
but
I
want
to
restrict
it
to
a
certain
network
interface,
which
means
I
want
to
create
the
socket
call,
bind
and
return
the
socket.
It's
the
only
thing,
I
want
to
change,
so
it's
that
that
it's
that
second
method
with
a
func
that
says
new,
socket,
socket,
bind
return
socket.
So.
H
D
Alternative
design,
I
think,
is
that
at
the
top
six
method,
six,
for
you
know
three
for
overloads
and
two
methods
is
a
concrete
sockets,
HP
Handler
connection
factory
type
with
like
three
virtuals
or
four
virtuals,
whatever
it
ends
up
being,
and
you
say:
new
sockets,
HTTP
handler
connection
factory,
sorry,
you
you
derive
from
socket
a
shipping
handler
connection
factory,
you
override
those.
You
know,
whichever
will
see
that
that's
you
need,
and
then
you
instantiate
that
and
you
assign
it.
A
So
in
that
case
they
make
sense
to
be
here,
but
if
they,
if
some
of
them
are
just
accelerators
to
avoid
writing
didn't
you
know
the
the
very
first
method
call
which
gives
you
the
the
connection
factory
specific
to
socket,
then
that
might
explode
badly
right
because
it
means
not
every
single
time.
We
have
one
more
thing
you
just
keep
to
add
and
in
two
places
right.
That's
the
kind
of
thing
I
try
to
avoid
you're.
D
A
D
And
I
have
no
problem
with
the
class
like
exposing
a
socket
HP
handler
connection
factory
with
multiple
virtuals
on
it.
It
means
the
use
of
those
is
a
little
bit
more
code
because
you
have
to
create
your
own
class
override
the
methods
and
then
instantiate
the
class,
but
maybe
it's
a
little
bit
more
for
future
proof.
Yeah.
H
And
the
two
argue
you
know
against
that,
just
to
make
sure
we're
designing
what
we
want
to.
If,
if
the
purpose
here
is,
you
would
end
up
with
three
virtuals,
but
really
the
best
answer.
Is
you
only
override
any
one
of
them?
Then?
Maybe
the
there
are
three
different
things
that
you
get
to
write
the
one
method
that
you
do
and
we
figure
out
how
to
compose
it
correctly
for
you.
H
D
Common
case
will
be
to
override
one
I.
Think
probably
the
you
know,
the
the
90%
case
is
to
override
one
I
think,
there's
probably
a
10%
case,
where
maybe
you
would
override
two,
because
if,
for
example,
you
were
overriding
the
kind
of
the
one
to
create
the
connection,
you
know
that
returns
a
stream
and
you
want
it
to
delegate
to
what
the
base
implementation
did
for
that
and
then
like
wrap
it
in
some
way
that
base
implementation
would
ends
up
using
the
virtual
that
created
the
socket.
D
E
H
Yep
and
as
a
to
understand
how
someone
uses
these
pretend
or
so
assume
we're
on
HTTP
one
one-
and
you
know
there's
this
thing
called
HTTP
that
doesn't
have
an
S
on
the
end
is
all
of
the
default
port,
routing
and
and
all
that
stuff
already
done,
and
the
DNS
endpoint
already
has
the
right
port,
or
is
somebody
responsible
for
inspecting
the
scheme
off
the
URI
of
the
message
and
doing
all
the
routing
themselves?
In
the
general
case,
the.
B
H
Out
how
much
work
is
somebody's
supposed
to
like
you're
passing
a
bunch
of
things?
Is
it
because
they
need
to
do
all
of
them,
or
is
it
because
some
people
want
to
like
write
down
one
thing
from
the
request
message
and
then
do
the
default?
Some
people
want
to
write
down
the
endpoint
and
do
the
default.
Some
people
want
to
filter
the
okay
yeah.
So.
B
So
the
DNS
endpoint-
you
probably
always
use
unless
you
were
maybe
doing
like
an
in-memory
transport.
The
request
message
here
is
used.
Is
there
because?
Well,
you
might
want
the
URL,
but
it's
only
the
first
URL
on
the
connection.
So
it's
not
super
useful.
Better.
Is
the
properties
/
options
grab-bag
on
on
their
request
message,
so
the
user
could
create
a
request
with
something
and
then
read
it
in
here
if
they
wanted
to.
D
The
short
answer
to
your
question:
Jeremy
is
the
port
in
the
DNS.
Endpoint
is
the
one
that
you
should
be
connecting
to.
Okay.
The
longer
answer
is
there
are
certain
places
where,
like
for
the
second,
with
the
overload
below
the
one,
that's
highlighted
that
returns
a
stream
or
a
connection
right.
You
might
not
be
going
over
TCP
at
all,
you
might
be
going
over
named
pipes,
you
might
be
going
over
UNIX
domain
sockets,
whatever
at
which
point
you're
gonna
need
to
reinterpret
the
data
in
the
request
message
and
the
endpoint.
B
D
Don't
I
don't
well
it's
not
that
I,
don't
like
them,
but
it's
a
necessary
evil
because,
let's
say
you're
doing
the
let's
say
we're
doing
the
virtual
approach.
So
we
had
a
socket
HP
handler
connection
factory
concrete
type
and
it
had
three
virtual
methods,
one
that
returned
to
socket,
one
that
returned
to
stream
and
one
that
returned
an
eye
connection
and
you
overload
override
the
right
one
to
get
the
behavior.
You
want
all
those
are
virtual,
because
the
base
implementations
provide
kind
of
the
functionality
for
those
that
socks
HTTP
handler
does
today
right.
A
D
Scheme,
we
don't
have
the
ability
to
have
a
base
implementation,
so
these
default
we're
basically
creating
a
new
pattern
here
where
these
quote
me
of
default
methods
are
the
base
implementation
and
if
you
wanted
to
do
the
equivalent
of
calling
to
base
you
instead
call
sake.
Hp,
Handler,
dot,
defaults,
create
socket
or
default,
establish
connection,
and
that's
as
if
you
were
calling
base
so
we're
inventing
a
new
pattern
that
I
haven't
really
seen
used
anywhere
and.
A
D
F
A
F
B
F
B
F
A
B
F
D
Think
I
talked
my
site
even
though
I
argued
with
you
Cori
and
presenting
the
static
methods.
I
think
I've
I
think
I've
argued
myself
into.
We
should
maybe
put
it
back
into
just
yeah.
H
D
Mean
the
thing
I
don't
like
is
is
to
do
anything
meaningful
with
it
to
do
anything
if
you're
gonna
use
that
class,
the
only
reason
you'd
use
it
really
is
to
derive
from
it
and
override.
So
we've
made
something:
that's
that
really
is
a
one-liner
into
like
a
ten
liner,
including
a
custom
tight
but
yeah,
but
maybe
that's
not.
F
A
A
A
H
D
B
D
F
B
D
C
H
So
it's
I
mean
it's
assuming
that
it's
easy
enough
to
create
a
connection
from
a
stream
where
it
will
then
just
return
a
thing
that
has
a
the
pipe
based
writer
over
a
stream
and
the
stream.
Then
then,
maybe
you
just
want
establish
connection
and
it's
you
know
two
more
lines
of
code
for
somebody
doing
a
stream
do.
B
F
D
B
F
D
B
H
C
B
B
B
D
B
F
D
B
F
F
H
B
F
B
F
H
We
we,
in
addition
to
providing
the
the
default,
call
the
other
one
implementation
we
get
to
control
the
it
once
you've
called
one
of
these.
You
can't
call
the
other
it
throws,
and
that
is
true
for
all
connections,
no
matter
what
that
is
part.
The
connection
contract
now
I
am
not
sure
about
that.
So
that
part
I'm
not
sure
about
yet
I
mean.
H
B
You
can
you
think
of
a
situation
where
you
are
using
a
pipe
and
suddenly
you
want
to
write
to
that
pipe
through
a
stream
yeah,
but
you
want
to
use
both
at
the
same
time.
I'm
like
so
it's
the
same
thing
from
using
a
network
stream
will
totally
clash
with
using
you
know
the
pipe
zone
buffering.
No,
so
so.
F
That's
the
problem
though,
but
so
like
alternating
between
stream,
pipe
and
middleware
will
work
fine,
like
reading
from,
like
the
stream
same
stream
using
stream
and
pipe
like
the
pipe
buffers
for
you
right,
like
you,
don't
control
like
basically
what
the
the
default
pipe
is.
Basically
gonna,
sip
out
of.
A
F
Sorry,
if
so,
if
it's
like,
adding
throttling
to
encryption,
that's
fine
well
I
mean
I,
guess
what
those
don't
know
throwing
doesn't
necessarily
use
the
stream.
But
if
you're
layering
transformations,
that's
one
thing:
if
you're
like
a
parser,
that's
taking
a
connection
and
then
using
the
stream
for
one
frame
and
then
a
pipe
for
the
next
frame
of
the
data,
then
that's
not
gonna
work.
A
F
Of
it
as
different
components,
I
know
that
if
you
interleave
in
the
same
component,
it
is
weird
and
bizarre
I'm
talking
about
two
different
things,
that
one
thing
that
was
written
first
dreams
and
one
thing
that
was
rid
of
her
pipes
and
the
first
thing
understands
that
the
next
thing
is
written
for
streams
and
I
use
this
pipe
on
it
and
it.
It
makes
sure
that
the
connection
is
in
the
race
day,
so
that
it
is
gonna
pass.
The
right
state
all
work
to
the
next
component
without
having
the
weird
behavior.
B
F
F
D
F
D
If
the
user
is
providing
one
of
one
of
those
things,
then
because
the
other
thing
doesn't
have
isn't
privy
to
whatever
buffering
it's
using,
we
would
have
to
wrap.
We
would
always
have
to
wrap
if
someone
gave
us
a
pipe
we'd
have
to
wrap
it.
If
someone
gave
us
a
stream,
we'd
have
to
wrap
it
because
we,
but
we
then
we
would
control
sort
of
the
siblings,
the
stream
and
the
pipe
siblings,
and
you
know
their
own
buffering
on
top
of
that
arbitrary
underlying
data
source
rights.
F
F
F
D
Problem
is,
if
you
try
and
use
both,
and
so
if
we
wanted
training
to
use
both,
we
couldn't
give
you
wrong
for
the
one
that
the
developer
created.
We'd
have
to
expose
our
own
wrapper,
I
guess
if
they
gave
us
a
stream
we'd
have
to
wrap
that
stream
in
our
own
stream
that
coordinated
with
the
pipe
right
so.
F
A
F
F
In
that
case,
you
would
want
to
rap
as
the
TLS
handshake
inspector.
So
you
would,
you
would
take
a
look
at
the
first
few
bytes
using
the
pipe
or
whatever,
and
then
you
just
wrap
the
connection,
and
you
know
you
want
to
start
from
the
beginning
anyway.
So,
yes,
it
would
be
easy
if
you
could
just
like
examine
the
bytes
using
the
pipe
and
then
not
consume
it,
but
it's
not
that
hard
to
just
wrap
it
again.
So.
A
F
E
F
F
If
you
are,
if
you
are
authoring
a
piece
of
thing,
a
component
that
runs
in
a
middleware
chain,
then
you
should
wrap
it
if
you
touch
this
dream
before
passing
it
on,
because
you
don't
know
that
someone
is
gonna,
read
the
pipe
of
the
stream
and
therefore
like
AMI
and
malfunction
all
right
thanks
for
writing
to
write
because
I
think
either
access
would
end
up.
Invalidating
the
others,
though,
for
writing
it's
doesn't
need
to
be
that
way.
It's
just
more
consistent,
I
guess.