Proposal: move ts_util.h/.cc into TS API (in ts namespace)

[Walt Karas <wk...@yahooinc.com.INVALID>]

That is move plugins/experimental/txn_box/plugin/include/txn_box/ts_util.h
to include/ts, and plugins/experimental/txn_box/plugin/src/ts_util.cc to
src/api .

May involve some picking and choosing.  ts_util.h includes common.h.  I
don't think we want to bring all of common.h into the TS API.

Re: [E] Proposal: move ts_util.h/.cc into TS API (in ts namespace)

[Walt Karas <wk...@yahooinc.com.INVALID>]

Hmm ts_util is a utility currently only used by txn_box.  It uses libswoc,
as do other parts of our code.

We have already decided to bring ts_util into our repo.  We already have to
maintain it.  It's a question of whether we want to get more use out of
it.  If we don't think it's of significant value to use C++ rather than C,
maybe we should just all switch to nginx?

On Thu, Apr 18, 2024 at 1:30 PM Leif Hedstrom <zw...@apache.org> wrote:

>
>
> > On Apr 18, 2024, at 11:20 AM, Masakazu Kitajo <ma...@apache.org> wrote:
> >
> > Like I said above, I think we should keep TS API minimal, because we
> cannot
> > change TS API casually. Once we add something, it's difficult to change
> or
> > remove it. I don't want to have much code with such constraints just for
> > convenience. That is why I've been very cautious about this (and any API
> > additions) and I call using libswoc stuff a huge commitment.
>
>
>
> I think the best argument I’ve heard against this is to not have public
> APIs that exposes libswoc APIs. Since we (hopefully) will move away from
> much of libswoc internally over time (e.g. std::fmt), exposing such
> dependencies in public API would make that transition difficult.
>
> Can we make these additions such that any libswoc dependency is hidden
> from the public API? Is that maybe part of the cleanup we’d do before this
> move ?
>
> — Leif
>
>

Re: [E] Proposal: move ts_util.h/.cc into TS API (in ts namespace)

[Leif Hedstrom <zw...@apache.org>]

> On Apr 18, 2024, at 11:20 AM, Masakazu Kitajo <ma...@apache.org> wrote:
> 
> Like I said above, I think we should keep TS API minimal, because we cannot
> change TS API casually. Once we add something, it's difficult to change or
> remove it. I don't want to have much code with such constraints just for
> convenience. That is why I've been very cautious about this (and any API
> additions) and I call using libswoc stuff a huge commitment.



I think the best argument I’ve heard against this is to not have public APIs that exposes libswoc APIs. Since we (hopefully) will move away from much of libswoc internally over time (e.g. std::fmt), exposing such dependencies in public API would make that transition difficult.

Can we make these additions such that any libswoc dependency is hidden from the public API? Is that maybe part of the cleanup we’d do before this move ?

— Leif

Re: [E] Re: Proposal: move ts_util.h/.cc into TS API (in ts namespace)

[Masakazu Kitajo <ma...@apache.org>]

Like I said above, I think we should keep TS API minimal, because we cannot
change TS API casually. Once we add something, it's difficult to change or
remove it. I don't want to have much code with such constraints just for
convenience. That is why I've been very cautious about this (and any API
additions) and I call using libswoc stuff a huge commitment.

Convenience wise, making it an independent library would be more desirable.
You could get new convenient features without upgrading ATS. You could make
incompatible changes independently from ATS versions. What would we lose if
we didn't have the wrapper as TS API?

Re: [E] Re: Proposal: move ts_util.h/.cc into TS API (in ts namespace)

[Walt Karas <wk...@yahooinc.com.INVALID>]

Although txn_box is experimental in open source, it has been used in prod
by Yahoo for some time, without causing performance issues.

I guess I'm not sure why you see this as a question of "necessity"?  You
could say a bicycle is not a necessity because you could walk.  The
question is, is it an improvement?  A true C++ API will be less verbose and
error-prone than a C-style API.  I am not saying we should deprecate the
C-style API, except possible in the very long term.

