Hi Andy,
On Wed, Aug 18, 2004 at 10:36:52PM +0200, [log in to unmask] wrote:
> Thanks for the observations. Some of the things you point out are historical
> in nature, some are there for modularity, and others for portability or
> compatbility. Here are some examples:
>
> > allow host xyz.standford.edu
> >If that is correct, the comment at the start of xallow should point
> >that out. The syntax description does indicate that the host/netgroup
> >argument is optional, but doesn't state the default. Another solution
> >is to make it mandatory.
> Quite correct, the documentation is lacking here. As for making things
> mandatory, many times our hands are tied. There are a lot of config files
> (not necessarily ours) that, for one reason or another, use the implied
> default. Our commitment has been to make any changes upwardly compatible to
> minimize the admin frustration level.
As we discussed earlier this week, personally I think _now_ is really good
time to fix some of these things. The set of BaBar users currently using
xrootd/olbd can probably be convinced to "cleanup" their config files, etc.
as long as you are clear about what changes are being made. It is far better
to rationalize things now, before (hopefully) a much larger community gets
ahold of it then have lots of strange inconsistencies there for "historical"
reasons that in practice do not matter right now.
My suggestion: clean things up now (such as Gregory and I have pointed
out in recent days) and just post a list of the things you've changed so it
is clear to people. They will adjust. We do not care about smooth backward
compatibility with the olbd version used with the AMS/Objy...
Pete
> >If I read the code correctly, the Meter code just execs the
> >monitor process using custom code that looks a lot like a
> >reimplementation of popen().
> Good observation. We've found that popen() is not thread-safe on some
> platforms. We've side-stepped the issue by just doing a thread-safe
> implementation.
>
> > General observations:
> > 1. The configuration file-reading code is effectively replicated 4 times.
> In some sense this is historical as each subcomponent was implemented
> independently of each other. Over time we've converged on a common way of
> doing things. However, other pressing developments pretty much caused us to
> stop at what you see. It may not be the prettiest code but at least it's
> debugged.
>
> > 2. There are several unnecessary casts in the code. Casting variables
> > of type "char *" to (const char *) when passing them as arguments to
> > functions expecting a (const char *) is redundant.
> Well, yes and no. It really depends on the compiler. In trying to support a
> rather lartge set of compilers we've found that some care about constness
> and some don't. I suppose we could mandate the compiler but compilers, like
> editors, fall into religuos territory and we've decided not to enter the
> fray. So far, the only common thing is that they don't seem to care about
> redundant casts when it does occur so that satisfies the compilers that
> simply do a syntactic check for type compatability.
>
> >I hope these are helpful.
> Absolutely, thank you for the suggestions and corrections. As many as we can
> encorporate will go in.
>
> Andy
-------------------------------------------------------------------------
Peter Elmer E-mail: [log in to unmask] Phone: +41 (22) 767-4644
Address: CERN Division PPE, Bat. 32 2C-14, CH-1211 Geneva 23, Switzerland
-------------------------------------------------------------------------
