Re: Scripting in Gnome

On 05/02/04 22:42, jamie wrote:

Thats true for objects that are unknown. In VBA, in-application specific

objects are just there - you dont need to explicitly use com or even
instantiate them (they obviously do that behind the scenes). That way
you can just dive in and use them without any additional glue. (Of
course external objects that you use in VBA have to be instantiated
That is an example of exposing an app's document model via COM :) In fact, I don't think VBA has an extension interface other than COM ...

VBA is a dumbed down language and thats why its popular (because
non-programmers can make use of it) so naturally I would want any method
we use for automation in VBA to be similarily dumbed down and wrapping
it in an object fashion is the way VBA achieves that. Might have to wait
for D-Bus/DOM then for the automation part...
Are you sure that VBA is popular because it is "dumbed down"? Languages like Python have simpler and more regular syntax. I would guess that the reason it is popular is due to what it can be used for (ie. lots of scriptable COM interfaces), and the fact that it has a builtin IDE in the Office apps.


I understand the problem as someone wisely said "the nice thing about
standards is there are so many to choose from".
True. I left off a number of other interfaces developers can pick, like Python or Perl's native extension interfaces ...

Because Bonobo is equivalent in functionality to COM, I was kinda hoping
a future version of Bonobo would be independent of corba or whatever
underlying mechanism is used so you could use whatever system works best
Well, Bonobo is just a set of standard CORBA interfaces, along with some conventions on how to tie interfaces together into a component, so it isn't really separable. Bonobo without CORBA wouldn't be Bonobo.

(obviously everyone will use the fastest and most efficient method
whilst keeping Corba for backwards compatibility). I think there's an
overwhelming case for replacing corba IDL with XML in bonobo if thats
done (XSLT for automatic language bindings would be very handy).
What do you see as the concrete benefits of replacing CORBA's interface description language with XML? A language binding can always ask the ORB to describe the types (and with ORBit2, you can get full method descriptions for object references). I can't see what benefit changing the on-disk representation of the interface descriptions will give.

If you are interested in scripting of applications, one thing you could do that would be useful would be to identify a set of requirements for such a scripting framework, and then check those requirements against the various options available. If none of them meet all the requirements, we would have some idea of what needs to be done to finish them. Some suggestions to get you started:

   * Must be easy to write code to glue the framework to a language.
   * For dynamic languages, only a fixed amount of code should be
     needed; ie. it shouldn't be necessary to pre-generate stub code.
   * Must be easy for applications to expose their APIs.  ie. shouldn't
     be too verbose (like the CORBA C mapping), or require the
     developer to refactor their app too much.
   * Have a type system that can support complex types (lists, structs,
     etc).  Preferably recursive types (eg. a list of lists or list of
     structs, etc).
   * It would be nice if the same or a similar interface could be used
     for in-process and out of process scripting.

You can probably think of others.


Email: james daa com au

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]