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

[Tim St Clair <tstclair@xxxxxxxxxx>]

inline 

----- Original Message -----
> From: "Brian Bockelman" <bbockelm@xxxxxxxxxxx>
> To: "Erik Paulson" <epaulson@xxxxxxxxxxxx>
> Cc: condor-devel@xxxxxxxxxxx
> Sent: Tuesday, June 25, 2013 3:45:34 PM
> Subject: Re: [HTCondor-devel] idle thoughts: json as classads
> 
> 
> 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.

They are?  Last I looked they were not so flexible, but if I'm wrong I would love to know. 
>From what I've seen it would have to be a string block w/ escaping. 

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

This is a shame. 

> 
> 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
> _______________________________________________
> HTCondor-devel mailing list
> HTCondor-devel@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/htcondor-devel