Archive of UserLand's first discussion group, started October 5, 1998.

Positional vs. keyword arguments in XML-RPC?

Author:Skip Montanaro
Posted:1/22/1999; 8:56:12 AM
Topic:Positional vs. keyword arguments in XML-RPC?
Msg #:2385
Prev/Next:2384 / 2386

My apologies if this has come up on the discussion list before and been rejected. I'm still pretty new and haven't had the time to work through all the discussion topics on the server yet.

In Python, you can call functions using positional or keyword notation (or a mix of the two). For example, I could define the following silly function:

    def breakfast(eggs=2, ham=0, spam=0, sausage=0, bacon=0):
	meat = spam + ham + sausage + bacon
	return (eggs, meat)

Most people will only want one sort of breakfast meat, so to order breakfast it might be called as

    basic = breakfast(3)		# 3 eggs, rest default to 0
    monty = breakfast(spam=2, eggs=3)
    mcmuffin = breakfast(ham=1, eggs=1)	# the muffin is extra...
    lumberjack = breakfast(6, sausage=3, bacon=3, ham=2)

I believe Perl also supports positional and/or keyword notation. I don't know a thing about Frontier, but it seems that it would be worthwhile to support it in XML-RPC. In terms of the wire protocol, it seems like it would be easy to allow an optional name tag within a param tag:

   
   
      examples.getStateName
         
            
               code
               41

I haven't given any thought to how much this would complicate implementation of libraries or what ramifications it might have for cross-language calling, for example making an RPC call from a client written in Python to a server written in C. I'll leave that for people like Ken MacLeod and Fredrik Lundh to comment on.

Why would it be useful? For me, it means being able to define an interface just once, in the server code. I'm still working on it, but right now because Python is so dynamic, all I need to do on the client side is instantiate xmlrpclib.Server and begin making calls:

    server = xmlrpclib.Server("http://dolphin.calendar.com:8000")
    yum = server.breakfast(3)

To support keyword arguments I will have to reproduce the function definitions in the client that mimic those on the server side. This means I increase the opportunity for error if the client and server interfaces get out of sync.

This is just a thought, and I can obviously live with things as they are. It's something that could be added further downstream as well, since I don't think it would break any client or server code that's currently written (it would require changes to calling libraries).

Skip Montanaro (skip@calendar.com)

There are responses to this message:

This page was archived on 6/13/2001; 4:47:31 PM.

© Copyright 1998-2001 UserLand Software, Inc.