Скрипты клиента или сложный вопрос безопасности и выбора языка для скриптов.

Ну на главной странице про Lua пишут :) Вроде с производительностью там всё нормально, контролировать AFAIK можно всё что нужно.

Мне тоже сразу Lua в голову пришла. :) Чего-чего, а песочницу там устроить элементарно.

!#/usr/bin/perl -wT

perldoc Safe, в принципе.

Хотя я бы, действительно, смотрел на lua скорее - хотя граблей в нем поналожено, говорят, немало. Ну и JS бы не отбрасывал - язык-то хороший, а производительность для client-side скриптинга редко так уж важна.

> хотя граблей в нем поналожено, говорят, немало

Кто говорит? И вообще какого рода грабли? В плане безопасности песочницы их нет и быть не может. Выдаёшь программке только те функции, что ей нужны, и всё. Lua маленькая, в ней легко разобраться, perl же настолько огромен и запутан, что вряд ли можно быть уверенным, что ты действительно отрубил скрипту _все_ возможности нагадить.

Наверное forth тоже неплох в этом смысле, но сдаётся мне, что среднестатистическому "кому угодно на стороне" lua покажется гораздо более простой для освоения. :)

Я бы выбрал scheme

>!#/usr/bin/perl -wT

И как потом из Перла юзать объекты вызвавшего окружения? :)

>Наверное forth тоже неплох в этом смысле, но сдаётся мне, что среднестатистическому "кому угодно на стороне" lua покажется гораздо более простой для освоения. :)

Да, на эти грабли уже наступалось :)

В тикле замечательно - safeTcl рулит. Плюс синтаксис элементарный, дальше ехать некуда. В Common Lisp можно подобное забабахать, но уже более сложным путём - собственный пэкедж, плюс запрет на использование префикса. В Scheme сравнительно легко.

bash in chroot?

>bash in chroot?

Под виндой? И как потом из этого чрута управлять 3D-объектами вызывающего клиента?

...

Вообще, чем дальше, тем больше мысли к JVM склоняются. Широкий выбор разнокалиберных языков, отработанная система безопасности на Java-апплетах, приличная производительность...

Но тогда возникает большая проблема с имеющимися планами писать клиент первого этапа на Питоне. А войну с нашими Питонерами я не выдержу :D

Погугли на тему python restricted execution - может, подойдет.

Такое ощущение, что ты еще до поста решил с jvm работать :) Зачем тогда спрашивать?

а как же jython?

У руби тоже есть механизм защиты. Не жабский, конечно, но есть.

>Такое ощущение, что ты еще до поста решил с jvm работать :) Зачем тогда спрашивать?

Мне очень хочется, но нужно себя ещё убедить. И не только себя :) А так - изначально первый этап планируется на Питоне... Но дальше я уже писал выше :)

>а как же jython?

Он пока только 2.2

А Питоновские программеры не признают Питона < 2.4 :)

Ну пусть доработают до 2.4:) А для не очень сложного скриптования и 2.2 вполне достаточно.

>Какие есть ещё альтернативы?

А ещё есть HaskellScript...

''' Правда он похоже сдохнет. Но идея хороша. '''

А чего с lua-то не так? Или ты её просто не знаешь? Потрать несколько часов. Это ровно её domain.

Кстати да, afaik unrealscript и есть lua. Можно взять cquake из quake:)

>Или ты её просто не знаешь? Потрать несколько часов.

Изучить синтаксис языка и изучить особенности его привязки - это два порядка разницы :) Впрочем, посмотрю, конечно... Правда, ещё есть LuaJava :D

> python restricted execution - может, подойдет.

Вряд ли. С этим всё очень плохо. Python'овцы на это в результате положили с прибором.

> ещё есть LuaJava

Не смотрел, конечно, но это какое-то извращение.

> > хотя граблей в нем поналожено, говорят, немало

> Кто говорит? И вообще какого рода грабли? В плане безопасности песочницы их нет и быть не может. Выдаёшь программке только те функции, что ей нужны, и всё.

Грабли в языке. Люди, писавшие на нем довольно сложные системы (AI-скриптинг коммерческой игры) говорят, что есть неочевидые проблемы с семантикой-синтаксисом самого языка. Типа ты думаешь, что написал одно, а на самом деле оно молча делает другое.

> Lua маленькая, в ней легко разобраться, perl же настолько огромен и запутан, что вряд ли можно быть уверенным, что ты действительно отрубил скрипту _все_ возможности нагадить.

в perldoc Opcode все неплохо расписано. Всего-то ~350 опкодов.

> Наверное forth тоже неплох в этом смысле, но сдаётся мне, что среднестатистическому "кому угодно на стороне" lua покажется гораздо более простой для освоения. :)

Вероятно.

Действительно , почему не руби ?
Песочницу довольно просто на нём реализовать , типа http://tryruby.hobix.com/ и www.ruby.ch

> неочевидые проблемы с семантикой-синтаксисом самого языка. Типа ты думаешь, что написал одно, а на самом деле оно молча делает другое.

Как-то это неконкретно. Я почему интересуюсь: я его маленько юзал (хотя до реального применения дело не дошло), и я просто не очень понимаю, что там может быть неочевидного? По нему есть ровно две книжки, которые надо прочитать, это занимает день, ну от силы два. После этого никаких вопросов по-моему быть не может в принципе. Вот мне и интересен пример хотя бы одной такой грабли. Может я где-то не там ходил. :)

Ruby с его safe level будет хорошим выбором.

посмотри язык E http://www.erights.org/ -- делали как раз для твоих целей. красивый ООП без классов, безопасность через контракты, и (любимая?) jvm в одной куче. а что еще нужно для щастья?... :)

думаю, что универсального способа на уровне "какой язык" - нет.
По-видимому, решается только через VM (virtual machines)

все эти safe level в php, ruby etc.
всего не учитывают и легко обходятся

луа не такая. :)

> Как-то это неконкретно. Я почему интересуюсь: я его маленько юзал (хотя до реального применения дело не дошло), и я просто не очень понимаю, что там может быть неочевидного? По нему есть ровно две книжки, которые надо прочитать, это занимает день, ну от силы два. После этого никаких вопросов по-моему быть не может в принципе. Вот мне и интересен пример хотя бы одной такой грабли. Может я где-то не там ходил. :)

Ну мопед не мой, я сам на Луа не писал. Я вообще против него ничего не имею - просто предупреждаю, что your mileage may vary.

В качестве примера приводили что-то в духе того, что в старых версиях ruby код return a + b парсился как return(a) + b. Делал он, соотвественно, нихрена не то, что подразумевается. Конкретно это, кажется, исправили - но вроде, на что-то еще такого плана жаловались.

s/ruby/lua/

конечно же.

Ну это значит баги в самом интерпретаторе. Далеко не факт, что в новых версиях это баги остались.

не, это был баг в языке - вот такие странные там правила приоритетов. Пофиксили это тем, что return теперь обязательно требует скобки.