On Thu, Apr 18, 2024 at 11:37 AM Masakazu Kitajo <ma...@apache.org> wrote:

> And the new one isn't? Any evidence?
>
> I really don't understand the necessity of having the new wrapper as part
> of TS API at this time. If you (or others) are not going to answer my
> questions and try to convince me, I'd have to throw -1. My suggestion would
> be to gain reputation while incubating the wrapper as an independent
> library.
>
> On Wed, Apr 17, 2024 at 7:15 PM Walt Karas <wk...@yahooinc.com.invalid>
> wrote:
>
> > The atscppapi was deprecated because it was buggy and had bad
> performance.
> >
> > On Wed, Apr 17, 2024 at 4:36 PM Masakazu Kitajo <m4...@gmail.com>
> wrote:
> >
> > > I'm not saying any C++ wrapper should not be made. I just don't think
> it
> > > should be TS API.
> > >
> > > I don't get why we can say the wrapper in a new experimental plugin is
> > good
> > > at this time. We don't have good C++ representation of request,
> response,
> > > header field, etc. even internally in tscore. And if we had, we could
> > > export them in a more straightforward way.
> > >
> > > What were the problems of atscppapi? How are those solved by the new
> > > wrapper? Why can we say the new wrapper is already in a good shape? Why
> > do
> > > we want to introduce a wrapper of the existing C API instead of
> replacing
> > > them with new API which would be naturally more C++ friendly even
> > without a
> > > wrapper?
> > >
> > > I have too many questions to throw +1 for this. Since the wrapper is
> > just a
> > > wrapper, we can see if it's good without having it as TS API. Do we
> have
> > a
> > > reason to skip doing that?
> > >
> > > On Wed, Apr 17, 2024 at 1:06 PM Walt Karas <wkaras@yahooinc.com.invalid
> >
> > > wrote:
> > >
> > > > The atscppapi had problems, but I don't agree that shows any C++
> > wrapper
> > > is
> > > > bad.  If we say we should not have an alternative C++ API, as well as
> > a C
> > > > API, that would imply we should not have a Lua API.
> > > >
> > > > On Wed, Apr 17, 2024 at 2:34 PM Masakazu Kitajo <ma...@apache.org>
> > > wrote:
> > > >
> > > > > We had a wrapper (the old TS CPP API), and we removed it. Why do we
> > > want
> > > > to
> > > > > have yet another wrapper now? What's the difference?
> > > > >
> > > > > Also, I don't like to have libswoc stuff in the API. Using it
> > > internally
> > > > is
> > > > > ok because we can replace it anytime but having it as part of API
> is
> > a
> > > > huge
> > > > > commitment.
> > > > >
> > > > > A wrapper could be provided separately as an independent library.
> > Then
> > > > you
> > > > > can make any changes anytime without waiting for ATS releases. If
> > it's
> > > > > convenient, plugin developers will use it, and they won't if they
> > don't
> > > > > like it for some reasons (instability, use of libswoc, etc.). One
> > might
> > > > > make a better wrapper. I don't see a reason to have such things as
> TS
> > > API
> > > > > and maintain it by ourselves. IMO, TS API should provide minimal
> > things
> > > > > which can be only done by API.
> > > > >
> > > > >
> > > > > On Wed, Apr 10, 2024 at 2:50 PM Walt Karas
> > <wkaras@yahooinc.com.invalid
> > > >
> > > > > wrote:
> > > > >
> > > > > > Yes, it's wrapper, that utilizes C++ features.  It's easier to
> use
> > > > (Imore
> > > > > > concise).  Easy to understand.  Can be intermixed with the base
> > API.
> > > > > >
> > > > > > On Wed, Apr 10, 2024 at 12:49 PM Leif Hedstrom <zwoop@apache.org
> >
> > > > wrote:
> > > > > >
> > > > > > > Any specific justifications for this? This is another
> abstraction
> > > of
> > > > > the
> > > > > > C
> > > > > > > APIs in C++?
> > > > > > >
> > > > > > > — Leif
> > > > > > >
> > > > > > > On Mon, Apr 8, 2024 at 13:28 Walt Karas
> > > <wkaras@yahooinc.com.invalid
> > > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > That is move
> > > > > > > plugins/experimental/txn_box/plugin/include/txn_box/ts_util.h
> > > > > > > > to include/ts, and
> > > > plugins/experimental/txn_box/plugin/src/ts_util.cc
> > > > > > to
> > > > > > > > src/api .
> > > > > > > >
> > > > > > > > May involve some picking and choosing.  ts_util.h includes
> > > > > common.h.  I
> > > > > > > > don't think we want to bring all of common.h into the TS API.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [E] Re: Proposal: move ts_util.h/.cc into TS API (in ts namespace)

