Re: [Fresco-devel] scripting

Sean Rae <[email protected]> writes:

> as retorted by Stefan:
> > I'm trying to imagine what you have in mind when talking about
> > scripting. Of course, there are python bindings for Fresco,
> > allowing you to write Fresco programs in python (and of course,
> > all other languages that have CORBA bindings).

Since it's so radically different from anything Xish, it's probably a
mistake to think about Fresco this way. What better place to say
something dumb than a public mailing list that's archived on the web? 

In any event, I imagined something like the API exposed by a window
manager. For instance, the blackbox/bbkeys relationship. blackbox
exposes some basic functions that allow you to manipulate the state of
the window manager (manipulating window positions, maximizing,
minimizing and killing windows, and so forth). bbkeys is a really
simple key-grabber that knows how to (a) make calls to blackbox and
(b) parse a configuration file. 

The code overhead for the arrangement is miniscule. blackbox already
has, for instance, a callback function to maximize a window. All that
is needed to allow bbkeys to work is a mechanism to invoke those
callbacks manually (if you can forgive my abuse of the term). So,
blackbox listens for certain mouse events from X (clicking the
maximize button) to trigger the callback. It's also possible to
short-circuit X and invoke the callback from blackbox's API. 

Of course, in Fresco, Things Are Different, so the analogy probably
doesn't map very well. But, it might be of some interest to be able to
manually invoke callbacks in Fresco in some orderly way. Or perhaps
just a few high level callbacks. 

That way, the "shell" wouldn't be part of Fresco at all. It would sit
off to the side. 

> [...snip...]
> > However, this may not be exactly what you are looking for,
> > i.e. write single clients that ask the server for a suitable
> > UI. You seem to want something to introspect and manipulate the
> > server's current state.
> Exactly.  Something to make (y)our lives easier.  It could be a
> resident program in the server address space that keeps track of
> current state variables and can be en/dis-abled with a configure
> flags... possibly?

I'm pretty certain you'd want this for debugging only. Using it to
port bbkeys to Fresco would be ridiculous. 

> > That's an interesting (and not so easy) thing, as there are quite a
> > number of delicate issues to deal with, such as security concerns.
> > What should a client be able to see ? How can it authenticate and how
> > should the server classify credentials to be able to decide what data
> > to expose ?
> At first, I had imagined a special-case shell that had complete access,
> like a fresco-ish root shell.  But a user-mode shell might be useful too,
> but like you said, it would be delicate.  Anyone have any ideas on models
> to go by?

Presumably, the shell would be running with the same UID that invoked
the server. Again, this is probably a dumb idea:

Right now, you can write programs in Python that can behave as Fresco
applications. These would be using Fresco's normal bindings, and would
behave as regular client applications. 

This Other Thing would probably bypass all of the shiny ORB stuff and
invoke (for instance) UI callbacks or something. Even if all it could
do was simulate the user clicking on the destroy button on a window,
you could still design some interesting tests.

So the standard APIs would talk to the server "from below," where as
This Other Thing would talk to the server "from above." 

I need to hunt down the relevant code in the Fresco project before I'd
call this anything other than a crackpot idea. 

> I guess our two choices are:
> a) build a resident server for the shell with clients that can
> connect and have restricted access dependant upon security levels of
> the user or

I suspect that this would be best done as a regular old Fresco
application. You'd just use Normal Means to give it the necessary
privileges. Quite useful, but not actually part of Fresco.

> b) we could have a single process that has complete access that you
> can have unrestricted access, something just for developers.  I
> guess it depends on how useful a user shell would be...?

I think they'd really be different animals, and that they'd both be
useful. You wouldn't really use AppleScript to debug System 7, would
you? And you probably wouldn't use MacsBugs macros (or whatever they
were called - it's been so long since I had a Mac) to automate your
desktop. 

Since System 7 didn't have any memory protection, or even an inkling
of privileges and authentication, you could accomplish similar things
with both tools with enough effort. But you wouldn't want to use a
debugger macro to invoke toolbox hooks to dial your modem and fetch
your email. 

Not that I did that. 

OK, I was 14 at the time. Cut me some slack. 

> > The basic architectural framework is already there, i.e. you
> > create a ClientContext and let it negotiate with the server to
> > receive a ServerContext, which you then use to talk to the
> > server. It's this ServerContext's job to allow or refuse any
> > further communication, such as kit creation.
> Looks like I have some reading to do... :)

Ditto. ^_^

> > May be it would be interesting to think further in that
> > direction...
> I think KDE is the most prominent proof-of-concept for this with
> their shell.  I like the idea of writing a shell script that can
> change the background or open up particular alert windows or
> whatnot.

There's also AppleScript and VB Script. You need look no further than
VB Script's most widely used programs (SirCam, Melissa...) to
understand why it's important that any such macro/scripting utility
take advantage of Fresco's authentication structure, and that it
should _not_ be integrated into Fresco itself. 

By that rational, FrescoScript should be a Fresco application with no
special hooks. You'd actually want to _deprive_ it of access
privileges granted to normal applications. Of course, you can probably
achieve all of that with Python, as Stefan pointed out. The world
probably does not need another scripting language.

On the other hand, you'd invoke debugging shell "from above."
Authentication and privileges wouldn't really come into play, except
on the OS level. If someone manages to run malicious code in the
debugging shell, they've rooted your box anyway. At least this way
they could pop a pretty little Fresco window that says "1 0wnz U!" or
"j00 d13 f00!" before they run "halt -w; rm -rf /*; halt -n" or "dd
-bs=1024 -if=/dev/random -of=/dev/hda" on your box.

> as said by Russell Neches:
> > It would also make it absurdly simple to invent and implement
> > torture-tests, and other debugging sorts of things. (I wonder how
> > many windows we have to pop up before the server keels over?)
> Awesome idea.  The only thing is: could we not do this just as
> easily with a suite of python test cases?  They're just as well
> adapted for quick prototyping and testing...  Now that I'm thinking
> about it, I haven't seen any test suites in the CVS tree.  Am I
> missing them or are they not written yet?

Thanks!

I think there is something kind of like that, although I've never run
it myself. Unfortunately, at the time I looked at it, it was so
effective at testing Fresco (then Berlin) that on my system it simply
locked the server. I assume that progress has been made since. ^_^

Russell Neches

PS - FrescoScript: you heard it here first. I hope I don't regret
that. ^_^