{section: Conversion to New ClassAds}

This is part of ticket #187.

{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.

{subsection: Additional conversion info}
{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.

{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 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.