I totally agree with less API is better.
> tsapi TSReturnCode TSHttpTxnClientStreamIdGet(TSHttpTxn txnp,
uint64_t *stream_id);
Stripping "Http2" looks reasonable. We can use this API for protocols that
have stream id.
> tsapi TSReturnCode TSHttpTxnClientPriorityGet(TSHttpTxn txnp,
uint64_t *stre
> On Sep 1, 2020, at 01:20, Masaori Koshiba wrote:
>
> I totally agree with less API is better.
>
>> tsapi TSReturnCode TSHttpTxnClientStreamIdGet(TSHttpTxn txnp,
> uint64_t *stream_id);
>
> Stripping "Http2" looks reasonable. We can use this API for protocols that
> have stream id.
>
>> t
+1 to use opaque structures and use protocol "type" as the "key".
I'd slightly prefer the caller pass in the protocol type rather than letting TS
automatically determine that (primary reason for that being let the user have
"control" on what they want to retrieve).
For e.g
tsapi TSReturnCode
>> (primary reason for that being let the user have "control" on what they
>>want to retrieve).
And of course, the API shall return TS_ERROR, if the passed in protocol "type"
is not correct for the given TXN.
On Tuesday, September 1, 2020, 08:45:21 AM PDT, Sudheer Vinukonda
wrote:
Thank you Sudheer, this is helpful.
Considering Masaori's input, it sounds like it would be wise to amend
TSHttpTxnClientPriorityGet to just take a single, generic priority opaque
structure:
tsapi TSReturnCode TSHttpTxnClientStreamIdGet(TSHttpTxn txnp,
TSHttpProtocolType type, void *stream_id);
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).
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 us
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 tx
> 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 (noti
+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
+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, 202
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 fu
12 matches
Mail list logo