[Masakazu Kitajo <ma...@apache.org>]

And the new one isn't? Any evidence?

I really don't understand the necessity of having the new wrapper as part
of TS API at this time. If you (or others) are not going to answer my
questions and try to convince me, I'd have to throw -1. My suggestion would
be to gain reputation while incubating the wrapper as an independent
library.

On Wed, Apr 17, 2024 at 7:15 PM Walt Karas <wk...@yahooinc.com.invalid>
wrote:

> The atscppapi was deprecated because it was buggy and had bad performance.
>
> On Wed, Apr 17, 2024 at 4:36 PM Masakazu Kitajo <m4...@gmail.com> wrote:
>
> > I'm not saying any C++ wrapper should not be made. I just don't think it
> > should be TS API.
> >
> > I don't get why we can say the wrapper in a new experimental plugin is
> good
> > at this time. We don't have good C++ representation of request, response,
> > header field, etc. even internally in tscore. And if we had, we could
> > export them in a more straightforward way.
> >
> > What were the problems of atscppapi? How are those solved by the new
> > wrapper? Why can we say the new wrapper is already in a good shape? Why
> do
> > we want to introduce a wrapper of the existing C API instead of replacing
> > them with new API which would be naturally more C++ friendly even
> without a
> > wrapper?
> >
> > I have too many questions to throw +1 for this. Since the wrapper is
> just a
> > wrapper, we can see if it's good without having it as TS API. Do we have
> a
> > reason to skip doing that?
> >
> > On Wed, Apr 17, 2024 at 1:06 PM Walt Karas <wk...@yahooinc.com.invalid>
> > wrote:
> >
> > > The atscppapi had problems, but I don't agree that shows any C++
> wrapper
> > is
> > > bad.  If we say we should not have an alternative C++ API, as well as
> a C
> > > API, that would imply we should not have a Lua API.
> > >
> > > On Wed, Apr 17, 2024 at 2:34 PM Masakazu Kitajo <ma...@apache.org>
> > wrote:
> > >
> > > > We had a wrapper (the old TS CPP API), and we removed it. Why do we
> > want
> > > to
> > > > have yet another wrapper now? What's the difference?
> > > >
> > > > Also, I don't like to have libswoc stuff in the API. Using it
> > internally
> > > is
> > > > ok because we can replace it anytime but having it as part of API is
> a
> > > huge
> > > > commitment.
> > > >
> > > > A wrapper could be provided separately as an independent library.
> Then
> > > you
> > > > can make any changes anytime without waiting for ATS releases. If
> it's
> > > > convenient, plugin developers will use it, and they won't if they
> don't
> > > > like it for some reasons (instability, use of libswoc, etc.). One
> might
> > > > make a better wrapper. I don't see a reason to have such things as TS
> > API
> > > > and maintain it by ourselves. IMO, TS API should provide minimal
> things
> > > > which can be only done by API.
> > > >
> > > >
> > > > On Wed, Apr 10, 2024 at 2:50 PM Walt Karas
> <wkaras@yahooinc.com.invalid
> > >
> > > > wrote:
> > > >
> > > > > Yes, it's wrapper, that utilizes C++ features.  It's easier to use
> > > (Imore
> > > > > concise).  Easy to understand.  Can be intermixed with the base
> API.
> > > > >
> > > > > On Wed, Apr 10, 2024 at 12:49 PM Leif Hedstrom <zw...@apache.org>
> > > wrote:
> > > > >
> > > > > > Any specific justifications for this? This is another abstraction
> > of
> > > > the
> > > > > C
> > > > > > APIs in C++?
> > > > > >
> > > > > > — Leif
> > > > > >
> > > > > > On Mon, Apr 8, 2024 at 13:28 Walt Karas
> > <wkaras@yahooinc.com.invalid
> > > >
> > > > > > wrote:
> > > > > >
> > > > > > > That is move
> > > > > > plugins/experimental/txn_box/plugin/include/txn_box/ts_util.h
> > > > > > > to include/ts, and
> > > plugins/experimental/txn_box/plugin/src/ts_util.cc
> > > > > to
> > > > > > > src/api .
> > > > > > >
> > > > > > > May involve some picking and choosing.  ts_util.h includes
> > > > common.h.  I
> > > > > > > don't think we want to bring all of common.h into the TS API.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [E] Re: Proposal: move ts_util.h/.cc into TS API (in ts namespace)

