It is hard to imagine a system that gives more flexibility than SWIG,=20
and doesn't require too much additional work to generate the wrappers.=20
But, as Brian suggests, it is very important that we try to=20
automatically maintain the client bindings. If you know of a tool, and=20
know how to use it, would you be willing to show us a prototype? Maybe=20
take a few functions from libplayerc and generate the wrappers for them=20
for, say, Guile, Python, and Java?
I help keep the SWIG Python bindings working, but if the Player Project=20
moves to an IDL, I would help with that. The questions that we would=20
need to answer about any proposed IDL:
- is it actively maintained?
- run at least on Linux, Unix, OS X, and Windows?
- easy to use?
- supports at least Java, Python, and Guile, but would include languages=20
like Ruby, Perl, Tcl, Mzscheme, and be extensible?
- can be put into the existing Player build steps?
I think SWIG answers all of these fairly well. Maybe Paul can shed some=20
light on the problems of auto wrapping using SWIG on Guile...
Geoffrey Biggs wrote:
> There is another alternative to SWIG for providing auto-generated clien=
> that would allow for more flexibility with the API provided by each lib=
> This would be to use an interface description language to describe the
> interface between the player server and clients rather than player.h. A=
> allows client libraries to automatically generate the packing/unpacking
> functions and ensures they're all the same without restricting clients =
> using the same API no matter what language. It would also make maintena=
> all the messages a lot easier.
> A related option is to layout player.h so that it can be automatically =
> for other client libraries to determine the messages required.
> Geoff Biggs
> Quoting Brian Gerkey <gerkey@...>:
>>I'd like to strongly recommend to client lib maintainers that they try
>>building their libs as wrappers around libplayerc. Furthermore, I'd
>>recommend the use of SWIG to do the wrapping.
>>Historically, we focused on the client/server protocol, on the
>>assumption that users would build client apps that directly manipulated
>>the socket to player. The C++ client lib began life as an example of
>>what you could do with player. But now things have developed to the
>>point where everybody uses a client lib, and the libs have gotten more
>>complex as the interface specification has grown and changed. It's a
>>tedious and bug-prone activity to duplicate the bit-packing and
>>bit-unpacking code in multiple languages. We're much more likely to ge=
>>it right by doing it once in libplayerc and then supporting other
>>langauges by binding to libplayerc. It's even more likely to be correc=
>>when we create the bindings automatically with SWIG.
>>There are good reasons for writing a client lib natively in the desired
>>language, such as providing a more natural API than what SWIG would
>>generate, or avoiding the need to load in binary extension modules.
>>But I'd like to see more auto-generated libs.
> Robotics research group, University of Auckland
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> Playerstage-developers mailing list
Douglas S. Blank, Assistant Professor
Bryn Mawr College, Computer Science Program
101 North Merion Ave, Park Science Bld.
Bryn Mawr, PA 19010 dangermouse.brynmawr.edu