Re: scripting

[Bill Haneman <Bill Haneman Sun COM>]

James Henstridge wrote:
...
> My question was whether this was going to be easier than custom CORBA 
> APIs.  Unless I am mistaken, an app author would need to keep the tree 
> of AtkObjects up to date and in synch with their document model 
> (assuming they don't actually store their document model as AtkObjects).
>
> This sounds like it would be more painful than implementing CORBA 
> servers in C.  And given the fact that no app is fully exporting their 
> document model via CORBA, I see no reason why they would put even more 
> effort into an at-spi based solution.

Having implemented some CORBA servers in C, I think implementing them as 
AtkActions and AtkObject proxies would be easier.

> If we want universal scriptability, it needs to be _very_ easy for 
> application authors to add.

In either case (CORBA C services, ATK, DBUS, etc.) we need to define 
some kind of conventions/toolkit in order to make it easy to do the 
usual desired things.  It seems to me that this would be at least as 
easy via ATK as it would via bonobo-application, or some new framework; 
it's mostly a question of what APIs/services we extend IMO.  IOW, we 
will need libgnome-app-services or something, the question has to do 
with what the application and client-side APIs would look like depending 
on what we base that library on.

Another characteristic of the ATK/AT-SPI approach would be that clients 
of the service would see either client CORBA bindings (the C bindings, 
uck, or the pyORBit bindings which are quite nice and easily scripted); 
the application would see ATK-type bindings which would use the 
GObject/GInterface paradigm instead.

So - if someone can clearly propose the kinds of services an application 
would need to expose to such scripting, we can look at how that might be 
implemented via these various frameworks, and how much existing code 
would be reusable in the different approaches.


- Bill

> James.