I think it would make sense to treat everything as asynch in the server
and hide the details in the client library, this would help streamline
the server a bit...a single trasmit queue and a single recieve queue...
Brian Gerkey wrote:
> On Sun, 14 Nov 2004, Toby Collett wrote:
>> I know you need a break after the latest push to get 1.6 out there,
>> but id just like to bring the geometry push data to the front of your
>> thoughts again for when you do get back to it.
> Indeed, I haven't forgotten.
>> I could look at reworking some of the server code to create a single
>> multi message type queue (data, config, geometry etc) but there isnt
>> much point me doing this if you already have your own ideas, so let
>> me know :)
> I'm currently thinking of something along those lines. Config
> requests/replies would remain a synchronous stream, and data/command
> would remain an asynchronous stream. But we'd add the ability for
> an interface to produce more than one type of data (and by extension,
> accept more than one type of command). This already happens in an ad
> hoc way with the config traffic: most config requests and replies have
> a subtype field that tells you how to interpret the rest of the payload.
> The goal would be to migrate that 'subtype' into the message header and
> let it apply to *all* messages. I've periodically looked into how best to
> implement this, but don't have a concrete solution yet. I'm open to