Code::Blocks Forums
Developer forums (C::B DEVELOPMENT STRICTLY!) => Plugins development => Topic started by: dmoore on December 03, 2007, 03:20:48 am
-
After a long break from CB coding, I'm planning to resume work on my Python plugin in the near future. The next step is to provide a communication path to python processes. This will allow me to offer features like symbol browsing for python code, a python interpreter as a dockable window etc. My first instinct was to try embedding python within a CB plugin. The problem is python embedding is a bit of a mess and it's very difficult to create multiple instances of the interpreter within a single process. On the python list the general recommendation is to avoid embedding and use inter process communication on one or more python process.
I've decided that it will be better to use something like XML RPC to communicate with either locally or remotely spawned Python processes. In the case of Python, XML RPC is a good choice because python provides an XML RPC library in the standard package. Presumably, using XML RPC I could create python intepreter and symbol browser servers, which would take requests over XML RPC from my CB python plugin.
Does anyone know of a good multi-platform implementation of XML RPC? Or perhaps there are better alternatives to XML RPC?
Beyond python I could see that there might be many applications of XML RPC (or related protocols) to CB plugins, especially in the embedded device world. Anyway, I'm just putting these ideas out here in case others might have some valuable input.
-
Zeroc ICE
boost.asio
gSoap
-
ICE looks interesting, especially if it supports all of the platforms and languages that it claims. Do you have experience with or preferences over your suggestions, gvv?
-
After a long break from CB coding, I'm planning to resume work on my Python plugin in the near future. The next step is to provide a communication path to python processes.
<offtopic> Hooray! :-) </offtopic>
-
It depends:
1) if your decision is to buy albeit use existing software then ICE IMHO is the best, good documentation, heaps of examples, good forum and it works first time out of the box. (no build in mingw yet - i had to test it in linux, i dont know how to use VC++)
2) if your decision is to make then boost.asio could be used as your base. (I am not sure about boost.asio and python re boost.python)
3) if you still insist on XML RPC then gSoap claims to be the fastest (not sure again about python). The only problem is documentation, you have to look under the hood to find out what is happening.
Sorry but I am basing my opinion in c++ not python.
-
gvv: As you say ICE looks the easiest to use, most portable and is the best documented. Now I understand that ICE is GPLed, so there should be no licensing issues for my open source application, right? (Maybe I missed what you mean by buy vs make?)
morten: don't hold your breath waiting. I've no idea how long this will take, but everything will make it into the project SVN.
-
buy vs make decision.
What I mean was:
buy - to use an existing product.
make - to write it from scratch.
-
If you don't think that spawning remotely is that important then I 'd throw dbus on the table.
-
yes, in the case of my python plugin i doubt that remote access is critical. although it is nice to think that you could access a python interpreter on a remote host by simply changing an address/port setting in the IDE.
the constraint is it has to work on both linux and win32 (well... it doesn't really but it would be a pain to have to manage code for two sets of protocols). does d-bus work acceptably on win32?
at the other extreme i can continue to use pipes as I did for the python debugger. I just wish there was better process management in wxWidgets. For example, a symbol browser should run as a very low priority python process (it's easy to parse the syntax tree of arbitrary python code in python) but I don't see how to set process priority that from wxwidgets.
BTW, A guy on the zeroc forums announced that he has almost got a mingw/gcc port of ice working (one unit test fails).
-
does d-bus work acceptably on win32?
There is a lot of work on it from the kde guys trying to get the windows port of kde. Check this (http://www.freedesktop.org/wiki/Software/dbus#head-04cafb2f7bd8608683af50dbaa089106271c8e9d)
-
thinking some more on this topic, at least in the short term I'm coming to conclusion that for my particular application using sockets makes the most sense:
1. supported in wxWidgets for windows and unix -- see wxSocketClient/wxSocketServer
2. supported in python in the standard libraries on windows and unix
3. simple API, just like pipes
4. unlike the implementation of pipes in python, bidirectional socket communication just works
5. I still get the option of remote communication
I can always port to something like ICE later on if I find I need the interface specification language, server side helper code etc...
-
I'm coming to conclusion that for my particular application using sockets makes the most sense:
You hopefully know what that means for users on Windows with a firewall? The firewall will start barking at C::B due to "phoning home" if you do so. This is not a no-go but keep in mind that C::B is often used by noobs that might just simply block the traffic or kill C::B and blame us writing viruses that phone home (to be dramatic). ;-)
-
Morten: I suspect this would apply to any RPC-based solution. I've seen the Netbeans IDE throw up firewall warnings, but that usually only happens once after installation. Would it be any different in the case of CB? Obviously users with more stringent firewall policies will have problems.
the bigger issue with a low level solution like piped processes or sockets is going to be dealing with unicode strings and other complex data types.
-
I have played around with ICE's Python and C++ versions on Linux. I can say they do indeed work, but I haven't yet used them in an application.
-
thought I'd return to this very old thread to say: xmlrpc++ for the win (http://xmlrpcpp.sourceforge.net/). far from perfect, but it gets the job done and I'm now looking at three (very crude) windowed python interpreters in my C::B session.