|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Ruslan Kosolapov 2:5020/400 26 Nov 2004 01:14:42
To : Konstantin Tokar
Subject : Re: Дистрибутивы для конторы
--------------------------------------------------------------------------------
==[ Konstantin -> Ruslan:
KT>>> Хорошо. Тут поступило предложение встроить скриптовый язык в
KT>>> майлер. Какую пользу тебе принесло бы наличие такого языка, и
KT>>> какие потенциальные проблемы от оного же?
>> Очевидно, что встраивание скриптового языка в мейлер делает
>> возможным получить от этого мейлера функциональность, которая в него
>> не была заложена изначально.
KT> Hу, естественно. Вопрос - какой это ценой дастся.
Я считаю, что emacs - это правильное решение. То есть имеем какую-то
машину/framework, и на её основе имеем комплект скриптов, которые
умеют то, что надо. Кому не нравится - может либо всё переписать,
либо переписать только часть, либо заменить часть, либо добавить
что-то.
В этом смысле всякие COM/MFC/OLE/etc архитектурно мне не противны.
То есть цена появляется, только если мы хотим переделать что-то уже
работающее.
>> Проблем у меня, как пользователя, от этого не прибавляется
>> (прибавляется ли проблем у владельцев телефонов с блютусом по
>> сравнению с владельцами телефонов без блютуса?)
KT> Да. Твой телефон любой, желающий достаточно сильно, может
KT> взломать. Есть даже такой вид спорта - антенна надевается на
KT> приклад и ловятся телефоны, которые лохи не позаботились защитить.
:) Я читал про это. Hе хочу спорить, но на мой взгляд это такие же
сказки, как и то, что высунутая в инет винда живёт там не более 20
минут.
>> Это всё мелочи, конечно (окромя фильтров - без них вообще смерть).
>> Однако каждая мелочь важна.
KT> Скриптовый язык в почтовике, во-первых, потребует реорганизовать
KT> внетренний API для постороннего использования,
Hадо сразу делать так, чтобы работало. Hе должно быть внутреннего
API, точнее, он сам должен быть скриптом, равноправным с остальными.
KT> и в случае ошибки в скрипте потенциально может угробить почту.
Эээ... Кому не надо, или кто опасается - пусть не пользуется.
KT> Всё это уничтожит возможность организовать поддержку пользователей.
Hет, понятно, что с точки зрения производителя коммерческого софта
возможность скриптинга есть зло. Мы вот вводим это в своих продуктах,
и как представитель QA я этому нифига не рад. Хотя шаг несомненно
правильный и потенциально даже полезный именно отделу QA в первую
очередь.
PS: это, по поводу поскипанного - я неправильно понял изначальную мысль,
и отвечал на вопрос "что даёт возможность скриптинга вообще", а не на
оргинальное "чем внутренний скриптинг лучше внешнего". Соответственно,
поскипанное не имеет смысла.
--
=[ Тебе сказали, и ты делаешь... Че, дурак, что ли?
=[ -- kan, 2001
--- ifmail v.2.15dev5.3
* Origin: SWSoft Novosibirsk, QA Department Second Manager (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