[Walt Karas <wk...@yahooinc.com.INVALID>]

The atscppapi was deprecated because it was buggy and had bad performance.

On Wed, Apr 17, 2024 at 4:36 PM Masakazu Kitajo <m4...@gmail.com> wrote:

> I'm not saying any C++ wrapper should not be made. I just don't think it
> should be TS API.
>
> I don't get why we can say the wrapper in a new experimental plugin is good
> at this time. We don't have good C++ representation of request, response,
> header field, etc. even internally in tscore. And if we had, we could
> export them in a more straightforward way.
>
> What were the problems of atscppapi? How are those solved by the new
> wrapper? Why can we say the new wrapper is already in a good shape? Why do
> we want to introduce a wrapper of the existing C API instead of replacing
> them with new API which would be naturally more C++ friendly even without a
> wrapper?
>
> I have too many questions to throw +1 for this. Since the wrapper is just a
> wrapper, we can see if it's good without having it as TS API. Do we have a
> reason to skip doing that?
>
> On Wed, Apr 17, 2024 at 1:06 PM Walt Karas <wk...@yahooinc.com.invalid>
> wrote:
>
> > The atscppapi had problems, but I don't agree that shows any C++ wrapper
> is
> > bad.  If we say we should not have an alternative C++ API, as well as a C
> > API, that would imply we should not have a Lua API.
> >
> > On Wed, Apr 17, 2024 at 2:34 PM Masakazu Kitajo <ma...@apache.org>
> wrote:
> >
> > > We had a wrapper (the old TS CPP API), and we removed it. Why do we
> want
> > to
> > > have yet another wrapper now? What's the difference?
> > >
> > > Also, I don't like to have libswoc stuff in the API. Using it
> internally
> > is
> > > ok because we can replace it anytime but having it as part of API is a
> > huge
> > > commitment.
> > >
> > > A wrapper could be provided separately as an independent library. Then
> > you
> > > can make any changes anytime without waiting for ATS releases. If it's
> > > convenient, plugin developers will use it, and they won't if they don't
> > > like it for some reasons (instability, use of libswoc, etc.). One might
> > > make a better wrapper. I don't see a reason to have such things as TS
> API
> > > and maintain it by ourselves. IMO, TS API should provide minimal things
> > > which can be only done by API.
> > >
> > >
> > > On Wed, Apr 10, 2024 at 2:50 PM Walt Karas <wkaras@yahooinc.com.invalid
> >
> > > wrote:
> > >
> > > > Yes, it's wrapper, that utilizes C++ features.  It's easier to use
> > (Imore
> > > > concise).  Easy to understand.  Can be intermixed with the base API.
> > > >
> > > > On Wed, Apr 10, 2024 at 12:49 PM Leif Hedstrom <zw...@apache.org>
> > wrote:
> > > >
> > > > > Any specific justifications for this? This is another abstraction
> of
> > > the
> > > > C
> > > > > APIs in C++?
> > > > >
> > > > > — Leif
> > > > >
> > > > > On Mon, Apr 8, 2024 at 13:28 Walt Karas
> <wkaras@yahooinc.com.invalid
> > >
> > > > > wrote:
> > > > >
> > > > > > That is move
> > > > > plugins/experimental/txn_box/plugin/include/txn_box/ts_util.h
> > > > > > to include/ts, and
> > plugins/experimental/txn_box/plugin/src/ts_util.cc
> > > > to
> > > > > > src/api .
> > > > > >
> > > > > > May involve some picking and choosing.  ts_util.h includes
> > > common.h.  I
> > > > > > don't think we want to bring all of common.h into the TS API.
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: [E] Re: Proposal: move ts_util.h/.cc into TS API (in ts namespace)

