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

SoulKeeper> А какой вообще доступ к серверу может быть у клиентских скриптов?

В первую очередь - это работа клиентских скриптов написанных одним пользователем на машине другого.

Грубо говоря - товарищ А. делает некий объект Б. со скриптами В. и передаёт его товарищу Г., который у себя его использует.

Для открытой системы это очень важный (и очень конкурентнодавительный) момент.

...

Опять же, ближайший аналог - тот же Web. Когда разработчик сайта пишет у себя на сайте JavaScript, выполняющийся в брайзерах заходящих к нему людей.

У нас же подразумевается более широкая трактовка. Если сторонний дизайнер сделает складную табуретку, то ему для введения её в мир не обязательно делать это через владельцев сервера. Он просто пишет 3D-модель и скрипт для управления моделью и вводит вносит в мир с собой. Потом может передать её другому. Или продать

Murkt> Java-апплеты это мертворожденный вариант. Их сейчас никто не использует, и на то есть причина, ИМХО.

Потому что мало кому нужна такая защищённость

Murkt> Честно сказать, не вижу вообще нужности в клиентских скриптах.

Так как ты будешь реализовывать функционал тех или иных внутримировых изделий? Они у тебя что, все статические будут?

Murkt> Да - пусть расширяют клиент, но распространять их нужно только центрально после проверки.

Не катит.

1. Никто просто физически будет не в состоянии проводить все такие проверки.

2. (самое важное) - кроме нашего будут и иные миры. Где, в таком случае, у владельца сервера будут ВСЕ возможности добраться до потрохов чужой машины. Это изначально крайне дискредитирует саму идею нашего проекта.

Murkt> Если ты весь клиент пишешь на Питоне, я не вижу способа как ты можешь запретить скриптам работать не в песочнице.

А что, в Питоновском скрипте можно запретить, скажем, доступ к файлам пользователя? Кроме того, Питон - это очень узкое ограничение. Ладно, клиент и сервер, их будет писать централизованная команда. Но скрипты - это то, на чём будет держаться весь мир. Они должны быть, с одной стороны, унифицированы, с другой - должен быть максимально возможный выбор разных подходов. JVM это обеспечивает. Питон в нынешнем виде - нет. JVM - это десятки языков. Питон - это только Питон. JVM - это годами оттачиваемая безопасность. Питон - это общая идеология "скрипту доступно всё".

Разве что подождать ещё лет 10 и дождаться Parrot?

SoulKeeper> Вывод - пишем на java

У нас очень мощное Питоновское лобби

Кроме того за Питон у нас два объективных факта.
1. На нём проще писать.
2. python-ogre разработан намного лучше, чем ogre4j.

Murkt>> Java-апплеты это мертворожденный вариант. Их сейчас никто не использует, и на то есть причина, ИМХО.
Balancer> Потому что мало кому нужна такая защищённость

Потому что в вебе есть более адекватные решения - джаваскрипт и флэш

Murkt>> Честно сказать, не вижу вообще нужности в клиентских скриптах.
Balancer> Так как ты будешь реализовывать функционал тех или иных внутримировых изделий? Они у тебя что, все статические будут?

Дай пример нестатического внутримирового изделия, которое ты можешь позволить ввести рядовому игроку непосредственно в игру? Учти, что у тебя всё-таки игра, а не лукьяновская глубина.

Murkt>> Если ты весь клиент пишешь на Питоне, я не вижу способа как ты можешь запретить скриптам работать не в песочнице.
Balancer> А что, в Питоновском скрипте можно запретить, скажем, доступ к файлам пользователя?

Удалить это из библиотеки, которая доступна скрипту... Правда, я пока не знаю как это можно сделать Меня посещали мысли насчёт статического анализа кода. А можно попробовать переопределить для этого кода builtin функции. Экспериментировать надо - я уверен, что можно найти решение.

Balancer> Кроме того, Питон - это очень узкое ограничение. Ладно, клиент и сервер, их будет писать централизованная команда. Но скрипты - это то, на чём будет держаться весь мир. Они должны быть, с одной стороны, унифицированы, с другой - должен быть максимально возможный выбор разных подходов. JVM это обеспечивает. Питон в нынешнем виде - нет. JVM - это десятки языков. Питон - это только Питон. JVM - это годами оттачиваемая безопасность. Питон - это общая идеология "скрипту доступно всё".

Сначала скажи мне, нужна ли всё-таки такая функциональность. ИМХО - нет.

SoulKeeper> Ага, лутше Сколько там ФПС под линуксом было?

Оно по крайней мере есть А ogre4j в работающем виде у меня элементарно сейчас нет. Есть куча несобираемых исходников

Murkt> Потому что в вебе есть более адекватные решения - джаваскрипт и флэш

Сам понимаешь, что флеш нам не подходит. А вот адекватный JavaScript - опять на JVM. Rhino зовётся

