[Homeros] I: Linux Journal о Luwrain

[Nikita]

Здравствуйте, Michael Pozhidaev.

> С одной стороны, если пользовательские скрипты будут всего лишь
> ещё одним расширением, это не так мало, но с другой, другие
> приложения/расширения могут нуждаться в возможности скриптования для
> своих собственныхъ задач.

Это-то да. Я хотел услышать минусы включения скриптинга в ядро. Я-то вообще 
не вижу с этим проблем, поэтому и дилеммы не чувствую.

> Но нечто подобное является каким-то
> хитрым косяком Android'а, где, как я понимаю, народ поплатился особенной
> гладкостью отрисовки.  Кто сможет сказать, актуально ли это для нас,
> полагая, что гладкость отрисовки UI нам неважна, может взять с полки
> пирожок.

Проблемы скорости отрисовки в Android актуальны преимущественно для видео 
игр.
Для вывода текста на экран это вообще непринципиальные задержки, так что для 
Luwrain гладкость отрисовки может как проблема не рассматриваться.

> Ты не должен хотеть читать/писать конфигурационный файл, потому что тебе
> будет выделено место в реестре, куда ты всё и сохранишь под строгим
> нашим контролем.

Ну это уже произвол. Может у меня общесистемная база данных в виде 
какого-нибудь CSV, в которую я что-то хочу записывать и из которой хочу 
что-то вычитывать, а потом это использовать вне Luwrain. А ещё может я хочу 
что-нибудь подсосать из Интернета, а писать для этого целое приложение - это 
больно жирно.
Как насчёт скриптов, которые будут, например, читать VCF-файлы и 
импортировать их в адресную книгу Luwrain, или наоборот делать обратный 
импорт. Нужная же вещь, а ты бьёш по рукам.

> Думаю, что дело кончится тем, что будет заведено
> несколько типов скриптов с разными полномочиями.

Мне кажется, логичнее единые скрипты, просто со списком разрешений.
Если какой-то скрипт хочет иметь доступ к файлам, я могу ему это просто не 
разрешать и тогда у него там будут просто возвращаться null или что-то 
подобное, короче тупо отваливаться этот функционал.
На Android или iOS сейчас примерно так и сделано с приложениями.
Успехов. Никита.