Why gnome apps should offer both guile and Corba.
- From: <jheintz iconcomp com>
- To: <gnome-components-list gnome org>
- Subject: Why gnome apps should offer both guile and Corba.
- Date: Wed, 4 Mar 1998 13:51:07 -0600
here are my thoughts on why gnome apps should offer both
guile as an extension language and export their services via
Corba.
I have made these opinions after having to work with Microsoft's
COM recently. Besides being brutally painful in way to many
area's, some of what it gives developers is just really useful.
Let's take an example. Pretend that every time I edit a file in
my gnome editor that I want to record this in a log that I keep for
recovery purposes in case I screw up some part of my system.
----How would I do this with Corba (or with COM)?
Assuming: that the gnome editor exported to Corba some way
to register for events like "file changed" and "file saved".
1) I would write a script X in some corba client to launch the
editor with the file.
2) Script X would register interest in the "file changed" event.
3) When script X got the "file changed" event it would record
this in my log.
Drawback: if I had another script Y that launched the editor
with a file and recorded every time I spell checked a file I would
be unable to run the editor from both of these scripts. I couldn't
record that I had edited a file _and_ spell checked it. Additionally
I would have know which one I wanted to do at launch time to pick
the correct script.
----How would I do this with guile extentions?
You all probobly know this better than I do, but basically
I would write a script extending the editor that hooked into
the right events. In MS land this is done with VBA(see below).
This allows me to just add my logging behavior to whatever
events I need and are exported by the editor and they are
executed for all files the editor opens.
Conclusion: both embedding guile into the app and exporting
Corba interaces solve different problems. Both are very useful
and do not need to overlap.
Notes about MS land and VBA: VBA is not the only scripting
engine that could be embeded into MS apps. There is something
called an "Active Scripting Engine" that VBA is one of. I think
the way it actually works is that an app has a placeholder for
an "Active Scripting Engine" that is called with the right args
when some event occurs. VBA is just always in that place.
Thanks for reading this far!
John Heintz
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]