[Masakazu Kitajo <m4...@gmail.com>]

I'm not saying any C++ wrapper should not be made. I just don't think it
should be TS API.

I don't get why we can say the wrapper in a new experimental plugin is good
at this time. We don't have good C++ representation of request, response,
header field, etc. even internally in tscore. And if we had, we could
export them in a more straightforward way.

What were the problems of atscppapi? How are those solved by the new
wrapper? Why can we say the new wrapper is already in a good shape? Why do
we want to introduce a wrapper of the existing C API instead of replacing
them with new API which would be naturally more C++ friendly even without a
wrapper?

I have too many questions to throw +1 for this. Since the wrapper is just a
wrapper, we can see if it's good without having it as TS API. Do we have a
reason to skip doing that?

On Wed, Apr 17, 2024 at 1:06 PM Walt Karas <wk...@yahooinc.com.invalid>
wrote:

> The atscppapi had problems, but I don't agree that shows any C++ wrapper is
> bad.  If we say we should not have an alternative C++ API, as well as a C
> API, that would imply we should not have a Lua API.
>
> On Wed, Apr 17, 2024 at 2:34 PM Masakazu Kitajo <ma...@apache.org> wrote:
>
> > We had a wrapper (the old TS CPP API), and we removed it. Why do we want
> to
> > have yet another wrapper now? What's the difference?
> >
> > Also, I don't like to have libswoc stuff in the API. Using it internally
> is
> > ok because we can replace it anytime but having it as part of API is a
> huge
> > commitment.
> >
> > A wrapper could be provided separately as an independent library. Then
> you
> > can make any changes anytime without waiting for ATS releases. If it's
> > convenient, plugin developers will use it, and they won't if they don't
> > like it for some reasons (instability, use of libswoc, etc.). One might
> > make a better wrapper. I don't see a reason to have such things as TS API
> > and maintain it by ourselves. IMO, TS API should provide minimal things
> > which can be only done by API.
> >
> >
> > On Wed, Apr 10, 2024 at 2:50 PM Walt Karas <wk...@yahooinc.com.invalid>
> > wrote:
> >
> > > Yes, it's wrapper, that utilizes C++ features.  It's easier to use
> (Imore
> > > concise).  Easy to understand.  Can be intermixed with the base API.
> > >
> > > On Wed, Apr 10, 2024 at 12:49 PM Leif Hedstrom <zw...@apache.org>
> wrote:
> > >
> > > > Any specific justifications for this? This is another abstraction of
> > the
> > > C
> > > > APIs in C++?
> > > >
> > > > — Leif
> > > >
> > > > On Mon, Apr 8, 2024 at 13:28 Walt Karas <wkaras@yahooinc.com.invalid
> >
> > > > wrote:
> > > >
> > > > > That is move
> > > > plugins/experimental/txn_box/plugin/include/txn_box/ts_util.h
> > > > > to include/ts, and
> plugins/experimental/txn_box/plugin/src/ts_util.cc
> > > to
> > > > > src/api .
> > > > >
> > > > > May involve some picking and choosing.  ts_util.h includes
> > common.h.  I
> > > > > don't think we want to bring all of common.h into the TS API.
> > > > >
> > > >
> > >
> >
>

