Re: ANN: LuaXMLRPC 1.0 Alpha

[Jay Carlson <nop@...>]

On Mon, 12 Jan 2004, Andre Carregal wrote:

> Hi,
>
> The Kepler Project has released the first alpha of LuaXMLRPC 1.0.

That's funny, I thought I released the first alpha of Lua XML-RPC
around two years ago.

See http://lua-users.org/lists/lua-l/2001-11/msg00403.html .

Yours appears better written.  But from the folks who used to be
touchy about anybody else reusing the name "lua", the reuse of
somebody else's existing name amuses me. :-)

One of the first lines in xmlrpc.lua is

  require "dom"

and I can't find that file.  I am of course quite curious about its
contents, as I can't reverse-engineer how you're mapping attributes
into Lua from reading xmlrpc.lua :-)

We may want to avoid the name "dom" for anything that doesn't bear a
close resemblance to the W3C DOM.

How are you handling encoding the Lua string "<"?  (This is why I
generate everything in the form of node trees.  That way all of the
logic in properly quoting strings into whatever their context is
centralized in the node marshaller, rather than something smeared all
over your code, waiting for you to forget.)

How do I send the XML-RPC <array> example given in the specification?

  <array>
    <data>
      <value><i4>12</i4></value>
      <value><string>Egypt</string></value>
      <value><boolean>0</boolean></value>
      <value><i4>-31</i4></value>
    </data>
  </array>

I think treating Lua tables with 1-valued keys as XML-RPC arrays makes
more sense than requiring special handling.  Users may get a big
surprise when writing natural Lua code that deals with Lua's
conventions for arrays, and end up with XML-RPC structs instead.  In
the worst case, your code can generate invalid XML-RPC from something
like

  {[1]='a', ["1"]='b'}

aka

  {'a', ["1"]='b'}

The situation for the array mapping is better in Lua 5.0.  In Lua
4.0, there was the nasty problem of transmitting an XML-RPC array that
started with false, as "nil" was the natural mapping for false, and
you couldn't distinguish {} from {nil}.

This morning in the shower I decided I was going to get more picky
about how my binding dealt with <i4>s.  Sending non-integral numbers
would result in an error (unless flagged with XMLRPC.double(3.14));
receipt of non-integral numbers in an <i4> would also result in an
error.

This evening while driving home I decided this might be a bit too
picky for some people, and maybe I should allow mapping non-integral
numbers to <double>s.  Although there could be a VM-wide setting like
my undocumented XMLRPC.strict that controls this, I think this is more
naturally an attribute of either the local proxy for each
server/method, or of the registration of functions.  Something like

  XMLRPC.register("foo.bar", {strict_numbers=false, utf8=true})

except somehow using tables.

Speaking of local proxies, you *know* you want to add the sugar so you
can do

  betty = XMLRPC.Server("http://betty.userland.com/RPC2";)
  betty.examples.getStateName(41)

It may not be a good idea, but it's so cool-looking....

-- some unique tables
local url_key = {"url_key"}
local name_key = {"name_key"}

local server_metatable = {}
local func_metatable = {}

function server_metatable.__index(table, key)
  local root_url = table[url_key]
  local f = {[url_key]=root_url, [name_key]=key}
  setmetatable(f, func_metatable)
  return f
end

function func_metatable.__index(table, key)
  local root_url = table[url_key]
  local basename = table[name_key]
  local f = {[url_key]=root_url, [name_key]=basename.."."..key}
  setmetatable(f, func_metatable)
  return f
end

function Public.Server(url)
  local s = {[url_key]=url}
  setmetatable(s, server_metatable)
  return s
end

function func_metatable.__call(func, ...)
  local url = func[url_key]
  local s = "<?xml version='1.0'?>"..Public.callToString(func[name_key], arg)

  return Public.do_xml_rpc_call(url, s)
end

Jay