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

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

ToDo:

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

Хорошая идея. Возможно попробую реализовать позже, когда хаб будет более стабильным и будет подключены бд и lua

Провёл тестирование на вместимость списков (хеш-таблиц) до 10000 пользователей

так для чего libmysql.dll нужна?

- а на ком и сколько по времени тестировалось? Что за хаб? Уж не на озерках который?

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

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

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

может не ндо, это, вэбсервер то?
есть отличные вэбсервера. нужен тока mysql.

Лично меня бы устроил обычный GUI Не хочется (да и не можется) возиться с вебом, проблемы на серверной стороне (хаб у меня удаленный на линуксе).

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

В 53 посту ссылка (интересно она отличается от версии 1.0.3 в 1 посте?) - работает отлично. Багов не замечено. От себя могу назвать стабильной версией .

Веб сервер апач - чем он вам не нравится? ( я против когда все в одном).

В 56 посту вопрос открыт, и еще один вопрос: Как свернуть в трей консоль хаба? - эта функция нужна.
И как запустить rusHub как системную службу?

По поводу линковки - было бы неплохо. Также как и управление через веб или icq

Итак, по порядку.

1). Ссылка в 53 посту отличается от версии 1.0.3. Отличия состоят в оптимизации хеш-таблиц, а именно в изменении зарезервированного места в зависимости от количества пользователей. Плюсы: 1) быстрый поиск по хеш-таблице за одну итерацию 2) освобождение оперативной памяти при снижении количества пользователей на хабе.

2). Разумнее сделать просто веб-морду, а веб сервером использовать, например, апач. Это опять же связано с оптимизацией. Хотя и можно засунуть веб сервер в ещё один поток, однако не вижу смысла изобретать велосипед, тем более, что апач справляется на все сто.

3). Теперь по поводу GUI. Разумно делать GUI через веб. Плюсы: 1) удалённое управление хабом с любого компа без дополнительной установки каких-либо программ (достаточно браузера); 2) ну и конечно кроссплатформеннсть такого GUI.

4). В принципе, можно будет сделать и обычное GUI, так сказать на выбор. Однако, это GUI будет как отдельная программа, и это позже.

5). Файл libmysql.dll - это заготовка для соединения с mysql сервером.

6). Как установить хаб как службу можно прочитать тут: http://mydc.ru/topic201.html (у меня установлен, и отлично работает).

предлагаю убрать все предыдущие версии иначе щас начнётся великая путаница! Думаю что в теме должен присутствовать только последний релиз!

Кстати о логах... как насчет опциональной возможности вести лог гл.чата самим хабом?

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

Чего ради? По-моему идеология "хаб в коробке" вполне себя оправдала. Модули нужны,но не под такие мелочи,однозначно.

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

Что в скрипте такого изменять,для чего заранее нельзя придумать условие? Имена файлов? Их предельный размер? Директорию? Содержание? Формат ввода? События для логирования?

делион. начинаем считать ресурсы. не все могут позволить, чтобы хаб вел 100500 логов и делал это сам. для логов давно созданы базы данных. Т.к. логи чата оно должно типо "при входе" показывать? Если чат тактивный - ресурсов будет есть достаточно, а в базах данных это все нормально будет решаться.

Пока речь идёт о логировании действий хаба для обнаружения багов, а не чата. И логироваться они будут на текущую сессию работы хаба.

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

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

Ну юзверю как бы весь чат даром не нужен,ему 20 последних сообщений хватит,и то не факт что нужно. Админам аналогично,в клиентах прокрутка есть,да и логи те же самые. Так что БД для логов главного чата или нечто скриптовое из сообщения выше видятся мне одинаково не к месту

Оооооо... появилось API!! Шикарно, шикарно! Ждём остальных вкусностей.
Хаб будет распознавать реконнект юзеров?

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

PS: Предлог "посредством" пишется слитно.

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

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

1) Обращаю внимание на то, что в отличии от птохи, в параметрах данных api функций отсутствует таблица tUser. Вместо неё, в большинстве функций присутствует только ник. Именно ник, а не идентификатор как в hex хабе, так как идентификатор никак не используется, а ник - это уже характеристика пользователя. Сделано это из соображения оптимизации. Остальные характеристики пользователя при необходимости можно будет получать по нику при помощи специальной функции. Дело в том, что в птохе при каждом вызове api функции, таблица tUser строится заново, соответственно поля этой таблицы помещаются каждый раз в lua стек, что по сути является каждый раз лишним, так как в луа скриптах редко используются некоторые поля этой таблицы, а иногда и вообще не используются. Спрашивается зачем каждый раз помещать эти поля в таблицу tUser, если они не будут использоваться. Давайте лучше будем вызывать функцию, которая будет строить эту таблицу, если нам нужен тот или иной параметр.
И ещё... Указанную функцию можно будет вызывать с параметром, который будет указывать на то, какие паля таблицы нам нужны. Это тоже оптимизация, так как в большинстве случаев нам не нужны все поля таблицы tUser.

2) В api1 и api2 птохи есть различия в том, что должна возвращать, например функция ChatArrival. В api1 для блокировки чата нужно возвращать 1, в api2 нужно возвращать true. Я совместил эти признаки и поэтому в api функции OnChat данного хаба для блокировки можно возвращать как 1, так и true (это не только для OnChat, но и для других функций).

3) На данный момент работаю над следующей фишкой:
пусть у нас есть 2 скрипта: скрипт антимата и скрипт истории сообщений чата. Скрипт антимата заменяет "плохие" слова в чате.
В PtokaX это бы реализовывалось следующим методом: скрипт антимата отсылал в чат изменённые сообщения и блокировал отправку реального сообщения. В таком случае, если бы скрипт истории чата стоял после скрипта антимата, то он бы не залогировал данное сообщение вообще, если же история чата находилась до антимата, то залогировалось бы сообщение с матом.
Итак, теперь как будет сделано в rushub...
Будет существовать такая функция, которая изменяет сообщение чата (изменяет реальное сообщение). И самое главное, что в скрипт, который будет находится ниже, будет поступать уже изменённое сообщение.

4) Если функция OnChat в каком-либо скрипте вернёт true, то, в отличии от птохи, выполнение функций OnChat всех остальных скриптов, которые находятся ниже, не блокируется. Блокируется только отправка сообщения в чат.

5) Функция Core.SendToAllWithoutNick будет отправлять сообщение всем, кроме указанного в параметрах ника.

6) Парсинг команд происходит до выполнения lua скриптов. Например, в команде OnChat(sNick, sMsg), sNick - это ник пользователя, а sMsg - это чистое сообщение, то есть без ника. Таким образом в скриптах не надо каждый раз парить и выполнять как в птохе код sData = sData:sub(tUser.sNick:len() + 4, -2). Кстати, символ | на конце сообщения также уже отсутствует.

Ну вот... Не удержался и раскрыл некоторые фишки

Что касается папки libs, то это я сделаю
По поводу функции реконнекта, то это реализую чуть позже. Пока это не так уж и важно.