Re: [Fresco-devel] scripting

Nick Lewycky wrote:

> 1. Allow the CommandKit to return a server-side Command that executes in 
> a CORBA-aware scripting language (such as JavaScript?) You'd pass in the 
> program text and it returns the Command object.

embedded interpreters would be very helpful in quite a number of 
situations. But I fail to see the relationship between such a device and
the debugging / inspection tool we are discussing here.
In fact, I was thinking about a server side interpreter as a way to 
extend the server's functionality without all the overhead normally 
involved with richer IDL. I remember for example discussions about a 
server-side constraint solver (as part of a special kit). The 
constraints are usually expressed as equations (inequalities), and 
instead of adding a whole lot of new IDL types to represent the related
entities, we could just define a language to express them, and then send
commands as strings to the server where these are interpreted.
This, however, only works well if the domain which you want to express
is pretty limitted (such as expressing positional relationships between
graphical objects).

So, in order to have 'command scripts', one would first have to come up
with a domain these commands act on, then express these commands in a 
suitable language. Not an easy task in general. I think this is the main
idea expressed in the first mail: to define what should be exposed to 
such an interpreter. And, as I added, some 'capability model' or 
somesuch that captures who is allowed to do what in this space...

> 2. Provide a suite of non-interactive programs that are capable of 
> manipulating the Display Server from the shell.

yes. Especially if there is some persistent non-client-specific state
that could be manipulated this way.

> 3. Integrate a set of queries that would be useful debugging, such as 
> "find window named <X> and output a copy of its scene graph" or somesuch.

yes !

> I'm not familiar with blackbox, but I know that sawfish has a tool 
> called sawfish-client. I'm just worried that a fresco swiss army knife 
> thingy will quickly turn into a Fresco binding for shell. That's 
> analogous to writing a Fresco/CORBA API wrapper for a new language, in 
> this case, shell.

good point.

> We already do use callbacks for DesktopKit (window manager) functions. 
> There's the MoveResizer Command that gets triggered when you grab a 
> corner of a window to resize it. Currently, that Command only exists 
> inside of the DesktopKit and there's no API you can use to ask the 
> DesktopKit to create you one. If it were to expose that, you could then 
> wrap a scripting language around it. But should we really expose such 
> things? I doubt the Fresco architects will like it much.

uh, these commands are created by the desktopkit, and you are free to 
call them any way you want, on button-click, per script, whatever.

> Suppose we were to invent the Fresco Debugging System! What do we want 
> it to do? Just like gdb and inspect the registers and stack, and dump a 
> backtrace, what should fdb be capable of?

whatever the central state 'variables' are (the scene graph, for one),
should be exposed to that.


> While we're busy thinking about manipulating the scene graph in a 
> debugger, now would be a good time to point out that the same basic idea 
> is good for building a Fresco IDE as well. Except that you'd expect an 
> IDE to run inside of Fresco while the debugger should sit outside, but 
> that's a minor detail with a proper MVC design.

I don't agree with that at all, or may be I'm just confused about your
usage of 'inside' vs. 'outside'.
You can justify easily why a debugger needs inside knowledge of the 
server (much like you need to compile with -g in order to use gdb), but
I can't see why an IDE needs to be anything but a normal fresco client.
You use it write fresco clients, which only use public interfaces 
anyways, so why would the IDE (as a convenience tool) need to know more ?

Regards,
		Stefan