rest protocol definition

[petr-tik]

As suggested by @jbcoe in FFIG/ffig#77,
The API will receive and send the following JSON:

request:

{
  "translation_unit": "class A { int x_; public: int getX() const { return x_; } void setX(int x) { x_ = x; } };",
  "bindings": ["ruby", "python"],
  "module": "TestModule"
}

response:

{
  "TestModule.py" : " ... ",
  "TestModule.rb" : " ... ",
  "TestModule_c.cpp" : " ... ",
  "TestModule_c.h" : " ... "
}

I was thinking, it's better to make separate requests for each binding.

Thoughts?

[petr-tik]

Also, the above spec implies that the client will turn source file into a translation unit.

Why not pass the whole source file in the POST request?

request:

{
  "translation_unit": 
"#ifdef __clang__
#define C_API __attribute__((annotate("GENERATE_C_API")))
#else
#define C_API
#endif

struct Asset
{
  virtual double PV() const = 0;
  virtual const char* name() const = 0;
  virtual ~Asset() = default;
} C_API;

struct CDO : Asset
{
  CDO() {}

  double PV() const override { return 0.0; }
  const char* name() const override { return "CDO"; }
};",
  "binding": "python",
  "module": "TestAsset"
}

[ajbennieston]

Separate requests for each binding would mean building the clang AST and ffig code model repeatedly, would it not?

[jbcoe]

It would and would be best avoided

[petr-tik]

What about caching results?

[jbcoe]

Seems unnecessary. What are the advantages over the wide REST API as proposed?

[petr-tik]

ok. Just to clarify on my second point.

From what I understand, the api will receive translation units and I thought it's best to use the whole of FFIG. Send the source file and generate TU on server.

what am I missing?

[jbcoe]

The user may have some of the headers so will need to locally construct the TU

[petr-tik]

What about restricting to standard headers?

[petr-tik]

Also, if you want to POST requests with translation units, it would be great to refactor ffig.main, so we can enter it from TU stage.

[jbcoe]

If we restrict to standard headers we can take source. Let's get something working first and nuance it later