** I have moved this thread to ps-developers**

The main trouble with the property bag model is that it avoids imposing any useful abstraction. Here's a complete and consistent interface:

class Proxy 
{
int SetProperty( string id, int val );
int SetProperty( string id, double val );
int SetProperty( string id, string val );

int GetProperty( string id, int& val );
int GetProperty( string id, double& val );
int GetProperty( string id, string& val );
};

This can do *everything* the Player proxies can do. But it says nothing about robots, and the compiler cannot help you.  Debugging code on a console-free robot because you typed "MAX_SPED" by mistake is exactly the kind of problem that hard-coded interface specs are designed to avoid. How do you know if your property-based code is portable? By looking at every string in every file and checking the manual to see that it "must be supported" by drivers? 

I'll repeat myself and suggest that properties should be restricted to driver-specific state. Anything generic should be part of the interface spec. Portable code should use no properties at all, and getting/setting properties should be visibly different to using regular Player interfaces. 

By the way, the simulation interface has long supported property bags for tweaking simulation models in a very general way, so I absolutely think it's useful in the right place. But it should be used very sparingly!

If we were going to go down this route, we could have saved a whole lot of time by using $(generic key-value middleware)  and just specified a set of robot-ish keys. 

That's a total of 4 cents worth, so I'll hush up now.

Richard/


On 22-May-07, at 7:51 PM, Toby Collett wrote:

This is something that is up for discussion, my personal opionion is that properties are fine for common functionality.

Here is a summary of the discussion Geoff and I had about this (I dont recall if it was in his original post). 

A list of preferred property names should be declared in the interface documentation. Properties such as max speed would be candidates for this. This means that *if* a driver supports a maximum speed property this would be called max_speed (or whatever it is defined as in the interface as the preferred name).

The benefit of this is that properties encapsulate the setting and getting both from the client end and from the config file and we do not need to create as many methods in our proxies as getting properties is generic.

The disadvantage is that the property names are not enforced by the compiler, so developers can name there properties slightly differently causing issues (hopefully documentation of these will mitigate this). The other disadvantage is accessing properties in the client proxy is slightly more tedious (PositionProxy->GetProperty("MAX_SPEED") as opposed to PositionProxy->GetMaxSpeed(). But we dont have to maintain as large a set of members in the proxies.

What is the wider opinion on this?

Toby


On 5/23/07, Richard vaughan <vaughan@cs.sfu.ca> wrote:

On 22-May-07, at 6:11 PM, Geoffrey Biggs wrote:

> Yep, definitely, that's a prime candidate for a property.

Isn't MAX_SPEED a near-universal property of a position device? Most
position devices should be able to supply that when queried.

I thought properties should be driver-specific, such as
"VFH_NEARNESS_THRESHOLD"  ( I made that one up).

The fact that you suggest a dedicated proxy function gives the game
away. Robot-portable code should almost never use properties. Or do I
misunderstand?

Richard/

> Geoff
>
> Brian Gerkey wrote:
>> On May 16, 2007, at 6:21 AM, Marcelo Salazar wrote:
>>
>>> Could be interesting to add a function to set the MAX_SPEED in the
>>> PlayerCc::Position2dProxy, for example:
>>>
>>> SetMaxSpeed (double amaxXSpeed, double amaxYawSpeed);
>>>
>>> Is it possible request to be included in the next version?
>>
>> This sounds like something that should go into Geoff's new property
>> bag framework, right?
>>
>>      brian.
>
>
> --
> Robotics research group, University of Auckland
> http://www.ece.auckland.ac.nz/~gbig005/
>
> ----------------------------------------------------------------------
> ---
> 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-users mailing list
> Playerstage-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/playerstage-users


-------------------------------------------------------------------------
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-users mailing list
Playerstage-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/playerstage-users



--
This email is intended for the addressee only and may contain privileged and/or confidential information
-------------------------------------------------------------------------
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-users mailing list
Playerstage-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/playerstage-users