[openbeos] Re: CLI-App-Backends vs. Components
- From: Erik Jaesler <erik@xxxxxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Fri, 26 Sep 2003 11:36:03 -0700
I'd just like to throw in the requisite note about replicants, that most
under-used facility of the BeOS. In my mind, this is how true
"component" programming (a la COM) was intended to be done in BeOS.
e
Isaac Yonemoto wrote:
A well-designed component framework usually also standardizes and,
ideally, also automates compatibility tests (i.e. tests, if components
can work together or if some need to be updated) and .. dream :-) ...
There is potential here, in BeOS scripting (by which I mean BMessage-based
scripting, *not* Bash-scripting) -- the only problem is that very few apps
really use it well, and some of BeOS's native apps (like Terminal) are
halfway-broken in terms of scripting.
BeOS scripting is, in my opinion, the platform to really be halfway
between CLI-interfacing and component-based interfacing. The only problem
is that standardization (by committee, or whatever) never really
occured. To script playing a media file on MediaPlayer is not the same as
on VLC, and in either case it is a total pain in the ass.
{ASIDE: Ideally, both would present a "FILE_NAME" variable and a
"PLAY_FILE" executable in the GETSUITES response, and do some checking to
make sure someone doesn't use it as an exploit (though with media files
that's tough), you could pass a B_REFS_RECIEVED but that only works
because you already know its functionality. As it stands, scripting is
really only usable as a way to interact with the GUI through the CLI.}
Anyways, scripting would allow you to assert a strong division-of-labor
principle across the board and even allow an application to send queries
and see if any already running apps can perform a desired task.
Isaac
- References:
- [openbeos] Re: CLI-App-Backends vs. Components
- From: Isaac Yonemoto
Other related posts:
- » [openbeos] CLI-App-Backends vs. Components
- » [openbeos] Re: CLI-App-Backends vs. Components
- » [openbeos] Re: CLI-App-Backends vs. Components
A well-designed component framework usually also standardizes and, ideally, also automates compatibility tests (i.e. tests, if components can work together or if some need to be updated) and .. dream :-) ...
There is potential here, in BeOS scripting (by which I mean BMessage-based scripting, *not* Bash-scripting) -- the only problem is that very few apps really use it well, and some of BeOS's native apps (like Terminal) are halfway-broken in terms of scripting.
BeOS scripting is, in my opinion, the platform to really be halfway between CLI-interfacing and component-based interfacing. The only problem is that standardization (by committee, or whatever) never really occured. To script playing a media file on MediaPlayer is not the same as on VLC, and in either case it is a total pain in the ass.
{ASIDE: Ideally, both would present a "FILE_NAME" variable and a
"PLAY_FILE" executable in the GETSUITES response, and do some checking to
make sure someone doesn't use it as an exploit (though with media files
that's tough), you could pass a B_REFS_RECIEVED but that only works
because you already know its functionality. As it stands, scripting is
really only usable as a way to interact with the GUI through the CLI.}Anyways, scripting would allow you to assert a strong division-of-labor principle across the board and even allow an application to send queries and see if any already running apps can perform a desired task.
Isaac
- [openbeos] Re: CLI-App-Backends vs. Components
- From: Isaac Yonemoto