> Its a judgement call, how much to minimize the API. Yes, that's why we send API proposals on the dev list. And I don't think I'm absolutely right. If we, as a community, want to have utilities as TS API, that's what we should do. I'm disappointed that others don't join this discussion, but if they don't mind making Cleanup.h TS API, that means we have many potential maintainers. I guess I could just abide and hope you and they maintain it.
Is providing Cleanup.h as TS API the one and only way? I don't understand why not promoting Cleanup.h means inevitable resource leak. Plugin developers can take care of it in their own way, right? One could copy Cleanup.h anytime if they want. How serious is the resource leak you mentioned? I'm not going to say memory leak is a good thing, but many plugins have been running ok without Cleanup.h. I don't see the immediate need for having Cleanup.h as TS API without thinking about a way to fix the fundamental problem. On Thu, Aug 31, 2023 at 7:09 PM Walt Karas <wka...@yahooinc.com.invalid> wrote: > We could also change the API so it provided plugins with raw HTTP headers, > and let each plugin parse the headerd. Its a judgement call, how much to > minimize the API. > > Scenario 1. We continue to write code without RAII. We have resulting > resource leaks. We (potentially) find a way to put RAII into the API in a > way we all agree on. Then we change existing code to use it. > > Scenario 2. We use the RAII provided by Cleanup.h. If we find a better > way, we change existing to use. > > Leaks followed by rewriting seems worse than no leaks followed by > rewriting. > > On Thu, Aug 31, 2023 at 6:20 PM Masakazu Kitajo <m4s...@gmail.com> wrote: > > > I don't see why we want to provide a helmet with TS API mark. Somebody > may > > make a third party helmet which is better than ours. Can we steal the > > design? Can we make a much better one? I'm not sure because that may > > require interface change and/or behavior change. Then ours would be > > useless. It's not only about "helmet". Any utilities would have this > issue. > > This is why I'm skeptical to have utilities as TS API and asking all if > we > > want to do this. > > > > On Thu, Aug 31, 2023 at 1:35 PM Walt Karas <wka...@yahooinc.com.invalid> > > wrote: > > > > > The analogy I would make is to needing a helmet to ride a motorcycle. > > You > > > don' t need it in the strictest sense, but you need it for a reasonable > > > level of safety. You need RAII for a reasonable level of safety > against > > > resource leaks. > > > > > > On Thu, Aug 31, 2023 at 1:50 PM Masakazu Kitajo <m4s...@gmail.com> > > wrote: > > > > > > > I see your point, but I think we need to draw a line. High-priority > > > > capability is blurry and questionable. We have not *needed* it for > > years. > > > > > > > > > We could support RAII better, but I don't think it's feasible in > > 10.0. > > > > > > > > This implies Cleanup.h will be unnecessary after we make it better. > > > > > > > > Not discarding Cleanup.h and promoting it to TS API are different > > things. > > > > TS API is not something we can casually change or remove. I'd rather > > not > > > > add a short lifetime temporary solution to TS API. > > > > > > > > > > > > > > > > On Wed, Aug 30, 2023 at 12:19 PM Walt Karas > > <wka...@yahooinc.com.invalid > > > > > > > > wrote: > > > > > > > > > The utilities in Cleanup.h add RAII capabilities to the TS API. I > > hope > > > > we > > > > > don't need to have a debate about the value of RAII. > > > > > > > > > > Certainly, any API can become bloated with too many features. But > > RAII > > > > > seems like a high-priority capability to support. We could support > > > RAII > > > > > better, but I don't think it's feasible in 10.0. Remember, it's > not > > > > really > > > > > being added. We are removing the distinction between the C and C++ > > > APIs. > > > > > We' re discarding the parts of C++ API that are incompatible with > > the C > > > > > API. I am proposing we not discard Cleanup.h, which is compatible > > and > > > > > enhances (previously) C API. > > > > > > > > > > On Wed, Aug 30, 2023 at 1:15 PM Masakazu Kitajo <mas...@apache.org > > > > > > wrote: > > > > > > > > > > > I wonder what should be part of TS API. There may be some > > exceptions, > > > > but > > > > > > TS API basically provides things that can only be done on ATS > core. > > > > > > > > > > > > Question for all, would we want to have utilities as TS API? > > > > > > > > > > > > -- Masakazu > > > > > > > > > > > > On Tue, Aug 22, 2023 at 11:48 AM Walt Karas > > > > <wka...@yahooinc.com.invalid > > > > > > > > > > > > wrote: > > > > > > > > > > > > > See the PR > > > > > > > > > > > > > > > > > > > > > https://urldefense.com/v3/__https://github.com/apache/trafficserver/pull/10231__;!!Op6eflyXZCqGR5I!HHlP-H_IgX9Ah46LlOiHqX--VcnzF3Dp5uG2JI_JXBmG8c_jMQNpsYQPvyDaaAsympzb7neltiG5Z7zseA$ > > > > > > . Cleanup.h > > > > > > > is currently available to plugins in include/tscpp/api . The > > > > proposal > > > > > is > > > > > > > to move it to include/ts . The declarations currently in the > > > > > > > atscppapi namespace are moved to the tsapi::c_support > namespace. > > > The > > > > > > > c_support sub-namespace is for declarations specifically > designed > > > to > > > > > work > > > > > > > with declarations in tsapi::c . > > > > > > > > > > > > > > > > > > > > > > > > > > > >
