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 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
> 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
>> for clients to decide if they want to use the standard proxy message
>> handling or keep track of messages themselves for a particular
>> with all the work that message handling entails. I might have a
>> look at
>> doing an experiment this weekend.
>> 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
>>> 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