Предложения для развития Опции

[Setuper]

Список пока не реализованных идей и запросов ( todo / future request / change request / improvement ).

ToDo:

• Сделать возможность запрета перенаправления по возвращаемому значению из функции OnOpForceMove
• Сделать возможность смены директорий на лету (сейчас могут быть с этим проблемы).
• Реализовать хранение информации в бд. По умолчанию в SQLite3 с возможностью подключения драйверов других баз данных (в частности, в первую очередь MySQL).
• Встроенный бан менеджер с перегружаемыми из lua событиями.
• Сделать параметр настроек "ограничение количества поисковых запросов".
• Функция статистики и информации о сервере.
• Реализовать функцию получения пользователей по профилю/профилям.
• Добавить возможность в функции Core.SendToIP отсылать данные таблице ip адресов, а не только одному ip.
• Сделать возможность смены настройки sAddresses на лету.
• Сделать поддержку характеристики QuickList.
  
  
  Оптимизация:
• Кеширование поисковых запросов и отвечающих им результатов поиска
• Умный кэш (кэш для рассылки всем, кроме...).
• Сделать хвостовой кэш для массовой рассылки: рассылка по окончанию шага цикла (кэш по умолчанию для массовой рассылки).
• Сделать отложенный выход для того чтобы не совершать бесполезные массовые рассылки.
• Сделать событие OnReEnter при условии реализации отложенного выхода.
  
  
  На потом:
• Оптимальная линковка хабов (встроенный в хаб функционал линковки).
• Авторегистрация хаба в хаблистах (процесс регистрации в отдельном потоке).
• Доработать анти-спам.
• Сделать потоки в Lua.

[Saymon21]

не пойму, к чему такие сложности? Чем плохо то, что сейчас?

[Setuper]

Хочу сделать поддержку первой версии команды $UserIP
С событием мне кажется будет лучшем вариантом

Тут не идёт речь об автоматической отсылке ip адресов при входе на хаб - это поддерживает вторая версия команды. Речь идёт именно о клиентском запросе ip адреса командой $UserIP.

Почитай описание команды $UserIP.

[DEN 007]

На будущее так сказать, сделать первый шаг для возможности на уровне хаба поддерживать заголовки, то есть расширить протокол, но это скорей на планы с adc. Думаю будет актуально. Через годик может и лидеры дц клиентов будут поддерживать данное расширение.

Перспективы применения широки, от определения домена с которого пришел юзер до определения юзер агента (клиента) прямо в заголовках. Выбора языка на котором отображать информацию на хабе и многое другое.

P.S. думаю нужно расширять протокол.

[Alexey]

Так это не по адресу, надо писать разрабочикам протокола ADC http://www.adcportal.com .
Подкинь посонам дровишек, а то давно не слышали: — Oh... these crazy russians!!!!1

Нахрена козе баян?

[Setuper]

Для начала нужно встроить adc. Плюшек, которые нужно сделать итак хватает

[Setuper]

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

По поводу реализации: под винду всё прозрачно - ловится SEH исключением. С линуксом всё обстоит сложнее, ибо надо сигнал превратить в исключение да ещё и в определенном состоянии поймать это исключение. Возможно в случае линукса нужно пойти по стопам java реализации исключений и позаимствовать сишный код оттуда

[mariner]

эм, но зачем, если можно реализовать обновленной версией сигналов. Той, которая потокобезопасная.

[Setuper]

Не ну как ты себе это представляешь?
Ну поймали мы сигнал, а что дальше делать? Ведь вся идея в том чтобы обработать исключение именно в определённом месте программы, где есть функционал для отключения плагина с ошибкой и после обработки продолжить работу хаба после вызова функции плагина не нарушая стек вызовов, а не где-то непонятно в какой функции и непонятно что после обработки делать. К тому же система принудительно килит процесс после обработки сигнала sigsegv.

[mariner]

Мб все-таки sigkill? Который 9ый.

Остальные сигналы можно подменить хендлерами.

[Setuper]

Хотелось бы обсудить новую фишку, которая планируется в ближайшей версии.

В свете внедрения протокола ADC возникла необходимость хранить совершенно произвольное число параметров пользователя. Другими словами, если в NMDC протоколе в команде $MyINFO постоянное число параметров, то в аналогичной команде INF протокола ADC число этих параметров в общем случае произвольно и, вообще говоря, не ограничено.

Сделав хранение произвольного числа параметров, сразу же возникла идея создания/установки параметров из Lua.

В итоге, через UID можно создавать и хранить свои параметры под свои нужды. Эти параметры будут жить в оперативке до момента дисконнекта юзера. Причём параметры будут сохранять свой тип данных. Кроме этого, при помощи данных параметров можно передавать данные между скриптами.

Пример:
script1.lua

Код

function OnUserEnter(UID)
  UID.param1 = 123
  UID.param2 = "123"
