Re: scripting

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


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