Re: [E] Re: Proposal: move ts_util.h/.cc into TS API (in ts namespace)

[Walt Karas <wk...@yahooinc.com.INVALID>]

The atscppapi had problems, but I don't agree that shows any C++ wrapper is
bad.  If we say we should not have an alternative C++ API, as well as a C
API, that would imply we should not have a Lua API.

On Wed, Apr 17, 2024 at 2:34 PM Masakazu Kitajo <ma...@apache.org> wrote:

> We had a wrapper (the old TS CPP API), and we removed it. Why do we want to
> have yet another wrapper now? What's the difference?
>
> Also, I don't like to have libswoc stuff in the API. Using it internally is
> ok because we can replace it anytime but having it as part of API is a huge
> commitment.
>
> A wrapper could be provided separately as an independent library. Then you
> can make any changes anytime without waiting for ATS releases. If it's
> convenient, plugin developers will use it, and they won't if they don't
> like it for some reasons (instability, use of libswoc, etc.). One might
> make a better wrapper. I don't see a reason to have such things as TS API
> and maintain it by ourselves. IMO, TS API should provide minimal things
> which can be only done by API.
>
>
> On Wed, Apr 10, 2024 at 2:50 PM Walt Karas <wk...@yahooinc.com.invalid>
> wrote:
>
> > Yes, it's wrapper, that utilizes C++ features.  It's easier to use (Imore
> > concise).  Easy to understand.  Can be intermixed with the base API.
> >
> > On Wed, Apr 10, 2024 at 12:49 PM Leif Hedstrom <zw...@apache.org> wrote:
> >
> > > Any specific justifications for this? This is another abstraction of
> the
> > C
> > > APIs in C++?
> > >
> > > — Leif
> > >
> > > On Mon, Apr 8, 2024 at 13:28 Walt Karas <wk...@yahooinc.com.invalid>
> > > wrote:
> > >
> > > > That is move
> > > plugins/experimental/txn_box/plugin/include/txn_box/ts_util.h
> > > > to include/ts, and plugins/experimental/txn_box/plugin/src/ts_util.cc
> > to
> > > > src/api .
> > > >
> > > > May involve some picking and choosing.  ts_util.h includes
> common.h.  I
> > > > don't think we want to bring all of common.h into the TS API.
> > > >
> > >
> >
>

Re: [E] Re: Proposal: move ts_util.h/.cc into TS API (in ts namespace)

[Masakazu Kitajo <ma...@apache.org>]

We had a wrapper (the old TS CPP API), and we removed it. Why do we want to
have yet another wrapper now? What's the difference?

Also, I don't like to have libswoc stuff in the API. Using it internally is
ok because we can replace it anytime but having it as part of API is a huge
commitment.

A wrapper could be provided separately as an independent library. Then you
can make any changes anytime without waiting for ATS releases. If it's
convenient, plugin developers will use it, and they won't if they don't
like it for some reasons (instability, use of libswoc, etc.). One might
make a better wrapper. I don't see a reason to have such things as TS API
and maintain it by ourselves. IMO, TS API should provide minimal things
which can be only done by API.


On Wed, Apr 10, 2024 at 2:50 PM Walt Karas <wk...@yahooinc.com.invalid>
wrote:

