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