On May 3, 2007, at 3:48 AM, amak4609@... wrote:
> based on our experience with Orca, transport layers may be
> especially if you are trying to squeeze a higher-level middleware
> into a
> layer currently occupied by raw protocols. It's possible to do, but
> may be
> easy or frustrating, depending on your perspective.
> at some point we set out to add an "Ice transport mechanism" but
> weeks abandoned the idea and decided to switch to a 100% Ice solution.
> all in all, I don't think it'd be a lot of work to add an Ice layer
> someone who's familiar with the Player internals, just beware of the
Thanks for the perspective, Alex. I think you're right. I've been
using Ice over the last few months for another project, and I've come
to the conclusion that we would gain little by laying the existing
Player protocol over Ice. (I've also come to the conclusion that,
while Ice is better than other middleware packages I've tried, I
still think it's too thick and opaque, but that's not the point here :)
I think the Player 2.0 XDR-TCP transport is working well, and would
prefer to pursue the following enhancements instead of implementing
- Facilitate new interface specification. The user should be able to
easily define a new interface, generate XDR bindings, and provide
those bindings to other applications, all without modifying <player.h>.
- Improve and fully integrate resource discovery. We already have
publish/subscribe semantics; we're just missing support for location-
- Facilitate standalone application development, so that people will
write more drivers and fewer clients. The client libs will always
play an important role because they provide a comfortable and safe
way to build an application. But I'd like to see advanced users
writing more drivers and building more peer-to-peer systems, in which
each component can both produce and consume data and commands. The
example of a standalone laser server that I posted a while back is a
first step in this direction.