Enterprise Desktop - Scripting

[Jim Bublitz]

On Sunday December 21 2003 13:56, Waldo Bastian wrote:

> On Sun December 21 2003 11:01, Jim Bublitz wrote:
> > "Scripting" means:

> [SNIP]

> > In most of these cases (I'll grant the distinction isn't
> > crisp), I want to use Python as high level glue, not to
> > write an app, but to perform a high level task using methods
> > from existing apps (especially their data
> > storage/processing/retrieval methods, like address book,
> > mail, spreadsheet, etc). Moreover, in many (most?) cases, I
> > want to do this from within KMail, KSpread, etc. as part of
> > the app's GUI (getting the menu entries up is trivial - I
> > want the menu entries to do something in code I write in a
> > language I choose). I can probably do most of these things
> > in 5-10 steps already - I want them to happen with a single
> > click.

> > DCOP *may* be an advantage in doing some of this (I have to
> > look at it more)

> To do the above scripting the application needs to have entry
> points, you don't want to open up every internal function of
> the application because that will be a mess and it will turn
> "scripting" into "application development". You want to have a
> simpler better defined interface that provides scripts with
> entry points in the application.

Up to this point, I'm in complete agreement. A scripting 
interface at the level we're discussing has different 
requirements (and maybe even different architecture) than the 
underlying C++ API.

> This is where DCOP comes in,
> with DCOP the application can provide in a very easy way an
> interface that it presents to the scripting world. This
> interface can then either be access via the DCOP protocol
> itself (e.g. via the "dcop" command line utility) or you can
> use it to make in-process calls from your scripting language
> to the application in which the script is embedded.

For the level of scripting I'm adovcating (or for the level of 
convenience I'd like personally), and assuming I used DCOP, DCOP 
itself would be completely invisible to the user. I haven't 
really resolved all of the issues, but I think just the 
construction and marshalling of arguments for DCOP from Python 
(via the DCOP interface itself) is problematic. If it's wrapped 
in C++ (as a Python module) it might not be a problem at all.

Just from a quick look the other day, I'd end up wrapping the 
actual DCOP interface and possibly extenidng it in one way or 
another, depending on whether the API is sufficiently exposed 
and how it's exposed. The alternative is simply writing bindings 
to a wrapper for an API and at the moment, that seems faster and  
easier to me, but I'm interested in looking at alternative ways 
of doing it (like a strictly DCOP interface). If I write my own 
C++ wrapper, any other language can write bindings to it as 
well, so there doesn't have to be a loss of "standarization" 
with that approach.

That I'd probably need to wrap/extend DCOP interfaces in most 
cases cancels out the biggest advantage DCOP might offer me, 
which is not having to develop and esp maintain the interface at 
all (or very little). 

> As for javascript vs. python. That's really a decision the
> user has to make, using a plugin architecture there is really
> no reason why one scripting language should be preferred over
> the other. 

I agree completely - I'm not advocating an official KDE scripting 
language at all. That seems like a bad idea.

> The applications all provide DCOP-based scripting
> interfaces (they still need a lot of improvement though) and
> the scripting engines only need to provide a way to hook
> themselves into the scripting architecture and bind themselves
> to DCOP exported interfaces.

That gets a big "it depends". I'd have to look much more closely 
at DCOP and see what the advantages and restrictions are. 

This still comes down to a lot of the other things I've mentioned 
in previous posts, like developer relations and how KDE markets, 
supports and guides this. From my side, I'm not inclined to 
track down every developer for every application to resolve DCOP 
issues for example. From the KDE side, I'd think KDE would want 
to be able to offer some degree of guidance about how stuff like 
this is implemented (or not to be implemented in extreme cases).

> What we now need is to flesh out this scripting architecture
> so that we can tie scripts to KActions via the XMLGUI
> framework and have hooks in place so that we can load
> arbitrary script-engines to execute such actions.

> E.g. kmainwinui.rc now has code like this to describe the
> KMail "Message" menu:

>   <Menu noMerge="1" name="message" >
>    <text>&Message</text>
>    <Action name="new_message" />
>    <Action name="post_message" />
>    <Separator/>
>
> It should be possible to add your own actions to that with
> something like: <Action name="send_inquiry" script="ruby">
>       ...some ruby script...
>    </Action>

The actual mechanics of handling that shouildn't be a problem - 
what's in place should be more than sufficient. There are other 
issues like installation, configuration and esp security and 
standardization that should also be addressed, but those seem a 
little premature at the moment.

Jim