Re: [E] Proposal: move ts_util.h/.cc into TS API (in ts namespace)

[Leif Hedstrom <zw...@apache.org>]

> On Apr 18, 2024, at 11:20 AM, Masakazu Kitajo <ma...@apache.org> wrote:
> 
> Like I said above, I think we should keep TS API minimal, because we cannot
> change TS API casually. Once we add something, it's difficult to change or
> remove it. I don't want to have much code with such constraints just for
> convenience. That is why I've been very cautious about this (and any API
> additions) and I call using libswoc stuff a huge commitment.



I think the best argument I’ve heard against this is to not have public APIs that exposes libswoc APIs. Since we (hopefully) will move away from much of libswoc internally over time (e.g. std::fmt), exposing such dependencies in public API would make that transition difficult.

Can we make these additions such that any libswoc dependency is hidden from the public API? Is that maybe part of the cleanup we’d do before this move ?

— Leif

Re: [E] Proposal: move ts_util.h/.cc into TS API (in ts namespace)

[Walt Karas <wk...@yahooinc.com.INVALID>]

Hmm ts_util is a utility currently only used by txn_box.  It uses libswoc,
as do other parts of our code.

We have already decided to bring ts_util into our repo.  We already have to
maintain it.  It's a question of whether we want to get more use out of
it.  If we don't think it's of significant value to use C++ rather than C,
maybe we should just all switch to nginx?

On Thu, Apr 18, 2024 at 1:30 PM Leif Hedstrom <zw...@apache.org> wrote:

>
>
> > On Apr 18, 2024, at 11:20 AM, Masakazu Kitajo <ma...@apache.org> wrote:
> >
> > Like I said above, I think we should keep TS API minimal, because we
> cannot
> > change TS API casually. Once we add something, it's difficult to change
> or
> > remove it. I don't want to have much code with such constraints just for
> > convenience. That is why I've been very cautious about this (and any API
> > additions) and I call using libswoc stuff a huge commitment.
>
>
>
> I think the best argument I’ve heard against this is to not have public
> APIs that exposes libswoc APIs. Since we (hopefully) will move away from
> much of libswoc internally over time (e.g. std::fmt), exposing such
> dependencies in public API would make that transition difficult.
>
> Can we make these additions such that any libswoc dependency is hidden
> from the public API? Is that maybe part of the cleanup we’d do before this
> move ?
>
> — Leif
>
>