Re: [HTCondor-devel] idle thoughts: json as classads

[Brian Bockelman <bbockelm@xxxxxxxxxxx>]

On Jun 25, 2013, at 2:58 PM, Erik Paulson <epaulson@xxxxxxxxxxxx> wrote:

> I'd like to be able to evaluate a ClassAd anywhere, so I think fixing on a strategy of trying to get evaluations back to the C++ library is a dead-end. Having a JSON object be a valid ClassAd is a win in the "evaluate everywhere" - though maybe all JSON objects are too simple to ever be useful as a ClassAd. 
> 

Yup - this is my concern.

It's nice to have JSON be a subset of ClassAds; to be really useful, I want things to go in the reverse direction - ClassAds be a subset of a more popular serialization language.

> Being able to evaluate a ClassAd everywhere is of course mostly orthogonal to the issue of how is the ClassAd represented, since I could write a ClassAd library in Javascript with the format as-is and make it work. However, I think having a serialization format that is valid JSON gives us the ability to transport and store ClassAds in a whole lot of new systems, and to be to do some rudimentary manipulation of the ClassAd in any language out of the box. Other libraries can look inside the JSON ClassAd and actually do some of the evaluation of the superset when needed. 
> 
> While ClassAds have been occasionally used outside of HTCondor, the uptake was never overwhelming and I think has fallen off (are there any external ClassAd users anymore?). We may have more luck if we started to look a little more like what the rest of the world expects. 
> 

What about ProtoBufs?  They are expressive enough to encapsulate ClassAds.

Unfortunately, most interaction with HTCondor isn't really RPC -- it's an undocumented custom binary protocol with a mix of ClassAds and binary data.  

Having more RPC-like interfaces would be a good goal; the SOAP clients were a good start toward a cross-language API, although the choice of data marshaling (SOAP) was unfortunate...

Brian

Attachment: smime.p7s
Description: S/MIME cryptographic signature