Daniel Chokola wrote:
Ok, executive summary of IRC discussion follows.
xmmsc_service_call (conn, service, "method", "intarg",
XMMSV_INT, 1337, "other arg", XMMSV_STR, "apanap", XMMS2_END);
that would work. i could internally turn it into a value_t
anders_: can varargs be a PITA for bindings
Ok, executive summary of IRC discussion follows.
xmmsc_service_call (conn, service, "method", "intarg",
XMMSV_INT, 1337, "other arg", XMMSV_STR, "apanap", XMMS2_END);
that would work. i could internally turn it into a value_t
anders_: can varargs be a PITA for bindings or not?
Service metho
Sebastien Cevey wrote:
What about putting named arguments in a dict (as you proposed) *and*
type-checking it on the server?
That was exactly what this point was /supposed/ to mean:
** Possible solution: enforce dict_t (also solves above problem):
args: { "cookie" => XMMSV_INT32, "num_korvs"
Selon Daniel Chokola <[EMAIL PROTECTED]>:
> The question becomes: should we leave typechecking entirely up to the
> clients or do part of it on the server? As soon as you use a container
> format, the server-provided typechecking is defeated and the client is
> again responsible for checking th
Sébastien Cevey wrote:
Today I realized my error, but thought, why don't I just do the same for
arguments?
[...]
* automatic vararg support
OTOH we already have optional arguments.
At the expense of some extra lines of service client code and extra
information to the arg_type_add call.
At Fri, 27 Jun 2008 13:33:14 -0400, Daniel Chokola wrote:
> While making it, I forgot that service clients allow multiple return
> values, so I assumed there was only one return value like in C
> functions, and made a return value an implicit value_t.
IIRC it was the case because at that time, we
Hello folks,
I've got a draft specification of the service clients API that I banged
out in Ruby yesterday. [1][2] While making it, I forgot that service
clients allow multiple return values, so I assumed there was only one
return value like in C functions, and made a return value an imp
