[Zope] xmlrpc calls require string results?
Dan Pierson
dan@remote.control.com
Thu, 4 Nov 1999 17:14:23 -0500
I'm using xmlrpclib from a standalone Python script to post articles to
Squishdot. It seems that calls to methods that return strings work fine,
while calls to other methods fail with tracebacks like the following:
Traceback (innermost last):
File "./postToControlCom.py", line 77, in ?
postMessage(msg)
File "./postToControlCom.py", line 68, in postMessage
summary, subject, "Automation List")
File "./xmlrpclib.py", line 547, in __call__
return self.__send(self.__name, args)
File "./xmlrpclib.py", line 630, in __request
request
File "./xmlrpclib.py", line 582, in request
headers
xmlrpclib.ProtocolError: <ProtocolError for silver.control.com/zope/: 500
Internal Server Error>
This sort of thing seems to happen no matter what the non-string return type
is. In the case above, the difference between the following code (which
works) and the failing code is exactly the rather bogus last line: "return
'Done'".
The code is in zope as an External Method (since I can't use xmlrpc to do
the same thing from my script).
def postSquishdotReply(self, title, author, body, email='', notify='',
file='',
summary='', subject='', dept='',
REQUEST=None, RESPONSE=None):
results = self.__call__({'title':title, 'subject':subject,
'op':'articles'})
if len(results):
# If there are multiple Articles with the same title and subject,
# just use the first one.
article = results[0]
article.addPosting(title, author, body, email, notify, file,
REQUEST, RESPONSE)
else:
self.addPosting(title, author, body, email, notify, file,
summary, subject, dept, REQUEST, RESPONSE)
# It appears that calls via xmlrpclib throw:
# xmlrpclib.ProtocolError:
# <ProtocolError for silver.control.com/zope/: 500 Internal Server
Error>
# if a method called by it doesn't return a string.
# This is bogus, but:
return 'Done'
BTW: all of this appears to me to be true whether or not Squishdot is
involved -- I have tested with target methods that are not part of it.
What am I doing wrong here?
Dan Pierson, Control Technology Corporation, <dan@control.com>