Re: [Fresco-devel] scripting

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).
Rather than "scripting", "debugging shell" might be more accurate of what
I had imagined.  We could most likely use python to write it, since it's
so easy to use (I'm newly exposed to the wonders of python).

> 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?

> 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?

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
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...?

> 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... :)

> 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.

------------------------------------
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?


 - - - - - - - - - - - - - - - - - -
           Sean Rae / es9
        cool and calculating
       www.birdnest.org/raes1
 - - - - - - - - - - - - - - - - - -