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
On 5/15/07, Brian Gerkey <brian@...> 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