I would look into Lua and see if there are any libraries available to create a (preferable for your development to make life easy) stand alone rest service.
Once you have a listener fired up in lua within LibreCAD 3 you can start processing the requests with Lua code and execute that against the kernel. Lua is almost already a plugin interface anyways, so that means when LibreCAD 3 fireup, you can communicate with it :) Or leave it out for user's that don't want to have the REST API enabled....
I'll look more into this. I am though a bit biased towards pure C++ work. People won't be dependent upon another language for the same until they personally prefer.
1) I would prefer an API that has the command in it's naming, for example : /api/entry/create_point /api/entry/create_line, /api/entry/create_circle etc... This way they are easer to be maintained, secured aswel.
Seconded! makes much more sense.
2) Think about sending objects instead of how a data structure looks like (as mentioned in your blog post) and let some underlaying framework take care of serialisation of said objects (this way you can create xml, json or whatever else).
Even I was thinking the same. Actually what I was thinking was how will this work with GUI components.
Like if I requested,
3) You might beable to take the objects from LibreCAD 3 itself somewhat how the builder does it's work, you might beable to take this straight from the current lua implementation
For example if there is a Lua rest service that can serialise objects, you can try to see what happens when you serialise something like :
layer = active.proxy.layerByName("0")
c=Circle(Coord(50, 50), 70.7106781, layer);
This should generate some json for you and see if that is suitable (remember I am a java guy and in java this stuff is easy because we reflections) and if that works :)
yes, Java/Go I've seen this for json. I'll see more into this.
first priority will be some REPL ( interactive command prompt ). That will communicate with kernel and write a DXF file. Then I'll write python scripts for the same. :p
Also ries the best part of this work is we can incorporate plugins with a license which we don't like. we just need them to communicate over IPC.
lets say a DWG/DXF library "A" is GPL and we prefer MIT, we might write a program that will parse the DWG/DXF using library "A" and send the data to some socket or HTTP. This can be seperately bundeled and Licensed GPL and distributed.
Our LC already listens on HTTP/socket so can recieve this data though being completely MIT without any problems.
Let me know how it goes,
Sure I'll keep updating.
PS: From looking at https://github.com/gaganjyot/cad_interface
this might not cross compile very well.
Actually I am on a windows platform these days. I'll port it to CMake once I get some POC going good.