end

script2.lua

Код

function OnUserEnter(UID)
  print(UID.param1)
  print(UID.param2)
end

в скрипте script2.lua в параметре UID.param1 будет число, а в параметре UID.param2 будет строка, которые и распечатаются.


Так как данные между скриптами должны будут передаваться, то на типы передаваемых данных наложены ограничения, а именно: можно передавать только данные по значению, то есть нельзя передавать Lua таблицы, Lua функции и другие данные, передаваемые по ссылке. Возможна только передача (сохранение в параметрах) следующих типов данных: строки, числа, логические значения.

На данный момент в русхабе существует один параметр подобного рода (UID.sData), в который можно записывать какую-нибудь строку.
Теперь даётся возможность пользователю самому выбирать имя параметра, и расширяются возможные типы параметров.

[Ksan]

Код

UID.param2 = "Это тот, который вчера тут спьяну посылал всех и вся. С него глаз не спускать!"

Эти параметры будут жить в оперативке до момента дисконнекта юзера

В принципе, и в базу их можно сохранять, или в файл.

[ExC0tiC]

Эти параметры будут жить в оперативке до момента дисконнекта юзера

Я понимаю, что эта фишка ещё полностью не продумана. Поэтому вопрос - при большом онлайне, не будет ли забивать оперативку, и использовать для хранения значений SQLite будет не лучше?

[Setuper]

Если не хочешь забивать оперативку - не юзай эти параметры. Чтобы ничего не забивать можно вообще не юзать скрипты.
Параметры исключительно для удобства написания скриптов. А если не хватает оперативки, то может стоит её прикупить?

[Setuper]

В новой версии (на данный момент 2.3.8[beta]) будет модифицирована система логирования.
В настройках уровни логирования iMaxLevel и iMaxErrLevel будут объединены в один уровень логирования iMaxLevel.

Номер уровня логирования может быть одним из следующих:

0 - FATAL
1 - ERROR
2 - WARN
3 - INFO
4 - DEBUG
5 - TRACE

по умолчанию будет выставляться: 3 (INFO).

[DEN 007]

В итоге, через UID можно создавать и хранить свои параметры под свои нужды. Эти параметры будут жить в оперативке до момента дисконнекта юзера. Причём параметры будут сохранять свой тип данных. Кроме этого, при помощи данных параметров можно передавать данные между скриптами.

• Идея замечательна, но хорошо бы на УРОВНЕ ХАБА при дисконекте все-таки куда то эти данные сохранять, это уже можно решить на модульном уровне (dat, xml, mysql, sqlite и т.д..)
• Так как по задумке все скрипты данные могут модифицировать, неплохо бы было блокировать изменение данных, пока с ними работает один из скриптов, зачем думаю всем понятно.

[Ksan]

Создавать копию предстоящих изменениям данных и процесс изменений производить только с ним, а на это время оригинал останется доступен другим скриптам. Как только копия претерпит окончательно изменения, она заменяет оригинал.
Как-то так..
Хотя, учитывая очень короткое врмя обработки данных (в том числе и изменения их), можно не париться вовсе.

[Setuper]

Русхаб работает в один поток, поэтому утверждение о блокировки изменений данных, пока с ними работает один из скриптов, - бессмысленное.
Реализация сохранения параметров куда-то - это уже на плечах самого скриптописателя.

Вообще говоря, эти параметры задумываются как временное хранилище, которое могут использовать все скрипты, поэтому о сохранении речи вообще говоря не идёт. Ведь например ip адрес пользователя (UID.sIP) мы же обычно не сохраняем, однако же его можно в какой-то степени считать тем же самым параметром, правда установлен этот параметр самим хабом, а не скриптом. Более того, внутри хаба параметр для ip или какой либо другой параметр в принципе хранятся одинаково.

[Otshelnik-Fm]

Ну на развитие врядли повлияет... - Предлагаю автору заполнить описание "Description" и "Publisher" - при просмотре в "управлении службами" винды или в утилитах типа "Autoruns" от sysinternals сразу бросается в глаза.

[Setuper]

Так вроде в последней версии добавлено

[Otshelnik-Fm]

Незнаю подходит ли вопрос для этой темы.

Setuper - ведется ли статистика сколько серверов rushub установлено?

Если встроить инструмент (по умолчанию вкл в конфиге) который будет передавать на главный сайт http://rushub.org/ информацию, что вот по такому-то ip - работает rushub (таким образом на главной можно сделать список хабов работающих на данной платформе, страну и город...). Я не говорю о модуле пингера для хаблиста, а о функционале зашитом в сам софт.

Тут конечно могут возникнуть непонятки от админов - но если админ хороший (читающий мануалы), то он увидит что для выключения функции прописать в конфиге... Но если он выключит - то ему хуже - его хаб пропадет с страницы списка хабов сайта rushub.