I was planning on replacing the internals of TxnArg with the Extendible. I
haven't fully fleshed out the API. I had planned to keep the C API backward
compatible. But I really want to dive into a C++ API with type safety,
which was a major goal in the Extendible implementation.
On Fri, Mar 6, 2020
I am in favor of this because although the replace of In Name Only types
with void * makes a more risky API, it is (in my judgement) a relatively
minor risk especially since almost all of those types are in fact
Continuations and the internals can
check the dynamic_cast for success. I think it is m
> On Mar 4, 2020, at 12:18 PM, Walt Karas
> wrote:
>
> Instead of int argument indexes, how about argument IDs of type:
>
> typedef struct
> {
> TSUserArgType type;
> short idx;
> } TSUserArgIDType;
>
> This would allow for more run-time type checking.
Not sure I follow that… The type
Instead of int argument indexes, how about argument IDs of type:
typedef struct
{
TSUserArgType type;
short idx;
} TSUserArgIDType;
This would allow for more run-time type checking.
On Wed, Mar 4, 2020 at 12:40 PM Alan Carroll
wrote:
> I like thinner and more automatic APIs. This is less
I like thinner and more automatic APIs. This is less typing overall,
because the Get/Set functions don't require a type name in them. It also
makes it easier to add or remove object args. Also, in the longer term (ATS
10) we should move to Extendible anyway, which provides real type safety.
On Wed
> On Mar 4, 2020, at 11:17 AM, Walt Karas
> wrote:
>
> So why do you like this?
- Less code
- Fewer APIs
- Generalizes the concept
I don’t feel super strongly about the Get() / Set()’ers, I can definitely
retain the underlying core changes (which are good), and keep (and add more) of
the
So why do you like this?
- Breaks lots of existing code.
- Less typesafe.
- Makes use more verbose.
It's good how the API has avoided the use of void pointers. We should not
reverse that design goal.
On Wed, Mar 4, 2020 at 12:03 PM Leif Hedstrom wrote:
>
>
> > On Feb 27, 2020, at 10:13 AM, Le
> On Feb 27, 2020, at 10:13 AM, Leif Hedstrom wrote:
>
> Hi all,
>
> This is an idea from Bryan Call, which he suggested as a solution for
> reloadable plugins changes that are now in 9.0.x. I recently ran into a
> different use case (thanks Miles …), which could really benefit (performance
> On Feb 27, 2020, at 8:02 PM, Sudheer Vinukonda
> wrote:
>
> definitely very useful to share global data in a consistent (and supported)
> manner than having to rely on something undocumented (like we do for sharing
> global data between global and remap plugins) which as it’s proven now is
Yeah, I misunderstood the use case and the proposal. Synced up with Leif
offline and I understand it better now. The existing Txn API allows to share
data across states within a given transaction, while the new API is to share
data globally across transactions.
I’m still +1 on the new API, of c
I'm thinking perhaps we should instead pass a const pointer to:
typedef struct {
TSReturnCode (*globalArgIndexReserve)(const char * name, const char *
description, int * arg_idx);
TSReturnCode (*globalArgIndexNameLookup)(const char * name, int *
arg__idx, const char ** description);
TSRetur
Did you mean:
void TSGlobalArgSet(int arg_idx, void * arg)
void * TSGlobalArgGet(int arg_idx)
???
On Thu, Feb 27, 2020 at 11:13 AM Leif Hedstrom wrote:
> Hi all,
>
> This is an idea from Bryan Call, which he suggested as a solution for
> reloadable plugins changes that are now in 9.0.x. I re
Sudheer, can you create a branch in your trafficserver fork, that switches
an existing plugin from using TxnArg to GlobalArg? I don't see how that
would work typically. I believe the point is that you want a different
value for the same arg index for each transaction.
On Thu, Feb 27, 2020 at 11:
Yes, definitely +1 on the idea!
Curious though, why couldn't we just ditch the existing ConnArg / SsnArg /
TxnArg, in favor of the GlobalArgs or may be even just replace the existing
ArgTable with the vector?
-- Sudheer
On Thursday, February 27, 2020, 09:13:11 AM PST, Leif Hedstrom
wrote:
I understand your goal but I think this is the wrong approach. I think it
would work better to add names to the "config" in the TSConfigGet family of
functions. This also provides a nice "check out/in" mechanism for
synchronization,
On Thu, Feb 27, 2020 at 11:13 AM Leif Hedstrom wrote:
> Hi all,
Hi all,
This is an idea from Bryan Call, which he suggested as a solution for
reloadable plugins changes that are now in 9.0.x. I recently ran into a
different use case (thanks Miles …), which could really benefit (performance
wise) with such APIs. I *could* use the TxnArg APIs instead, but the
16 matches
Mail list logo
