Closed Bug 35889 Opened 22 years ago Closed 22 years ago
[RFE] Add a scriptable XML-RPC XPCOM component
Add a XML-RPC client component, so's we can call remote server procedures.
Adding people to CC list per req. of waterson.
<g> Our radar will have to see it as well of course.
Adding some ppl to CC list
Adding warren 2
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.
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.