Language agnostic scripting framework architecture
==================================================

Author: Laszlo Kovacs

1. Project goals 
----------------

1. Provide a language agnostic scripting framework  specification
and implementation that allows compiled and interpreted scripting
engines to be plugged into StarOffice. This includes support  for
plugging in various IDEs.

2. Integrate in the framework described at (1) a scripting engine
for  scripts  developed in JAVA and a scripting engine for a JAVA
based scripting language.

3. Select an IDE and integrate it into the framework described at
(1).   Implement  command  line  tools  that  duplicate  the  IDE
functionality (for script  developers  who  prefer  command  line
environment).

4.  Refactor  the  current   StarBasic   scripting   engine   and
environment  so  that  it  is plugged into StarOffice through the
framework described at (1). Decision has to be  made  about  what
kind  of  IDE  to  provide (the old one or integrate with the new
one).

2.Language agnostic scripting framework
---------------------------------------

This section deals with the first item of the project goals.

The main components of the language agnostic scripting  framework
are described below.

2.1 Runtime environment 
-----------------------

A language agnostic  runtime  environment  has  to  allow  script
engine  developers  to plug in script engines (runtime instances)
of compiled or interpreted languages.

Runtime instances have to be managed by a runtime  manager.  They
need  to implement interface(s) through  which the associated VM,
interpreter can be started, stopped, identified, status  queried,
configured.

Runtime instances have to be easily deployable  into  StarOffice,
implementation  as  UNO  components  or  using  UNO wrappers will
achieve this.

Because  of   the   specifics   of    individual   VM/interpreter
configurations  the  runtime implementation will probably have to
provide its own specific configuration tool.

Runtime services that are common for every runtime and should  be
part of the scripting framework implementation are:

1. If compiled scripts are deployed by source then they will have
to  be compiled before running. The location of related compilers
have to be discovered for this, probably configured  through  the
configuration tool.

2. Executed scripts have to be provided with context. This can be
obtained from the storage service or can be assigned dynamically.

3. Lifecycle services: resources acquired by the script  have  to
be tracked and cleaned up after execution.

4. A sandbox could be provided for managing script resources  and
access  permissions  to  the  file system and StarOffice services
granting  various  rights  to  scripts.  However  this  might  be
difficult  to  achieve  in  a  language  agnostic  way. A simpler
approach  is  described  in  the  "Binding  to  events"   section
(signatures).

5. Defining a state persistence service is a  simple  matter.  In
case  of  languages  that support persistence StarOffice specific
persistence services can be hidden from developers.

6. Single threaded scripts  have  to  be  safely  usable  in  the
multithreaded  StarOffice  environment.  A simple approach of not
running two scripts at the same time in the same context  (Single
Threaded Apartment model) might be enough here.

2.2 Binding to events ---------------------

A binding UI (part of StarOffice) has to be  provided  for  users
who  use  scripts  developed  by  script developers. This UI will
allow binding of scripts and script methods to StarOffice events.
The  binding  UI  should  navigate  scripts  developed in all the
supported languages.  This can be achieved with a generic  naming
scheme  that   easily  maps  to  the  supported  languages naming
schemes. Deployment information is needed to describe the methods
implemented  by  a  script  (depending  on  languages this may be
automatically generated from the script). The binding UI also has
to facilitate parameter passing to scripts.

It  might  be  preferred   to   provide   very   simple   editing
functionalities in the binding UI so that a script can be changed
and saved by the user before it is run.

Security related issues in this case are:

1. If scripts are provided by source they  may  be  encrypted  so
that  only  certain  users can run them. The binding UI has to be
able to decrypt them based on passwords provided by the user.

2. Scripts have to be prevented of harmful behavior. This may  be
achieved  by  a  sandbox  type  of  approach  implemented  in the
runtime. This however might be difficult  to  achieve  for  every
language in a language agnostic way.

An alternative approach is similar to the Java applet signatures.
Scripts  can  contain  a  signature from a trusted source meaning
that they can be trusted. It would be up to the  user  to  decide
whether  scripts  are  run  or  not based on their signatures. If
scripts are run they would have  full  access  to  resources  and
StarOffice  services.  An extension to this where trusted scripts
would be granted with more resources and possibilities  than  not
trusted ones might be difficult to implement.

2.3 IDE services 
----------------

