On Monday November 12, 2001 02:41, ian reinhart geiser wrote:
> Read the pdf, it is very short and a quick read.
> The idea is that some out of process behavior is not appropriate for
> automation.  The idea behind this is to provide a common interface for
> script engines to extend the application.  If you read the linked
> document you will see that the API is made to provide access to the
> parent object in the application so that you can use something like
> python or ruby to embed and extend the current application or just
> script it.

I did read it.  You only provide an API for the application finding out 
the script's progress.  There's not one line about how the script can get 
information from the application.

> This is to bridge the gray area between plugins and dcop scripting
> again, this is spelled out in the pdf file, if you read it.

Why do you assume I didn't read it?  You didn't address what I ask - How 
are the scripts supposed to get information from and pass commands back to 
the application?  Your writeup seems more focused on philosophy and 
buzzwords than how people will actually use the thing.

> If you think along the lines of how ScriptFoo in GIMP works or how they
> python extensions work in XCircut, you will see how this becomes very
> useful.

ScriptFu scripts in Gimp has access to Gimp's internals.  Your script API 
gives no such access to applications that I can find.

I think a generic system to allow language-independent scripting would be 
nice.  There just needs to be a way for the application to export a list 
of function calls back to the script, so that the script can actually *do* 
something that ordinary DCOP-based scripting cannot.

-- 
Neil Stevens
neil@qualityassistant.com

Don't think of a bug as a problem.  Think of it as a call to action.