On 6/26/2013 9:51 AM, Alain Roy wrote:
On Jun 25, 2013, at 1:45 PM, Brian Bockelman <bbockelm@xxxxxxxxxxx> wrote:
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...
Maybe what Erik is really hoping for is a modern API to Condor that is easier to use. JSON ClassAds (if there was a nice way to pull them off) would be one step towards a RESTful API.
At one level, chasing the latest RPC style for an API isn't worth the time. On the other hand, there are some pretty significant toolsets that can help people build on top of a RESTful API. There are lots of Javascript libraries that make it easier to use REST and JSON to build a UI. It's also easier to consume as a client in other environments when building tools. That said, I understand that it may not be the top priority for Condor.
-alain
Pithy comments:
SOAP is still supported, both native in the schedd and collector and
also via the Aviary contrib.
A RESTful interface is available via the CondorAgent contrib.
Also not clear that the browser is the most important client environment
-vs- a scripting environment widely used in scientific computing like
Python.... and HTCondor v8.0.0 now includes Python client packages that
are built on top of libcondorapi.
-Todd
p.s. awesome to have west-coast Dr Roy in the discussion!
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}