Re: [Playerstage-developers] another crazy scheme

[ahoward <ah...@po...>]

Hi Nik:

We have been thinking along much the same lines.  With the latest release,
Player supports configuration requests that return information such as
device geometry: playerv uses such requests to work out how to render
things in the GUI, for example.  We have also discussed the possibility of
having "device caps" messages, but havent really thought this through yet.
Note that Player only acquired synchronous request/reply (RPC) in the
latest version, so we have only just started exploring such possibilities;
to fully realize this abstract model, we will probably need to add support
for server configuration files also.

How do you like playerv, BTW?

	A.

P.S.  My apologies for not replying earlier on this: I have been OS for
the last couple of weeks.


On Mon, 24 Jun 2002, Nik A. Melchior wrote:

> Please bear with me.  I implemented the reorganized class structure last
> week (just for position devices) under a "general-api" branch (for lack of
> a better name), but I began to rethink this approach over the weekend.
> I'm still concerned about fixing this problem once in C++, but still
> needing to solve it in the other client libs.
>
> I think a change in the server would be beneficial.  Suppose the server
> only kept track of the type of device: after instantiation, rwi_position
> and p2_position could each be treated merely as position devices.  The
> client lib would ask for a connection to a device of type
> PLAYER_POSITION_CODE with a certain index.  It would be the client's
> responsibility to discover the capabilities of the specific device,
> perhaps thru use of a new message type.
>
> This will likely require more network traffic, but I think it is a more
> easily extensible approach.  When a new device of a known type is added to
> the server, the client libs will not need to be changed.  Even if a device
> with a new capability is added, the client libs will likely only need a
> convenience method for passing the appropriate message.  The only real
> work for the client libs will come with the addition of an entirely new
> type of device.
>
> I think this will also allow tools like playerv to "just work" with new
> devices of known types.  Stage would also gain the ability to emulate any
> type of device, as long as the world files support (say) a way to specify
> how many laser readings to report.
>
> Does this make any sense?  Will it unnecessarily restrict the proxies to
> push all the logic into the server?  Am I missing any fundamental
> principles in the server (or elsewhere) that would make this dangerously
> difficult or unwise?  I think the device initialization is the only thing
> to change (since it works based on the device code) besides some device
> logic.
>
> -- Nik
>
>
>
> -------------------------------------------------------
> Sponsored by:
> ThinkGeek at http://www.ThinkGeek.com/
> _______________________________________________
> Playerstage-developers mailing list
> Pla...@li...
> https://lists.sourceforge.net/lists/listinfo/playerstage-developers
>

Andrew Howard                           email: ah...@po...
Department of Computer Science          http:  www-robotics.usc.edu/~ahoward
University of Southern California       phone: 1 (213) 740 6416
Los Angeles, CA, U.S.A. 90089-0781      fax:   1 (213) 740 7512
    << Insert pithy saying here >>>