From: Geoffrey B. <g....@au...> - 2007-04-21 03:48:58
|
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? Geoff 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. > > -- Robotics research group, University of Auckland http://www.ece.auckland.ac.nz/~gbig005/ |