Функция Access. Важность на грани эфемерности
В современных IRC-сервисах мало что изменилось с тех далеких времен, когда писались их первые прототипы. Бесспорно, расширился функционал, появились продуманные реакции на различные ситуации в irc, увеличилась стабильность. Однако, осталось и множество некоторых функций, наличие которых обуславливалось решением ранних задач в IRC. Среди такого функционала наличествует и любимая некотрыми категориями пользователей irc подсистема Access. Что же она из себя представляет такого? В общих чертах, это возможность пользователей сервисов гибко управлять собственным каналом посредством одной-двух команд. К примеру chanserv access #канал ADD ник "уровень" - добавит в список доступа на Вашем канале пользователя с любыми полномочиями. Распространённая команда, которая способна добавить ипользователя с правами от войса до почти совладельца. Надо лишь знать число уровня, которое даёт определённые права. С таким подходом безусловно удобно разграничивать права пользователей, производить какие-либо "тонкие" настройки прав. В некоторых сервисах возможно прописать и "отрицательный" урвоень доступа. С таким, пользователь, вместо войса или опа получит обратный эффект - деоп, девойс, а при желании и бан. Собсвенно, этим и ограничивается практически весь полезный функционал команды Access. Да, она удобна, да она предоставляет неплохие статистические данные о списке доступа канала. И...всё. В своё время, данная подсистема видимо заменяла собой команды VOP, OP, SOP и т.п. Точнее, тогда вероятно их и не было, в первых версиях. Однако с появлением упрощённых конкретных команд, важность Access стала весьма спорной. Большинство пользователей использует упрощённые заученные (либо забитые в скрипты) команды автоопа, хопа, войса и проч. Ацессом пользуются в основном "умудрённые" опытом пользователи, время от времени играющиеся с тонкими настройками доступа каналов. С появлением "прогрессивных" сервисов значимость функции Access была пересмотрена разрабочиками. Некоторые их них решили оставить эту подсистему (или не убирать её вовсе), как например в популярных Anope, некоторые - писавшие ядро своих версий сервисов с нуля, вполне логично решили на нагружать его дублирующими функциями, а заполнить это место куда более полезными новшествами - это и дополнительные функции, опции, расширенная информация, улучшенная устойчивость перед сбоями. Таким путём пошли, к примеру, разработчики используемых сетью IRCLuXe.RU сервисов. Эти сервисы, имея подсистему Level, обладают огромным расширенным функционалом, в том числе и информационным. Они же - весьма устойчивы к сбоям и атакам недоброжелателей. Множество пользователей оценили удобство этих сервисов в управлении каналами. И никто из них ни разу не задумался о "великой потере" - отсутствию функции Access. Им она попросту не нужна, так как в целом, её функционал так или иначе перекрывается упрощёнными командами + огромные встроенные дополнительные возможности настройки канала на нашем сервисном ПО. И только некоторые админы, закостеневшие в консервативных привычках с плохо скрываемым раздражением кричат на всех углах об ужасающем, видите ли, недостатке сервисов - отсутствии аццесса, который давно уже собственно никого не волнует. А может они просто не хотят заново обучаться работе с сервисами без зазубренных до зубовного скрежета, никогда не меняющихся команд и концепций? Пора уж вылезать из уютного старинного гнёздышка, если не сказать - устаревшего. Ведь даже IRC периодически должен немного изменяться и шагать к прогрессу. Время покажет.
|