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

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

ToDo:

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

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

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

русские горки( russian hill hub ,RusHill )или русская пуля из-за скорости работы =) p/s( К@пит;-)шка )

Я за текущее название. Очень патриатично даже.

p.s. хаб работал на автопилоте пока я путешествовал - ни одного вылета (v_1.0.5e).

У меня есть следующая идея: хаб - это просто сервер работающий на nmdc протоколе, а все другие возможности реализуются плагинами. Плагины могут взаимодействовать между собой, и каждый плагин имеет собственные настройки.

Возможные плагины:

Lua
Mysql
Commands
Bans
Profiles
Unflood

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

Лучше распредели возможности между плагинами и самим хабом.

А почему бы не всунуть это всё в сам хаб, чтоб всё отлажено было и проблем в случае чего не возникало. Но и чтоб была возможность полностью отключать что надо допустим правкой конфигов каких-то, но чтоб не более смены 0 на 1.

Присоединяюсь к dimetrius. Так будет проще конечному пользователю

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

Голосую за модульность.

Интересно, модуль для перла или питона напишет кто-нибудь? Или птока-совместимый луа? ;)

Плагин перла или питона я уверен можно будет реализовать.
Что касается птока-совместимого lua, то тут существует несколько противных факторов (лично с моей точки зрения): использование таблицы tUser считаю нагрузочным фактором, хоть разработчики и попытались убрать из ней большинство полей. Разделение всех api функций по разным таблицам также непонятно, лучше запихнуть всё в Core, так будет легче начинающему программисту и так можно будет одной строкой оптимизировать эту таблицу:
Идём далее, и находим неудобство, например, в 10 вызовах одной и той же функции SetMan.GetString с разными аргументами, если нам вдруг понадобилось каких-то 10 параметров. То же самое касается и функции Core.GetUserData. Проблема решается использованием битов для каждого из параметров, то есть вызов одной функции с одним аргументом, который описывает необходимые поля.


Теперь по поводу встраивания всех прочих возможностей в хаб. Если использовать плагины, то всё будет работать также отлажено, и при возникновении ошибки сразу будет ясно в каком плагине копать, а не копать во всём хабе. Встраивание в хаб отличается лишь тем, что всё будет переплетено и не будет чёткого разделения, и, кроме этого, лишний неиспользуемый код будет висеть грузом. В случае плагинов, мы просто отключаем этот груз (выбрасываем его).
Кстати, идея такова: плагин представляет из себя dll библиотеку (so библиотеку). Все плагины помещаются в специальную папку plugins, которая создаётся, если она не создана, при запуске хаба. Именно папка plugins сканируется хабом для обнаружения плагинов. Можно сделать настройку: загружать ли новый плагин автоматически или использовать ручную заргузку. Ручная загрузка означает то, что новый плагин не будет загружаться при сканировании этой папки, а в настройках будет помечено, что этот плагин отключен и его можно будет включить вручную (через команду, через веб интерфейс или через gui). Плагины могут взаимодействовать между собой. Например, у нас 2 плагина: плагин антифлуда и плагин банов. Плагин антифлуда имеет настройку бана при обнаружении флуда, и, соответственно, использует функцию бана из плагина банов. Теперь мы отключаем плагин банов. Плагин антифлуда забанить не сможет, а сможет, например, только разъединить пользователя без бана или оповестить о флуде.

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

М-да,пример не очень удачный...

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

Ждем-с описание API для плагинов если таковой имеется!

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

Описание api для плагинов приведу, возможно, позже, а может и в ближайшее время.
Это скорее будет не api, а методика по созданию плагинов с соответствующими заголовочными файлами абстрактного механизма хаба.

Для описания методики, наверное будет разумно создать в разделе других языков программирования статейку. Там же можно будет разъяснить принципы наследования и другие понятия языка с++.

Как продвигается разработка? что-то 2 месяца тишина...

Разработка продвигается. Сейчас разрабатывается большой блок (настройки + профили + mysql)

Увидел, что в теме новые сообщения, последний ответ Сетапера, и уже приготовился ставить/смотреть/тестить русхаб... а тут такой облом ;)

Сейчас самая проблемная часть проектируется. Как только я её сделаю, дальше будет намного легче и быстрее идти процесс.

Успехов. Что тут еще можно пожелать то?

Хотелось бы, чтобы еще одна "фиговинка" была реализована.
В настройках прописывается ник админа и ему бы приходили всякие собщения которые приходят опам (с ключом то бишь) но даже если в настройках этого ключа у него нет Хм.. Вроде доступно объяснил?)

Ага. Реализация функционала операторов не будет привязываться к ключикам))) То есть все настройки зависят только от профиля, но никак не от какого-то атрибута профиля.