Murkt> Дай пример нестатического внутримирового изделия, которое ты можешь позволить ввести рядовому игроку непосредственно в игру?

Я уже приводил пример - складная табуретка. Одним 3D ты ничего не сделаешь, нужна активность.

Играющий IP-канал радиоприёмник, трансляция видео в телевизоре, самодельный велосипед и т.д. и т.п...

Murkt> Учти, что у тебя всё-таки игра, а не лукьяновская глубина.

Мы делаем всё-таки не игру. С ориентацией на одну только игру мы обречены с самого начала Наша задача - интерактивный открытый виртуальный мир. Это, всё же, гораздо ближе к Диптауну, чем к любой, самой продвинутой ММОРПГ

А ставку на насыщение нашего мира как раз собираемся делать на сторонние разработки.

Murkt> Удалить это из библиотеки, которая доступна скрипту... Правда, я пока не знаю как это можно сделать

Вот в том-то и проблема, что то, что уже реально работает в Java, в Питоне нам придётся ещё изобретать и изобретать...

Murkt> Сначала скажи мне, нужна ли всё-таки такая функциональность. ИМХО - нет.

ИМХО, у нас очень и очень многое будет на такой функциональности базироваться. Любой нестатический объект потребует скриптования. Вводить эти объекты централизованно - я уже писал выше. И ресурсов не хватит, и дискредитация идеи сторонними серверами.

Balancer> Оно по крайней мере есть А ogre4j в работающем виде у меня элементарно сейчас нет. Есть куча несобираемых исходников

Пойду взгляну на них. Смущает org.eclipse...

SoulKeeper> Смущает org.eclipse...

У них сейчас много библиотек, не связанных с Eclipse. Ну, как org.apache не обязательно связаны с tomcat

Murkt> Вот в том-то и фишка, что на то, что нам придётся изобретать в Питоне, придётся потратить меньше времени и усилий чем на то, чтоб разобраться и заставить работать то, что написано в Java

Зато потом на JVM смогут писать гораздо больше людей, чем на Питоне. Ибо Питон - это Питон, а JVM - это Java, JRuby, Jaskell, LuaJava, Jython, Groovy, Rhino (aka JavaScript), PHP, Tcl, JBasic, JScheme и т.д. и т.п.

...

Жалко, всё же, что Jython сейчас только 2.2, был бы он хотя бы 2.4, вопрос бы сам собой решился

Balancer> Да, ещё и JBForth у меня будет, таки, генерировать байткод и нативные Java-классы

И когда это чудо будет работать :)?

Balancer>> Ибо Питон - это Питон, а JVM - это Java, JRuby, Jaskell, LuaJava, Jython, Groovy, Rhino (aka JavaScript), PHP, Tcl, JBasic, JScheme и т.д. и т.п.
Murkt> Ничего подобного. Для каждого из этих языков тебе придётся тащить за собой его библиотеку. Скажем о потреблении памяти? По двадцать мегабайт для каждого из двух десятков языков минимум.


На дворе 2007-й год плавно переходящий в 2008-й. К 2010 если что-то и получится, то память в 4 гига будет стандартом на десктопах(если не больше). Так что сотня-другая ничего не изменит.

Реально нужна практичность, а не память Да и 4-х ядерники стоять будут почти на любом геймерском компе.

Murkt> Ничего подобного. Для каждого из этих языков тебе придётся тащить за собой его библиотеку.

Это в скриптовом варианте. Многие же из них умеют делать нативные Java-классы.

И в любом случае, закинуть клиенту библиотеку на фоне гигабайтных 3D-объектов - это мелочи. И этот вопрос как раз можно решать централизованно

Murkt> Скажем о потреблении памяти? По двадцать мегабайт для каждого из двух десятков языков минимум.

Ну, мой JBForth, например, очень редко больше сотни-другой килобайт оперативки жрал В любом случае, расход памяти - это не то, чем должен Питон гордиться

SoulKeeper> И когда это чудо будет работать :)?

Не думаю, что очень скоро. Ибо пишется не с практическими соображениями, а на интерес. Точнее, ещё не пишется, только концепция продумывается. Ибо там многое будет отличаться от классического Форта.

...

Кстати, идею разнокалиберных языков, способных генерировать Java-классы, можно на L2F обкатать

Murkt>> Ничего подобного. Для каждого из этих языков тебе придётся тащить за собой его библиотеку.
Balancer> Это в скриптовом варианте. Многие же из них умеют делать нативные Java-классы.
Balancer> И в любом случае, закинуть клиенту библиотеку на фоне гигабайтных 3D-объектов - это мелочи. И этот вопрос как раз можно решать централизованно

Всё равно будет дурдом. Тебе для каждого языка придётся делать такие-сякие обёртки, защиты, етц. Я - против многоязычия. Кто захочет что-то привнести в мир - даже в ассемблере разберётся, а мы "заставим" его выучить всего-лишь часть Питона - один из самых простых языков для новичка.