We shouldn’t be concerned about the support for writing plugins in Java and 
calling into C vs C++, since no one is doing it and I haven’t heard of anyone 
attempting it.

We should look at Luajit and V8 support for calling C++ APIs since that is the 
path we are on and going down.

-Bryan


> On May 17, 2019, at 10:04 AM, Walt Karas <wka...@verizonmedia.com.INVALID> 
> wrote:
> 
> Is it somehow inherently more dangerous or disaster-prone than calling into
> Lua code that calls back into the C TS API?
> 
> On Fri, May 17, 2019 at 11:59 AM Jason Giedymin <jason.giedy...@gmail.com>
> wrote:
> 
>> Sounds like a disaster.
>> 
>> -Jason
>> 
>>> On May 17, 2019, at 12:51 PM, Bryan Call <bc...@apache.org> wrote:
>>> 
>>> Having a plugin that would call into Java and then back into C sounds
>> like a really bad idea.
>>> 
>>> -Bryan
>>> 
>>> 
>>>> On May 17, 2019, at 8:59 AM, Walt Karas <wka...@verizonmedia.com.INVALID>
>> wrote:
>>>> 
>>>> http://jonisalonen.com/2012/calling-c-from-java-is-easy/
>>>> 
>>>> I don't know if there is a way to call Java from C or C++, which you
>> would
>>>> also need to have a Java plugin.  If no one is currently doing anything
>>>> like this we probably shouldn't worry about it.
>>>> 
>>>>> On Fri, May 17, 2019 at 10:54 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
>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>> 
>> 

Reply via email to