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