►
From YouTube: System.Net.Connections
Description
Powered by Restream https://restream.io/
A
B
Sure
so
this
issue
is
essentially
an
abstraction
over
socket
so
that
we
can
use
things
that
are
not
socket
in
classes
like
HTTP
clients.
You
know
anything
that
needs
to
establish
a
connection.
Kestrel
is
already
doing
something
with
a
very
similar
api
today
and
kestrel
would
also
be
adopting
this
going
forward.
B
C
B
A
D
Wife,
actually,
in
fact,
I
added
a
comment
at
the
end
of
the
issue
that
basically
raises
both
of
these
issues
and
proposes
an
alternative
usage
that
I'm
pretty
sure
that
you
have
arguments
wife.
You
know
you
visit
the
way
you
did,
but
I
would
be
interested
in
kind
of
comparing
contrasting
and
seeing
why
kind
of
the
non
interface
and
not
factory
by
design,
you
know
wouldn't
work
or
would
be
yeah.
B
D
B
E
B
B
This
does
the
same
thing,
but
for
actually
establishing
connections.
So
in
this
example
here
you
can
see
I'm
layering,
a
SSL
connection,
factory
on
top
of
a
sockets
connection
factory
and
then
just
calling
it
and
connect
a
sink
in
the
same
way
you
would
call
stream
dot
read
and
that
sort
of
routes,
everything
down
through
the
layers
of
the
composition.
B
B
The
next
feature
is
extensibility,
so
this
would
be
proposed,
as
essentially
the
the
standard
recommended
model
for
anyone
who
is
exposing
or
anyone
who's
establishing
a
connection.
They
can
accept.
One
of
these
connection
factories
and
let
the
user
override
how
they
want
to
make
connection
so
HTTP
client
has
a
ton
of
examples
of
people
wanting
something
like
this
from
wanting
to
set
socket
options
to
just
controlling
DNS
or
even
replacing
TCP
completely.
A
common
example
that
I
found
elsewhere
and
other
platforms
is
wanting
to
route
through
things
like
a
sucks
proxy.
B
It
would
be
very
easy
for
anyone
to
plug
in
you
know
in
any
sort
of
new
transport
that
they
want
through
this
and
we're
starting
out
with
just
HTTP
client
here,
but
this
could
go
through
like
SMTP
clients,
sequel
connection.
We
would
encourage
third
party
libraries
to
use
this
and
try
to
create
kind
of
in
an
ecosystem
of
various
transports
and
filters
that
people
could
choose
through.
B
B
B
Often
you
want
to
shut
down
a
socket
and
have
it
be
half
open,
so
you
have
to
keep
track
of
a
socket,
even
though
you
might
be
layering
tons
of
things
on
top
of
it.
Similarly,
SSL
stream
has
things
you
know
beyond.
You
have
to
authenticate
as
the
client
you
might
want
to
get
various
properties
such
as
the
cipher
strengths,
and
that
sort
of
thing.
B
So,
even
though
stream
is
composed,
you
still
kind
of
have
to
keep
track
of
the
individual
layers
and
especially
in
instances
where
you're
trying
to
provide
extensibility,
it
becomes
very
challenging
to
allow
users
to
plug
in
at
very
specific
points
in
your
in
your
layering,
while
still
keeping
track
of
all
the
things
that
you
need.
So
one
way
this
tries
to
solve.
This
is
through
property
bags,
which
aren't
great,
but
I
would
love
suggestions
for
something
else.
That's
better,
so
you
can
see
an
example
of
our
TLS
implementation
here.
B
Similarly,
so
that's
sort
of
the
implementation
of
the
connection
properties
and
then
below
that
we
have
the
actual
usage
of
you
know.
I've
established
this
connection
and
now
I
want
to
pull
that
SSL
connection
properties
out
of
that
connection,
as
well
as
wanting
to
pull
the
socket
out
of
the
connection,
this
is
sort
of
a
way
that
any
custom
implementation
would
have
to
know
which
properties
that
it
needs
to
provide
as
well.
B
B
B
So
I
showed
the
example
earlier
of
in
inside
of
HD
HTTP
client.
How
I
defines
three
separate
layers
via
this
middleware
concept?
This
is
sort
of
an
example
of
what
of
those
layers
might
look
like
and
how
it
might
pull
information
out
from
outside
of
its
own
layer
and
be
able
to
use
that
and
pass
it
down
and
make
intelligent
decisions.
B
Right:
here's,
the
good
stuff,
the
API
connection
properties
is
the
property
bag.
We
have
a
similar
interface
in
in
BC.
Already
a
service
provider
in
system
component
model
I
believe
that
we
could
reasonably
choose
to
use
I,
don't
know
what
the
layering
looks
like
on
that
wait.
What
what
to
do?
What
do
you
think,
instead
of
my
connection
properties,
it's
sort.
B
G
D
Yeah
by
the
way,
with
not
having
a
good
general
purpose
property
bag
idea
in
BC
L
is
a
very
long
issue
in
visitor
I.
Remember
discussions
about
it
literally
like
15
years
ago
and
as
with
many
of
similar
problems,
the
discussion
always
ends
with
G's.
We
need
to
ensure
that
it
works
for
everything.
It
may
be
more
complicated
than
just
a
simple
interface
one
method.
D
B
B
Okay,
I'll
give
you
a
broad
overview
and
then
we
can
dive
in
individual
ones.
So
there
is
this
connection:
property
collection.
This
is
basically
just
an
easy
implementation
of
this
for
users
that
just
want
to
pass
it
in
a
couple
properties
when
they
call
connect
internally,
there's
sort
of
a
more
optimal
way
to
implement
this
collection.
Often
you
can
kind
of
share
allocations,
so
it's
not
something
that
we
would
generally
use
in
our
own
code,
but
it's
there
just
to
make
lives
easier
if
the
users
and
the.
B
B
The
usage
of
this
would
be
that
the
user
uses
one
of
them
and
then
to
prevent
sort
of
weird
issues
with
buffering
and
whatnot.
If
they
try
to
use
the
other
one,
we
would
throw.
This
is
an
interface,
so
we
can't
guarantee
that,
but
that
would
be
our
own
implementation
and
guidelines
that
we
would
place
for
that.
You
know
how
you
could
guarantee
that
an
interface.
B
B
Next,
we
have
this
eye
connection
interface.
This
is
what
is
returned
by
all
the
factories.
Currently,
in
theory,
we
could
have
a
connection
stream
and
I
connection
be
merged,
but
they
are
separated
because
we
are
anticipating
adding
some
quick
features
later
on
and
the
eye
connection
stream
really
fits
for
quick,
but
I
connection
does
not
so
the
eye
connection
Factory
it
just
has
connect
and
bind
on
it
and
bind
returns.
The
next
interface,
the
eye
connection
listener,
which
allows
you
to
then
accept
connections,
you'll
notice
that
all
of
these
have
async
on
them.
B
You
know
socket
bind
today
is
not
async,
but
there
are
cases
where
a
custom
transport
would
have
that
be
a
synch,
for
instance,
a
socks
proxy.
You
have
to
send
something
out
to
tell
the
the
proxy
that
it
needs
to
listen
on
a
port
that
sort
of
thing
so
we're
just
preparing
for
I/o
in
all
these
little
places,
including
in
disposal.
B
Finally,
we
have
some
extensions
just
to
make
things
a
little
easier.
All
of
these
interfaces
create
quite
a
lot
of
ceremony.
If
all
you
want
to
do
is
inject
a
stream
filter,
so
we
provide
this
nice
easy
filter
method
that
just
gives
you
lets.
You
provide
a
callback
that
says
you
know
for
this
connection
and
these
properties
I'm
just
going
to
return
this
stream
and
use
that
and
another
one
that
returns
the
eye
connection
I
only.
E
B
B
G
B
B
G
B
Could
add
a
ball
I
think
my
my
feeling
on
that
is
that
in
general
we
should
encourage
any
sort
of
reusable
libraries
to
just
implement
both
and
anyone
who
is
implementing
their
own
for
something
super
specific.
Maybe
they
want
to
do
something
special
in
just
kestrel
and
they
never
plan
to
call
connect
it's
okay,
to
place
a
burden
on
them
of
throwing
not
implemented
exception
and
saying
you
did
this.
You
know
that
it
won't
work.
E
Client-Server
stack,
there's
the
more
practical
concern
that
we
faced,
which
is
let's
say
you
have
a
filter
method
that
has
overloads
for
I
connection,
Factory
and
I
connection
listener,
Factory,
and
then
you
have
one
concrete
implementation
that
may
influence
both
interfaces.
So
you
have
a
socket
connection,
whatever
that
implements
both
you
try
and
pass
it,
and
you
get
ambiguity
from
the
community
McHugh
dr's
from
the
compiler,
because
I
can't
figure
out
which
one
you
want
to
use,
and
then
you
want
to
do
things
like
composable
stuff.
E
So
you
want
to
have
a
wrapper
for
these
things,
so
you
basically,
then
you're
forced
to
create
two
completely
separate
rap
composable
chains,
one
just
for
eye
connection
listener
and
one
just
for
eye
connection.
Sorry,
one
just
for
a
connection
factory,
one
just
for
a
connection
listener
factory
and
you
can't
ever
merge
them
together
in
a
concrete
class,
because
then
it's
ambiguous
as
to
which
you
would
end
up
going
with.
So
you
you
end
up
with
two
completely
separate
things,
improve
you
forever.
So,
like
extension,.
E
E
Interfaces
right,
or
even,
if
just
yes
or
if,
if
I,
wanted
to
implement
like
I'm,
forced
to
have
an
SSL
connection
factory
and
a
nexus
L
connection
listener,
factory
I
can't
put
them
both
on
the
same
class,
because
then,
when
I
then
try
and
pass
that
to
the
next
thing
up
the
chain
that
might
say
have
two
constructors,
one
that
takes
an
AI
connection
factory
and
one
that
takes
my
connection
listener
factory.
It
can't
decide
between
the
two,
the.
G
Thing
is,
though,
it
it
doesn't
solve
the
problem.
So
what
you
saw
is
you
can
know
right
methods,
dot
that
I
can
wrap
a
single
type
to
handle
both
client
and
server.
But
you
haven't
saw
the
issue
that
you
thought
the
case
that
the
consumer
of
the
interface
doesn't
know
what
is
actually
implemented,
but
I
think
what
would
you.
G
The
reasoning
around
having
small
discrete
interfaces
versus
having
big
abstract
base
classes
is
that,
as
you
add,
more
about
behavior
that
wasn't
on
the
interface
in
the
first
place,
so
there's
to
design
there's
to
design
plus
things
right.
One
is
you
have
an
abstract
base
class
that
has
a
bunch
of
functionality
as
the
baits,
as
you
add,
more
features
that
are
that
can't
be
infinite
on
every
single
derived
class.
G
You
have
to
add
boolean,
it's
like
can
read
can
write,
can
do
new
thing
all
right,
because
if
you
can't
provide
a
default
notation,
then
you
have
to
throw
and
to
avoid
the
consumer.
Getting
that
exception,
you
have
to
add
a
bool
to
make
it
nice
to
use
right.
The
other
design
pattern
is,
you
have
small,
discreet
interfaces
and
people
cast
a
figure
out
what
is
supported
all
right
and
that's
kind
of
the
other,
the
other
side
of
the
coin.
For
that.
D
We
don't
did,
we
don't
have
the
can
methods,
because
we
wanted
to
have
big
classes
and
some
subtypes
not
implementing
the
functionality.
We
have
they're
the
testers
because
we
kept
adding
functionality
that
didn't
exist
before
so.
We
had
to
have
default
implementation
of
the
functionality
which
was
not
implemented
by
some
subtypes,
so
string
has
can
seek
it
and
you
know
the
other
things,
because.
D
D
B
D
And
for
the
very
same
reason
you
know
and
there's
pushed
very
strongly
for
having
one
stream
we
had
these
discussions
long
time
ago.
People
wanted
to
have
two
streams
and
basically
he
said
the
same
thing
that
Steve
just
said,
which
is
the
moment
you
break
it.
Yes,
in
some
cases
it's
kind
of
looks
nicer,
and
then
you
notice
the
ripple
effect,
which
is
everything
now
is
bifurcated,
and
you
keep
kind
of
you
know
it
keeps
giving
I.
G
Am
not
convinced
that
the
that
we
have
experienced
the
other
way
enough
to
to
come
to
see
that
is
better
or
worse
than
stream,
so
like
if
you
derive
from
stream.
Now
you
have
to
override
a
bunch
of
things
because
we
added
a
bunch
of
behaviors
right
we're
in
this
model,
so
the
and
this
isn't
the
same
as
dream,
but
there
are
two
messes
specifically
there's
connect
and
bind
nine.
B
G
Think
having
smaller
interfaces
it's
better,
just
because
you
know
for
fun.
If
you
implement
that
interface,
you
yeah,
you
have
to
admit
that
that
one
connector
by
Nasik
method
and
I
don't
know
that
we
have
situations
where
we
actually
have
overlap
between
server
and
client
I.
Think,
like
I,
think
during
our
investigations
there
was
very
little
overlap
at
the
factory
level.
Yeah.
D
I
think
it's
worth
with
Laurie
I'm,
just
saying
just
because
they
said
the
advantage
of
one
design.
Like
you
said
you
know
splitting
there
is
I.
Don't
think
anybody
in
this
group
denies
that
there
would
be
some
advantages
of
the
split
I
would
just
say:
let's
not
take
it
lightly,
the
implication.
Basically,
for
you
know,
stream
stream
has
problems,
but
at
least
we
know
what
the
problems
are.
It's,
like
you
know
the
evil
that
you
know
correct,
yep,
the
other
side
that
use.
As
you
said,
we
experiment.
It's.
D
We
don't
have
a
very
concrete
experience
with
it.
Like
evolution
of
this
API
is
how
it
goes
over.
You
know
next
10
years,
but
it's
actually
a
problem.
We
don't
we
don't
know,
what's
gonna
happen
with
this
thing
in
10
years
and
we
know
what's
gonna
happen
will
unify
the
API.
It's
gonna
the
same
exact
problems
that
stream
has
and
it's
gonna
have
the
same
advantages.
That
stream
has.
B
B
Having
a
merged
interface
I
think
is
fine
if
we
say
that
you
know,
if
you
want
to
provide
a
Sox
connection
factory,
we
expect
you
to
provide
both
connect
and
bind.
It's
gonna
be
a
reusable
nougat
package
that
you
know,
server
or
client
can
use
or
aunt
will
end.
We
would
say
if
you
have
something
very
opinionated
that
only
works
for
your
specific
use
case,
and
it's
not
like
this
reusable
module
that
you're
distributing.
G
Seems
like
the
wrong
pivot
right.
So
what
if
there's
actually
features
that
don't
make
any
sense
on
the
server
but
make
sense
as
client
middleware
that
you
end
up
having
to
throw
in
bind
always
because
there's
no
real
implementation,
like
a
DNS
cache,
you
want
to
cache.
The
soma
passes
passes
in
Edina
endpoint
and
you
want
to
cache
it
for
some
amount
of
time.
So
you
create
a
DNS
endpoint
battery
and
that
makes
no
sense
on
the
server
side.
I
mean
it
could,
but
it
doesn't
and
bind
does
what
it
always
throws.
G
G
Sorry
good,
so
the
interface
has
two
things
and
I
and
I'm
forced
to
implement
both
things
and
I.
Don't
how
about
implementation
ever
or
one
of
those
two
things
and
there's
no
boo.
That's
not
looking
check
to
see
if
this
works
or
not
so
it
seems.
It
just
seems
weird
to
me
that
your
fourth
thing
that
can
be
on
the
interface,
how.
G
E
So
your
solution,
just
to
clarify
your
solution,
is
to
have
two
completely
separate
type
hierarchies,
one
for
client,
one
for
server,
and
anyone
who
wants
to
play
in
this
has
two
completely
separate
type
hierarchies,
one
for
client
and
one
for
server
and
there's
no
overlap
between
client
and
server.
So
they're
really
just
two
completely
separate
staffs
right.
G
E
H
G
B
H
Sorry
so
I
think
the
question
is
like:
are
we
okay,
because
we
can't,
if
we
have
two
interfaces,
have
a
concrete
factory
implement
both
because
passing
it
into
methods
which
require
passing
all
the
time
which
is
part
of
the
problem?
And
what
David
saying
is
he'd
still
shared
the
connection?
Even
if
you
do
have
two
different
factories.
They'd
have
to
be
two
different
actual
types
at
the
factory
level,
but
they
could
share
the
same
class,
for
the
connection
is
what's
happening
like
for
me
right,
I,
guess.
G
Will
I
will
say
that
there
today
today
in
cash
flow
on
the
server
side,
we
exposed
the
connection
to
the
user?
We
don't
expose
the
actual
batteries
and
they
on
that.
On
that
part,
a
stack
not
on
the
pathway,
part
of
it.
So
there's
a
there's
a
case
for
you
have
gone
past
the
connection
buying
stage
and
you're
not
trying
to
transform
white,
and
that
is
kind
of
where
the
connection
is
shared
and
you
can
and
you
can
compose
more
things
after
doing
the
initial
stage.
H
Yeah,
so
what
data
strain
says?
I
experimented
with
this,
you
know
abstraction
in
kestrel,
and
the
abstraction
point
in
the
kestrel
is
not
at
the
listener.
Factory
interface
you're,
actually
wrapping
the
I
connection
listener,
and
that's
because
we,
basically
let
you
define
middleware
per
endpoint,
so
having
someone
basically
do
kind
of
the
the
lookup
for
what
they
should
do
at
the
factory
level
is
just
like
a
lot
of
busy
work.
The
casual
is
already
doing
so.
You.
H
I
connection
listener
today,
like
in
3-1
or
whatever
we're
wrapping
the
connection
context,
which
is
the
equivalent
of
the
I
connection
and
going
forward
in
five.
Oh,
we
plan
to
basically
continue
supporting
the
old
model
if
you'd
basically
have
something
that
just
rapid
that
I
can
actually
similar
to
those
extension
methods,
but
also
support
wrapping
the
I
connection
listener.
H
E
That's
part
of
my
concern,
so
do
let
me
do
we
expect,
and
this
is
sort
of
a
meta
question,
but
do
we
expect
an
ecosystem
of
components
that
just
wrap
by
connection
there's?
No,
no
I
connection
listener
factory,
no
I
connection
factory
in
the
picture
you
get
a
new
kit
package
and
all
it
does
is
taken
an
eye
connection
and
spit
out
in
our
connection.
I.
Think.
G
E
Reason
I'm
asking
is
because
that's
the
only
thing
holding
together,
client
and
server
here,
if
it's
not
for
that,
there's
no,
this
isn't
the
client
server
story.
This
is
two
completely
different
stories
that
happen
to
be
in
the
same
proposal.
Yes,
if
we
don't
expect
any
components
of
that
ilk,
then
there's
no
point
in
trying
to
pretend
that
these
two
things
are
the
same.
If
we
do
expect
components
of
that
ilk,
then
there's
value
agreed.
G
B
G
H
E
H
E
That's
where
I
was
going
so
in
discussing
all
the
various
scenarios
for
sockets.
They
should
be
handler
this,
like
the
presence
of
eye
connections,
strongly
suggested
that
we
should
have
the
ability
to
do
two
different
things.
One
is
provide
the
eye
connection
factory
and
the
other
is
regardless
of
what
I
connection
factory
stock
is
HTTP
handler
is
using
insert
a
transform
on
the
eye
connection
that
was
in
place.
Yeah
right.
We.
G
E
I
wasn't
saying
we
force.
That
is
the
only
point
of
composition.
I
was
saying
that
if
you
go
with
with
the
two
inner
like
the
two
different
model-
yep
you
you
can't
just
have
that
as
Raizel
point
yeah
you
you
need
an
additional
one
focused
on
my
connection.
We
basically
need
to
make
eye
connection
as
star
citizen
as
the
factories
yep.
B
B
D
B
B
D
This
issue
they
would
they
could
implement
like
we
are.
We
are
doing
this
trick
very
often
were
like
internally.
If
we
want
to
share
some
state
and
or
optimize,
there
is
an
internal
object.
That
kind
of
has
everything,
and
then
it
just
gives
you.
You
know
two
children
corresponding
to
either
the
reading
site
or
the
writing
side
and
the
children
have
nothing
nothing
they
just
forward
to
that
to
the
shared
object.
G
Places
and
more
about
the
patterns
that
make
it
more
more
volatile.
So,
for
example,
if
you
make
a
big
interface
chances
are
you're
gonna
want
to
keep
adding
to
it,
because
you
made
it.
You
made
that
interface,
the
single
kind
of
entry
point
to
everything
versus
making
small
discrete
interfaces
you
tend
to
have
more
but
which,
which
could
lead
to
more
casting,
but
we
kind
of
design
patterns
around
where
that
wasn't
a
problem
and
we
don't
not
have
a
base
class,
we
kind
of
have
a
mix
of
both
things.
G
So
I
think
it
was
just
depending
on
the
consumption
we'd,
the
different
things
so,
for
example,
in
in
Kestrel,
we
have
feature
interfaces
that
are
implemented
on
on
a
big
object
that
are
very
small,
that
we
add
more
those
too.
So
we
add
features
by
adding
more
interfaces
and
we
just
leave
the
interface
as
like
as
as
broken
or
old
or
whatever,
and
we
don't
change
the
interface
yeah,
but.
D
I
think
the
reason
for
it
is
that
small
interfaces
in
general
are
more
successful.
Yeah
like
ienumerable
is
successful
because
it's
so
simple
and
small
I,
but
the
problem
is
that
sometimes
things
cannot
be
simple,
so
if
they
can
be
simple
sure,
but
sometimes
things
are
just
not
simple
and
the
moment
they
are
not
simple,
I,
don't
think
they
can
be
interfaces
that
may
be.
You
know
the
way
I
would
describe
it
and
when
I
see
you
know
this
stuff
I
mean
it
reminds
me.
D
G
D
Know
it
was
about
the
reader,
it
was
about
something
about
complete,
oh
I
forgot
anyway,
I
mean
we
keep
running
into
this
issue.
We
keep
running
into
this
issue
that
we
ship
interfaces,
and
then
you
know
a
year
later.
We
like
our
shorts,
like
what
do
we
do
now
and
yes,
I
agree
that
it
happens
from
time
to
time
that
we
have
a
simple
interface
and
it's
successful.
Yes,
it's
so.
E
I
have
a
question
on
both
sides
of
this
argument.
Just
understand
people's
positions
so
so
Christoph
does
your
position
change
given
default
interface
methods
and
to
David?
What
do
we
lose
if
we
make
things
like
eye
connection
listener
factory
into
connection
listener
factory
in
particular?
Given
this,
you
know
the
scenarios
in
which
this
is
going
to
be
used
so.
D
D
D
A
D
The
second
thing
is,
the
way
I
would
think
about
it
is
I
would
design
it
first
with
classes
and
then,
if
there
are
problems,
then
you
can
have
a
discussion
of
the
trade-offs
between
you
know:
risk
with
themes.
You
know
it
not
being
supported
in
runtime
like
I'm,
more
much
more
open
to
people
saying
well,
we
tried
it.
We
try
to
follow
the
you
know
the
philosophy
of
that
net
and
it
didn't
work.
Those
are
the
concrete
things
that
you
know
prevents
us
from
doing.
This
I
am
much
less
sympathetic
to
well.
D
G
For
me,
we
have
a:
we
have
a
hierarchy
in
a
spinnaker
that
we
have
to
figure
out
how
to
reconcile
with
this
anyway.
I
think
part
is
part
of
the
strategy
was
sense,
these
things
or
interfaces.
We
can
now
implement
them
both
on
our
current
abstract,
our
current
implementations
and
it
wouldn't
cause
my
strife
and
we
could
slowly
deprecated
the
old
interfaces
and
move
to
the
new
interfaces,
but
maybe
there
are
ways
to
return
it
to
make
it
a
base.
Class
I,
don't
think
they
can
all
be
base
classes.
G
D
Yeah
this
is
this
is
the
kind
of
like
approach
that
I
do
like,
which
is
you
know
we
tried
and
we
run
into
concrete
issues.
Yeah-
and
you
know
at
that
point
because
it's
all
it's
a
trade-off
correct.
It's
a
trade-off
between
how
we
think
we
will
want
to
evolve
it
in
the
future.
You
know
what
problems
we're
gonna
round,
how
the
inside
gonna
work
by
the
way
of
that
acronym
dense.
Now,
it's
easy
to
put
it
in
a
sentence
is.
A
G
Think
is
the
other
experiences
just
because
we
actually
tried
to
use
them
aggressively
and
we
didn't
just
throw
them
away
and
say
we're.
Gonna
have
a
base
mask,
are
everything
so
we
kind
of
use
them
aggressively
and
then
we
kind
of
understood
what
the
edges
were
and
I
wouldn't
I,
wouldn't
simplify
it
by
saying
you
cannot
have
parameters.
It's
super
nuanced
right.
E
B
Yeah
yeah,
when
I
was
making
this
and
I
didn't
really
see
a
benefit
to
using
a
abstract
base
class.
Just
because
what
this
is
used
for
it's,
it
can
really
assume
nothing
about
what
the
implementation
is
going
to
be.
So
I
can't
imagine
what
you
would
do
with
the
base
class
that
you
could
not
do
with
a
dim,
but.
A
So
I
mean
basically,
you
have
to
assume
in
the
VCL
it'll
be
at
least
ten
years
before
we
use
Adam
like
that's.
Essentially,
you
know
the
because
Christoph's
point
of
dotnet
framework
doesn't
support
them.
We're
gonna
have
customers
on
dotnet
framework
for
a
long
time.
We
don't
want
to
have
two
standards,
one
for
things
that
we
know
we're
in
the
box
now
and
one
for
things
that
works
planning
on
making
as
a
nougat
package
and
then
oh,
we
want
to
take
this
thing
that
was
in
box
and
making
a
nougat
package.
A
A
G
E
G
I
E
And
using
interfaces
after
a
feature
was
introduced
versus
before
the
feature
was
introduced
like
moving
forward.
Everyone
knows
that
default
interface
methods
are
a
thing
yep
that
wasn't
the
case
20
years
ago,
and
when
you
say
everybody
you
mean
who,
like
Kathy,
using.net
like
new
every
new
version.
Of.Net
includes
support
for
default
interface
methods.
I
know.
G
E
D
I'm
just
saying
that
the
practical
outcomes
will
be
the
same
whether
the
interface
was
pre-existing
or
not,
because
most
customers
don't
know
about
it
or
don't
think
or
don't
even
know
what
the
implication
could
be
of
adding.
You
know
a
new
method
to
Indian
interface,
so
I
feel
practical
perspective,
I
think
whether
interface
already
shipped
10
years
ago,
or
it's
a
new
one,
I,
don't
think
that
it
makes
a
difference.
I,
I.
F
E
Think
there's
a
you
know
when
it
comes
to
gyms
there's
a
big
difference
between
adding
something
to
I
enumerate
in
the
system
collections,
generic
name,
space
versus
adding
something
to
eye
connection
listener,
Factory
in
the
system:
net,
dot
connections,
dot,
you're
using
something
super
advanced
namespace.
Oh
yeah,.
G
C
G
A
G
At
some
point,
we're
gonna
we're
gonna,
have
to
try
it
and
understand
what
it
does.
I
feel
comfortable
and
maybe
we'll
go
back
and
forth,
but
like
I,
don't
want
to
I,
don't
want
to
rely,
but
I
don't
want
to
leave.
I
was
like
a
thing
that
we
can't
use
anyway
up
in
this
chamber
concerned
and
we
won't
use
it,
but
then
like
let's
not
pretend
that
it
does
exist
right.
Yeah,.
D
So
I
think
we
should
try
them
and
you
you
right,
but
everything
that
you
just
said
I
totally
agree
the
the
argument
that
I'm
trying
to
make
is.
We
should
terrorists
we
already
in
correct.
There
are
some
risks.
We
should
know
why
we
are
taking
them
and
design.
Today,
basically
said
you
know,
everything
is
an
interface
right.
Well,
we
haven't
tried
to
you
know
like
make
some
of
those
things
classes.
C
E
B
G
E
You
have
you're
forced
to
implement
these
two
completely
separate
class
hierarchies,
in
which
case
I
think
it's
a
reasonable
thing
to
do
to
to
split
them.
So
I'm,
okay,
with
that,
as
long
as
like
that's
our
sort
of
guidance
around
how
these
are
used
on
the
second
piece,
given
how
small
these
are
and
the
fact
that
I
think
you
know
that
I
connection
listener
factory
does
one
thing
you
had
one
job
I
actually
think
it's
oh
and
that
it
takes
a
property
back.
So
it's
effectively
virginal
in
terms
of
what
it
accepts
in
the
future.
E
Maybe
not!
Ideally,
but
like
there
are
ways
to
do
it
personally:
I'm,
okay,
with
these
being
interfaces,
but
I
totally
respect
people
that
and
the
opinion
that
there
might
be
a
reason
or
a
need
to
at
these
in
the
future.
When
we
decide
that
both
stream
and
pipe
are
no
longer
the
cool
kids
on
the
block,
and
we
want
to
add
the
third
thing
you
know-
maybe
that's
a
good
example
but
I'm
okay,
with
with
either
thing
there
I
I,
think
it
does.
B
So
the
first
thing
I
would
ask
for
clarification
on
is
it
sounds
like
we
will
be
recommending
I
connection
as
the
way
to
filter
just
the
data
stream
in
a
wave
that
has,
if
you
have
a
filter
that
does
not
need
to
be
applied
during
establishment
of
the
connection,
we
would
recommend
that
you
write
your
filter
on
my
connection
only
and
completely
skip
the
factories
yep.
Yes,.
E
And
I
think
it's
twofold:
one
is
for
the
sort
of
component
implementer
I
think
the
requirement
is
what
you
just
said
for
the
client
or
server
implementer.
It
is
exposing
the
ability
to
use
such
a
transform
and
or
oh
and
then
for
also
for
the
component
implementer.
It's
kind
of
building
that
model.
You
know
you,
you
would
implement
your
combined
connection
implementation
as
a
public
class
with
a
constructor
that
takes
the
in
connection
that
it's
wrapping
or
some
such
thing.
Yeah.
A
Because
somewhere
I
mean
if
some
protocols
like
SMTP
with
start
TLS
are
after
the
connection
has
started,
you
start
adding
new
layers,
and
so
just
doing
it
at
a
factory
level
is,
is
limiting
in
that
in
those
scenarios
and
then
I,
there's
sort
of
the
like
does
what
like
factory
composition?
Presumably
is
really
you
call
the
other
factory
to
get
its
connection
than
you
do
your
stuff
on
top
of
the
connection,
which
really
means
that
it's
all
actually
just
connection
filtering
or
layering,
the.
E
Other
thing
that
add
is
you
know
anytime:
we
ship
an
abstraction,
it's
really
nice.
When
we
have
some
implementations
of
it.
We
know
that
there
are
common
things
that
we'd
like
to
see
done
between
client
and
server.
For
example,
it'd
be
great
to
have
some
sort
of
you
know,
debugging
login
component,
where
you
can
just
see
written
out
to
console
or
whatever,
like
in
a
nice
format.
E
It
form
the
bytes,
the
the
plaintext
bytes
that
are
coming
across
the
wire,
that's
something
that
would
plug
in
just
as
well
with
this
into
kestrel,
as
it
would
into
sockets
HTTP
handler
as
it
would
in
to
SMTP
clients
that
went
into
whatever
and
that's
the
kind
of
thing
like.
If
we're
gonna
pick
one
thing
to
sort
of
validate
this,
we
might
want
to
consider
shipping
that
in
the
box.
E
D
E
We
explain
the
splitting
would
basically
just
be
anywhere
UCI
connection
factory
I
connection
factory
just
becomes
rather
than
two
in
two
methods.
On
that
one
interface,
it
becomes
two
interfaces,
an
eye
connection
factory
that
has
connect
async
and
an
eye
connection
listener
factory.
That
has
bind
a
sync.
That's
it
yep.
D
H
On
a
slightly
like
topic,
Corey
and
I
discussed
this
already,
but
how
do
we
feel
about
AI,
async,
disposable
and
I
disposable?
Being
on?
Like
you
know,
all
these
interfaces
together?
My
feeling
is
that
in
the
cases
where
disposal
isn't
asynchronous
at
all,
basically
where
it's
generally
non
blocking
I
can't
say
that
always
is
but
one
it
is
a
sink.
H
There's
no
like
blocking
I/o
API
that
you
could
use
generally,
like
generally
you're
waiting
on
another
thread
to
like
finish
its
usage
of
the
memory
pool
or
something
like
that
I'm,
at
least
in
Kestrel.
So
my
feeling
is
your
eye
disposal
implementation.
If
it
wasn't
just
something
simple
we'd
be
blocking
anyway,.
A
B
B
If
we
put
this
interface
into
HTTP
client,
suddenly
we
need
to
like
what
block
when
people
call
dispose.
Do
we
tell
everyone?
Okay,
sorry,
change
your
code
to
await
using
putting
this
directly
into
the
interface
put
being
eye
disposable
in
here
makes
it
easier
for
existing
libraries
to
adopt
this
pattern
without
forcing
their
users
to
make
some
some
larger
changes.
G
A
D
We
talked
in
the
context
of
the
sync
HTTP
api's:
we
should,
how
is
their
rule?
The
static
analysis
rule
that
basically
tells
people
if
you
in
an
async
context,
called
async
versions
of
api's.
Otherwise,
maybe
it's
fine
to
call
sig
measures,
because
that
would
also
like
address
the
issue
that
Corey
was
talking
about,
which
is
existing
code,
keeps
calling
this
post
too
bad.
You
know
the
frame
is
already
synchronous,
so
so
so
what?
But
it
would
be
good
to
if
you
I
mean
a
nice
same
phrase,
to
kind
of
point
people
in
the
right
direction.
D
G
E
H
B
Is
intended
to
be
layered
with
composition
right
and
the
property
bags
allow
you
to
not
pay
attention
to
all
the
individual
layers,
so
the
the
anticipation
is
that
the
interface
should
be
sort
of
the
default
way.
You
use
it
you're
just
going
to
call
new
your
concrete
implementation
and
then
never
pay
attention
to
that
implementation.
Again.
You're
only
gonna
use
this
through
the
interfaces,
and
why
is
so
white.
G
B
H
B
But
if
we
say
that
the
factory
is
not
disposable,
then
the
user
then
has
to
pay
attention
to
you
know
their
sockets
factory.
They
have
to
keep
that
around
because
they'll
have
to
dispose
that
and
then
they
have
all
the
other
layers.
On
top
of
that
that
they
might
also
need
to
dispose
all
I'm
saying.
G
Is
that
you
have
to
make
everything
disposable
to
like
keep
that
assertion
all
right?
Everything
just
like
everything,
just
in
case
and
basically
have
to
know
up
inside
of
it
and
and
that
that
is
the
other
side
of
the
coin,
to
not
knowing
if
you
have
to
disclose
where
everything
is
disposable
by
default.
And
that's
how
you
single
that
that
may
be
that
they
have
to
call
this
bullets
but
I'm.
Not
seeing
that
as
like
a
better
argument.
But.
I
What
ends
up
happening
is
that
you
may
call
a
method
that
is
in
no
op
right,
but
in
the
grand
scheme
of
things
that
might
still
be
better
than
strengthening
your
entire
co-pays,
with
a
scars
and
and
and
remembering
to
do
that
in
all
cases
right
so
I
think
that's
the
that's
the
trade-off,
but
I
mean
yes,
you
can,
you
could
argue
and
say,
no
interface
should
ever
be
I
disposable.
The
caller
always
has
to
check,
but
then
then
really
could
get
super
tedious
right.
So
very.
G
Really
tricky
to
know
ahead
of
time
what
made
this
possible,
because
you're,
just
assuming
that
the
factory
is
disposable
and
is-
and
in
this
case
it
happens
to
be
because
Kestrel
and
it
in
our
current
battery-
needs
to
allocate
a
pool
that
gets
disposed
and
disposed,
but
I
think
had
that
not
have
been
there.
This
thing
would
not
have
been
responsible
because,
for
example,
TCP
listener
isn't
disposable.
G
A
G
I
Yeah
I
mean
what
I'm
missing
is
like.
What's
the
benefit
of
not
doing,
are
you
just
saying
the
guideline
of
implementing
a
disposable
is
prone
to
arrows
because
you
might
not
know
upfront
what
to
call,
but
then
I
would
say
well
if
you
miss
something
too
bad,
we
can
edit
in
the
next
version,
but
an
interface
of
course,
but
an
absolute
in
an
abstract
based
class.
You
can
of
course,
add
new
interface
implementations.
So,
like
that's,
why
I'm
saying
I'm
gonna
tell.
G
H
E
E
H
E
H
E
I
E
Anyway,
and
not
having
the
interface
and
just
always
query
before
it
actually
makes
that
worse.
Exactly
now,
if
sake
seems
to
be
handler,
is
supposed
to
just
query
for
I
disposable
on
the
factory
and
call
it
if
it
had
it
yeah.
No,
it
doesn't
it's
gonna
always
call
you're,
never
gonna
be
able
to
share
yeah.
G
E
B
E
B
Think
David
I
understand
your
perspective.
You
know
someone's
in
a
DI
environment,
it
makes
sense
to
say:
hey
it's
the
containers
job
to
dispose.
Why
would
I
have
a
dispose
method
I'm
on
my
interface
but
elsewhere,
where
you
may
not
be
using
di,
and
you
know
you
just
want
to
keep
this
one
interface
around
I
think
disposed,
makes
sense
in
kind
of
the
same
way.
People
are
disposing
of
stream.
Today,.
E
B
B
I
But
I
guess
to
your
earlier
point.
But
if
the
idea
is
you
instantiate
the
concrete
factory
once
and
then
everything
else
is
expressed
over
the
interfaces,
then
why
would
anybody
ever
have
to
dispose
the
factory
because
they
didn't
see
that
the
top
frame
would
own
the
factory
right
quart
Corey's
point
was.
I
A
But
then
we're
back
to
the
question
of
should
because
Corey
said,
factory
composition
was
one
of
the
design
goals.
So
does
that
composition
model
need
to
assume
there's
no
ownership
transference?
Does
it
need
to
assume
there
is
ownership
transference
or
do
we
get
the
parameter
and
if
we
get
the
parameter,
but
it's
not
disposable,
then
we've
kind
of
lost
the
meaning
of
what
that
parameters.
For
so.
I
A
I
D
G
D
D
D
G
Think
that
matters
I
think
think
of
it.
This
way
like
when
you
create
the
pool
in
castro,
imagine
it
had
an
argument
that
was
the
pool
you
want
to
use
that
could
be
given
to
you
right.
Yeah
and
I
could
have
a
pool
like
only
open
to
I,
suppose
it
just
kind
of
kind
of
gross,
but
today
and
cash,
oh,
the
the
factory.
Is
it
the
thing
that
owns
a
pool?
I
mean
when
you
dispose
the
battery
the
pool
goes
away,
but.
F
E
E
Started
say:
let's
say
in
stocks
which
begin
there
we
we
wanted
to
have.
You
know
there
was
a
phase
of
the
app
that
made
a
whole
bunch
of
networking
quests
and
then,
after
that,
it
was
done.
It
was
doing
a
bunch
of
processing
on
the
results.
If
it's
factory
pre
creative,
it,
you
know,
allocated
a
bunch
of
memory.
Pin
buffers
used
that
for
the
all
requests
that
are
made
on
the
handler
and
then
I'm
done
with
HTTP.
After
that,
there's
no
point
in
keeping
the
memory
around
I.
G
H
G
G
D
F
E
D
D
That
you
pass
right,
but
this
is
the
same
thing
that
we
have
I
think
analogous
to
what
we
have
with
HTTP
kind,
correct
like
we
made
HTTP
client
disposable,
because
in
reality
it
is
a
disposable
resource,
but
it
caused
all
kinds
of
problems,
because
it's
a
shared
resource
and
it's
not
clear
in
the
end,
who
owns
it
and
like
I've,
seen
called
seriously
like
yesterday,
I
was
on
a
meeting
with
somebody.
They
implemented
ref
counting
for
HTTP
clients
that
they
create
in
there
like
I,
won't
mention
who.
D
E
H
A
D
It's
possible
really
works
really
well
for
these
likes,
you
know
short,
live
things
like
I,
create
a
connection
when
I'm
done
with
it
and
I'm
the
only
owner
when
I
done
with
it,
I'm
done
for
the
shared
resources
yeah,
we
don't
have
a
good
solution.
This
is
one
additional
shared
resource
that
we
are
introducing,
that
is
disposable
and
I,
don't
think
disposable
works
well
for
for
di
works.
H
D
G
For
use
in
NHP
net
core,
it
isn't
matter.
If
the
interface
are
the
concrete
it'll
get
disposed
at
the
appropriate
time,
because
we
we
actually
don't
have
the
classes
themselves
disposed
there
they're
the
the
things
that
were
given
to
them.
It
happens
by
a
I,
know:
site
Orchestrator.
So
it's
more
a
use
case
for
if
you
were
nearing
up
a
bunch
of
things,
pass
them
around
by
hand
without
without
having
an
Orchestrator
who
does
the
disposal
and
who
does
the
casting
and
who
haven't
detect
what
so
I'm
more
concerned
about
the.
E
The
intermediate
components
in
the
chain
here
because
I
hope,
respectively
saying,
is
everyone
who
raps
pick
one
of
these
things.
Everyone
who
creates
a
round
for
that
is
and
contains
one.
You
know,
that's
a
decorator
yeah
now
has
to
just
in
case
it
implements
I
disposable
and
has
to
prepare
you
for
I
disposable,
at
which
point
it
may
as
well.
Be
I
disposable.
H
B
A
Well,
I
mean
starvation
or
the
the
fun
starvation
we
already
get
with
HTTP
of.
If
you
don't
dispose
it,
then
eventually
we
run
out
of
sockets,
but
that
means
that
we
go
into
a
blocking
phase,
so
we're
not
allocating
memory,
so
the
GC
doesn't
kick
in.
So
the
final
answers
don't
want
the
process.
Deadlock.
A
A
H
F
H
H
A
I
mean
the
the
so
the
counter
position
for
connection
factories
not
being
disposable
is
simply
saying
if
you
called
new
you're
responsible
for
knowing
when
to
call
dispose
and
that
you
that
you
saw
when
you
said
new,
socket
factory
that
it
was
disposable.
So
you
put
it
into
using
and
you
own
you
own
the
scope,
and
that
I
mean
that
is
a
story
and
if,
but
that
was
that
really
suggests
that
we
think
that
it's
rare,
that
a
factory
owns
or
is
disposable.
E
E
H
I
got
a
new
question
related
suppose
I
talked
to
Corey
about
this.
A
little
bit.
Do
we
want
abort
is
right
now,
if
you
wanna
like
and
riding
through
the
stream,
you
call
dispose,
and
you
know
the
thing
gets
that
which
is
great.
But
what,
if
there's
like
some
rate,
timeout
that
I'm
trying
to
enforce
and
there's
the
backpressure
and
I
do
not
want
to
like
flush.
What's
ever,
you
know
in
our
internal
buffers
and
I
want
to
abort
not
like
send
a
pin.
H
D
Do
I
don't
understand
what
so
I
connection
stream
is
literally
I
was
thinking.
We
were
talking
about
classes
and
interfaces,
it
seems
like
it
could
even
be
a
strapped.
It
stores
the
property
back
stream
and
a
pipe
and
it's
half
of
work,
and
what
would
the
imagine
that
it
was
a
strap
that
just
has
these
three
fields?
What
would
their
board
do?
It.
G
D
G
G
B
H
B
B
D
H
D
Mean
it's
the
same
problem:
it's
not
clear
what
the
relationship
is
between
those
tools.
Some
of
them
have
exactly
same
implementation.
Some
of
them
were
trying
to
make
it
different
and
and
I
feel
like
one
danger
with
the
board.
Is
it's
basically
yet
another
take
on
okay?
We
have
a
different
method
and
it's
not
clear
whether
it
does
the
same
thing
or
not,
but
here's.
G
H
H
A
H
Okay,
the
weird
thing
about
it
is
at
least
in
casual,
it's
important
that
you
can
call
a
port
after
you
call
disposed,
or
at
least
before
disposing
completes,
because
it's
a
way
to
like
cancel
it.
What
so,
if
disposed,
disgraceful-
and
that
is
the
weird
thing
and
I
I
can
see.
Who
are
you
just
laughing
over
there?
It's
like
if
disposed,
is
I
want
to
flush
the
rest
of
my
output
buffer,
and
that
takes
too
long.
Castrol
avoids.
E
H
H
B
H
E
B
E
Don't
know
what
they
are,
but
I
the
only
thing
I
just
reason:
discussion,
I
have
no
qualms
with
adding
additional
methods
here.
The
the
thing
I
do
care
about
is
that
we
don't
use
this
after
dispose
and
definitely
not
while
dispose
a
sink
is
in
flight,
but
your
third
sphere
and
then
secondarily,
if
we're
already
talking
about
adding
methods
to
this,
while
I
was
in
the
camp
of
interfaces
far.
G
A
Well,
in
I
mean
yeah
like
once
it's
a
class,
then
certainly
we
could
codify
in
you
know,
hey
I've
started
async
disposed.
Abort
is
now
going
to
throw
the
Eau
de
immediately,
even
if
the
async
disposes
in
flight,
like
you
can
build
that
into
the
base
class.
Before
you
start
calling
off
the
virtual
members.
G
And
today
the
connection
actually
is
a
base
class,
so
we
have
the.
We
have
an
interface
for
the
listener
and
the
and
the
connect
side
of
things.
But
then,
once
you
get
a
connection
mat
that
is
a
base
class
because
we
we
actually
expect
it
to
add
more
things
to
the
base
class.
That's
why
we
made
out
of
bus.
So
there
you
go
yeah.
A
So
yeah,
so
why
so
there's
a
comment
that
says
connection
stream
and
connection
are
split
because
of
quick,
but
connection
has
only
has
two
endpoints
and
they're,
both
nullable,
which
means
assuming
that
quick
just
says:
endpoints,
don't
make
sense
they're
just
both
null
if
you're
using
quick.
So
why
is
there
a
separation.
B
We
could
say
that
I
think
that
there's
it's
a
slight
difference
there
knowable
in
the
case
that
someone
has
weird
you
know,
maybe
an
in-memory
transport
where
an
endpoint
just
doesn't
make
sense
in
quick.
If
you
ask
for
an
endpoint
on
a
connection,
you're
really
just
doing
the
wrong
thing.
It's
not
the
case
of
like
it
makes
sense
for
it
to
be
null
it's
more
like
you're,
calling
it
in
the
wrong
place.
So
it's
a
usage,
error,
I.
G
Yeah
I
agree:
I
think
we
shouldn't
be
pure
at
all.
Actually
I
think
we
should
put
things
that
can
be
know
if
they're
super
commonly
used.
One
of
our
design
matters
in
Ethernet
was
to
maybe
h-2b
context
the
the
place
where
people
have
the
most
common
properties
that
are
used
in
HTTP,
even
though
there
aren't
all
like
super
pure
because
making
it
really
pyramid
made
it
hard
to
use.
So
we
hoist
things
from
features
and
into
properties
that
are
used
everywhere
and,
of
course,
it's
a
it's
an
actively.
G
D
B
B
It
does
prevent
present
some
problems.
If
you,
for
instance,
if
one
layer
wants
to
expose
an
int
and
then
the
next
layer
also
wants
to
expose
an
int,
you
could
very
easily
shadow
without
knowing
it.
The
workaround
for
this
is
that
each
one
would
define
some
ifou
that
has
an
int
on
it
to
kind
of
disambiguate
that,
but
it
is
a
risk
with
accepting
types.
G
Like
this
thing
is
not
property
bike,
it
is
not
a
name
by
you
key
of
stuff.
It
is
a
type
for
a
specific
reason.
This
is
trying
to
work
around
the
type
system.
Internet,
basically
right.
Well,
we
basically
want
to
to
to
do
is
to
a
love
for
a
model
where
you
can
decorate
connections
right
over
and
over.
G
So
you
start
with
the
sockets,
and
you
have
a
cell,
then
you
have
some
of
them
some
other
connection,
and
you
want
the
person
who
has
any
connection
to
be
able
to
reach
back
into
the
object
hierarchy
of
things
that
were
wrapped
to
expose
properties
that
were
either
from
sockets
or
a
cell
stream,
or
vice
versa.
So
you
can
think
think
of
it
like
trying
to
like
to
imagine
you
want
to
basically
derive
from
everything
you
wrapped
and
expose
the
properties
of
the
entire
object.
Our
key
as
you
wrap
more
things
so.
G
E
H
So
imagine
that
you
could
take
an
eye
connection
and
then
just
wrap
it
and
then
add
interfaces
influence
to
it.
So,
in
this
whole
wrapping
infrastructure,
we
have
an
eye
connection
which
also
implements
a
bunch
of
other
interfaces.
You
and
I
add
an
interface
implementation
or
maybe
decorate
an
interface
implementation
and
pass
it
down.
You
know
the
call
site,
but-
and
you
can
do
that
today
with
decorators
the
problem
is
you
lose
all
the
interfaces
you
don't
know
about,
because
you
can't
like
pass
those
through
right.
G
So
it's
not
a
property
bag
in,
in
a
sense
that
the
the
way
it
is
consumed
is
you're,
trying
to
actually
use
interfaces
or
use
types
to
override
implementations
so
like
so.
Yes,
it
is
a
bag
of
properties,
but
the
the
specific
properties
are
text
because
you're
trying
to
basically
override
types.
So,
like
the
whole
thing
were
you
talking
about,
you
can't
have
two
int
that
is
actually
intentional
you're
doing
it
you're
trying
to
intentionally
override
an
interface
implementation.
E
For
me,
like
the
ins,
may
not
be
the
best
example,
but
so
imagine
that
local
endpoint
and
remote
endpoint
were
in
first-class
properties
here
right
then
our
case
were
there
they're,
both
being
provided
by
the
same
layer
of
this
thing,
but
there
are
two
different
endpoints
yeah
and
we
have
to
the
scheme
of
use.
This
type
is
working
around
the
type
system
than
having
to
introduce
new
types.
For
each
of
these
is
a
workaround
for
working
around
the
type
system.
Sure.
G
H
G
D
G
We
have
a
system
of
using
types
in
in
the
server
and
the
features
exist
across
so,
for
example
like
if
you
want
to
get
property
from
it
from
SSL's
from
from
an
SSL
implementation,
we
have
an
SSL
feature
that
has
a
bunch
of
properties
on
there.
If
that
isn't
the
same
key
between
client
and
server,
you
lose
the
sharing
right.
Why.
G
G
E
Creates
a
different,
it
exposes
it
in
a
different
way.
So
if
you
have
object,
then
you
you
need
to
expose
static
properties
that
name
the
objects
to
be
used
for
a
given
thing.
So
you
have
public
static
object,
local
endpoint,
public
static
object,
remote
endpoint,
key
or
whatever,
and
those
are
the
things
that
you
then
pass
in
as
the
it
is
the
key
it
just
so
happens
that
the
concrete
type
of
the
object
returned
from
the
SSL
properties.
Key
property
would
be
a
type
I
think.
A
A
Like
I
see
that
there's
the
extension
method
of
try
get
of
tea
to
say:
oh
the
property
key
type
and
the
value
are
probably
always
the
same
thing,
but
it's
an
interface.
The
way
it's
proposed
right
now,
there's
literally
no
requirement
to
do
that
like
you
could
pass
in.
You
know,
type
of
dictionary
of
string
string
and
it
and
the
thing
that
it
Out's
is
a
boolean
like
the
there's,
our
so
use
it
so
type
is
just
being
used
as
object,
and
you
can
do
object
equality,
the
same
as
the
object.
B
G
B
E
D
So,
by
the
way,
another
reason
why
we
so
we
had
a
similar
feature
in
early
on
and
we
are
still
probably
will
need
to
add
it
in
a
circle
and
we
typed
it
as
object,
and
the
reason
was
also
one
additional
awesome
feature
for
it.
We
wanted
sometimes
to
smuggle
properties
across
many
layers,
but
we're
we
owned
both
the
ends,
but
the
customer
code
was
in
the
middle
and
we
didn't
want
them
to
access
this
property.
D
It
was
basically
a
private
property
and,
and
it
was
we
explored
actually
using
types
and
unfortunately,
at
that
point
you
have
to
kind
of
a
you
know,
had
a
type
that
is
not
public
type,
and
sometimes
you
know
that
the
natural
type
is
a
public
type
when
you
make
it
into
an
object.
The
awesome
feature
is
that
you
can
basically
just
have
internal
objects.
This
is.
G
D
E
D
G
Just
so
you
know
like
today,
we
actually
have
that's
why
I
don't
want
to
call
it
property
bag
like
we
have
two
different
things.
One
is
a
feature
collection
and
the
key
is
types
and
one
is
an
object
of
a
dictionary,
and
that
is
what
you're
talking
about
like
that
property
bag
is
for
arbitrary
stuff
internal
object,
keys,
whatever
you
want
to
show
smuggle
through
the
actual
object.
App
is
similar.
Twelve
hhb
client
has
a
property
bag
on
the
request
message
that
is
optically
as
well.
G
This
is
specifically
about
like
so
you
could
I
can
seal.
You
can
say
like
we
want
to
use.
We
want
to
have
the
same,
buying
v4
keys
for
arbitrary
types,
but
we
made
a
choice
to
make
a
future
collection,
a
special
object
with
different
semantics,
and
this
much
were
specifically
about
how
type
of
a
rights
work
in
the
object
hierarchy.
So.
D
G
H
Corey's
point:
like
anyone
consuming
I
connection
properties
knows
the
type
of
the
thing
that's
getting
returned
like
they
have
to
unless
I'm
doing
some
sort
of
reflection.
So
now
you
need
to
know
this
like
additional
thing.
Keys
and
I
do
like
type
being
prescriptive,
because,
given
all
of
the
ASI
legacy,
I
think
that
so
it
will
ultimately
end
up
using
as
a
key
and
I
see
that
the
point
that
we
could
use
both
the
property
and
it
could
just
happen
to
be
the
type
which
is
the
key.
A
G
E
You
you
you
may
they
may
be
one
of
the
same,
but
they
may
not
end
point
is
being
is
a
good
example
right.
I
I.
If,
if
we
didn't
have
these
two
properties
here
and
I
had
to
fish
these
out
of
connection
properties,
how
do
I
do
that
I
would
have
to
add
two
new
types
purely
to
extract
the
end
point
you.
G
Would
add
one
new
type
called
a
endpoint
so
like
what
we're
doing
is
gonna?
We
have
these
things
called
features,
and
then
you
implement
features
on
your
on
your
your
type
would
implement
a
connection.
I
would
implement
a
connection,
feature
ie
block
feature.
You
have
that
for
features,
and
you
expose
those
features
by
returning
like
when
my
son,
my
loss,
try
get.
You
basically
returned
this
right,
but
so
a
bunch
of
like
Thank
You
fun
it
right
so.
E
G
A
E
G
C
G
A
E
A
E
G
E
E
And
I
return,
whatever
I
want
there,
it
could
be
new
object,
it
could
be
type
of
something
and
that
that
property
is
the
key
that
I
used
to
look
it
up
and
the
and
I
realize
it
is
adding
something-
and
maybe
this
is
probably
I
of
the
beholder.
But
it's
to
me
it's
cleaner
to
add
a
new
property
that
it
is
dad
in
your
type.
If.
G
Every
socket
had
a
bar,
you
could
just
try
get
socket
on
the
type
now
you're
done
and
not
have
to
add
a
property
called
bark.
This
only
is
this
when
you
want
things
that
are
cross-cutting
when
you
want
to
do
things
that
are
that
are
abstracted
and
cross-cutting
and
maybe
maybe
on
different
different
implementations,
you
want
to
explore
SSL
properties
because
it
may
come
from
my
cell
stream
or
from
quick
or
from
a
different
implementation
of
SSL
other
than.
G
E
History,
so
so,
but
that's
that's
exactly
the
case.
Oh
it
wouldn't
just
be
socket,
it
would
be,
you
know
they
suck
it,
because
there
might
actually
be
two
sockets
involved
like
there
could
be
a
proxy.
There
could
be
something
that's
causing
me
to
have.
Multiple
levels
of
actually
and
I
want
to
go
to
specify
which
thing
I
want
to
get
just
asking
for
socket
is
insufficient
right.
G
G
Thinking
about
it,
look
at
like
an
interfaith
implementation:
we're
trying
to
get
is
a
dumb
cast.
That
is
the
mental
model
that
the
mental
model
is
I,
want
to
access
a
specific
set
of
features
or
behavior
from
a
type
alright.
They
that
we
do
that
in
is.
Is
you
downcast,
so
you're
doing
an
ass
cast
to
an
interface
to
get
the
application
together,
because
it
feels.
A
To
me
like,
like
this,
is
sort
of
suggesting
in
XML
terms
that
what
you
want
is
the
ancestors
walk
and
that
you
want
to
ask
for
ancestors
of
type
blank
and
that
we
should
just
build
that
in
instead
of
have
this
loosely
typed
key
like
so,
you
ask
for
hey.
Go
give
me
all
my
socket
ancestors,
hey
socket
ancestor
now:
I
have
a
strong
reference
to
a
socket.
I
can
reuse
all
the
properties
off
of
socket,
and
we
don't
need
this.
No,
no.
G
E
The
problem
is
were
looking.
We
have
two
different
mental
models
for
what
this
is.
You
say,
that's
the
model,
that's
your
vision
for
the
model,
I
think
that's
different
than
what
what
I
think
of
is
the
model
and
I
think
they're
both
valid.
I
but
I
think
we're
thinking
of
it
differently
and
I.
Don't
know
that
we
can
say
what
is
right
and
what
is
wrong
so,
but
David
is
your
interface.
H
D
Think
that
we
could
so
I
understand
now
how
you
guys
are
using
it
and
why
you
oppose
object,
but
I
think
that
we
could
kill
two
birds
with
one
stone.
I
think
there's
gonna
be
scenarios
where
people
want
to
do
both.
What
you
want
to
do,
but
also
smuggle
arbitrary
properties
through
you
know,
chain
and
I.
Think
taking
object
would
basically
let
you
do
both
like
you
can
keep
using
it
with
tides
and
if
somebody
just
wants
to
smuggle
a
property
that
they
can
do
it
with
object.
Key.
H
E
B
B
A
A
Collection
requires
a
minimum
of
being
enumerable,
so
you
can't
use
it
sure
or
you
can
derive
from
stream
or
be
enumerable,
but
those
are
those
are
names
that
have
meaning
and
don't
don't
start
muddying
the
meaning
sure
it
may
be
that
I
connection
stream
just
becomes
you
know
connection
with
the
last
point
of
combine
them.
I,
don't
know
what
to
do
about
the
property
bag.
B
D
I
Who
took
math
to
pull
it
off
now?
The
question
is:
can
can
David
summarize
in
writing
what
he
wants?
The
pattern
to
be
because
I'm
still
not
entirely
sure
I
understand
how
that
would
be
different
from
the
property
based
approach
in
terms
of
expressiveness
I
mean
I,
understand
the
mechanical
differences
I
still
struggle
with
whether
there
is
an
expressiveness
difference
between
the
two
you're.
H
H
I
H
H
G
E
Buy
this
consumption
pattern
as
a
really
nice
benefit
to
the
type
using
a
type
yeah.
I
still
worry.
What
happens
when
you
do
out
endpoint,
but
maybe
my
concerns
are
unfounded.
I
just
I,
don't
want
to
be
in
a
position
where
come
next
six.
We
say
we
have
to
add
14
different
new
types,
purely
for
the
concept
of
extracting
stuff.
From
these
dictionaries,
the.
I
At
that
point,
the
question
is:
what's
the
benefit
of
a
proper
tea
bag
right
because
you
might
as
well
just
write
types
so
I
mean
if
you
basically
expose
every
property
on
bases
somewhere
type,
and
then
everybody
just
outs
do
overtime
at
that
point.
What's
that,
what's
the
difference
to
actually
adding
the
properties
to
the
right
type
in
the
first
place,
one
of
the
property
back
would
be
that
it's
extensible
right,
which
means
that
there
should
be
independent
things
on
them
for
the
most.
B
I
G
You
want
to
install
the
users,
at
least
in
our
scenarios.
That's
the
model
right,
you!
You
want
to
get
a
feature
from
the
server
that
is
on
IX.
You
asked
for
the
is
feature
because
your
on
is,
and
a
feature
does
not
is
this
on
on
Castro,
because
it's
an
is
specific
behavior,
so
you're
asking
for
four
capabilities,
not
like
properties.
E
So
in
this
model,
anyone
who
introduces
I'm
trying
to
get
a
picture
so,
let's
say
I,
want
to
implement
my
foo
feature.
Yep
I
need
to
I
build
a
a
fool
connection,
factory,
a
fool
connection,
listener,
factory
and
I
foo
connection
properties
and
I
expose
off
of
the
I
foo
connection
properties.
Anything
relevant
to
my
type
is
that
correct.
It's.
G
So
that's
why
a
super
we're
in
South
middleware
run
after
after
establishment.
So
if
all
you
want
to
do
is
append
the
pita
to
to
a
connection,
you
only
have
to
implement
the
new
properties
and
decorate
the
current
connection.
I
came
in
add
your
feature
and
expose
the
other
ones
via
calling
through
to
your
thing,
you
wrapped,
so
that
to
expose
a
single
feature,
you
just
have
to
wrap
the
connection
and
have
a
feature.
E
G
G
I
E
A
The
this
it
just
gets
a
little
weird
with.
If
something
has
the
accelerator
for
socket,
which
I
think
the
point
Steve
was
making
that
they
put
an
accelerator
for
socket,
but
some
other
types
that
they're
based
on
also
has
a
concept
of
having
a
socket
because
they're
talking
to
different
end
points
and
now
you've
you've
lost
the
composability
because
you
you're
now
talking
about
you,
know
the
connection
to
Azure
storage
socket.
But
it's
built
on
top
of
a
thing.
G
South
Stream
was
a
mistake
and
it
should
have
been
in
the
first
place.
We
actually
have.
We
actually
have
features
exposed
all
the
properties
of
a
stealth
stream
like
itls
feature
right
and
that
actually
has
the
the
it
actually
has
the
properties
require
or
to
exploit
the
information.
And
it's
actually
exposed
by
by
the
quick
alert
in
ms
quick
by
the
adapter.
So
that
interface
actually
isn't
title
stream
at
all
and
it
should
and
that
object
should
not
have
been
in
there
in
the
first
place,
because
it's
basically
a
global
property
bag.
A
All
right
about
it
again,
if
we,
you
know,
make
it
the
class
is
set
of
interface.
It
seems
like
this
is
sort
of
what
we're
talking
about
as
just
the
built-in
way
of
doing
stuff
ignore
the
fact
that
it
doesn't
compile,
and
then
maybe
it
makes
sense,
because
at
least
now
all
of
these
types
are
limited
like
so
I.
Think
one
thing
I'd
like
to
see
is
what
all
the
proposed
properties
like
an
idea
of
what
the
proposed
properties
are
to
see.
B
A
A
Cuz
I
mean
if
we
had
something
like
you
know,
my
my
dummy
model
here
of
the
Tri
get
property
that
takes
a
T
being
the
only
public
model.
We
can
take
that
T
and
now
constrain
it
to
some
base
class
or
interface
and
say
this
is
now
the
very
clear
documented.
You
can
only
expose
things
that
are
intended
to
be
returned
through
this
property
set.
G
A
I
mean
again
looking
at
things
here
like
the
is
SL
connection
properties.
I
would
again
say
this
shouldn't
be
an
interface
because
half
of
the
things
on
here
didn't
exist
in
three
versions
ago,
meaning,
obviously
this
is
growing,
so
it
should
be
a
class.
So
you
can
get
the
most
up-to-date
version
and
not
need
to
introduce
new
types
for
is
SL
connection
properties
for
dotnet
six
and.
H
E
Of
part
of
it
also
I
have
to
ask
my
understanding,
there's
there's
a
whole
lot
of
interface,
dispatch
and
collection,
look
up
and
object
overhead
and
sup
here.
My
assumption
is
that
we
don't
we're
not
particularly
concerned
about
the
overhead
involved
in
this
level.
Yes,
that's
true,
because
if
it's
not
we're
in
trouble.
G
Yeah
we
do
so.
We
do
use
this
model
for
it
for
our
HTTP
context
there,
which
is
per
request-
and
we
did
a
bunch
of
stuff
to
like
super
optimize,
the
very
common
cases
to
avoid
interfaces
patch.
You
know
in
a
lot
of
the
common
cases,
so
we
do
care,
but
for
the
for
the
things
we
do
care
about,
we
we
spent
a
lot
of
time
optimizing.
Those
the
way
as
well.
I'm
gonna
show
you
what
we
did
to
me
that
yeah.
B
B
G
It
tries
to
basically
use
either
a
cache
version
of
the
feature
or,
if
it,
if
the
version
is
updated,
it'll
go
to
the
question
to
get
a
new
version
of
it,
so
think
of
it.
As
like
a
for
the
very
fast
news
cases,
we
don't
want
to
call
try
get.
We
want
to
get
the
feature
once
and
then
have
it
me
store
it
and
until
the
version
changes.