You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Alan Carroll <so...@verizonmedia.com.INVALID> on 2020/09/01 21:11:07 UTC
Re: [E] Re: TS API Review: New HTTP/2 stream id and priority getters
Sorry for chiming in late -
Note this is extremely similar to IP addresses and I recommend we use the
same solution. That is, there is a class HttpPriority which has just a
type/style/family value and possibly a length. This is an abstract class
like sockaddr (which no one actually instantiates). The family indicates
the concrete type, which is something like Http2Priority or Http3Priority,
etc., just like sockaddr_in and sockaddr_in6. When you call the priority
getter, it returns a HttpPriority* which is a pointer to a concrete
instance, the type of which is determined by the family. Again, just like
getting an IP address from a socket.
Re: [E] Re: TS API Review: New HTTP/2 stream id and priority
getters
Posted by Sudheer Vinukonda <su...@yahoo.com.INVALID>.
+1
On Tuesday, September 1, 2020, 03:49:43 PM PDT, Masaori Koshiba <ma...@apache.org> wrote:
> tsapi TSReturnCode TSHttpTxnClientStreamIdGet(TSHttpTxn txnp,
TSHttpStreamId *stream_id);
> tsapi TSReturnCode TSHttpTxnClientStreamPriorityGet(TSHttpTxn txnp,
TSHttpPriority *priority);
+1
On Wed, Sep 2, 2020 at 7:35 AM Brian Neradt <br...@gmail.com> wrote:
> I updated the protocol draft with this input (notice I kept the updated API
> implementation as the second commit in the PR for the sake of comparison):
> https://github.com/apache/trafficserver/pull/7149
>
> The API now looks like the following:
>
> tsapi TSReturnCode TSHttpTxnClientStreamIdGet(TSHttpTxn txnp,
> TSHttpStreamId *stream_id);
> tsapi TSReturnCode TSHttpTxnClientStreamPriorityGet(TSHttpTxn txnp,
> TSHttpPriority *priority);
>
> TSHttpStreamId and TSHttpPriority are now abstract structures that can
> reference TSHttp2StreamId and TSHttp2Priority objects. In the future we can
> expand this to include version 3 values of these. Notice that the above are
> generic to the specific HTTP protocol type used by the transaction.
>
> I'll hold off on updating the docs in the PR until I get confirmation that
> this looks OK to the community.
>
> Thanks,
> Brian
>
> On Tue, Sep 1, 2020 at 4:20 PM Brian Neradt <br...@gmail.com>
> wrote:
>
> > This sounds good to me. This essentially puts the type parameter in the
> > structure itself rather than as a separate parameter to the functions.
> >
> > On Tue, Sep 1, 2020 at 4:11 PM Alan Carroll
> > <so...@verizonmedia.com.invalid> wrote:
> >
> >> Sorry for chiming in late -
> >>
> >> Note this is extremely similar to IP addresses and I recommend we use
> the
> >> same solution. That is, there is a class HttpPriority which has just a
> >> type/style/family value and possibly a length. This is an abstract class
> >> like sockaddr (which no one actually instantiates). The family indicates
> >> the concrete type, which is something like Http2Priority or
> Http3Priority,
> >> etc., just like sockaddr_in and sockaddr_in6. When you call the priority
> >> getter, it returns a HttpPriority* which is a pointer to a concrete
> >> instance, the type of which is determined by the family. Again, just
> like
> >> getting an IP address from a socket.
> >>
> >
> >
> > --
> > "Come to Me, all who are weary and heavy-laden, and I will
> > give you rest. Take My yoke upon you and learn from Me, for
> > I am gentle and humble in heart, and you will find rest for
> > your souls. For My yoke is easy and My burden is light."
> >
> > ~ Matthew 11:28-30
> >
>
>
> --
> "Come to Me, all who are weary and heavy-laden, and I will
> give you rest. Take My yoke upon you and learn from Me, for
> I am gentle and humble in heart, and you will find rest for
> your souls. For My yoke is easy and My burden is light."
>
> ~ Matthew 11:28-30
>
Re: [E] Re: TS API Review: New HTTP/2 stream id and priority getters
Posted by Masaori Koshiba <ma...@apache.org>.
> tsapi TSReturnCode TSHttpTxnClientStreamIdGet(TSHttpTxn txnp,
TSHttpStreamId *stream_id);
> tsapi TSReturnCode TSHttpTxnClientStreamPriorityGet(TSHttpTxn txnp,
TSHttpPriority *priority);
+1
On Wed, Sep 2, 2020 at 7:35 AM Brian Neradt <br...@gmail.com> wrote:
> I updated the protocol draft with this input (notice I kept the updated API
> implementation as the second commit in the PR for the sake of comparison):
> https://github.com/apache/trafficserver/pull/7149
>
> The API now looks like the following:
>
> tsapi TSReturnCode TSHttpTxnClientStreamIdGet(TSHttpTxn txnp,
> TSHttpStreamId *stream_id);
> tsapi TSReturnCode TSHttpTxnClientStreamPriorityGet(TSHttpTxn txnp,
> TSHttpPriority *priority);
>
> TSHttpStreamId and TSHttpPriority are now abstract structures that can
> reference TSHttp2StreamId and TSHttp2Priority objects. In the future we can
> expand this to include version 3 values of these. Notice that the above are
> generic to the specific HTTP protocol type used by the transaction.
>
> I'll hold off on updating the docs in the PR until I get confirmation that
> this looks OK to the community.
>
> Thanks,
> Brian
>
> On Tue, Sep 1, 2020 at 4:20 PM Brian Neradt <br...@gmail.com>
> wrote:
>
> > This sounds good to me. This essentially puts the type parameter in the
> > structure itself rather than as a separate parameter to the functions.
> >
> > On Tue, Sep 1, 2020 at 4:11 PM Alan Carroll
> > <so...@verizonmedia.com.invalid> wrote:
> >
> >> Sorry for chiming in late -
> >>
> >> Note this is extremely similar to IP addresses and I recommend we use
> the
> >> same solution. That is, there is a class HttpPriority which has just a
> >> type/style/family value and possibly a length. This is an abstract class
> >> like sockaddr (which no one actually instantiates). The family indicates
> >> the concrete type, which is something like Http2Priority or
> Http3Priority,
> >> etc., just like sockaddr_in and sockaddr_in6. When you call the priority
> >> getter, it returns a HttpPriority* which is a pointer to a concrete
> >> instance, the type of which is determined by the family. Again, just
> like
> >> getting an IP address from a socket.
> >>
> >
> >
> > --
> > "Come to Me, all who are weary and heavy-laden, and I will
> > give you rest. Take My yoke upon you and learn from Me, for
> > I am gentle and humble in heart, and you will find rest for
> > your souls. For My yoke is easy and My burden is light."
> >
> > ~ Matthew 11:28-30
> >
>
>
> --
> "Come to Me, all who are weary and heavy-laden, and I will
> give you rest. Take My yoke upon you and learn from Me, for
> I am gentle and humble in heart, and you will find rest for
> your souls. For My yoke is easy and My burden is light."
>
> ~ Matthew 11:28-30
>
Re: [E] Re: TS API Review: New HTTP/2 stream id and priority getters
Posted by Alan Carroll <so...@verizonmedia.com.INVALID>.
Some notes:
maskit - we can just add another enum value. You're right that it should
probably not be "ProtocolType" because it may be unrelated. "PriorityType"
would probably be better as a name.
There shouldn't be a "0_9" - I thought we had agreed to not support that at
all anymore.
There should be an INVALID of some sort, equivalent to AF_UNSPEC.
I agree with maskit that the indirection isn't worth it for the ID.
On Tue, Sep 1, 2020 at 8:08 PM Masakazu Kitajo <ma...@apache.org> wrote:
> Actually, I don't understand TSHttpProtocolType. Shouldn't it be
> StructureType? Let's say we support a new priority scheme that is available
> on both H2 and H3. What would be the TSHttpProtocolType for it?
>
> Masakazu
>
> On Wed, Sep 2, 2020 at 9:37 AM Masakazu Kitajo <ma...@apache.org> wrote:
>
> > +1 I'm ok with the new function signatures that use abstract structures.
> >
> > However, I'm not sure if we really need that flexibility for Stream ID, I
> > can't say 64-bit is big enough, but I think extensibility is not
> > everything. Usability matters. Should we prepare for 128-bit stream ids
> > now? Would we take the same approach for TSUrlPortGet to prepare for
> 32-bit
> > port numbers?
> >
> > Masakazu
> >
> > On Wed, Sep 2, 2020 at 7:35 AM Brian Neradt <br...@gmail.com>
> > wrote:
> >
> >> I updated the protocol draft with this input (notice I kept the updated
> >> API
> >> implementation as the second commit in the PR for the sake of
> comparison):
> >>
> https://urldefense.com/v3/__https://github.com/apache/trafficserver/pull/7149__;!!Op6eflyXZCqGR5I!R1jXXdxiTw57gMmYf4tr78KcBgZfbbrmlMwrL-m5hwDyQg7Ue6tcXgslvNZ9bxq2Wr5rdqwl9w$
> >>
> >> The API now looks like the following:
> >>
> >> tsapi TSReturnCode TSHttpTxnClientStreamIdGet(TSHttpTxn txnp,
> >> TSHttpStreamId *stream_id);
> >> tsapi TSReturnCode TSHttpTxnClientStreamPriorityGet(TSHttpTxn txnp,
> >> TSHttpPriority *priority);
> >>
> >> TSHttpStreamId and TSHttpPriority are now abstract structures that can
> >> reference TSHttp2StreamId and TSHttp2Priority objects. In the future we
> >> can
> >> expand this to include version 3 values of these. Notice that the above
> >> are
> >> generic to the specific HTTP protocol type used by the transaction.
> >>
> >> I'll hold off on updating the docs in the PR until I get confirmation
> that
> >> this looks OK to the community.
> >>
> >> Thanks,
> >> Brian
> >>
> >> On Tue, Sep 1, 2020 at 4:20 PM Brian Neradt <br...@gmail.com>
> >> wrote:
> >>
> >> > This sounds good to me. This essentially puts the type parameter in
> the
> >> > structure itself rather than as a separate parameter to the functions.
> >> >
> >> > On Tue, Sep 1, 2020 at 4:11 PM Alan Carroll
> >> > <so...@verizonmedia.com.invalid> wrote:
> >> >
> >> >> Sorry for chiming in late -
> >> >>
> >> >> Note this is extremely similar to IP addresses and I recommend we use
> >> the
> >> >> same solution. That is, there is a class HttpPriority which has just
> a
> >> >> type/style/family value and possibly a length. This is an abstract
> >> class
> >> >> like sockaddr (which no one actually instantiates). The family
> >> indicates
> >> >> the concrete type, which is something like Http2Priority or
> >> Http3Priority,
> >> >> etc., just like sockaddr_in and sockaddr_in6. When you call the
> >> priority
> >> >> getter, it returns a HttpPriority* which is a pointer to a concrete
> >> >> instance, the type of which is determined by the family. Again, just
> >> like
> >> >> getting an IP address from a socket.
> >> >>
> >> >
> >> >
> >> > --
> >> > "Come to Me, all who are weary and heavy-laden, and I will
> >> > give you rest. Take My yoke upon you and learn from Me, for
> >> > I am gentle and humble in heart, and you will find rest for
> >> > your souls. For My yoke is easy and My burden is light."
> >> >
> >> > ~ Matthew 11:28-30
> >> >
> >>
> >>
> >> --
> >> "Come to Me, all who are weary and heavy-laden, and I will
> >> give you rest. Take My yoke upon you and learn from Me, for
> >> I am gentle and humble in heart, and you will find rest for
> >> your souls. For My yoke is easy and My burden is light."
> >>
> >> ~ Matthew 11:28-30
> >>
> >
>
Re: [E] Re: TS API Review: New HTTP/2 stream id and priority getters
Posted by Masakazu Kitajo <ma...@apache.org>.
Actually, I don't understand TSHttpProtocolType. Shouldn't it be
StructureType? Let's say we support a new priority scheme that is available
on both H2 and H3. What would be the TSHttpProtocolType for it?
Masakazu
On Wed, Sep 2, 2020 at 9:37 AM Masakazu Kitajo <ma...@apache.org> wrote:
> +1 I'm ok with the new function signatures that use abstract structures.
>
> However, I'm not sure if we really need that flexibility for Stream ID, I
> can't say 64-bit is big enough, but I think extensibility is not
> everything. Usability matters. Should we prepare for 128-bit stream ids
> now? Would we take the same approach for TSUrlPortGet to prepare for 32-bit
> port numbers?
>
> Masakazu
>
> On Wed, Sep 2, 2020 at 7:35 AM Brian Neradt <br...@gmail.com>
> wrote:
>
>> I updated the protocol draft with this input (notice I kept the updated
>> API
>> implementation as the second commit in the PR for the sake of comparison):
>> https://github.com/apache/trafficserver/pull/7149
>>
>> The API now looks like the following:
>>
>> tsapi TSReturnCode TSHttpTxnClientStreamIdGet(TSHttpTxn txnp,
>> TSHttpStreamId *stream_id);
>> tsapi TSReturnCode TSHttpTxnClientStreamPriorityGet(TSHttpTxn txnp,
>> TSHttpPriority *priority);
>>
>> TSHttpStreamId and TSHttpPriority are now abstract structures that can
>> reference TSHttp2StreamId and TSHttp2Priority objects. In the future we
>> can
>> expand this to include version 3 values of these. Notice that the above
>> are
>> generic to the specific HTTP protocol type used by the transaction.
>>
>> I'll hold off on updating the docs in the PR until I get confirmation that
>> this looks OK to the community.
>>
>> Thanks,
>> Brian
>>
>> On Tue, Sep 1, 2020 at 4:20 PM Brian Neradt <br...@gmail.com>
>> wrote:
>>
>> > This sounds good to me. This essentially puts the type parameter in the
>> > structure itself rather than as a separate parameter to the functions.
>> >
>> > On Tue, Sep 1, 2020 at 4:11 PM Alan Carroll
>> > <so...@verizonmedia.com.invalid> wrote:
>> >
>> >> Sorry for chiming in late -
>> >>
>> >> Note this is extremely similar to IP addresses and I recommend we use
>> the
>> >> same solution. That is, there is a class HttpPriority which has just a
>> >> type/style/family value and possibly a length. This is an abstract
>> class
>> >> like sockaddr (which no one actually instantiates). The family
>> indicates
>> >> the concrete type, which is something like Http2Priority or
>> Http3Priority,
>> >> etc., just like sockaddr_in and sockaddr_in6. When you call the
>> priority
>> >> getter, it returns a HttpPriority* which is a pointer to a concrete
>> >> instance, the type of which is determined by the family. Again, just
>> like
>> >> getting an IP address from a socket.
>> >>
>> >
>> >
>> > --
>> > "Come to Me, all who are weary and heavy-laden, and I will
>> > give you rest. Take My yoke upon you and learn from Me, for
>> > I am gentle and humble in heart, and you will find rest for
>> > your souls. For My yoke is easy and My burden is light."
>> >
>> > ~ Matthew 11:28-30
>> >
>>
>>
>> --
>> "Come to Me, all who are weary and heavy-laden, and I will
>> give you rest. Take My yoke upon you and learn from Me, for
>> I am gentle and humble in heart, and you will find rest for
>> your souls. For My yoke is easy and My burden is light."
>>
>> ~ Matthew 11:28-30
>>
>
Re: [E] Re: TS API Review: New HTTP/2 stream id and priority getters
Posted by Masakazu Kitajo <ma...@apache.org>.
+1 I'm ok with the new function signatures that use abstract structures.
However, I'm not sure if we really need that flexibility for Stream ID, I
can't say 64-bit is big enough, but I think extensibility is not
everything. Usability matters. Should we prepare for 128-bit stream ids
now? Would we take the same approach for TSUrlPortGet to prepare for 32-bit
port numbers?
Masakazu
On Wed, Sep 2, 2020 at 7:35 AM Brian Neradt <br...@gmail.com> wrote:
> I updated the protocol draft with this input (notice I kept the updated API
> implementation as the second commit in the PR for the sake of comparison):
> https://github.com/apache/trafficserver/pull/7149
>
> The API now looks like the following:
>
> tsapi TSReturnCode TSHttpTxnClientStreamIdGet(TSHttpTxn txnp,
> TSHttpStreamId *stream_id);
> tsapi TSReturnCode TSHttpTxnClientStreamPriorityGet(TSHttpTxn txnp,
> TSHttpPriority *priority);
>
> TSHttpStreamId and TSHttpPriority are now abstract structures that can
> reference TSHttp2StreamId and TSHttp2Priority objects. In the future we can
> expand this to include version 3 values of these. Notice that the above are
> generic to the specific HTTP protocol type used by the transaction.
>
> I'll hold off on updating the docs in the PR until I get confirmation that
> this looks OK to the community.
>
> Thanks,
> Brian
>
> On Tue, Sep 1, 2020 at 4:20 PM Brian Neradt <br...@gmail.com>
> wrote:
>
> > This sounds good to me. This essentially puts the type parameter in the
> > structure itself rather than as a separate parameter to the functions.
> >
> > On Tue, Sep 1, 2020 at 4:11 PM Alan Carroll
> > <so...@verizonmedia.com.invalid> wrote:
> >
> >> Sorry for chiming in late -
> >>
> >> Note this is extremely similar to IP addresses and I recommend we use
> the
> >> same solution. That is, there is a class HttpPriority which has just a
> >> type/style/family value and possibly a length. This is an abstract class
> >> like sockaddr (which no one actually instantiates). The family indicates
> >> the concrete type, which is something like Http2Priority or
> Http3Priority,
> >> etc., just like sockaddr_in and sockaddr_in6. When you call the priority
> >> getter, it returns a HttpPriority* which is a pointer to a concrete
> >> instance, the type of which is determined by the family. Again, just
> like
> >> getting an IP address from a socket.
> >>
> >
> >
> > --
> > "Come to Me, all who are weary and heavy-laden, and I will
> > give you rest. Take My yoke upon you and learn from Me, for
> > I am gentle and humble in heart, and you will find rest for
> > your souls. For My yoke is easy and My burden is light."
> >
> > ~ Matthew 11:28-30
> >
>
>
> --
> "Come to Me, all who are weary and heavy-laden, and I will
> give you rest. Take My yoke upon you and learn from Me, for
> I am gentle and humble in heart, and you will find rest for
> your souls. For My yoke is easy and My burden is light."
>
> ~ Matthew 11:28-30
>
Re: [E] Re: TS API Review: New HTTP/2 stream id and priority getters
Posted by Brian Neradt <br...@gmail.com>.
I updated the protocol draft with this input (notice I kept the updated API
implementation as the second commit in the PR for the sake of comparison):
https://github.com/apache/trafficserver/pull/7149
The API now looks like the following:
tsapi TSReturnCode TSHttpTxnClientStreamIdGet(TSHttpTxn txnp,
TSHttpStreamId *stream_id);
tsapi TSReturnCode TSHttpTxnClientStreamPriorityGet(TSHttpTxn txnp,
TSHttpPriority *priority);
TSHttpStreamId and TSHttpPriority are now abstract structures that can
reference TSHttp2StreamId and TSHttp2Priority objects. In the future we can
expand this to include version 3 values of these. Notice that the above are
generic to the specific HTTP protocol type used by the transaction.
I'll hold off on updating the docs in the PR until I get confirmation that
this looks OK to the community.
Thanks,
Brian
On Tue, Sep 1, 2020 at 4:20 PM Brian Neradt <br...@gmail.com> wrote:
> This sounds good to me. This essentially puts the type parameter in the
> structure itself rather than as a separate parameter to the functions.
>
> On Tue, Sep 1, 2020 at 4:11 PM Alan Carroll
> <so...@verizonmedia.com.invalid> wrote:
>
>> Sorry for chiming in late -
>>
>> Note this is extremely similar to IP addresses and I recommend we use the
>> same solution. That is, there is a class HttpPriority which has just a
>> type/style/family value and possibly a length. This is an abstract class
>> like sockaddr (which no one actually instantiates). The family indicates
>> the concrete type, which is something like Http2Priority or Http3Priority,
>> etc., just like sockaddr_in and sockaddr_in6. When you call the priority
>> getter, it returns a HttpPriority* which is a pointer to a concrete
>> instance, the type of which is determined by the family. Again, just like
>> getting an IP address from a socket.
>>
>
>
> --
> "Come to Me, all who are weary and heavy-laden, and I will
> give you rest. Take My yoke upon you and learn from Me, for
> I am gentle and humble in heart, and you will find rest for
> your souls. For My yoke is easy and My burden is light."
>
> ~ Matthew 11:28-30
>
--
"Come to Me, all who are weary and heavy-laden, and I will
give you rest. Take My yoke upon you and learn from Me, for
I am gentle and humble in heart, and you will find rest for
your souls. For My yoke is easy and My burden is light."
~ Matthew 11:28-30
Re: [E] Re: TS API Review: New HTTP/2 stream id and priority getters
Posted by Brian Neradt <br...@gmail.com>.
This sounds good to me. This essentially puts the type parameter in the
structure itself rather than as a separate parameter to the functions.
On Tue, Sep 1, 2020 at 4:11 PM Alan Carroll
<so...@verizonmedia.com.invalid> wrote:
> Sorry for chiming in late -
>
> Note this is extremely similar to IP addresses and I recommend we use the
> same solution. That is, there is a class HttpPriority which has just a
> type/style/family value and possibly a length. This is an abstract class
> like sockaddr (which no one actually instantiates). The family indicates
> the concrete type, which is something like Http2Priority or Http3Priority,
> etc., just like sockaddr_in and sockaddr_in6. When you call the priority
> getter, it returns a HttpPriority* which is a pointer to a concrete
> instance, the type of which is determined by the family. Again, just like
> getting an IP address from a socket.
>
--
"Come to Me, all who are weary and heavy-laden, and I will
give you rest. Take My yoke upon you and learn from Me, for
I am gentle and humble in heart, and you will find rest for
your souls. For My yoke is easy and My burden is light."
~ Matthew 11:28-30
Re: [E] TS API Review: New HTTP/2 stream id and priority getters
Posted by Brian Neradt <br...@gmail.com>.
Considering this input:
- I changed the TSHttpTxnClientStreamIdGet to return a uint64_t.
- I removed 0_9 from the protocol type list and added
HTTP_PROTOCOL_TYPE_HTTP_UNSPECIFIED.
- I renamed TSHttpProtocolType to TSHttpPriorityType.
The API functions now look like:
tsapi TSReturnCode TSHttpTxnClientStreamIdGet(TSHttpTxn txnp, uint64_t
*stream_id);
tsapi TSReturnCode TSHttpTxnClientStreamPriorityGet(TSHttpTxn txnp,
TSHttpPriority *priority);
The draft PR is updated with these changes:
https://github.com/apache/trafficserver/pull/7149
Thanks,
On Wed, Sep 2, 2020 at 12:37 PM Brian Neradt <br...@gmail.com> wrote:
> Correct, a regular C struct.
>
> On Wed, Sep 2, 2020 at 11:28 AM Leif Hedstrom <zw...@apache.org> wrote:
>
>>
>>
>> > On Sep 1, 2020, at 3:11 PM, Alan Carroll
>> <so...@verizonmedia.com.INVALID> wrote:
>> >
>> > Sorry for chiming in late -
>> >
>> > Note this is extremely similar to IP addresses and I recommend we use
>> the
>> > same solution. That is, there is a class HttpPriority which has just a
>> > type/style/family value and possibly a length. This is an abstract class
>> > like sockaddr (which no one actually instantiates). The family indicates
>> > the concrete type, which is something like Http2Priority or
>> Http3Priority,
>> > etc., just like sockaddr_in and sockaddr_in6. When you call the priority
>> > getter, it returns a HttpPriority* which is a pointer to a concrete
>> > instance, the type of which is determined by the family. Again, just
>> like
>> > getting an IP address from a socket.
>>
>>
>> I assume with class here, you mean a regular C struct ?
>>
>> — Leif
>>
>>
>>
>
> --
> "Come to Me, all who are weary and heavy-laden, and I will
> give you rest. Take My yoke upon you and learn from Me, for
> I am gentle and humble in heart, and you will find rest for
> your souls. For My yoke is easy and My burden is light."
>
> ~ Matthew 11:28-30
>
--
"Come to Me, all who are weary and heavy-laden, and I will
give you rest. Take My yoke upon you and learn from Me, for
I am gentle and humble in heart, and you will find rest for
your souls. For My yoke is easy and My burden is light."
~ Matthew 11:28-30
Re: [E] TS API Review: New HTTP/2 stream id and priority getters
Posted by Brian Neradt <br...@gmail.com>.
Correct, a regular C struct.
On Wed, Sep 2, 2020 at 11:28 AM Leif Hedstrom <zw...@apache.org> wrote:
>
>
> > On Sep 1, 2020, at 3:11 PM, Alan Carroll
> <so...@verizonmedia.com.INVALID> wrote:
> >
> > Sorry for chiming in late -
> >
> > Note this is extremely similar to IP addresses and I recommend we use the
> > same solution. That is, there is a class HttpPriority which has just a
> > type/style/family value and possibly a length. This is an abstract class
> > like sockaddr (which no one actually instantiates). The family indicates
> > the concrete type, which is something like Http2Priority or
> Http3Priority,
> > etc., just like sockaddr_in and sockaddr_in6. When you call the priority
> > getter, it returns a HttpPriority* which is a pointer to a concrete
> > instance, the type of which is determined by the family. Again, just like
> > getting an IP address from a socket.
>
>
> I assume with class here, you mean a regular C struct ?
>
> — Leif
>
>
>
--
"Come to Me, all who are weary and heavy-laden, and I will
give you rest. Take My yoke upon you and learn from Me, for
I am gentle and humble in heart, and you will find rest for
your souls. For My yoke is easy and My burden is light."
~ Matthew 11:28-30
Re: [E] TS API Review: New HTTP/2 stream id and priority getters
Posted by Leif Hedstrom <zw...@apache.org>.
> On Sep 1, 2020, at 3:11 PM, Alan Carroll <so...@verizonmedia.com.INVALID> wrote:
>
> Sorry for chiming in late -
>
> Note this is extremely similar to IP addresses and I recommend we use the
> same solution. That is, there is a class HttpPriority which has just a
> type/style/family value and possibly a length. This is an abstract class
> like sockaddr (which no one actually instantiates). The family indicates
> the concrete type, which is something like Http2Priority or Http3Priority,
> etc., just like sockaddr_in and sockaddr_in6. When you call the priority
> getter, it returns a HttpPriority* which is a pointer to a concrete
> instance, the type of which is determined by the family. Again, just like
> getting an IP address from a socket.
I assume with class here, you mean a regular C struct ?
— Leif