Hi Brian,
You didn't miss much. he thinking is that a code change is more invasive
and prone to errors than simply removing a command line option. A config
change removing a command line option is usually easier than changing the
config file itself. That was my only point.
Andy
On Thu, 4 Sep 2014, Brian Bockelman wrote:
>
> On Sep 4, 2014, at 12:44 AM, Andrew Hanushevsky <[log in to unmask]> wrote:
>
>> OK, I have a working version that uses keepalive by default but I am still concerned that merely turning on that as a default is a major change in the way things work. Yes, you now will have an option nokeepalive as well as a "kaparms" to set the keepalive values (well, only for Linux). Given my apprehension, I am considering adding a command line option (say -A) that says keepalive should be the default. That at least allows diffrentiation between xrootd and cmsd (the cmsd doesn't really benefit from a keepalive setting). The default distribution could add the -A option in the start up script to use keepalive as a default. The benefit is that this approach allows a quick reversion to the old defaults without requiring a config file change should keepalive cause a problem.
>>
>> So, what do people think about this approach?
>>
>
> I'm not sure I follow the logic. Here are the cases I'm thinking about:
> 1) We decide to keep keepalive by default, but a single sysadmin doesn't like it. Sysadmin must take action to turn it off.
> 2) We decide to back out the keepalive by default.
>
> (1) is covered regardless by the "nokeepalive" option you mention above. For (2), I think the two are equivalent:
> (a) Distributors make a release removing the "-A" option.
> (b) Distributors make a release which reverts the code change.
>
> Either way a new release is required, right? My thoughts is that, if a new release is required regardless, we might as well reduce the command line options and do everything via code.
>
> Or perhaps there's an angle I'm missing? I do often miss things...
>
>> Andy
>>
>> P.S. Doing this and keeping ABI compatability for XrdNetSocket was an interesting excersise.
>>
>
> C++ ABI compatibility issues make me sad inside:
>
> https://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++
>
> There's at least a few folks working on making ABI issues easier to detect (https://sourceware.org/libabigail/).
>
> Brian
>
>
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1
|