Re: [Playerstage-users] wish list?

[Radu B. R. <ru...@cs...>]

Fred, you raised a very important point in this discussion. Actually, 
with the major overhaul in Player 2, it is now possible to drop the 
client-server architecture, and simply wrap against certain libraries 
(you will need libplayercore and libplayerdrivers for your application - 
for instance).

I think that what Brian was suggesting is that different people have 
different needs, so the best way to make everybody happy is to have a 
lightweight modular architecture, on top of which we can build other 
more "complex" things (I wouldn't call TCP/IP complex, but CORBA almost 
gets there).

In my opinion, we shouldn't drop any of the existing transport or 
communication mechanisms, but rather add new ones, and, when necessary 
adapt the current ones to allow the existence of the new ones. Makes sense?

Cheers,
Radu.

Fred Labrosse wrote:
> On Tue, 6 June, 2006 9:57 pm, Geoffrey Biggs wrote:
>   
>> I also think that the ideas mentioned below of making player less
>> "client-server" and more "distributed-control-network" is an important
>> direction. I think we need to move away from the idea of an overall
>> commanding client program doing all the management and more towards
>> local autonomy, and maybe moving away from the client-server layout is
>> one way to achieve this.
>>     
>
> Is the server/client architecture actually needed?  Let me explain!  I do
> appearance-based vision, i.e. no feature extraction.  This means that my
> client needs to get raw images from the camera, which when sent over the
> network (even localhost) between the server and my client, this introduces
> impossible delays.  At the moment, I can see two solutions:
>
> - not using player for the camera grabbing (my current solution as I had
> the code from before using player);
> - have my code not as a client but as a "driver" (or should that be a
> service or something like that?), at least something that runs in the
> server.
>
> Actually, the latter is probably the best way to do it, since as other did
> put it, player is also a sensor system.  Is that something that is already
> possible (I have to admit that I didn't look at that at all since I have
> my own working solution now)?  If it is possible, this also means that
> player should contain some image processing functions that all vision
> algorithms could use, and I would be more than happy to contribute to
> that, even possibly give you some (not everything is relevant) of my code.
>
> Cheers,
>
> Fred
>
>
>
>
> _______________________________________________
> Playerstage-users mailing list
> Pla...@li...
> https://lists.sourceforge.net/lists/listinfo/playerstage-users
>   

-- 
| Radu Bogdan Rusu | http://rbrusu.com/
| http://www9.cs.tum.edu/people/rusu/
| Intelligent Autonomous Systems
| Technische Universitaet Muenchen