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
+1 Tested on Fedora 31. Built and ran regression tests.
-Bryan
> On Feb 26, 2020, at 1:54 PM, Bryan Call wrote:
>
> I've prepared a release candidate (rc2) for 7.1.9. The release notes for
> 7.1.9 are available at:
>
>
> https://github.com/apache/trafficserver/pulls?utf8=✓&q=is%3Acl
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:
Hi all,
This is a proposal to add a new virtual method to the CPP API to get access
to TSRemapRequestInfo.
We're working on a plugin that changes the origin URL on demand, and the
CPP API is a little bit confusing around which URL you need to modify to
accomplish this, specially if you want to le
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:
> On Feb 26, 2020, at 2:54 PM, Bryan Call wrote:
>
> I've prepared a release candidate (rc2) for 7.1.9. The release notes for
> 7.1.9 are available at:
+1.
— Leif
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
10 matches
Mail list logo
