= Сообщение: 1175 из 2623 =================================== RU.FTN.DEVELOP =
От : Sergey Poziturin 2:5020/2141.1 21 Mar 17 16:24:08
Кому : Alexey Vissarionov 21 Mar 17 16:24:08
Тема : HotdogEd database synchronization
FGHI : area://RU.FTN.DEVELOP?msgid=2:5020/2141.1+58d12fed
На : area://RU.FTN.DEVELOP?msgid=2:5020/545+58d11fc3
= Кодировка сообщения определена как: CP866 ==================================
Ответ: area://RU.FTN.DEVELOP?msgid=2:463/3232+58d145b2
==============================================================================
Hi, Alexey!
21 мар 17 15:42, Alexey Vissarionov -> Sergey Poziturin:
SP>>>> Хочу приделать к хотдогу возможность синхронизировать свои базы
SP>>>> с нашими настольными фидошными комплектами. Hа выходе хочу
SP>>>> получить следующее: прозрачность (до определённой степени)
SP>>>> работы с фидой на телефоне и на большом компе. Без разницы, где
SP>>>> почта получена или читается. Делать это планируется в 3 этапа
SP>>>> следующим образом: Этап 1. [...] jvm api для работы с базами
SP>>>> сообщений
AV>>> Это, соответственно, Jam и Squish, причем Squish более
AV>>> распространен. Бывают и другие, но их количество пренебрежимо
AV>>> мало.
SP>> Отдельно стоит вопрос с нетмейлом, у некоторых база в msg
AV> Покажите мне хотя бы одного человека, у которого это так _И_ которого
AV> данное положение дел устраивает :-)
Hу, скажем так, в 1998 году меня это устраивало :) Для нетмейла. Всё остальное было в сквише. Все мои знания основаны на памяти о тех годах.
SP>> Теоретически, если я все верно рассчитал, в этот момент мы можем
SP>> в него положить сообщение тоссером на компе, перенести его на
SP>> телефон, и положить туда сообщения с хотдога, а в хотдог забрать
SP>> сообщения, положенные тоссером с компа.
AV> Да. Причем делать это придется в три прохода: на первом затаскиваем
AV> базу сообщений с ББ на КПК (инкрементально, ибо rsync), импортируем
AV> сообщения, которых нет в собакоеде (это будет медленная операция, ибо
AV> базу придется просматривать целиком; такова плата за минимализацию
AV> трафика при обмене), проверяем, не изменилась ли база на ББ (если да -
AV> снова затаскиваем итд), экспортируем написанные в собакоеде сообщения
AV> в локальную копию и уже ее отправляем на ББ.
AV> В этой схеме есть всего одно место, где могут порыться подводные
AV> грабли: блокировка базы ББ на время синхронизации. Если при запуске
AV> тоссера можно банально проверить флаг и, если таковой есть, либо
AV> подождать, либо просто обработать сообщения при следующем запуске, то
AV> с редактором сложнее. Хотя остается возможность свалить это на
AV> пользователя :-)
Именно так, поэтому и рассматриваю возможность отказа от таскания файлов (даже в виде rsync).
SP>>>> Функцию переноса базы с телефона на компьютер и обратно берёт
SP>>>> на себя сам пользователь.
AV>>> Думаю, для этого понадобится держать отдельно базу сообщений
AV>>> собакоеда и опять-таки отдельно базу в squish.
SP>> Так и есть, у хотдога всегда будет своя база сообщений (у
SP>> редактора) в виде sqlite-бд.
AV> Это понятно. А дополнительно к ней в соседнем каталоге будет
AV> squish-база.
Да. Большая, жирная база. Вот это тоже не очень нравится.
SP>>>> Я как джавист готов сделать некое референсное приложение на
SP>>>> springboot, соответственно ему будет нужна ява-машина и
SP>>>> вычислительные ресурсы,
AV>>> Кхм... 1/20 типового АЛУ ("ядра") Xeon и 128 Мб памяти
AV>>> обслуживают две сотни линков, практически все из которых тянут
AV>>> фуллфид, и при этом тоссинг занимает всего 4 секунды каждые 10
AV>>> минут. Вопрос: сколько ресурсов надо будет выделить
AV>>> дополнительно для обслуживания всего одного линка? :-)
SP>> Вопрос открытый. По скорости все хорошо, а вот по памяти может
SP>> быть несколько больше.
AV> Это был намек на то, что софт для ББ не нужен. Вообще.
SP>> Возможно, нам придётся отказаться от концепции передачи файлов
SP>> между телефоном и компом и перейти на передачу сообщений и
SP>> статусов. Что-то типа nntp (передача новых сообщений с их
SP>> статусами и флагами). Именно чтобы не гонять трафик лишний и
SP>> чтобы можно было настроить количество сообщений, возраст
SP>> максимальный и тд. И без rsync можно обойтись и этап сразу будет
SP>> третий.
AV> Одного не понимаю: нахрена? Это уже будет не FTN, и даже не NNTP, а
AV> просто какая-то хня.
Это будет такой тоссеромейлер над обычной фидошной базой. Только у них свой протокол для вставки сообщений и смены их статусов.
SP>> Сделать эдакую распределенную базу сообщений между компом (или
SP>> несколькими) и телефоном (или несколькими). Мне эта идея
SP>> нравится. Заодно и телефоны подружим разные. Что скажешь?
AV> Для распределенной базы понадобится добавлять ее поддержку в SMAPI. И
AV> еще хорошо, если в результате получится что-то похожее на... git :-)
Hе, SMAPI трогать не будем. Hаша штука будет работать параллельно.
SP>>>> Готова ли общественность самостоятельно, хоть на php,
SP>>>> реализовать для себя клиента протокола для приёма и отдачи
SP>>>> файлов?
AV>>> Реализовать-то можно... только нахрена, когда есть rsync over
AV>>> ssh?
SP>> Я как-то больше мыслю в сторону веб-сервисов.
AV> Ты всерьез думаешь, что ради фидошной читалки кто-то будет ставить
AV> tomcat и прочую ботву, которую он за собой потащит по зависимостям?
Это не требуется, спрингбут представляет собой один jar, которому нужна только jre. Всё остальное там внутри.
Т.е. юзеру будет нужно:
1. Установить яву, если ещё не. По версии - это к автору API, я буду от его решения плясать.
2. Скачать софтину и ввести пару настроек (пути к базе, настройки сети и доступа).
3. Запустить софтину.
4. Обеспечить доступ к порту извне.
Я понимаю, что тебе нравится rsync, мне тоже. Hо он для решения нашей задачи подходит плохо, поскольку наш инструмент должен решать её на другом уровне. Пулять файлы тут хуже, чем пулять сообщения.
Кстати, для решения п.4 я думаю сделать какой-нибудь публичный гейт. Именно для этого протокола. Там делов на полдня, а юзеру не нужно морочиться с ip, пробросом и прочее.
То есть работать будет по такой схеме:
Hа компе:
Софтина на компе-> tcp outgoing -> Гейт
Hа телефоне:
Софтина на телефоне -> tcp outgoing -> Гейт -> existing tcp socket -> софтна на компе.
Соответственно гейт может стоять на компе локально, тогда это будет чисто p2p. А может быть публичный гейт, который будет у меня или у кого-то другого на сервере, тогда не нужно на компе самому принимать входящие.
Естественно, будет возможность закрутить гайки на гейте.
Всё в этой схеме хорошо, но есть 2 минуса:
1. По ресурсам будет жрать больше на сервере, чем rsync.
Мои прикидки:
По диску где-то 150-200 Мб на jre+софт.
По оперативной памяти: думаю, 128 Мб на jre+tomcat+софт хватит. Это, конечно, будет зависеть от реализации API Виталием.
2. Требуется аудит безопасности гейта. Поскольку всё будет открыто, думаю, это не проблема.
Зато и плюсы есть:
1. Hе нужно перекладывать логику (и cpu time) для анализа изменений на телефон. Это очень-очень-очень сэкномит батарейку.
2. Hе нужно держать на телефоне файлы фидошных баз.
3. Hе нужно морочиться с настройкой rsync и доступом к нему через инет.
Есть предположение, что по трафику будет паритет с rsync. Во-первых, потому что мы тоже передаём только изменённые данные (кстати, у rsync такое не всегда может получиться, например при пуржинге баз полетит твоё гигабайт на телефон в полном объёме), во-вторых, потому что мы тоже умеем использовать потоковое сжатие.
Открытые вопросы:
1. Как обеспечить блокировку базы и нужно ли это делать? Как отнесётся тоссер hpt, если в момент его тоссинга кто-то ещё запишет в эту базу сообщения?
2. Как разруливать ситуацию, когда между телефоном и гейтом связь есть, а между гейтом и компом нет? Сбрасывать, думаю. Хотя есть вариант копить и потом при появлении связи отдавать, но первый вариант мне нравится больше.
--
[ vbane72@yandex.ru ] [2:5020/2141] [ Hotdogs 4ever ]
http://vp.propush.ru
--- binkd/1.1a-94/Darwin | hpt/mac 1.9.0-cur | GoldED+/OSX 1.1.5-b20160322
* Origin: Somewhere on Mac (2:5020/2141.1)
|
