Closed Bug 35889 Opened 22 years ago Closed 22 years ago

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

Categories

(Core :: XML, enhancement, P3)

enhancement

Tracking

()

VERIFIED FIXED

People

(Reporter: mj, Assigned: mj)

Details

Attachments

(3 files)

2.89 KB, application/x-compressed
Details
2.88 KB, application/x-compressed
Details
11.95 KB, application/x-compressed
Details
Add a XML-RPC client component, so's we can call remote server procedures.
Status: NEW → ASSIGNED
Attached file Proposed interfaces
Adding people to CC list per req. of waterson.
<g> Our radar will have to see it as well of course.
Keywords: zopestudio
Adding some ppl to CC list
Adding warren 2
Attached file Implementation
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.
Target Milestone: --- → M16
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.
I'd suggest to keep it separate for now. The type system for XML-RPCs is 
evolving very fast.
Bad reason. Make them the same until there's a really good reason to be 
different.
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.
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.
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.
Target Milestone: M16 → Future
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).
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.
Target Milestone: Future → M16
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!
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Adding myself to Cc. This feature would make creating a Mozilla-based
administration interface to Midgard much easier.
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.
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)
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.
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.

Marking this bug fixed in terms of implementation. Bugs with implementation 
should be written up separately.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.