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
functionality?
brian.
> 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.

Thread view

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/

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/

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
functionality?
brian.
> 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.

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
http://playerstage.sourceforge.net/doc/Player-cvs/player/group__player__clientlib__cplusplus.html
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?
Toby
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
> functionality?
>
> brian.
>
> > 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.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> Playerstage-developers mailing list
> Playerstage-developers@...
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>
--
This email is intended for the addressee only and may contain privileged
and/or confidential information

On 5/14/07, Toby Collett <tcollett+player@...> wrote:
> 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
>
> http://playerstage.sourceforge.net/doc/Player-cvs/player/group__player__clientlib__cplusplus.html
>
> 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?
There is a fairly complete example program giving many different ways of
defining callbacks in examples/libplayerc++/example2.cc.
A simplified version (showing only one way to do it) could serve as the
basis for a nice tutorial. (I'm not volunteering, either.)
--
joq