You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Walt Karas <wk...@oath.com.INVALID> on 2018/06/15 17:00:09 UTC
Suggestion: "Rolling" TS API changes
We could have a ts2.h include file that included ts.h. It would
contain stuff like:
#define TSExistingStructType TSExistingStructTypeVer2
typedef struct
{
... fields ...
} TSExistingStructTypeVer2;
#define TSExistingAPIFunc TSExistingAPIFuncVer2
void TSExistingAPIFuncVer2(... formal parameter list ...);
As well as new declarations / definitions. Once all plugins were
using ts2.h, then ts.h could be revised to be equivalent to ts2.h.
ts2.h would become a symbolic link to ts.h. Once all plugins were
changed back to including ts.h, the symbolic link could be removed.
There could hypothetically be multiple layers using this approach.
There could be a ts3.h include file that includes ts2.h. I could
contain stuff like
#undef TSExistingAPIFunc
#define TSExistingAPIFuncVer3
void TSExistingAPIFuncVer3(... formal parameter list ...);
Clearly there are some API changes where this approach would not work,
but many where it would work.
One way I'm thinking I would like to use this approach is to
substitute multiple, more specific types for the TSMLoc type. The
goal is to have more compile time checking. Currently we rely on run
time checks, and there are also cases where a coding error could
result in undefined run time behavior (memory corruption).
Re: Suggestion: "Rolling" TS API changes
Posted by Leif Hedstrom <zw...@apache.org>.
> On Jun 18, 2018, at 6:09 PM, Alan Carroll <so...@oath.com.INVALID> wrote:
>
> I would presume this would be used only for the C++ API and/or the C++
> utility headers.
That’s not what the initial email implied (it specifically points to <ts/ts.h>).
— Leif
Re: Suggestion: "Rolling" TS API changes
Posted by Alan Carroll <so...@oath.com.INVALID>.
I would presume this would be used only for the C++ API and/or the C++
utility headers.
On Mon, Jun 18, 2018 at 7:37 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>
> > On Jun 15, 2018, at 2:21 PM, Jason Kenny <jk...@oath.com.INVALID>
> wrote:
> >
> > This method works.. it is a lot easier if used with namespaces as the
> "set"
> > of changed objects are wrapped in a versioned namespace. This is a lot
> > easier for a user to map to, then having a lot of different versioned
> > objects.
>
>
> I didn’t say it doesn’t work. I said it’s not worth the headaches. And,
> these are C APIs, what you describe sounds like abstractions like COM for
> objects ?
>
> Seems like no one else cares? If so, just do it.
>
> I’d insist that status quo should be retained, such that for the 99% of us
> that just does #include <ts/ts.h>, things should just work as we expect,
> and always get the version of the API(s) that are pertinent to that LTS
> version I’m compiling against. And when we rev versions (from 7 to 8, or 8
> to 9), the defaults should change such that my plugins gets that get the
> right version for that release. This implies that whomever implements this,
> will be responsible for making sure that appropriate version updates are
> done at all major versions, and removing the old versions etc. as needed.
>
> Ciao,
>
> — Leif
>
>
Re: Suggestion: "Rolling" TS API changes
Posted by Leif Hedstrom <zw...@apache.org>.
> On Jun 15, 2018, at 2:21 PM, Jason Kenny <jk...@oath.com.INVALID> wrote:
>
> This method works.. it is a lot easier if used with namespaces as the "set"
> of changed objects are wrapped in a versioned namespace. This is a lot
> easier for a user to map to, then having a lot of different versioned
> objects.
I didn’t say it doesn’t work. I said it’s not worth the headaches. And, these are C APIs, what you describe sounds like abstractions like COM for objects ?
Seems like no one else cares? If so, just do it.
I’d insist that status quo should be retained, such that for the 99% of us that just does #include <ts/ts.h>, things should just work as we expect, and always get the version of the API(s) that are pertinent to that LTS version I’m compiling against. And when we rev versions (from 7 to 8, or 8 to 9), the defaults should change such that my plugins gets that get the right version for that release. This implies that whomever implements this, will be responsible for making sure that appropriate version updates are done at all major versions, and removing the old versions etc. as needed.
Ciao,
— Leif
Re: Suggestion: "Rolling" TS API changes
Posted by Jason Kenny <jk...@oath.com.INVALID>.
This method works.. it is a lot easier if used with namespaces as the "set"
of changed objects are wrapped in a versioned namespace. This is a lot
easier for a user to map to, then having a lot of different versioned
objects.
The end result is that the user will map to a space like ats_8 that is an
alias for something like ats_8.1.0. GIven the code need to be recompiled
the user just gets something that works. If there is a breakage the user
can compile the plugin to a more exact version. The namespace allows this
to work all the objects in a release and if more advanced stuff is needed
they can still do it at a per-object level. However here the objects will
not be all over the place
Jason
On Fri, Jun 15, 2018 at 1:32 PM, Leif Hedstrom <zw...@apache.org> wrote:
>
>
> > On Jun 15, 2018, at 11:38, Walt Karas <wk...@oath.com.INVALID> wrote:
> >
> > It potentially could allow moving to a new major release without the
> > need to immediately update all one's plugins.
> >
> > Are there any TS users that continuously deploy from master and don't
> > wait for releases?
>
> None that I know of.
>
> Still sounds like we’d add complexity to solve a problem that doesn’t
> exist. And now developers have to know which version of an include to use?
> Not to mention us managing multiple versions of these APIs.
>
> I say just bite the bullet once a year (possibly), for the last 10 years
> that has worked fine AFAIK. Its not like we make such changes frequent
> either. If it’s an issue , make a tool that updates code automatically for
> your in-house plugins. We did that once before, when we made major API
> changes.
>
> Ciao,
>
> — Leif
> >
> >> On Fri, Jun 15, 2018 at 12:04 PM, Leif Hedstrom <zw...@apache.org>
> wrote:
> >> Hmmm, this sounds awful :). What is the intent / problem solved here?
> >>
> >> We can break APIs between major versions, so why do we need this?
> >>
> >> — leif
> >>
> >>
> >>> On Jun 15, 2018, at 11:00 AM, Walt Karas <wk...@oath.com.INVALID>
> wrote:
> >>>
> >>> We could have a ts2.h include file that included ts.h. It would
> >>> contain stuff like:
> >>>
> >>> #define TSExistingStructType TSExistingStructTypeVer2
> >>>
> >>> typedef struct
> >>> {
> >>> ... fields ...
> >>> } TSExistingStructTypeVer2;
> >>>
> >>> #define TSExistingAPIFunc TSExistingAPIFuncVer2
> >>>
> >>> void TSExistingAPIFuncVer2(... formal parameter list ...);
> >>>
> >>> As well as new declarations / definitions. Once all plugins were
> >>> using ts2.h, then ts.h could be revised to be equivalent to ts2.h.
> >>> ts2.h would become a symbolic link to ts.h. Once all plugins were
> >>> changed back to including ts.h, the symbolic link could be removed.
> >>>
> >>> There could hypothetically be multiple layers using this approach.
> >>> There could be a ts3.h include file that includes ts2.h. I could
> >>> contain stuff like
> >>>
> >>> #undef TSExistingAPIFunc
> >>> #define TSExistingAPIFuncVer3
> >>>
> >>> void TSExistingAPIFuncVer3(... formal parameter list ...);
> >>>
> >>> Clearly there are some API changes where this approach would not work,
> >>> but many where it would work.
> >>>
> >>> One way I'm thinking I would like to use this approach is to
> >>> substitute multiple, more specific types for the TSMLoc type. The
> >>> goal is to have more compile time checking. Currently we rely on run
> >>> time checks, and there are also cases where a coding error could
> >>> result in undefined run time behavior (memory corruption).
> >>
>
>
Re: Suggestion: "Rolling" TS API changes
Posted by Leif Hedstrom <zw...@apache.org>.
> On Jun 15, 2018, at 11:38, Walt Karas <wk...@oath.com.INVALID> wrote:
>
> It potentially could allow moving to a new major release without the
> need to immediately update all one's plugins.
>
> Are there any TS users that continuously deploy from master and don't
> wait for releases?
None that I know of.
Still sounds like we’d add complexity to solve a problem that doesn’t exist. And now developers have to know which version of an include to use? Not to mention us managing multiple versions of these APIs.
I say just bite the bullet once a year (possibly), for the last 10 years that has worked fine AFAIK. Its not like we make such changes frequent either. If it’s an issue , make a tool that updates code automatically for your in-house plugins. We did that once before, when we made major API changes.
Ciao,
— Leif
>
>> On Fri, Jun 15, 2018 at 12:04 PM, Leif Hedstrom <zw...@apache.org> wrote:
>> Hmmm, this sounds awful :). What is the intent / problem solved here?
>>
>> We can break APIs between major versions, so why do we need this?
>>
>> — leif
>>
>>
>>> On Jun 15, 2018, at 11:00 AM, Walt Karas <wk...@oath.com.INVALID> wrote:
>>>
>>> We could have a ts2.h include file that included ts.h. It would
>>> contain stuff like:
>>>
>>> #define TSExistingStructType TSExistingStructTypeVer2
>>>
>>> typedef struct
>>> {
>>> ... fields ...
>>> } TSExistingStructTypeVer2;
>>>
>>> #define TSExistingAPIFunc TSExistingAPIFuncVer2
>>>
>>> void TSExistingAPIFuncVer2(... formal parameter list ...);
>>>
>>> As well as new declarations / definitions. Once all plugins were
>>> using ts2.h, then ts.h could be revised to be equivalent to ts2.h.
>>> ts2.h would become a symbolic link to ts.h. Once all plugins were
>>> changed back to including ts.h, the symbolic link could be removed.
>>>
>>> There could hypothetically be multiple layers using this approach.
>>> There could be a ts3.h include file that includes ts2.h. I could
>>> contain stuff like
>>>
>>> #undef TSExistingAPIFunc
>>> #define TSExistingAPIFuncVer3
>>>
>>> void TSExistingAPIFuncVer3(... formal parameter list ...);
>>>
>>> Clearly there are some API changes where this approach would not work,
>>> but many where it would work.
>>>
>>> One way I'm thinking I would like to use this approach is to
>>> substitute multiple, more specific types for the TSMLoc type. The
>>> goal is to have more compile time checking. Currently we rely on run
>>> time checks, and there are also cases where a coding error could
>>> result in undefined run time behavior (memory corruption).
>>
Re: Suggestion: "Rolling" TS API changes
Posted by Walt Karas <wk...@oath.com.INVALID>.
It also allows for non-backward-compatible API changes in non-major releases.
On Fri, Jun 15, 2018 at 12:38 PM, Walt Karas <wk...@oath.com> wrote:
> It potentially could allow moving to a new major release without the
> need to immediately update all one's plugins.
>
> Are there any TS users that continuously deploy from master and don't
> wait for releases?
>
> On Fri, Jun 15, 2018 at 12:04 PM, Leif Hedstrom <zw...@apache.org> wrote:
>> Hmmm, this sounds awful :). What is the intent / problem solved here?
>>
>> We can break APIs between major versions, so why do we need this?
>>
>> — leif
>>
>>
>>> On Jun 15, 2018, at 11:00 AM, Walt Karas <wk...@oath.com.INVALID> wrote:
>>>
>>> We could have a ts2.h include file that included ts.h. It would
>>> contain stuff like:
>>>
>>> #define TSExistingStructType TSExistingStructTypeVer2
>>>
>>> typedef struct
>>> {
>>> ... fields ...
>>> } TSExistingStructTypeVer2;
>>>
>>> #define TSExistingAPIFunc TSExistingAPIFuncVer2
>>>
>>> void TSExistingAPIFuncVer2(... formal parameter list ...);
>>>
>>> As well as new declarations / definitions. Once all plugins were
>>> using ts2.h, then ts.h could be revised to be equivalent to ts2.h.
>>> ts2.h would become a symbolic link to ts.h. Once all plugins were
>>> changed back to including ts.h, the symbolic link could be removed.
>>>
>>> There could hypothetically be multiple layers using this approach.
>>> There could be a ts3.h include file that includes ts2.h. I could
>>> contain stuff like
>>>
>>> #undef TSExistingAPIFunc
>>> #define TSExistingAPIFuncVer3
>>>
>>> void TSExistingAPIFuncVer3(... formal parameter list ...);
>>>
>>> Clearly there are some API changes where this approach would not work,
>>> but many where it would work.
>>>
>>> One way I'm thinking I would like to use this approach is to
>>> substitute multiple, more specific types for the TSMLoc type. The
>>> goal is to have more compile time checking. Currently we rely on run
>>> time checks, and there are also cases where a coding error could
>>> result in undefined run time behavior (memory corruption).
>>
Re: Suggestion: "Rolling" TS API changes
Posted by Walt Karas <wk...@oath.com.INVALID>.
It potentially could allow moving to a new major release without the
need to immediately update all one's plugins.
Are there any TS users that continuously deploy from master and don't
wait for releases?
On Fri, Jun 15, 2018 at 12:04 PM, Leif Hedstrom <zw...@apache.org> wrote:
> Hmmm, this sounds awful :). What is the intent / problem solved here?
>
> We can break APIs between major versions, so why do we need this?
>
> — leif
>
>
>> On Jun 15, 2018, at 11:00 AM, Walt Karas <wk...@oath.com.INVALID> wrote:
>>
>> We could have a ts2.h include file that included ts.h. It would
>> contain stuff like:
>>
>> #define TSExistingStructType TSExistingStructTypeVer2
>>
>> typedef struct
>> {
>> ... fields ...
>> } TSExistingStructTypeVer2;
>>
>> #define TSExistingAPIFunc TSExistingAPIFuncVer2
>>
>> void TSExistingAPIFuncVer2(... formal parameter list ...);
>>
>> As well as new declarations / definitions. Once all plugins were
>> using ts2.h, then ts.h could be revised to be equivalent to ts2.h.
>> ts2.h would become a symbolic link to ts.h. Once all plugins were
>> changed back to including ts.h, the symbolic link could be removed.
>>
>> There could hypothetically be multiple layers using this approach.
>> There could be a ts3.h include file that includes ts2.h. I could
>> contain stuff like
>>
>> #undef TSExistingAPIFunc
>> #define TSExistingAPIFuncVer3
>>
>> void TSExistingAPIFuncVer3(... formal parameter list ...);
>>
>> Clearly there are some API changes where this approach would not work,
>> but many where it would work.
>>
>> One way I'm thinking I would like to use this approach is to
>> substitute multiple, more specific types for the TSMLoc type. The
>> goal is to have more compile time checking. Currently we rely on run
>> time checks, and there are also cases where a coding error could
>> result in undefined run time behavior (memory corruption).
>
Re: Suggestion: "Rolling" TS API changes
Posted by Leif Hedstrom <zw...@apache.org>.
Hmmm, this sounds awful :). What is the intent / problem solved here?
We can break APIs between major versions, so why do we need this?
— leif
> On Jun 15, 2018, at 11:00 AM, Walt Karas <wk...@oath.com.INVALID> wrote:
>
> We could have a ts2.h include file that included ts.h. It would
> contain stuff like:
>
> #define TSExistingStructType TSExistingStructTypeVer2
>
> typedef struct
> {
> ... fields ...
> } TSExistingStructTypeVer2;
>
> #define TSExistingAPIFunc TSExistingAPIFuncVer2
>
> void TSExistingAPIFuncVer2(... formal parameter list ...);
>
> As well as new declarations / definitions. Once all plugins were
> using ts2.h, then ts.h could be revised to be equivalent to ts2.h.
> ts2.h would become a symbolic link to ts.h. Once all plugins were
> changed back to including ts.h, the symbolic link could be removed.
>
> There could hypothetically be multiple layers using this approach.
> There could be a ts3.h include file that includes ts2.h. I could
> contain stuff like
>
> #undef TSExistingAPIFunc
> #define TSExistingAPIFuncVer3
>
> void TSExistingAPIFuncVer3(... formal parameter list ...);
>
> Clearly there are some API changes where this approach would not work,
> but many where it would work.
>
> One way I'm thinking I would like to use this approach is to
> substitute multiple, more specific types for the TSMLoc type. The
> goal is to have more compile time checking. Currently we rely on run
> time checks, and there are also cases where a coding error could
> result in undefined run time behavior (memory corruption).