SP>> Кстати, если кто-то хочет иметь возможность править этот SP>> файл на гитхабе совместно со мной - пишите, обсудим. Я бы SP>> не хотел отвечать за него в одиночку, вдруг трамвай или SP>> кирпич. AV> Hе нравится мне этот ваш гитхаб, ну да ладно - записывай меня.
Чуть позже дам технические подробности. Перетру с Ваней Агарковым, как лучше это организовать.
SP>> при выборе узла для подачи заявки в списке будет выполняться SP>> сортировка по следующему алгоритму: выше будут те узлы, SP>> которые предоставляют больший сервис. Если узлы SP>> предоставляют одинаковый сервис, то выше будет тот, у SP>> которого номер меньше (сравниваем числа). AV> Рекомендую в качестве основного критерия выбирать узлы из AV> сетей, которые географически ближе к пользователю. То есть, AV> например, пойнту из Барнаула наверняка будут более интересны AV> узлы из 5000, 5001 или 5005 (расстояние до которых 200, 270 и AV> 360 км), нежели из европейской части нашей необъятной (расстояние до AV> которых на порядок больше) - и для получения местных эх, и банально для AV> информирования собеседников о своем местоположении.
Да, уже думаю над этим. Каким образом привязаться к месту на телефоне б-м понятно, а вот как лучше поступить с узлами? Разве что ввести ещё один тэг <Location> с координатами и ранжировать по расстоянию.
SP>> Узел, предоставляющий полный формат эх, будет выше, чем SP>> тот, который предоставляет краткий. AV> Эталонную реализацию софта, который будет генерировать такой AV> список на узле, использующем hpt - в президиум. А до того прошу AV> трактовать форматы одинаково.
Ок, не вопрос.
SP>> Если кому-то интересно, как для http двухпроходная схема SP>> (запрос-подтверждение) реализована на /2141, могу SP>> предоставить мои кривые скрипты на php (у меня на узле SP>> jnode). AV> Попробую угадать: они работают с БД?
Да. Мне приходит письмо на каждый запрос, я из него перехожу сразу по ссылке accept или decline, тогда юзер прописывается или нет как поинт, и ему уходит письмо соответствующего содержания. Hу и могу весь список запросов увидеть. Это очень удобно, так как позволяет всё делать с телефона одним нажатием на кнопку.
С hpt всё это тоже просто, конечно, особенно если конфиги правильно организованы.
SP>> Hу а кто не хочет городить веб-сервер, может AV> .... придумать, как засунуть это в одну сессию binkp (у меня AV> http есть, но планирую при случае заняться).
Я тоже думал на тему, что сделать ещё один тип requestby="binkp", тогда бы прямо как в старые добрые времена можно было бы на узел непарольный нетмейл с запросом зафигачить с адреса .999 :)
SP>> При http-запросе всё, что нужно знать хотдогу - это 2 SP>> строки. В первой OK или ERROR, а во второй - поинтовый SP>> адрес, который присвоен поинту в случае ответа OK. AV> А что писать во второй строке при ответе ERROR - сообщение с AV> диагностикой? Хочу, в частности, проверять пароль на AV> криптостойкость.
Да, там может быть причина отказа, она будет в хотдоге отображена вместе с грустной вестью.
Кстати, вот ещё, не сделать ли ещё тег с какой-то памяткой юзеру? Типа motd. Они будут его видеть при выборе узла. Там бы такие типы как ты могли бы сразу всех застращать про безопасность :)
