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 <mas...@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 <wka...@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 <m4s...@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 <wka...@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 <mas...@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 > > <wka...@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 > > > <wka...@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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
