[classad-users] What is the future of the ClassAd C++ library ?

[Laurent Aphecetche <aphecetc@xxxxxxxx>]

Hi,

I've seen a message in classad-dev mailing list about this mail title, 
where there's this sentence : "I'm interested in how ClassAds are being 
used now, particularly outside of Condor.  I'd also like to know what 
ClassAd users want from ClassAds. "

So well, as a user of ClassAds, here's my input.

I'm using ClassAds for one project, and planning to use them in another one.

The first one is AliEn (http://alien.cern.ch) which could be summarized 
as a mini data grid for the CERN Experiment ALICE 
(http://alice.web.cern.ch/Alice/). There ClassAds are used to make 
matchmaking between jobs and machines, i.e. their natural way I would 
say (only "originality" is that as AliEn is written in PERL, I wrote a 
PERL module for wrapping C++ ClassAd  library). So far we are very happy 
with what ClassAds provide.

The second project in which I intend to use ClassAds is PHENIX (again a 
high energy physics experiment, this time in USA 
http://www.phenix.bnl.gov). Here the usage is probably more unusual.

The idea is to use ClassAds to make generic object factories. In PHENIX 
software, we happen to need to create some objects depending on a set of 
conditions (expressed by some attributes, e.g. simulation=1, 
runnumber=28567, tag="test_prod_v1", etc...). What I would like to do 
then is something like :

class XFactory
{
   X* create(const ClassAd& conditions);
   bool registerCreator(const ClassAd& requirements, X* (*)(const 
ClassAd&));
};

and in *user* code the only interfaces exposed are those of the base 
class  X, and that of the XFactory, e.g.

ClassAd conditions("[ simulationflag=1; runnumber=250; ]");

X* x = XFactory::instance()->create(conditions);

Now, *developpers* that want to provide concrete instances of X subtypes 
will register their object creator to the factory, specifying (using a 
classad with some requirements) upon which set of conditions this 
creator will be picked up :

class X1 : public X {}

X1* creatorX1(const ClassAd& cond) { e.g. return new X1(cond); }

ClassAd requirements("[ Requirements = other.simulationflag > 0 && 
other.runnumber < 40000 ]");

XFactory::instance()->registerCreator(requirements,creatorX1);

So far so good. I already have a prototype implementation that is 
working fine, at least on Linux using gcc-2.95.3. Now here's the time 
for the requests ;-)

I would really like to see the C++ ClassAd library being developped for 
more portability. Our PHENIX code strives to run on as many compilers 
pairs as possible. One of such is Sun Workshop Pro 6. I tried to use 
ClassAd 0.9.4 and got a hard time to get it working (I had to clutter 
the code with stuff like :

#ifdef _DO_NOT_HAVE_HASHMAP
typedef std::map<std::string, ExprTree*, CaseIgnLTStr> AttrList;
#else
typedef std::hash_map<std::string, ExprTree*, StringCaseIgnHash, 
CaseIgnEqStr> AttrList;
#endif

to bypass the fact that hash_map is *not* provided by this STL 
implementation, which is of no surprise as it is *not* part of the C++ 
Standard (though it was in the original SGI STL implementation).

I you could come up with a better solution, or at least incorporate it 
in your developpement so the next versions will run on SunPro, I would 
be grateful !

Also, as I already requested in a previous mail, it would be very 
convenient to prefix all the ClassAd source code (at least the .h that 
get installed), so naming clashes won't happen (which is currently very 
likely in a big project that would use the library as it is now, due 
e.g. to common.h ;-))

OK, that's it. Thank you for your attention and sorry for the long mail.

Regards,

-- 
Dr. Laurent APHECETCHE (mailto:aphecetc@xxxxxxxx) (IN2P3-CNRS)
SUBATECH-EMN-4 rue Alfred Kastler-BP 20722-44307 NANTES cedex 03
TEL (+33/0) 2 51 85 84 17 - FAX (+33/0) 2 51 85 84 24 (France)
Collaboration PHENIX http://www.phenix.bnl.gov/~aphecetc

Condor Classads Info:
http://www.cs.wisc.edu/condor/classad/