35889 - [RFE] Add a scriptable XML-RPC XPCOM component.

Status: VERIFIED FIXED

(Core :: XML, enhancement, P3)

Description

[Martijn Pieters]

Add a XML-RPC client component, so's we can call remote server procedures.

Comment 1

[Martijn Pieters]

Attachment: Proposed interfaces

Comment 2

[Martijn Pieters]

Adding people to CC list per req. of waterson.

Comment 3

[Martijn Pieters]

<g> Our radar will have to see it as well of course.

Comment 4

[ruslan]

Adding some ppl to CC list

Comment 5

[ruslan]

Adding warren 2

Comment 6

[Martijn Pieters]

Attachment: Implemented interfaces, tgz.

Comment 7

[Martijn Pieters]

Attachment: Implementation

Comment 8

[Martijn Pieters]

Attached implementation works, except for XmlRpcClient::call. See bug #37913.

Extract the tarball into the components subdirectory, and force a an
autoregistration of components and interfaces. One way is to rm both
component.reg and components/xpti.dat.

I am now looking into integrating this into the build system, and after review
this will be checked in.

Comment 9

[Warren Harris]

Hmmm. Why do we want to do this now?

Also, nsIDictionary is almost exactly nsIProperties. nsIXmlRpcClient looks a 
lot like an xpconnect interface. We'll get more leverage if we consolidate.

Cc'ing jband.

Comment 10

[ruslan]

I'd suggest to keep it separate for now. The type system for XML-RPCs is 
evolving very fast.

Comment 11

[Warren Harris]

Bad reason. Make them the same until there's a really good reason to be 
different.

Comment 12

[Martijn Pieters]

Warren: I need XML-RPC support for ZopeStudio now. I agree that RPC could/should
be a part of XPCOM, but would you use XML-RPC as the underlying protocol? W3C
only recenetly started discussing requirements for such protocols, you'd have to
wait a long time before any standard from them. I can't wait that long. 

I could just bundle this component with Zope Studio, but seeing the attention
this bug has been getting (11 votes, 12 email addresses on the CC list), I think
I am not the only one needing this. If a pluggable RPC architecture is devised
for Moz, we can always fold XML-RPC into that.

I was unaware of nsIProperties. If I can get an enumeration or array of the
defined properties, I'll gladly switch to that interface instead. If I knew how
to return a nsIQueryResult from a JS component, I could base nsIDictionary on
nsIProperties and only add the enumeration. Does XPConnect translate for me if I
just return the result of a QueryInterface call?

Ruslan: XML-RPC is frozen, there will be no changes to the spec, types will not
change. SOAP 1.1 has just been released, maybe you were thinking of that? SOAP
!= XML-RPC. SOAP was developed by the same authors (together with some new
people), and as such can be seen as a successor. XML-RPC is vastly more simple
and therefor in widespread use.

Comment 13

[Martijn Pieters]

Sidenote: The ProgIDs of both components will have to be changed, but as long as
bug #37275 is under discussion this can wait. I don't want to have to change
ProgIDs twice.

Comment 14

[Warren Harris]

Seems like if xml-rpc is evolving pretty fast, it might be a bad thing to 
standardize on. And if it's relatively new, it's probably also a bad thing to 
standardize on since there's no experience with it. Does it handle distributed 
transactions, for instance?

Finally, since this is not a requirement for Netscape's product plans, we can't 
be responsible for it in the short term. If you want to contribute it, we can't 
stop you, but our engineers need to focus on getting seamonkey out right now, 
or the mozilla codebase is a lot less interesting to the world.

Moving to FUTURE milestone.

Comment 15

[edd]

XML-RPC, the protocol, is pretty stable, and not changing. Support for it is
built into Zope and quite a few other released products. XML-RPC's been in its
current form for the best part of two years.

Support for XML-RPC in Mozilla would make it a leading contender as an
application platform, enabling a standard way of doing out of band server
transactions.

(What /is/ evolving rapidly is the SOAP protocol, a fancy version of XML-RPC
that doesn't look as though it would be sensible to implement for a while yet.
We'll doubtless find out more at WWW9).

Comment 16

[Martijn Pieters]

Warren: This particular bug is about the frozen standard XML-RPC
(http://www.xmlrpc.com/), not about RPC protocols in general. If people want
more general RPC support, a new bug should be opened.

The implementation is ready, I only need to integrate it with the Moz build
system (shouldn't be hard, all JS). This is a simple XPConnect component,
Mozilla needn't standardize on this particular RPC standard at all. Also, I
wasn't expecting any Netscape engineer focus.

I had changed this to M16 because I was planning to have everything checked in
and ready by then. If this is incorrect usage of the Target Milestone
indicator,could you elaborate? Changing it back for now.

Comment 17

[Martijn Pieters]

Component has been checked in, and is now part of the default build on all
platforms. For a quick test, look in extensions/xml-rpc/test, and follow the
README therein. For those not pulling source, see LXR: 
  http://lxr.mozilla.org/seamonkey/source/extensions/xml-rpc/test/

If may see a bunch of asserts about Atoms, thread-safety and refcounts, sspitzer
and ruslan are looking into those. This component reveils a flaw elsewhere, they
ar not caused by a bug in my code (as far as we could tell).

Happy RPC-ing!

Comment 18

[bergie]

Adding myself to Cc. This feature would make creating a Mozilla-based
administration interface to Midgard much easier.

Comment 19

[Martijn Pieters]

Component is part of the default build and is installed with the core browser.
If anyone has tried it out and found it working, please feel free to mark
VERIFIED. If you don't have the priviliges to do so, just add a comment with
'Verified on <platform>' here.

Comment 20

[R. Saravanan]

Verified component on Linux. This is really cool. I'm going to write some
Javascript to allow command line access to XML-RPC on XMLterm (synchronous).
Could anybody point me to info on XML-RPC servers that return more interesting
stuff than state names?

Thanks
(Added myself to CC list)

Comment 21

[Taras Tielkes]

Any chance components like these could be exposed to client script on web pages 
in a safe way? It would be very useful to load and post data from the 
originating host.

Comment 22

[Martijn Pieters]

Note that synchronous usage of the component is still broken, bug #37913. A fix
seems imminent though. That said, a command line interface would be extremely
cool, of course =) Ask around on www.xmlrpc.com, I'd say.

I cannot speak for allowing remote scripts easy access to this component.
Currently such a script would have to explicitly request access to XPConnect,
which would also give that script access to the filesystem. I assume that more
finegrained control will be available at some point.

I don't think that this bug entry is the place to ask questions regarding the
usage of XML-RPC though. Please use newsgroups like netscape.public.mozilla.xml,
.xpcom and .security for this kind of thing. See
http://www.mozilla.org/community.html.

Comment 23

[Christine Hoffman]

Marking this bug fixed in terms of implementation. Bugs with implementation 
should be written up separately.