Re: Scripting in Gnome

[James Henstridge <james daa com au>]

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
> manually)
>  
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.

[snip]

> 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.

James.

--
Email: james daa com au
WWW:   http://www.daa.com.au/~james/