I just pushed a commit that implements option 2 above because I felt
that it was a more straightforward approach that can be easily
documented (and is). The alternate approach of `memcpy`ing a static
instance, while simple on the surface, seems a little too in the weeds
for an API caller that may n
r a size value, or
> both, so that backwards compatibility can be maintained.
>
> On Tue, Jul 27, 2021 at 3:59 PM Jeff Elsloo wrote:
>
> > Hi Alan,
> >
> > I modified the function I introduced to take an options struct as its
> > single argument to reduce the clu
Hi Alan,
I modified the function I introduced to take an options struct as its
single argument to reduce the clutter. I added the fields necessary to
support my work in PR #8088 and will update #8089 if the changes in
the former are accepted. I did not add a field for transparency as you
mentioned
Hi all,
I'd like to introduce a change to an existing API that leads to a new
function signature and add two new related convenience functions that
enable plugins. This change enables control of buffer sizes and
watermarks used with IOBuffers between the plugin and the core, which
is implemented t
May 6, 2021 at 11:42 AM Jeff Elsloo wrote:
>
> I just pushed a commit that incorporates this feedback and updated the
> dependent PR that enhances the xdebug plugin to reflect the change.
> The diff is as follows:
>
> – tsapi TSReturnCode TSHttpTxnCacheDiskPathGet(TSHttpTxn tx
API, the signature should be arranged to return a view. E.g.
>
> const char * TSHttpTxnCacheDiskPathGet(TSHttpTxn txn, int * length);
>
> This is modeled on API calls such as TSHttpHdrHostGet,
> TSHttpTxnPluginTagGet, and the family of TSUrlHostGet etc.
>
>
>
> On Tue, May 4
Hi all,
I'd like to propose the introduction of a new TS API,
TSHttpTxnCacheDiskPathGet. The function signature is as follows:
tsapi TSReturnCode TSHttpTxnCacheDiskPathGet(TSHttpTxn txnp, const char **path);
The intent of this API is to expose the underlying disk used to
service a request, regar
