Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

XML RPC for plugins?

<< < (2/3) > >>

dmoore:
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.

gvv:
buy vs make decision.

What I mean was:
buy  - to use an existing product.
make - to write it from scratch.

yop:
If you don't think that spawning remotely is that important then I 'd throw dbus on the table.

dmoore:
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).

yop:

--- Quote from: dmoore on December 04, 2007, 07:15:07 pm ---does d-bus work acceptably on win32?

--- End quote ---

There is a lot of work on it from the kde guys trying to get the windows port of kde. Check this

Navigation

[0] Message Index

[#] Next page

[*] Previous page