[Bf-python] Blender scripting API

[Stephen Swaney]

On Mon, Apr 13, 2009 at 04:24:21PM +0200, Antti Siponen wrote:

> I just had in mind an idea/voice that says:
> 
> "Why do we have the C/Python/C marshalling hardcoded into the API
> functions?" (Or do we? At least it seemd so to me)
> 
> ...
> 
> For example if I wanted to try out some Fran modelling scripts with blender
> I would have to compile Blender to kick a haskell intepreter instead
> of the python one and do
> some extra marshalling too. Many languages have ready thought-out
> marshalling procedures
> for interfacing with C, but not for example with Python.
> 
> So what I propose is that we could have the scripting API exposed as
> C-calls and have a separate
> marshalling parts for interfacing it with the scripting language (Even
> with Python, even if we have a
> Python interpreter inside)

I am somewhat confused by your use of the word 'marshalling'.
Traditionally, this means to serialize a data structure or object in
order to stream it over the wire or to disk.

Essentially, what you are talking about is being able to embed another
scripting language and use it to call Blender's internal API.  The
main problem with this idea is that there *is* no Blender API to wrap
directly - although the 2.50 project will change this.  People who
want to use Blender as a shared library or .dll face the same issue.

Blender was written directly as an application and not as a library
for use by other programs.  This limited what we were able to easily
accomplish with the current Python API without rewriting major parts
of Blender - a task we did not want to take on at the time.  The job
was made more difficult due to Blender's UI code and database
manipulations often being intertwined and the lack of a notification
mechanism.

Because of this, our BPy focus was on providing the facilities to
write importers and exporters so Blender could be used as part of a
tool chain with other applications.  Interactivity was not an original
requirement and is an obvious place where the current design falls
short.

The current 2.50 project is focused on refactoring Blender's event
handling subsystem.  This work will separate the UI code from data
manipulation functions and provide a notification or signaling mechanism.
This will provide you with the basic features you need.  But embedding
another interpreter and moving the data in and out of it will still be
up to you.

-- 
Stephen Swaney			
sswaney at centurytel.net