With boost enabled in the c++ client libraries the client lib can run in a thread and it uses the boost signaling library to signal the arrival of new data which gives the ability for callbacks etc.

I think the overview page for the C++ lib is the place to put the information, at the moment it is very sparse


A couple of tutorials, one for the basic c++ library and one for the boost features would help a lot as well, unfortunately I am not volunteering to write them just at the moment...

Maybe even a feature highlights list at the start of the docs or on the main website/wiki?


On 5/15/07, Brian Gerkey <brian@gerkey.org> wrote:

On Apr 20, 2007, at 8:49 PM, Geoffrey Biggs wrote:

> OK, so this has turned out to be yet another case of "Geoff thinks of
> something handy, but finds it's already been done and nobody knows
> about
> it." Why aren't people using this functionality more? Or at all?

So there already is a callback mechanism?  In both libplayerc and
libplayerc++?  Any suggestions on how to better publicize this


> Geoffrey Biggs wrote:
>> Perhaps one way to allow this would be to provide a mechanism in the
>> client libraries for message processing callbacks to be registered,
>> either on a per-device basis or a per-client basis (or both). The
>> callback would receive the message header and body and could do
>> what it
>> wants with it, then return a value that says for the proxy to either
>> ignore that message (eg if the callback did something else
>> suitable with
>> it already) or to process it as normal (eg if the callback just
>> registered that a certain type of message came through).
>> I don't think this would be very hard to implement, and it would
>> allow
>> for clients to decide if they want to use the standard proxy message
>> handling or keep track of messages themselves for a particular
>> device,
>> with all the work that message handling entails. I might have a
>> look at
>> doing an experiment this weekend.
>> Geoff
>> Brian Gerkey wrote:
>>>>  (I mean, how client program should know if it can use scans data
>>>> together with pose info offered by SCANPOSE subtype?).
>>> This is a little tricky, because the client libraries are still
>>> based
>>> on a proxy model.  So the incoming message stream is transparently
>>> unpacked and the data stored into the proxy as if it represents the
>>> state of the device.  This works most of the time, but as you point
>>> out, there can be some ambiguity in that the client program does not
>>> know exactly which subtype messages have been received.
>>> It may be useful to think about providing a mechanism in the client
>>> libraries to process messages as they come in, in addition to having
>>> the proxy store their data.

This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
Playerstage-developers mailing list

This email is intended for the addressee only and may contain privileged and/or confidential information