Hi all,

  well, right now I am unable to see a clear reason for this. Let's 
discuss it. Those values were supposed to be in general "arbitrary", in 
the sense that normally it has no sense at all to modify e.g., a timeout 
value. It is 60 sec, but 90 or 120 makes very little difference if you 
are using the software in a plain way.

  The direction I'd like to look at is a direction where one has no need 
to tweak with strange parameters to have a nice xrootd experience.

The dreamable solution is that the client manages its "crucial" 
parameters by itself (e.g. the cache block size or the number of 
parallel streams). For instance, we were recently planning the 
implementation of the multistream xfers, and we totally agreed on the 
fact that the client has to calculate (and adjust) internally this 
parameter with no need for intervention. Why would one want to modify a 
parameter that works?
The consequence of your proposal is instead a multiplication of the 
parameters, so I am a bit puzzled. Can you give some use cases where 
such a functionality is mandatory? Where for mandatory I intend that a 
*real* test fails (or performs poorly) with value X=default and succeeds 
with value Y. Right now I am unable to wonder such a situation.

  The other direction I am looking at is the reduction of the global 
overhead. I will work heavily on that, since there are many aspects that 
are worth an optimization.
Right now the most frequently used parameters are read from the env only 
in the ctor, in order to avoid a mess of accesses to string-based hash 
tables. Every time I find a parameter which is read too many times per 
single transaction, I wonder if I can move it to the ctor (and loose the 
possibility to change it at runtime). Asking for the ability of 
generically modifying param values during the use of a single instance 
of the client (or a connection) would raise a lot this overhead for sure.


Derek Feichtinger wrote:
> Hi, Gerri and Fabrizio
>> Yes, as it is now TXNetFile allows only one set of globally-set config
>> options.
>> I remember a brief discussion we had Fabrizio and I once on this, but then
>> nothing has been done.
>> As this may be relevant also for  'xrdcp',  perhaps  we should introduce
>> the possibility to define 'per host' rules in a config file checked by
>> XrdClient,
>> making use of the existing 'if-then' infrastructure used for server
>> directives.
>> What do you think?
> That sounds good. But even on top of that it would be nice to be able to set 
> the options per connection. Maybe the logic of my program wants to check 
> fast, whether it can access certain non critical files, but still I want to 
> have more stringent settings for critical files. If I use threads, the gEnv 
> way would force me to introduce mutexes (by the way: what happens in the case 
> of async connections, when I change the options while they are still in 
> process?).
> Cheers,
> Derek