I really think we should be doing a c and c++ API. Allen had a PR at one point to move some source around to make this easier to do.
Jason On Fri, May 17, 2019 at 10:55 AM Leif Hedstrom <zw...@apache.org> wrote: > > > > On May 17, 2019, at 9:48 AM, Walt Karas <wka...@verizonmedia.com.INVALID> > wrote: > > > > But are there people who write plugins in other languages (like Java for > > example) that can call C functions, but not C++ functions? If so, > wouldn't > > this break their plugins? > > > Never heard of that. How would someone do that ? You can write Java such > that the C-callbacks / continuations from ATS somehow gets called into the > appropriate Java API? dlopen() would need to find all these entry points in > the .so. > > — leif > > > > > On Fri, May 17, 2019 at 8:41 AM Leif Hedstrom <zw...@apache.org> wrote: > > > >> If we change this, such that all plugins must be compiled with C++ > >> compilers, we have the liberty of using C++’ism in the public > interfaces, > >> such as ts/ts.h and ts/remap.h. This has benefits, such as being able to > >> expose internal APIs of ATS without going through complex glue > interfaces > >> and opaque pointers. > >> > >> The disadvantage is that keeping ABI compatibility is a fair amount more > >> tricky. However, I don’t feel this is a significant issue, as long as we > >> don’t break it within minor / patch releases. It does make things > trickier > >> here too though, so we have to be open to the possibility of accidental > >> breakage of ABI compatibility. > >> > >> I think the advantages outweighs the disadvantages. The tasks for this > is > >> tracked on > >> > >> https://github.com/apache/trafficserver/issues/5360 > >> > >> > >> Cheers, > >> > >> — leif > >> > >> > >
