* Curtis Olson -- Monday 19 February 2007: > I don't think it's fair to characterize these as secret features that can > only be used by one customer.
OK, you are right. The customer gets them set up, not knowing about them. And everyone else can look at the source code. For more serious work this will probably always be necessary. Not that it can't all be documented, but it's a lot of work, and a bit redundant too, when everyone looks at the code, anyway. ;-) What I would like to suggest is to remove the "show" command. set/get are enough, and additional, redundant commands don't make the usage any easier. Just the opposite. (Like --props and --telnet. :-) > The property system is a way to manage and store "data". It ties an "ascii" > name to a physical memory location in a very convenient way. This is great, > this is useful, this is critical. And that's where I indeed disagree, and I think the author of most of the property code (David M.) does/did, too. The property system, IMHO, is and should not be just a data storage medium. It is FlightGear's nervous system and messaging system. The colored ATC screen messages are simply output by writing text to /sim/screen/red, /sim/screen/green, etc. (see $FG_ROOT/Nasal/screen.nas). The Festival output is done by writing text to /sim/sound/voices/atc, etc. And if you write text to /sim/messages/pilot, it is copied to /sim/screen/yellow (causing the yellow text) *and* to /sim/sound/voices/pilot. It's a clever (IMHO :-) messaging system. Waypoints are set by writing them to /autopilot/route-manager/input. In your opinion this should all have been done via oodles of fgcommands()? That do then not work in the property browser, in the httpd interface, on the command line, ...? Big loss, no gain. > But there is also a need to tie an "ascii" name to a physical function call > and handle the ability to pass in an arbitrary number of arguments to that > function. This is what the fg_command interface does. Yes, and what tied functions do with less overhead, quicker, and more universal. :-} > Conceptually, I like the separate between functions and data. It is true > that we have built some very capable systems that can cross over and do a > lot more than their original design, and their may be times when listeners > are appropriate. Hey, I had in my originally message suggested "listeners", but I corrected this. I meant tied functions. Listeners aren't needed for that. (Although they are also very efficient, more than fgcommands). > How do you do: > > set /sim/audio/play /usr/local/share/sounds/ <space> foo.wav ? Simple and without overengineering: :-P set /sim/audio/play /usr/local/share/sounds/ set /sim/audio/play foo.wav > In both of these examples, how do you repeat the function call. Just writing again. How do you think I output two festival voice messages? > What happens if you "set /sim/screenshot 1" when the value is already "1"? That doesn't matter. The tied function doesn't even need to look at the value, if it isn't interested. Still quicker than an fgcommand call. > What do you do if you want to play the sound again? The same what I do already now when I want a Festival message played again. I write it again. No-brainer. :-) > What do you do if you have functions that require multiple options? Yes, that's a case where a fgcommand() can be better. In the routemanager it's just "set /autopilot/route-manager/input [EMAIL PROTECTED]". See? Two values. But it needs to be parsed, something that the fgcommand does automatically, especially when it's called from XML context. > I hope we can move forward both being better informed. Oh, yes, sure. I hope I don't need to remove all the cases (and there are a lot!), where the property system is already used for messaging and triggering actions. We'd lose some major features in one go. m. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
