Re: XMLRPC 0.0 for Lua

["Jay Carlson" <nop@...>]

> I've put an initial release of client/server bindings for Lua for XML-RPC
at
> http://www.place.org/~nop/luaxmlrpc-0.0.tar.gz . It contains my lxp expat
> binding, and uses LuaSocket for client transport.

Argh, you knew there had to be a reason why it was version 0.0.  I just
found it.  There's a hole in the type system.

Let's say you want to transmit a struct, {early=false} which looks like this
in XML-RPC on the wire:

<struct>
  <member>
    <name>early</name>
    <value><boolean>0</boolean></value>
  </member>
</struct>

XML-RPC false is mapped to Lua nil.  There's no way to send that struct,
because the Lua table is {early=nil}, which is equal to {}.  (Similarly,
arrays with a first element of false fail the "is this an array" test.)

OK, so what can be done to fix this up?  I want to support the echo test in
Lua as function echo(v) return v end, so at the least there has to be some
kind of strict mode, such that a round trip through the type system doesn't
alter semantics.

First option: in-band signalling.  Make an XMLRPC.false (which will have to
evaluate true in the Lua sense).  It's painless to support this outbound,
such that clients sending messages and servers returning values can use this
if they have to transmit such structs and arrays.  It's more painful to
support it inbound, where all values from the network have to be carefully
treated---"if v and v~=XMLRPC.false".

Second option: out-of-band signalling.  Add an additional (non-string,
non-numeric) key to structs and arrays that indicates which elements exist
but have false (aka nil) values.  This makes iteration less fun.

Third option: magic tables.  As above, but hide the is-present key behind a
layer of tagged "settable".

I think I'll make XMLRPC.false always available for outbound values, and
leave inbound false mapped to nil unless a "strict" flag is set.  I'll
probably make the strict flag global at first, but later it can be a
per-function flag in the registry.

Of course, XMLRPC passed the validator test and successfully interacted with
a bunch of network services even with this hole, so it's not like you can't
use it... :-)

Jay