discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Talking to GNUstep (in many languages)


From: Stefan Urbanek
Subject: Talking to GNUstep (in many languages)
Date: Sat, 15 Sep 2001 16:39:02 +0200 (CEST)

Hi all,

There was an idea to create general - language independent scripting
framework for GNUstep. Here is a sketch of such framework. 

Idea is to have applications, that can execute scripts or just one-line
statements in any available scripting language. 

Scripting Environment
---------------------

An application will prepare scripting environment by making some of apps
objects available by some name. 

ex.:
        STEnvironment *env;
        
        [env setName:@"mail" forObject:mail];
        [env setName:@"subject" forObject:[mail subject]];
        [env setName:@"receiver" forObject:[mail receiver]];



Environment is something like language context, where script is being
executed. There are objects registered by name, so you can use them from your
script. Your application can have several environments. For example, one for
each document, mail...

ex. (Example is going to be a mail filter. Let mail filter by a association
between mailbox and a expression. Whe expression is true, mail goes to that
mailbox.):

    receiver == 'gnustep-dicuss@gnu.org'

or something like this:

    addressBook emailAddressesForGroupWithName:'firends'
                                      contains:receiver

Also, scripting environment contains method name alias/restriction. For
example, I've used method aliases to map Smalltalk bynary selectors to
gnustep methods, like when sending selector '@' to NSArray, it is translated
to 'objectAtIndex:'. With method restriction, you can deny some methods to a
class. This can be used to prevent creating script viruses. Your application
just denies methods of some classes not available for scripting. For example,
you can deny method for deleting files, allocating some kinds of objects...
This can be enabled or disabled, when it is disabled, I call it full
scripting - you can send any message to any kind of object. Application can
have environment description(s) in a file (example attached) or it can
allow/deny by 'hand' using STEnvironments:

  - denySelector:forObjectsOfType:
  - allowSelector:forObjectsOfType:
  - denyAllSelectorsForObjectOfType:
  - allowAllSelectorsForObjectOfType:

Scripting Engine
----------------

Scripting engine is used for executing scripts.

ex.: 

        STEgnine *engine /* say we already have this */;
     ...
     [engine   executeCode:filter 
             inEnvironment:[activeMail scriptingEnvironment]
                  language:'PerlTalk']
     ...

-   executeCode:(NSString *)code 
  inEnvironment:(STScriptingEnvironment *) env
       language:(NSString *)languageName

Next is for scripts with more methods:

- executeScript:(NSString *)script 
  inEnvironment:(STScriptingEnvironment *) env
       language:(NSString *)languageName

For some languages, they have to be separate methods, for some they can be
the same.


Engine and Languages
--------------------
The idea was, as also Lyndon mentioned before, to have "bundled languages".
Engine will load appropriate bundle for language, that is actualy needed. 

Application does not have to know anything about scripting languages. It is
the matter of user. But, user has to be able to specify the language used for
scripting in application. Or...there sould be a language autodetection. This
is difficult for simple statements, but I thing for large cote it should
work.

The interface between Engine and backend (bundled language)

- executeCode:inEnvironment:
- executeScript:inEnvironemnt:

- canCompileCode: /* can be used for language auto-detection when language is
nil or @"" or @"auto"... */

Scripting framework does not care, if the language is compiled, or directly
interpreted.

Language backend will just execute a script and send messages to objects. It
can use environment to get the real selector:

    STEnvironment *env; /* we have this */
    SEL            sel;
    ...
    sel = [env selectorFromString:selectorString forReceiver:target]
    ...

It will convert the selector name, or raise an exception, if selector is
denied.

Then you just prepare the invocation and invoke it.

In StepTalk there already some additions, that can be used:

NSInvocation
- (void)setArgumentAsObject:(id)anObject atIndex:(int)anIndex
- (id)getArgumentAsObjectAtIndex:(int)anIndex
- (id)returnValueAsObject

These two methods are converting between GNUstep objects (NSNumber,
NSString,...) and simple C types (int, char *, ...)


Languages and Language Bundles
------------------------------

Language bundles can be stored in

*_GNUSTEP_ROOT/Library/Scripting/Languages

It will be good, if there will be some kind of description of that language,
language aliases (objc, objective-c, objectivec,...)

Defaults
--------
Suggested defaults:

GSFullScripting (bool) - enable full scripting by default for all apps
GSDefaultsScriptingLanguage - default scripting language


Remote scripting
-----------------
The idea is to script application/server remotely. You connect to scripted
object, where an new scripting environment is created. Script is executed in
that environment. Application may customize the environment depending on the
caller or may limit number of scripting connections, etc... 

The method should be
-       remoteScriptingEngine
or there should be some authentification of caller.

Summary
-------
Application developers:

  STEnvironment interface
  - setName:(NSString *)name forObject:anObject

  - denySelector:forObjectsOfType:
  - allowSelector:forObjectsOfType:
  - denyAllSelectorsForObjectOfType:
  - allowAllSelectorsForObjectOfType:

   OR

  environment description file(s)

  STEngine interface
  -   executeCode:(NSString *)code 
    inEnvironment:(STScriptingEnvironment *) env
         language:(NSString *)languageName

Language backend developers:

  STEnvironment interface
  - selectorFromString:forReceiver:

  They have to implement at least theese methods:
  - executeCode:inEnvironment:
  - executeScript:inEnvironemnt:
  - canCompileCode:

I think, it looks simple, and it will be really nice to have gnustep
scriptable. Even better - to have it scriptable in many languages, like
Lyndon mentioned: StepTalk, WebScript, PerlTalk, RubyTalk, JavaTalk, (and why
not also EnglishTalk or FrenchTalk? :o) 

What do you think about it?


Stefan


PS: Also, how can it be named? My suggestion is something like "GNUstep
Talking", or just Talking.



___________________________________________________________
Do You Yahoo!? -- Un e-mail gratuit @yahoo.fr !
Yahoo! Courrier : http://fr.mail.yahoo.com



reply via email to

[Prev in Thread] Current Thread [Next in Thread]