glob2-devel
[Top][All Lists]
Advanced

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

Re: [glob2-devel] Embedded scripting language (again)


From: Martin Voelkle
Subject: Re: [glob2-devel] Embedded scripting language (again)
Date: Sun, 26 Feb 2006 11:51:53 +0100

> IMHO, a far better solution would be to use Stackless Python[1]... a python
> implementation that doesn't use the C stack.  It supports microthreads[2],
> along with serializing them in the middle of execution[3].  (This is really
> all we need.)
>
> One thing to note is that stackless does not yet support python2.4.  However,
> this is planned for a PyCon sprint[4].

Great! So at least it looks possible.

> >   Cons:
> >     1) Is a large dependancy
>
> In the case of stackless, it would be worth considering including it in the
> distribution, especially as it doesn't have a release.  This is how Blender
> and (I assume) EVE Online[5] do it.  (Although, Blender uses standard
> CPython.)  This would also allow cutting out unneeded modules.  (Who needs to
> decode MIME email headers in a map script???)

Stackless is a whole python distribution. I don't know if it can be
used throught boost.python... But that would just mean having to bind
using a C API.
I've seen that CherryFlow (a python lib) requires either Stackloess or
Statesaver, a single-file c plugin. Could we use that small plugin
instead?
http://subway.python-hosting.com/wiki/CherryFlow

> >     2) Can allow a hacker access to the underlieing system if he/she
> > is experienced enough and willing to work around all inplace security
> > features (python does have them)
>
> It might be better to say that python _had_ them.  The restricted execution
> framework was disabled in python2.3[6].
>
> Perhaps omitting the 'os' and 'sys' modules and the 'file' type would be all
> that is necessary.  At any rate, Blender had a _browser pluggin_ that would
> execute python code, so it's not like glob2 would be the first.

Blender does it:
http://www.blender.org/modules/documentation/publisherdoc/pythonsecurity.html

> I think that from a technical standpoint, python would work.  The question I
> see now is, "is it overkill?"  Although I would love to use my favorite
> language in my favorite computer game, Lua or Tea might work just as well,
> with far less overhead ... so ... I guess I'm not being much help here :D

Problem is both Tea and Lua use the C stack.

So go ahead, create a branch and try python!

Martin




reply via email to

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