Трекер под XenForo. Быть или не быть?

Yoskaldyr, собираешься ли ты учавствовать в написании трекера под xenForo? Просто, если я не ошибаюсь, ты принимал активное участие и в разработке трекера под булку.
p.s. И это, где то я уже твой авик видел...

 

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

Ну вообще-то я его написал... И на vbtt.org уже описывался, что трекер может будет, а может и нет, т.к. больше интересуют магнеты с просмотром статы по ним.

 

Кого интересуют?

 

Меня Но это задача немного не для php

P.S. пошел жесткий оффтоп

 

Блин, ну тоды может попросим уважаемых администраторов/модераторов вынести это в отдельную ветку? Ибо тема наклёвывается быть интересной, вопрос то животрепещущей для многих. Как я уже отписался на vbtt.org, что лично меня останавливает переход на "ксению" лишь из-за отсутствия трекера, даже при наличии стабильной версии xenForы. По сему, было бы здорово, если б кто-то из вас, парни, переписал трекер под xenForo. Только я б лично стопицоттыщ спасибо сказал бы за это, не говоря уж о многих других людях! А магнеты... что магнеты... Вы (Skald и ты) думаете, что это коим-то образом избавит сайт/админов от ответственности? Конечно же нет =) Это такие же сцылки как и все остальные, да принцип раздачи другой, но суть то от этого не меняется. И потом, самое главный принцип тут один, волков(правообладателей) бояться - в лес не ходить.

 

^^
ну так быть или не быть?

 

от меня - пока нет. И сразу хочу сказать - если и будет - это будет еще большая жесть чем установка моего vbtt 2.5 (для обычного среднестатистического админа который ставит трекер), т.к. мускуля там не будет вообще - в лучшем случае xcache, а так скорее всего или redis или что-то на nodejs, а может redis+nodejs (для этого минимум нужен будет вдс).

 

просто портить ксен трекером на пхп+мускуль - это издевательство над трудом разрабов ксена.

 

Я думаю, есть варианты. С MySQL можно работать через Handler Socket и это очень быстро. Percona билд MySQL содержит этот плагин по умолчанию. Так что, если сделать модульный API трекера, юзер сможет выбирать, работать ли трекеру через обычный SQL, нагружая сервер, или использовать быстрые API. Конечно, последний вариант будет доступен только на серверах, где установлено расширение Handler Socket для PHP и для MySQL соответственно.

Я бы поучаствовал в разработке трекера. Собирался сам чего-нибудь сделать, но одному мне сейчас такое не поднять. Не хватит свободного времени. Да и не люблю я проектировать HTML-интерфейс... Со вкусом плохо Вот внутренним API самого трекера я бы занялся, наверное.

 

Хандлер сокет быстр, но есть и более быстрые решения, а раз все равно выделенный сервер нужен то почему бы не их использовать. Сам анносер лучше написать на чем-либо отличном от php и просто все временные данные хранить в переменных, а не дрюкать базу (например на том же nodejs или на lua модуле для nginx-а ). И по таймауту просто записывать изменения, тут уже не важно в какую базу и по какому протоколу, т.к. запись будет пакетной, то накладные расходы по парсингу sql запроса будут просто минимальны относительно времени самого запроса.

Или вообще всю трекер логику сделать на стороне БД, например Tokio Tyrant/Kyoto Tycoon с их lua расширением. Т.е. по скорости получим что-то очень близкое к XBTT (а может и быстрее), но вся пользовательская стата будет перенесена туда же за счет гибкости скриптовых языков.

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

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

 

да для начало хотя-бы ББ магнита кто-бы замутил-бы........

 

Эх, ждём бэкэнда