{section: Conversion to New ClassAds}

This is part of ticket #187.
See #227 for benchmark comparisons.

{subsection: Analysis of Condor's use of old ClassAds}
*: {wiki: OldClassAdUsageSummary Old ClassAd usage summary} -
A summary of the number of call sites in the Condor code for each Old {quote:ClassAds} method.

*: {wiki: OldClassAdUsageDetails Old ClassAd usage details} -
Details of the number of call sites in the Condor code for each Old {quote:ClassAds} method, and where it's called from.

*: The wiki code for the individual calls is available in /p/condor/workspaces/nleroy/OldClassAdWiki -- the summary and detail files above are in there, as well as the code for each of the above, each in it's own file.

*: {wiki: ClassAdConversionTodo Conversion TODO list}

{subsection: Additional conversion info}
{subsubsection: Compatibility Class}
To ease the transition to new {quote:ClassAds}, we will create compatibility methods that mimic the interface of old {quote:ClassAds}. We will put these methods in a child class to new {quote:ClassAds} called {quote:CompatClassAd}. This child class will be part of the Condor C++ utility library. This leaves the new {quote:ClassAds} library completely independent of other Condor code.

Methods with more than a dozen or so callsites will be emulated in {quote:CompatClassAd} when feasible. Some methods, particularly those dealing with {quote:ExprTrees}, cannot be emulated easily, and the callsites will have to be modified. Once the initial transition is complete, we can update callsites at our leisure, with a large dose of student work, until {quote:CompatClassAd} is no longer needed.

{subsubsection: ClassAd Functions}
There are some {quote:ClassAd} functions that exist in old {quote:ClassAds} but not new {quote:ClassAds}. These are ones based on Condor's {quote:StringList} class and provide a poor man's list functionality in old {quote:ClassAds}, by allowing a single string to be interpreted as a comma-separated list of items. We should support these functions in new {quote:ClassAds}.

{subsubsection: Direct use of ExprTree}
Many parts of the code do the following to evaluate an expression in the context of a {quote:ClassAd}:
*: Parse() to create an {quote:ExprTree}
*: ExprTree::EvalTree() to evaluate it against an ad
*: Examine the resulting {quote:ExprResult} object

These need to be converted to the following sequence:
*: ClassAdParser::ParseExpression()
*: ExprTree::SetParentScope()
*: ExprTree::Evaluate()
*: Examine the resulting Value object

This work can probably be done mostly by a student. We can also write compatibility versions of Parse() and EvalTree().

In new {quote:ClassAds}, there is no assignment operator inside an {quote:ExprTree}. A {quote:ClassAd} contains a list of attribute name and {quote:ExprTree} pairs. Any code in Condor that's directly inserting or extracting {quote:ExprTree}'s from a {quote:ClassAd} will need to be updated.

{subsubsection: ClassAdList}
There is no equivalent to the {quote:ClassAdList} class in new {quote:ClassAds}. We propose writing a compatibility {quote:ClassAdList} that's a simple wrapper around an STL vector of {quote:ClassAd} pointers. We would emulate the interface of the old {quote:ClassAdList}, but not the reference counting. Nowhere do we put the same {quote:ClassAd} into multiple {quote:ClassAdLists}.

In a couple places (matchmaker.cpp and condor_query.cpp), we move an ad from one list to another. For these locations, we'll need to add a method to allow movement without deletion.

{subsubsection: STL Exceptions}
Do we need to worry about handling exceptions from STL objects?

{subsubsection: Chained Ads}
New {quote:ClassAds} support chaining, but the iterators ignore them. The chained ad can be referenced explicitly by callers where it matters.

{subsubsection: Warnings}
It would be nice to emit warnings whereever the compatibility functions are invoked, so that we don't forget to convert them eventually.

{subsubsection: Invisible Attributes}
Old {quote:ClassAds} support the notion of private attributes that can be marked invisible when exporting an ad. The set of invisible attributes is static and invisibility is only done for the put() and dPrint() calls, so we can handle this strictly in the compatibility functions.

{subsubsection: String Escaping}
String escaping is different between new and old {quote:ClassAds}.
With a couple minor tweaks, the compatibility functions will use the old {quote:ClassAd} escaping rules. The new parser would continue to use the new escaping rules. We'll have to be careful when changing existing code to call the new methods, especially when parsing expressions taken from a user.

{subsubsection: String Classes}
New {quote:ClassAds} use std::string while old {quote:ClassAds} use {quote:MyString}. The compatibility functions can accept {quote:MyString} where appropriate. But as new code is written or old code is converted, they will have to start using std::string.