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. > > > > > > > > > > > > > > > > > > > > > > > > > > > >
