Re: scripting with bonobo

["Dirk-Jan C . Binnema" <bulkmail dds nl>]

Hi Michael,

On Mon Jun 26, 2000 at 10:46:08AM -0400, Michael Meeks wrote:

> 	I am not convinced that DII/DSI does what we need, also it
> certainly doesn't deal with security ie. it would be nice to know what
> ramifications a method has / to allow passing a security mask eg. so we
> can allow gui interaction but not file IO in a script.

Well, the script runs with the privileges the user has that started
the app that runs the script. But you probably think of someone
sending you a gnumeric-sheet with some virus. Ok... IIRC  the 'basic'
versions of VBScript and JScript in the MS environment do not give you
any file i/o functions, and no GetMeSomeOLE2Object. You have to
implement those yourself. So the only way to get file i/o is if one of
the objects you get through 'add_object' (in my example) has file i/o
capability. Also you can set the 'Safe for Scripting' flag on
objects, which decided whether they can be instantiated from a
(non-priviledged) script.

However, as Python and Perl are much more powerful, it's hard to limit
their capabilities for doing file i/o and other stuff that may be
security sensitive.

Maybe we can add a special 'script' user with very limited privileges, and
let scripts run in that context. It can still do useful 'dangerous' stuff using the
app-provided object model. 

> 	I am moderately convinced that cooking our own IDispatch interface
> has many advantages; eg. the ambiguity between 'method invoke' and
> 'property get' implicit in MS' interface IIRC.

In MS-circles, IDispatch is not very popular, as it's slow and very
not-cool to program from C/C++. (However, ORBit out-of-process
components are pretty slow as well, compared to in-proc COM
components). 

The invoke/get stuff is just some syntactic sugar, which
(IMHO) doesn't justify the ugliness of IDispatch programming. You win
some, you loose a lot more.  

Can you elaborate on the problems with DII/DSI? 

> > Yes. There's overlap with Automation here - you'll probably want to
> > expose the same object model both inside the app (scripting) and
> > outside the app (automation). And of course keep consistency - you
> > don't want 'document.writer' in one app and 'currentdoc.author' in
> > nother.
> 
> 	Yes; to an extent this can be done nicely just using BonoboObjects
> inside your application, but you will probably have to the aggregation
> manualy, many people like a Gtk widget base.

yes, you're right. hadn't thought of that.

Cheers,
	Dirk-Jan. 

+--------------------------------------------------+
          Dirk-Jan C. Binnema <djcb@dds.nl> 
           http://www.casema.net/~devnull
 --------------------------------------------------
                 PGP/GPG fingerprint:
 BB49 41D7 053D E5F1 F333 586E C530 CBC3 4352 A39F
+--------------------------------------------------+