Re: [E] Re: TS API Review: New HTTP/2 stream id and priority getters

2020-09-02 Thread Alan Carroll
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

Re: [E] Re: TS API Review: New HTTP/2 stream id and priority getters

2020-09-01 Thread Masakazu Kitajo
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 wrote: > +1 I'm ok with the new

Re: [E] Re: TS API Review: New HTTP/2 stream id and priority getters

2020-09-01 Thread Sudheer Vinukonda
+1 On Tuesday, September 1, 2020, 03:49:43 PM PDT, Masaori Koshiba wrote: > tsapi TSReturnCode TSHttpTxnClientStreamIdGet(TSHttpTxn txnp, TSHttpStreamId *stream_id); > tsapi TSReturnCode TSHttpTxnClientStreamPriorityGet(TSHttpTxn txnp, TSHttpPriority *priority); +1 On Wed, Sep 2,

Re: [E] Re: TS API Review: New HTTP/2 stream id and priority getters

2020-09-01 Thread Masakazu Kitajo
+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

Re: [E] Re: TS API Review: New HTTP/2 stream id and priority getters

2020-09-01 Thread Masaori Koshiba
> 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 wrote: > I updated the protocol draft with this input

Re: [E] Re: TS API Review: New HTTP/2 stream id and priority getters

2020-09-01 Thread Brian Neradt
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

Re: [E] Re: TS API Review: New HTTP/2 stream id and priority getters

2020-09-01 Thread Brian Neradt
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 wrote: > Sorry for chiming in late - > > Note this is extremely similar to IP addresses and I recommend we

Re: [E] Re: TS API Review: New HTTP/2 stream id and priority getters

2020-09-01 Thread Alan Carroll
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).