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