On 2/19/07, Melchior FRANZ <[EMAIL PROTECTED]> wrote:
Well, I don't like secret features that can only be used by one
"customer", and are of no use for the majority of users. That
doesn't mean that I would like to see the extra commands in "help",
because this is exactly the clutter that doesn't belong there. (Like
the functions in the first place.) But then again, properties would
have to be documented, too, so this isn't really my best argument.
I don't think it's fair to characterize these as secret features that can
only be used by one customer.
We have an fg_commands subsystem (source code in
.../src/Main/fg_commands.cxx) that publishes an interface to a large set of
available commands. These might not be over documented, but they definitely
aren't secret, and they are available to any subsystem through the
fg_commands interface.
The code you stumbled over simply is providing an interface between the
telnet connection and the fg_commands, it's not actually implementing any
commands in the code. The special cases you see are there to do special
handling of arguments to the function calls.
How do I call them from the http interface?
I don't believe any one added an interface between the httpd server and the
fg_command module. I'm not sure that's the fault of the fg_command module.
OK, there are functions
that can be called from Nasal and GUI XML. Those are already hacks,
if you ask me. Why does there need to be an fgcommand "timeofday"? What's
wrong with "set /sim/time/timeofday noon".
Because setting /sim/time/timeofday to noon does nothing right now. You
have to set the value of "warp" which is an offset in seconds from the true
time. That means there needs to be some additional code that happens so
that when you call do_settimeofday("noon"), the system figures out what time
offset in seconds is required to accomplish that.
Is the property
system not good enough for some types of information? And why exactly?
There are no technical reasons, really.
This boils down to programming philosophy, so I don't expect everyone to
agree with me on this. But, here's the way I see it.
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.
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. It is soft of a
simpler procedural analogy to the "data" management system.
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. But still I think it's important and valuable to be able
to tie "ascii" names to real functions so that scripts and external software
can launch specific function calls within FlightGear.
Huh? What's wrong with "set /sim/audio/play
/usr/local/share/sounds/foo.wav".
This might be a bad example, but what if we want to pass the directory and
the file name as separate arguments. How do you do:
set /sim/audio/play /usr/local/share/sounds/ <space> foo.wav ?
And "set /sim/screenshot 1"?
In both of these examples, how do you repeat the function call. What
happens if you "set /sim/screenshot 1" when the value is already "1"?
What do you do if you want to play the sound again?
What do you do if you have functions that require multiple options?
I would argue that in these cases your property system abstraction starts to
become obtuse and difficult to understand and doesn't work in a
straightforward, obvious manner.
I don't think all procedures can be forced into a "set a property value"
mold. I believe its much better to separate the act of managing data from
the act of triggering function/procedure calls.
fgcommands predate the property system, AFAIK. They were necessary before,
and now they are overused, because people don't understand how to use
the property system. Some of the commands are nice, of course. But most
are superfluous, especially those that are added these days.
As stated above, I personally disagree from a philosophical and design
perspective. Let's use the property system to manage data and use the
fg_command system to launch procedures.
I see this as analogous to the argument of using XML to represent data and
nasal/C++ to represent code. As soon as you try to abuse XML into
representing logic and sequential operations and programming functionality,
you start running into a lot of difficulties. That doesn't stop people
because it's tempting to write if/then/else and while loops and procedure
calls in xml and it can be abused to do that ... but it's just not a natural
tool for the job of programming and leads to incredibly difficult and
indecipherable code.
That said, there is an immense amount of grey area here to deal with.
We could cite counter examples back and forth all day long. At the end of
the day, I appreciate being able to share my perspective and design
philosophy, and I appreciate you being able to share yours, and I hope we
can move forward both being better informed.
Best regards,
Curt.
--
Curtis Olson - University of Minnesota - FlightGear Project
http://baron.flightgear.org/~curt/ http://www.humanfirst.umn.edu/
http://www.flightgear.org
Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d
-------------------------------------------------------------------------
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
