Having slept on the dynamic array issue a couple of things have occurred
1) as previously mentioned, the static limits are features of the
drivers and clients alone, not the transport layer
2) The server is already c++ only so there is no issue here with
creating classes to wrap the structures (and therefore handle the arrays)
3) So the c client is the only area where changing will require manual
memory management, and this should be able to be wrapper up in the proxies.
We should be able to move to dynamic length arrays without affecting any
client applications, and we should be able to simply the driver updates
with some wrapper classes around the raw structures.
At the same time we could implement Brians pluggable interfaces, which
should be kept separate from pluggable drivers to encourage reuse of the
If people agree with this the question becomes who has time to carry
this all out, and are we aiming to incorperate this in 2.1 or somewhere
further down the track (and can we add the queue autopointers while we
are breaking everything else :)
Radu Bogdan Rusu wrote:
> So it looks like there are two separate things, which could be "solved" through a single,
> but more major modification.
> Unfortunately it seems that the array problem is related to the possibility of having a
> C-compatible framework. Drop C, and you already get access to vectors/dynamic arrays. Keep
> C, drivers+clients must take care of memory management.
> I think one of the most powerful features of Player is its "language independence",
> meaning that we have a bunch of very different programming languages that it can be used
> from. I wouldn't like this to die. I have colleagues who have been using Player/Gazebo
> with LISP for years now, and their results are impressive.
> On the other hand, it seems that by switching to an IDL like ICE, you still get the
> possibility of using it from at least C++, Java and Python (I am not mentioning PHP since
> we don't have a client for Player yet, and the other two languages supported by ICE are
> evil anyway).
> Keeping two versions of Player is out of the question. It would complicate things way too
> So the goal would be to keep the current TCP/UDP transport mechanism (libplayertcp+xdr)
> and add a libplayerice near it, so that the user could switch between the two transport
> mechanisms. Maybe, just maybe, we could keep two separate lists of "supported
> languages/platforms", one based on the standard TCP/UDP/XDR mechanism, and another based
> on ICE, meaning that for instance we would still have Ada, LISP, etc clients for
> libplayertcp/xdr, but only C++/Java/Python would be supported for libplayerice. It might
> sound "cruel", but I think it's reasonable. I guess not too many people would like to code
> CORBA/ICE/ACE/etc wrappers in LISP anyway.
> I guess the only issue is... what happens to plain C? A lot of other platforms ran away
> from it, and are either 100% C++, or hybrid, by making use of IDLs such as ICE.
> I would like to see a better way of defining interfaces, as Brian mentioned, but I am also
> a fan of the already imposed standards too. I guess the possibility of serializing your
> own objects or defining your own data structures in a true manner, through the usage of an
> opaque interface would still be the best way to go for people who need "obscure" definitions.
> The most important move for me personally, would be to get rid of the "static" limits,
> since I don't think we can keep on boosting them up forever. Even with the newly proposed
> 3dpointcloud (or whatever its name is going to be at the end) interface, it will be hard
> to decide on an upper limit.
> Feel free to correct me if I'm wrong.
> Brian Gerkey wrote:
>> On Jul 9, 2006, at 11:30 PM, Radu Bogdan Rusu wrote:
>>> And since we're talking about the "wish list", what about true
>>> dynamic arrays (without a
>>> PLAYER_MAX limit) and other transport mechanisms ? The sooner we
>>> talk about it (easier to
>>> put it on the table here, than one just wasting time going through
>>> the code and trying to
>>> understand), the sooner I could get some students working on it. ;)
>> Historically, those limits were there because all messages were fixed
>> size, even when sent on the wire. When we moved to XDR-encoding, the
>> messages became dynamically-sized on the wire. However, they're
>> still passed at max-size going in and out of drivers (and clients).
>> Doing it like this simplifies the messaging API, because I can pass
>> you a pointer to a fixed-size struct, and you can easily access its
>> member fields directly.
>> People are starting to chafe at these limits, so the question is how
>> best get away from them.
>> One way would be to keep the fundamental definition of the messages
>> as C structs, but specify arrays as pointers (with an auxiliary size
>> field), instead of sized arrays. The structs would still be fixed-
>> size and could, for example, be safely declared on the stack. As
>> Toby has pointed out, you would have to explicitly manage the memory
>> pointed to by the structs. We could hide some of this in the
>> transport layer(s), but drivers and clients would end up doing some
>> memory management.
>> An alternative would be to drop C structs as the definition language
>> for Player messages, and move to a "modern" interface definition
>> language. I've never tried one, but I imagine that the IDLs used by
>> CORBA systems must be flexible enough to do what we want. The
>> question there is how much overhead is involved in using the IDL, and
>> how easy it is to access IDL-defined structures in various languages
>> (importantly, C).
>> I'm very interested in implementing a peer-to-peer transport
>> (possibly ICE, which many have mentioned recently) in the near
>> future, and I'd like to roll this variable-sized message change in at
>> the same time.
>> Another thing to think about is how we can distribute the interface
>> definitions. Right now everything is defined in player.h, which
>> makes the addition of new interfaces somewhat cumbersome. I've
>> gotten close to a plugin-interface setup, but we're still missing
>> some functionality to make this easy to do. CARMEN does something
>> interesting here, which is for each module to provide a library that
>> packs, unpacks, and provides accessor functions for all messages that
>> the module produces. So if you want to read messages from the
>> 'laser' module, you link your program against the 'laser_interface'
>> library. Of course, by distributing the interface definitions to
>> this degree, there's no way to guarantee (or effectively encourage)
>> multiple drivers/modules to adhere to a common interface.
>> Comments, thoughts?