Re: [Tsp-devel] XMLRPC command channel status

[Eric Noulard]

2008/2/6, Yves DUF <address@hidden>:
> Just to enlight the results of theses removing, and correct me if I'm wrong
> :
>  - C based consumers will only be able to use ONCRPC channel.

Currently yes.

> - Ruby and other nices scripts consumers will use XMLRPC.

Yes unless there is ONCRPC lib for the concerned language.

> - Java will stay based on RemoteTea, so ONCRPC.

Yes.

> - Providers will be able to answer both and more.

Yes.

> For the Ruby, Java, or Provider side that sounds perfect.
> But for the C consumers, something slighty annoy me. The ONCRPC port to
> windows was quite painful (not for me, but for theses marvelous hackers that 
> did it)

It was not "that" painful, it was mainly because we did not
plan to hack oncrpc lib.
The painful thing is rpcgen is not working on Windows so that
we need to generate rpc stubs on linux, hack the files "manually"
and use them on windows, how nice  :(

See
tsp/src/core/rpc/*.win32 files ...

That's why would say that I would personally like to get rid of both
ONCRPC and XMLRPC and use a "pure socket" command channel
with custom generated C code for TSP request encoding.

Fred Deweerdt initiate some work with an ANTLR which as far as
I know is in stand by for now.
This would be easier for embedded target AND for the portability.
If we had OUR tspcmd_gen (instead of rpcgen) we would be
able to easily _generate_ code for ANY kind of command channel
(ONCRPC, XMLRPC, pure socket etc..) for many languages (C, Ruby,
Python, Java)...
on many platforms.

That's some work but it would be of great interest (at least to me),
even for non TSP usage.

>  We could imagine that TSP compilation under Vista might
> raise some new difficulties :=)

I doubt it since besides security issues with portmap and oncrpc
 the ONCRPC code is plain C with no tricks.

Did anyone tried a Vista/MSVC compilation?

> Won't we regret the XMLRPC in that case ?

May be you are right.
But if anyone regrets that he can take the last commited code
from the CVS history and begin with that.

I found it better than having dead code in the tree
-- 
Erk