You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Leif Hedstrom <zw...@apache.org> on 2019/05/17 13:41:20 UTC
[PROPOSAL] Make all plugins require C++ compiler
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
Re: [PROPOSAL] Make all plugins require C++ compiler
Posted by Chris Lemmons <al...@gmail.com>.
I've been toying with Rust plugins for ATS, but certainly nothing in
production. It's worth considering, though, that the plugin
architecture is specifically designed so that users can keep their
plugins private if they wish, so there may be some plugins we don't
know about out there. If we make a breaking change, we may want to go
through the notice-and-deprecation process to let folks know.
On Fri, May 17, 2019 at 11:43 AM Bryan Call <bc...@apache.org> wrote:
>
> 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 <wk...@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 <ja...@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 <wk...@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 <wkaras@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
> >>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >>
>
Re: [PROPOSAL] Make all plugins require C++ compiler
Posted by Bryan Call <bc...@apache.org>.
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 <wk...@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 <ja...@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 <wk...@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 <wkaras@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
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>
>>
Re: [PROPOSAL] Make all plugins require C++ compiler
Posted by Walt Karas <wk...@verizonmedia.com.INVALID>.
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 <ja...@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 <wk...@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 <wkaras@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
> >>>>>
> >>>>>
> >>>
> >>>
> >
>
Re: [PROPOSAL] Make all plugins require C++ compiler
Posted by Jason Giedymin <ja...@gmail.com>.
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 <wk...@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 <wk...@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
>>>>>
>>>>>
>>>
>>>
>
Re: [PROPOSAL] Make all plugins require C++ compiler
Posted by Bryan Call <bc...@apache.org>.
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 <wk...@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 <wk...@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
>>>>
>>>>
>>
>>
Re: [PROPOSAL] Make all plugins require C++ compiler
Posted by Walt Karas <wk...@verizonmedia.com.INVALID>.
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 <wk...@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
> >>
> >>
>
>
Re: [PROPOSAL] Make all plugins require C++ compiler
Posted by Jason Kenny <jk...@verizonmedia.com.INVALID>.
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 <wk...@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
> >>
> >>
>
>
Re: [PROPOSAL] Make all plugins require C++ compiler
Posted by Leif Hedstrom <zw...@apache.org>.
> On May 17, 2019, at 9:48 AM, Walt Karas <wk...@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
>>
>>
Re: [PROPOSAL] Make all plugins require C++ compiler
Posted by Walt Karas <wk...@verizonmedia.com.INVALID>.
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?
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
>
>