Developers  need  an  IDE  or  simple  command  line  tools   for
development.  The  development  tasks these tools have to support
are accessing/editing/storing code,  compiling,  debugging,  code
encryption/decryption (see "Binding to events").

The  scripting  framework  has  to  include   specification   and
implementation   of   services   that   will   support   the  IDE
functionalities.  These  are  storage,  debugging  and  compiling
services.  Encryption/decryption  services are simple and will be
shared between the binding  UI,  the  IDE,  the  macro  recording
component and possibly the runtime environment.

The compiling service supports easy plug in of various  compilers
for  compiled  languages. Apart from the IDE another higher level
component  that  needs  the  compiler  service  is  the   runtime
environment,  in  case scripts are deployed by source and need to
be compiled before being run.

Explicit   debugging   services   (breakpoint   setting/clearing,
variable  evaluation  etc.)  need  to  be defined. Some debuggers
(JVM) allow direct connection of the IDE to them,  with  no  need
for a special debugging service.

Access/edit/save of scripts,  their  deployment  information  and
context  has  to  rely  on  the  script  navigation  and  storage
services. No extra  services  have  to  be  defined  here.  These
services (especially assigning context) have to be shared between
the IDE and the binding UI.

2.4 Script navigation and storage
---------------------------------

Script storage is a lower level service that most  of  the  other
services  will  rely  on. IDEs and command line development tools
will have to load, edit, save scripts. The binding UI  will  have
to  be  able  to  navigate  through the scripts, their deployment
information and context. Runtimes will need to  locate  and  load
the scripts that are selected for execution.

A storage service has to implement access, navigation and  saving
of  scripts,  their  deployment  information  and context for all
supported languages, interfaces will have to be defined for this.

The approach of script storage in relation to documents  and  the
application  has  to  be  defined. Scripts can be part of related
documents or referenced  from  documents.  The  application  wide
scripts  will  have  to  be  stored in an application rather than
document specific area.

2.5 Macro recording 
-------------------

Macro (script) recording has to be  supported  by  the  scripting
framework.  The  sharing  of responsibilities between StarOffice,
the scripting framework and  language  specific  macro  recording
components has to be researched.

3. IDE implementation and command line tools
--------------------------------------------

This section deals with the third item of the project goals.

The main issue here is whether the preferred solution is  to  use
an  IDE framework (such as NetBeans) to develop the IDE or an IDE
is developed from scratch (for example using JBuilder).

IDEs will use the compiler service and the debugging service  for
development.  They  will  use the storage service to edit scripts
and to deploy scripts in various contexts (assigned to  documents
or  application wide). The part of the IDE that is implemented on
top of the storage  service  has  to  be  more  complex  than  an
ordinary file selection box as it has to access and store scripts
in relation to various contexts.

Close integration  between  the  binding  UI,  the  IDE  and  the
debugging   services   is   needed   for  script  testing  during
development. After a script  has  been  saved  (with  a  specific
context),  developers have to be able to bind it to an event, run
it in a debugger and set breakpoint or evaluate variables through
the IDE.

Editing command line tools will have to implement easy extraction
and  saving  of  scripts  in  document  and application contexts.
Command line compiling does not need extra support. Command  line
debugging  needs  support  for  setting the script context before
running and cooperation with the binding UI.

An important feature of an IDE is a GUI  builder.  Modern  script
environments  include  GUI  builders.  In  the  language agnostic
context the main issues are whether a  language  independent  GUI
building  framework is feasible, and what effort will this put on
developers to learn yet another UI  API.  Alternatively  the  GUI
builder   can   be  deferred  to  the  individual  script  engine
implementations. The possibility to achieve similar look and feel
to StarOffice is important in this case.


4. Architecture diagram 
------------------------

This  diagram  tries  to  capture  both  the  language   agnostic
scripting  framework and the integrated IDE. It contains only the
components and their  relationships  (connecting  lines  describe
relationships), not what services the components provide.

It does not deal with  the  security  related  issues  of  script
execution (the sandbox vs the signature approach).

In case of the signature approach a signature service has  to  be
provided  that  allows  scripts  to  be  signed whenever they are
created (IDE, macro recording)  and  to  retrieve  the  signature
before assigning to an event (binding UI).

In case of the sandbox approach the common runtime services  have
to  be  extended  with  the sandbox implementation and a security
configuration UI provided that configures the sandbox. This could
be built on top of the signature approach.


























