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

[Laurent Aphecetche <aphecetc@xxxxxxxx>]

Alain Aslag Roy wrote:
> 
>> 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.
> 
> 
> Laurent, thank you for your input! We are always delighted to have more 
> examples of where people are using ClassAds.
> 
>> 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.


> Is there any relation to the resource broker used in the EDG, or is this 
> totally independent work.

That's a somewhat parellel work I would say, and a somewhat opposite 
job<->machine relationship (EDG resource broker, as far as I know, 
pushes jobs to machines whereas AliEn broker uses a pull model where 
machines request for jobs).

> Also, how did you write the Perl wrapper? I've been meaning to make that 
> easier for people, but I haven't had a chance to do it. I was thinking 
> about using SWIG and extending the c interfacein cclassad.c.

I did use SWIG to make the wrapper. It's not a complete wrapper though 
(I did not directly wrapped ClassAd class but a mere Classad adapter 
class with only the methods I needed).

>> The idea is to use ClassAds to make generic object factories.
> 
> 
> I'm not sure I completely understand, but this sounds very interesting!
> 
>> 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
> 
> 
> Yes, I am happy to try to make everything more portable. We are happy to 
> see ClassAds being more widely used, and would like to encourage it.
> 
> Given other things in my schedule, it's not likely to happen for a month 
> or two. If you wish to make some nice modifications to the code to make 
> it more portable in a pretty way, I would be happy to take your 
> submissions and add them to the ClassAd library. Otherwise, it will be 
> on my medium-term to do list.
> 
> Are there any other issues you have had with the SunPro compiler, or is 
> it just the hash_map? We also use another non-standard STL container 
> class (I forget which one off the top of my head, and I'm writing this 
> without Internet access.

Yep, it's <slist> (I simply replaced it with <list>).
BTW, I assume you did choose hash_map versus map for performance reason. 
Had you timed the difference or not ? Also, what's the typical usage of 
your maps : as many insertions as lookup or more probably much more 
lookups -in matching I guess- than inserts ? In the latter case I think 
some AssocVector stuff would be the portable way to consider (see e.g. 
Loki C++ Design or Meyers Effective STL books).

>> 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 ;-))
> 
> 
> Yes, I'll try to do this. It's a bit of a hassle, because I have to deal 
> with CVS, but it's clearly important to do, so I will do it.
> 

Thanks.

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/