> Yes, it's wrapper, that utilizes C++ features.  It's easier to use (Imore
> concise).  Easy to understand.  Can be intermixed with the base API.
>
> On Wed, Apr 10, 2024 at 12:49 PM Leif Hedstrom <zw...@apache.org> wrote:
>
> > Any specific justifications for this? This is another abstraction of the
> C
> > APIs in C++?
> >
> > — Leif
> >
> > On Mon, Apr 8, 2024 at 13:28 Walt Karas <wk...@yahooinc.com.invalid>
> > wrote:
> >
> > > That is move
> > plugins/experimental/txn_box/plugin/include/txn_box/ts_util.h
> > > to include/ts, and plugins/experimental/txn_box/plugin/src/ts_util.cc
> to
> > > src/api .
> > >
> > > May involve some picking and choosing.  ts_util.h includes common.h.  I
> > > don't think we want to bring all of common.h into the TS API.
> > >
> >
>

Re: [E] Re: Proposal: move ts_util.h/.cc into TS API (in ts namespace)

[Damian Meden <da...@yahooinc.com.INVALID>]

I like the idea. +1

On Wed, Apr 10, 2024 at 10:49 PM Walt Karas <wk...@yahooinc.com.invalid>
wrote:

> Yes, it's wrapper, that utilizes C++ features.  It's easier to use (Imore
> concise).  Easy to understand.  Can be intermixed with the base API.
>
> On Wed, Apr 10, 2024 at 12:49 PM Leif Hedstrom <zw...@apache.org> wrote:
>
> > Any specific justifications for this? This is another abstraction of the
> C
> > APIs in C++?
> >
> > — Leif
> >
> > On Mon, Apr 8, 2024 at 13:28 Walt Karas <wk...@yahooinc.com.invalid>
> > wrote:
> >
> > > That is move
> > plugins/experimental/txn_box/plugin/include/txn_box/ts_util.h
> > > to include/ts, and plugins/experimental/txn_box/plugin/src/ts_util.cc
> to
> > > src/api .
> > >
> > > May involve some picking and choosing.  ts_util.h includes common.h.  I
> > > don't think we want to bring all of common.h into the TS API.
> > >
> >
>

Re: [E] Re: Proposal: move ts_util.h/.cc into TS API (in ts namespace)

[Walt Karas <wk...@yahooinc.com.INVALID>]

Yes, it's wrapper, that utilizes C++ features.  It's easier to use (Imore
concise).  Easy to understand.  Can be intermixed with the base API.

On Wed, Apr 10, 2024 at 12:49 PM Leif Hedstrom <zw...@apache.org> wrote:

> Any specific justifications for this? This is another abstraction of the C
> APIs in C++?
>
> — Leif
>
> On Mon, Apr 8, 2024 at 13:28 Walt Karas <wk...@yahooinc.com.invalid>
> wrote:
>
> > That is move
> plugins/experimental/txn_box/plugin/include/txn_box/ts_util.h
> > to include/ts, and plugins/experimental/txn_box/plugin/src/ts_util.cc to
> > src/api .
> >
> > May involve some picking and choosing.  ts_util.h includes common.h.  I
> > don't think we want to bring all of common.h into the TS API.
> >
>

Re: Proposal: move ts_util.h/.cc into TS API (in ts namespace)

[Leif Hedstrom <zw...@apache.org>]

Any specific justifications for this? This is another abstraction of the C
APIs in C++?

— Leif

On Mon, Apr 8, 2024 at 13:28 Walt Karas <wk...@yahooinc.com.invalid> wrote:

> That is move plugins/experimental/txn_box/plugin/include/txn_box/ts_util.h
> to include/ts, and plugins/experimental/txn_box/plugin/src/ts_util.cc to
> src/api .
>
> May involve some picking and choosing.  ts_util.h includes common.h.  I
> don't think we want to bring all of common.h into the TS API.
>