Hi folks,
the Bitfrost spec only touches briefly on D-Bus. So I was
wondering ... At the very simplest, an activity could ignore the quit
message sent from the frame - is it going to get killed after a
timeout? Or, it could flood the D-Bus with a lot of messages.
So, are there general mechanisms in place to defend against this? As
I understand it, sharing "active documents" which contain code are
explicitly encouraged in the educational vision of the project. Or
does an activity that allows "active" documents have to provide their
own sandbox to try to minimize what the code could do? Like, if we
made D-Bus accessible to JavaScript in the browser, would that be a
Bad Thing? If we allowed Python as a scripting language in the
browser? Which I would find immensely cool.
The problem at hand for me is that we wanted to switch etoys to
handle d-bus itself for quite some time. This would, for example, get
rid of the Python wrapper which would free up some valuable system
resource. A few months ago everybody thought this was a good idea,
and actually encouraged to develop a non-Python activity, if only to
make sure the protocol used really is independent of the
implementation language.
However, this would potentially give direct d-bus access to every
etoy. I think it would not be worse than sharing a Python activity
that could cause havoc on the d-bus easily. But I'd like to hear
other's opinions on that.
- Bert -
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
