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