НotdogEd database synchronization

Sergey Poziturin написал(а) к Alexey Vissarionov в Mar 17 08:40:25 по местному времени:

Нello, Alexey Vissarionov.
On 20.03.17 3:30 PM you wrote:

SP>> Хочу приделать к хотдогу возможность синхронизировать свои базы с
SP>> нашими настольными фидошными комплектами. На выходе хочу получить
SP>> следующее: прозрачность (до определённой степени) работы с фидой
SP>> на телефоне и на большом компе. Без разницы, где почта получена
SP>> или читается. Делать это планируется в 3 этапа следующим образом:
SP>> Этап 1. [...] jvm api для работы с базами сообщений
AV> Это, соответственно, Jam и Squish, причем Squish более
AV> распространен. Бывают и другие, но их количество пренебрежимо
AV> мало.

Отдельно стоит вопрос с нетмейлом, у некоторых база в msg (это же opus зовётся)?

Это скорее к Виталию, наверное, хочет ли он этим заниматься.

SP>> 4. Делать всё это по расписанию или по внешнему сигналу
SP>> (сообщения от провайдера сообщений о получении новой почты).
AV> Ээээто вообще про что? Про внутренности собакоеда, или?

Да, это про особенности андроидной реализации. Все это планируется автоматизировать.

SP>> Таким образом на этом этапе имеем возможность наполнять фидошную
SP>> базу сообщений несколькими независимыми методами: или с хотдога,
SP>> или с софта на компе.
AV> Насколько я пони мяу, речь про фидошный софт?

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

SP>> Функцию переноса базы с телефона на компьютер и обратно берёт на
SP>> себя сам пользователь.
AV> Думаю, для этого понадобится держать отдельно базу сообщений
AV> собакоеда и опять-таки отдельно базу в squish.

Так и есть, у хотдога всегда будет своя база сообщений (у редактора) в виде sqlite-бд.

SP>> 2. Какие средства синхронизации файлов для п.2 вы бы предложили,
SP>> помимо root+rsync?
AV> А зачем для rsync рутовые права?

А есть его дистрибутив готовый под андроид без рута, без бизибокса и всего такого? Если есть, это упрощает задачу.

AV> Не говоря уж о том, что кроме rsync ничего реально и не нужно -
AV> максимум перезапись файлов на mass storage device вручную.

Угу.

Меня вообще говоря тоже не радует идея писать это все самостоятельно.

SP>> Я как джавист готов сделать некое референсное приложение на
SP>> springboot, соответственно ему будет нужна ява-машина и
SP>> вычислительные ресурсы,
AV> Кхм... 1/20 типового АЛУ ("ядра") Xeon и 128 Мб памяти обслуживают
AV> две сотни линков, практически все из которых тянут фуллфид, и при
AV> этом тоссинг занимает всего 4 секунды каждые 10 минут. Вопрос:
AV> сколько ресурсов надо будет выделить дополнительно для
AV> обслуживания всего одного линка? :-)

Вопрос открытый. По скорости все хорошо, а вот по памяти может быть несколько больше.

AV> Да, чуть не забыл: gremlin@fido:~ > du -sh ~/fido/msgbase 2.6G
AV> /home/gremlin/fido/msgbase

Надеюсь, rsync не поперхнется.

Возможно, нам придётся отказаться от концепции передачи файлов между телефоном и компом и перейти на передачу сообщений и статусов. Что-то типа nntp (передача новых сообщений с их статусами и флагами). Именно чтобы не гонять трафик лишний и чтобы можно было настроить количество сообщений, возраст максимальный и тд. И без rsync можно обойтись и этап сразу будет третий.

Сделать эдакую распределенную базу сообщений между компом (или несколькими) и телефоном (или несколькими).

Мне эта идея нравится. Заодно и телефоны подружим разные.

Что скажешь?

Кстати, тогда Виталий может под Java 8 писать, но часть на андроиде не нужна.

SP>> Готова ли общественность самостоятельно, хоть на php, реализовать
SP>> для себя клиента протокола для приёма и отдачи файлов?
AV> Реализовать-то можно... только нахрена, когда есть rsync over ssh?

Я как-то больше мыслю в сторону веб-сервисов.

SP>> PS: в итоге может быть даже кто-то откажется от доставки фидошной
SP>> почты на хотдоге в пользу доставки на компе и синхронизации в
SP>> дальнейшем с хотдогом. Это одна из мыслей, которую я думаю.
AV> Таким образом собакоед, по сути, превратится во внешний редактор.
AV> Что, разумеется, радует.

Что, неужели его доставщики сообщений настолько плохие?

--
Best regards!
Posted using Нotdoged on Android
--- Нotdoged/2.13.5/Android

Vladimir Fyodorov написал(а) к Sergey Poziturin в Mar 17 09:06:52 по местному времени:

Разнообразно приветствую тебя, Sergey!

21 Марта 2017, Sergey Poziturin писАл к Alexey Vissarionov следующее:

SP>>> 2. Какие средства синхронизации файлов для п.2 вы бы предложили,
SP>>> помимо root+rsync?
AV>> А зачем для rsync рутовые права?
SP> А есть его дистрибутив готовый под андроид без рута, без бизибокса и
SP> всего такого? Если есть, это упрощает задачу.

Если для синхронизации потребуется рутовать телефон, то многие предпочтут остаться без синхронизации. Я так точно.

Всяческих благ. Искренне Ваш, Vladimir Fyodorov, эсквайр.
... Пытка овеpквотингом пpодолжалась тpетий час
--- GoldED+/W64-MSVC 1.1.5-b20161221

Sergey Poziturin написал(а) к Vladimir Fyodorov в Mar 17 09:50:34 по местному времени:

Нello, Vladimir Fyodorov.
On 21.03.17 9:06 AM you wrote:

SP>>>> 2. Какие средства синхронизации файлов для п.2 вы бы
SP>>>> предложили, помимо root+rsync?
AV>>> А зачем для rsync рутовые права?
SP>> А есть его дистрибутив готовый под андроид без рута, без
SP>> бизибокса и всего такого? Если есть, это упрощает задачу.
VF> Если для синхронизации потребуется рутовать телефон, то многие
VF> предпочтут остаться без синхронизации. Я так точно.

И я тоже.

--
Best regards!
Posted using Нotdoged on Android
--- Нotdoged/2.13.5/Android

Yury Roschupkin написал(а) к Sergey Poziturin в Mar 17 13:04:12 по местному времени:

Нello, Sergey Poziturin.
On 21.03.17 8:40 you wrote:

SP> Возможно, нам придётся отказаться от концепции передачи файлов
SP> между телефоном и компом и перейти на передачу сообщений и
SP> статусов. Что-то типа nntp (передача новых сообщений с их
SP> статусами и флагами). Именно чтобы не гонять трафик лишний и чтобы
SP> можно было настроить количество сообщений, возраст максимальный и
SP> тд. И без rsync можно обойтись и этап сразу будет третий. Сделать
SP> эдакую распределенную базу сообщений между компом (или
SP> несколькими) и телефоном (или несколькими). Мне эта идея
SP> нравится. Заодно и телефоны подружим разные.

Я не девелопер, но как пользователю мне такой вариант нравится. Главное, сохранять на компе фидошные базы в прежнем виде.

--
WBR, YuR
--- Нotdoged/2.13.5/Android

Sergey Poziturin написал(а) к Yury Roschupkin в Mar 17 14:32:10 по местному времени:

Нello, Yury Roschupkin.
On 21.03.17 1:04 PM you wrote:

SP>> Возможно, нам придётся отказаться от концепции передачи файлов
SP>> между телефоном и компом и перейти на передачу сообщений и
SP>> статусов. Что-то типа nntp (передача новых сообщений с их
SP>> статусами и флагами). Именно чтобы не гонять трафик лишний и
SP>> чтобы можно было настроить количество сообщений, возраст
SP>> максимальный и тд. И без rsync можно обойтись и этап сразу
SP>> будет третий. Сделать эдакую распределенную базу сообщений
SP>> между компом (или несколькими) и телефоном (или несколькими).
SP>> Мне эта идея нравится. Заодно и телефоны подружим разные.
YR> Я не девелопер, но как пользователю мне такой вариант нравится.
YR> Главное, сохранять на компе фидошные базы в прежнем виде.

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

Чуть позже опубликую мысли по этому поводу.

--
Best regards!
Posted using Нotdoged on Android
--- Нotdoged/2.13.5/Android

Alexey Vissarionov написал(а) к Sergey Poziturin в Mar 17 15:42:36 по местному времени:

Доброго времени суток, Sergey!
21 Mar 2017 08:40:24, ты -> мне:

SP>>> Хочу приделать к хотдогу возможность синхронизировать свои базы с
SP>>> нашими настольными фидошными комплектами. На выходе хочу получить
SP>>> следующее: прозрачность (до определённой степени) работы с фидой
SP>>> на телефоне и на большом компе. Без разницы, где почта получена
SP>>> или читается. Делать это планируется в 3 этапа следующим образом:
SP>>> Этап 1. [...] jvm api для работы с базами сообщений
AV>> Это, соответственно, Jam и Squish, причем Squish более
AV>> распространен. Бывают и другие, но их количество пренебрежимо
AV>> мало.
SP> Отдельно стоит вопрос с нетмейлом, у некоторых база в msg

Покажите мне хотя бы одного человека, у которого это так И которого данное положение дел устраивает :-)

SP> (это же opus зовётся)?

Угу.

SP> Это скорее к Виталию, наверное, хочет ли он этим заниматься.

А смысл?
Ну вот правда - кому и, главное, на кой хрен может понадобиться msg?

SP>>> Таким образом на этом этапе имеем возможность наполнять фидошную
SP>>> базу сообщений несколькими независимыми методами: или с хотдога,
SP>>> или с софта на компе.
AV>> Насколько я пони мяу, речь про фидошный софт?
SP> Речь про наполнение фидошной базы сообщений. Есть, допустим,
SP> sq*-файл.

Прежде всего, .sqd (еще есть индексы и ластриды).

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

Да. Причем делать это придется в три прохода: на первом затаскиваем базу сообщений с ББ на КПК (инкрементально, ибо rsync), импортируем сообщения, которых нет в собакоеде (это будет медленная операция, ибо базу придется просматривать целиком; такова плата за минимализацию трафика при обмене), проверяем, не изменилась ли база на ББ (если да - снова затаскиваем итд), экспортируем написанные в собакоеде сообщения в локальную копию и уже ее отправляем на ББ.

В этой схеме есть всего одно место, где могут порыться подводные грабли: блокировка базы ББ на время синхронизации. Если при запуске тоссера можно банально проверить флаг и, если таковой есть, либо подождать, либо просто обработать сообщения при следующем запуске, то с редактором сложнее. Хотя остается возможность свалить это на пользователя :-)

SP>>> Функцию переноса базы с телефона на компьютер и обратно берёт
SP>>> на себя сам пользователь.
AV>> Думаю, для этого понадобится держать отдельно базу сообщений
AV>> собакоеда и опять-таки отдельно базу в squish.
SP> Так и есть, у хотдога всегда будет своя база сообщений (у
SP> редактора) в виде sqlite-бд.

Это понятно. А дополнительно к ней в соседнем каталоге будет squish-база.

SP>>> 2. Какие средства синхронизации файлов для п.2 вы бы предложили,
SP>>> помимо root+rsync?
AV>> А зачем для rsync рутовые права?
SP> А есть его дистрибутив готовый под андроид без рута, без бизибокса и
SP> всего такого? Если есть, это упрощает задачу.

Не знаю, но для работы ему нужны только возможность запустить ssh и доступ к файловой системе.

SP> Меня вообще говоря тоже не радует идея писать это все самостоятельно.

И не надо. А на ББ вообще никакой дополнительный софт не нужен.

SP>>> Я как джавист готов сделать некое референсное приложение на
SP>>> springboot, соответственно ему будет нужна ява-машина и
SP>>> вычислительные ресурсы,
AV>> Кхм... 1/20 типового АЛУ ("ядра") Xeon и 128 Мб памяти обслуживают
AV>> две сотни линков, практически все из которых тянут фуллфид, и при
AV>> этом тоссинг занимает всего 4 секунды каждые 10 минут. Вопрос:
AV>> сколько ресурсов надо будет выделить дополнительно для
AV>> обслуживания всего одного линка? :-)
SP> Вопрос открытый. По скорости все хорошо, а вот по памяти может быть
SP> несколько больше.

Это был намек на то, что софт для ББ не нужен. Вообще.

AV>> Да, чуть не забыл: gremlin@fido:~ > du -sh ~/fido/msgbase 2.6G
AV>> /home/gremlin/fido/msgbase
SP> Надеюсь, rsync не поперхнется.

Пфффф... Вот типичный пример, когда он работал примерно 10 секунд:

sent 1935 bytes received 9525633 bytes 907387.43 bytes/sec
total size is 57863636836 speedup is 6073.29

SP> Возможно, нам придётся отказаться от концепции передачи файлов между
SP> телефоном и компом и перейти на передачу сообщений и статусов. Что-то
SP> типа nntp (передача новых сообщений с их статусами и флагами). Именно
SP> чтобы не гонять трафик лишний и чтобы можно было настроить количество
SP> сообщений, возраст максимальный и тд. И без rsync можно обойтись и
SP> этап сразу будет третий.

Одного не понимаю: нахрена? Это уже будет не FTN, и даже не NNTP, а просто какая-то хня.

SP> Сделать эдакую распределенную базу сообщений между компом (или
SP> несколькими) и телефоном (или несколькими). Мне эта идея нравится.
SP> Заодно и телефоны подружим разные. Что скажешь?

Для распределенной базы понадобится добавлять ее поддержку в SMAPI. И еще хорошо, если в результате получится что-то похожее на... git :-)

SP>>> Готова ли общественность самостоятельно, хоть на php, реализовать
SP>>> для себя клиента протокола для приёма и отдачи файлов?
AV>> Реализовать-то можно... только нахрена, когда есть rsync over ssh?
SP> Я как-то больше мыслю в сторону веб-сервисов.

Ты всерьез думаешь, что ради фидошной читалки кто-то будет ставить tomcat и прочую ботву, которую он за собой потащит по зависимостям?

SP>>> PS: в итоге может быть даже кто-то откажется от доставки фидошной
SP>>> почты на хотдоге в пользу доставки на компе и синхронизации в
SP>>> дальнейшем с хотдогом. Это одна из мыслей, которую я думаю.
AV>> Таким образом собакоед, по сути, превратится во внешний редактор.
AV>> Что, разумеется, радует.
SP> Что, неужели его доставщики сообщений настолько плохие?

Они хорошие. Единственное, чего там не хватает лично мне - синхронизации ластридов между узлом и пойнтом.


--
Alexey V. Vissarionov aka Gremlin from Kremlin
gremlin ПРИ gremlin ТЧК ru; +vii-cmiii-ccxxix-lxxix-xlii

... Существует два уровня защиты: high и нэхай
--- /bin/vi

Sergey Poziturin написал(а) к Alexey Vissarionov в Mar 17 16:24:08 по местному времени:

Нi, Alexey!

21 мар 17 15:42, Alexey Vissarionov -> Sergey Poziturin:

SP>>>> Хочу приделать к хотдогу возможность синхронизировать свои базы
SP>>>> с нашими настольными фидошными комплектами. На выходе хочу
SP>>>> получить следующее: прозрачность (до определённой степени)
SP>>>> работы с фидой на телефоне и на большом компе. Без разницы, где
SP>>>> почта получена или читается. Делать это планируется в 3 этапа
SP>>>> следующим образом: Этап 1. [...] jvm api для работы с базами
SP>>>> сообщений
AV>>> Это, соответственно, Jam и Squish, причем Squish более
AV>>> распространен. Бывают и другие, но их количество пренебрежимо
AV>>> мало.
SP>> Отдельно стоит вопрос с нетмейлом, у некоторых база в msg
AV> Покажите мне хотя бы одного человека, у которого это так И которого
AV> данное положение дел устраивает :-)

Ну, скажем так, в 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 :-)

Не, SMAPI трогать не будем. Наша штука будет работать параллельно.

SP>>>> Готова ли общественность самостоятельно, хоть на php,
SP>>>> реализовать для себя клиента протокола для приёма и отдачи
SP>>>> файлов?
AV>>> Реализовать-то можно... только нахрена, когда есть rsync over
AV>>> ssh?
SP>> Я как-то больше мыслю в сторону веб-сервисов.
AV> Ты всерьез думаешь, что ради фидошной читалки кто-то будет ставить
AV> tomcat и прочую ботву, которую он за собой потащит по зависимостям?

Это не требуется, спрингбут представляет собой один jar, которому нужна только jre. Всё остальное там внутри.

Т.е. юзеру будет нужно:
1. Установить яву, если ещё не. По версии - это к автору API, я буду от его решения плясать.
2. Скачать софтину и ввести пару настроек (пути к базе, настройки сети и доступа).
3. Запустить софтину.
4. Обеспечить доступ к порту извне.

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

Кстати, для решения п.4 я думаю сделать какой-нибудь публичный гейт. Именно для этого протокола. Там делов на полдня, а юзеру не нужно морочиться с ip, пробросом и прочее.

То есть работать будет по такой схеме:

На компе:
Софтина на компе-> tcp outgoing -> Гейт

На телефоне:
Софтина на телефоне -> tcp outgoing -> Гейт -> existing tcp socket -> софтна на компе.

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

Естественно, будет возможность закрутить гайки на гейте.

Всё в этой схеме хорошо, но есть 2 минуса:

1. По ресурсам будет жрать больше на сервере, чем rsync.
Мои прикидки:
По диску где-то 150-200 Мб на jre+софт.
По оперативной памяти: думаю, 128 Мб на jre+tomcat+софт хватит. Это, конечно, будет зависеть от реализации API Виталием.

2. Требуется аудит безопасности гейта. Поскольку всё будет открыто, думаю, это не проблема.

Зато и плюсы есть:

1. Не нужно перекладывать логику (и cpu time) для анализа изменений на телефон. Это очень-очень-очень сэкномит батарейку.

2. Не нужно держать на телефоне файлы фидошных баз.

3. Не нужно морочиться с настройкой rsync и доступом к нему через инет.

Есть предположение, что по трафику будет паритет с rsync. Во-первых, потому что мы тоже передаём только изменённые данные (кстати, у rsync такое не всегда может получиться, например при пуржинге баз полетит твоё гигабайт на телефон в полном объёме), во-вторых, потому что мы тоже умеем использовать потоковое сжатие.

Открытые вопросы:

1. Как обеспечить блокировку базы и нужно ли это делать? Как отнесётся тоссер hpt, если в момент его тоссинга кто-то ещё запишет в эту базу сообщения?

2. Как разруливать ситуацию, когда между телефоном и гейтом связь есть, а между гейтом и компом нет? Сбрасывать, думаю. Хотя есть вариант копить и потом при появлении связи отдавать, но первый вариант мне нравится больше.

--
[ vbane72@yandex.ru ] [2:5020/2141] [ Нotdogs 4ever ]
http://vp.propush.ru
--- binkd/1.1a-94/Darwin | hpt/mac 1.9.0-cur | GoldED+/OSX 1.1.5-b20160322

Vitaliy Aksyonov написал(а) к Sergey Poziturin в Mar 17 17:19:20 по местному времени:

Привет, Sergey!

21 мар 17 16:24, Sergey Poziturin -> Alexey Vissarionov:

SP>>> Сделать эдакую распределенную базу сообщений между компом (или
SP>>> несколькими) и телефоном (или несколькими). Мне эта идея
SP>>> нравится. Заодно и телефоны подружим разные. Что скажешь?
AV>> Для распределенной базы понадобится добавлять ее поддержку в
AV>> SMAPI. И еще хорошо, если в результате получится что-то похожее
AV>> на... git :-)
SP> Не, SMAPI трогать не будем. Наша штука будет работать параллельно.

Да. Не надо мучать старичка. :)

SP>>>>> Готова ли общественность самостоятельно, хоть на php,
SP>>>>> реализовать для себя клиента протокола для приёма и отдачи
SP>>>>> файлов?
AV>>>> Реализовать-то можно... только нахрена, когда есть rsync over
AV>>>> ssh?
SP>>> Я как-то больше мыслю в сторону веб-сервисов.
AV>> Ты всерьез думаешь, что ради фидошной читалки кто-то будет
AV>> ставить tomcat и прочую ботву, которую он за собой потащит по
AV>> зависимостям?

[skip]

SP> Всё в этой схеме хорошо, но есть 2 минуса:

SP> 1. По ресурсам будет жрать больше на сервере, чем rsync.
SP> Мои прикидки:
SP> По диску где-то 150-200 Мб на jre+софт.
SP> По оперативной памяти: думаю, 128 Мб на jre+tomcat+софт хватит. Это,
SP> кoонечно, будет зависеть от реализации API Виталием.

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

SP> Открытые вопросы:
SP> 1. Как обеспечить блокировку базы и нужно ли это делать? Как отнесётся
SP> тоссер hpt, если в момент его тоссинга кто-то ещё запишет в эту базу
SP> сообщения?

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

SP> 2. Как разруливать ситуацию, когда между телефоном и гейтом связь
SP> есть, а между гейтом и компом нет? Сбрасывать, думаю. Хотя есть
SP> вариант копить и потом при появлении связи отдавать, но первый вариант
SP> мне нравится больше.

А нужен ли гейт? Зачем плодить сущности?

С наилучшими пожеланиями, Vitaliy.

... 10.0 times 0.10 is hardly ever 1.00.
--- GoldED+/LNX 1.1.5-b20160201

Sergey Poziturin написал(а) к Vitaliy Aksyonov в Mar 17 19:57:30 по местному времени:

Нello, Vitaliy Aksyonov.
On 21.03.17 5:19 PM you wrote:

SP>> Всё в этой схеме хорошо, но есть 2 минуса: 1. По ресурсам будет
SP>> жрать больше на сервере, чем rsync. Мои прикидки: По диску где-то
SP>> 150-200 Мб на jre+софт. По оперативной памяти: думаю, 128 Мб на
SP>> jre+tomcat+софт хватит. Это, кoонечно, будет зависеть от
SP>> реализации API Виталием.
VA> Большого расхода не предполагается. Всю базу в память грузить не
VA> буду. Максимум - те сообщения, что пользователь либы загрузил и
VA> держит. Если поднадобится работать с ну очень большими
VA> сообщениями, можно продумать загрузку кусками.

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

SP>> 2. Как разруливать ситуацию, когда между телефоном и гейтом связь
SP>> есть, а между гейтом и компом нет? Сбрасывать, думаю. Хотя есть
SP>> вариант копить и потом при появлении связи отдавать, но первый
SP>> вариант мне нравится больше.
VA> А нужен ли гейт? Зачем плодить сущности?

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

А ведь это типичная ситуация у людей (кроме админов).

--
Best regards!
Posted using Нotdoged on Android
--- Нotdoged/2.13.5/Android

Vitaliy Aksyonov написал(а) к Sergey Poziturin в Mar 17 20:25:54 по местному времени:

Привет, Sergey!

21 мар 17 19:57, Sergey Poziturin -> Vitaliy Aksyonov:

SP>>> Всё в этой схеме хорошо, но есть 2 минуса: 1. По ресурсам будет
SP>>> жрать больше на сервере, чем rsync. Мои прикидки: По диску
SP>>> где-то 150-200 Мб на jre+софт. По оперативной памяти: думаю, 128
SP>>> Мб на jre+tomcat+софт хватит. Это, кoонечно, будет зависеть от
SP>>> реализации API Виталием.
VA>> Большого расхода не предполагается. Всю базу в память грузить не
VA>> буду. Максимум - те сообщения, что пользователь либы загрузил и
VA>> держит. Если поднадобится работать с ну очень большими
VA>> сообщениями, можно продумать загрузку кусками.
SP> Нет, об этом пока не думай, больших сообщений (таких, что не пролезут
SP> в память) не будет.

Это возможнная доделка на несильно близкое будущее. :)
Я просто к тому, что так сделать тоже можно.

SP>>> 2. Как разруливать ситуацию, когда между телефоном и гейтом
SP>>> связь есть, а между гейтом и компом нет? Сбрасывать, думаю. Хотя
SP>>> есть вариант копить и потом при появлении связи отдавать, но
SP>>> первый вариант мне нравится больше.
VA>> А нужен ли гейт? Зачем плодить сущности?
SP> Как без гейта связать два устройства, не имеющих возможности принять
SP> из сети входящее соединение? Например, они за прокси и не имеют белого
SP> адреса или коннекты им просто недоступны по любой причине?

SP> А ведь это типичная ситуация у людей (кроме админов).

В таком случае, конечно да.

С наилучшими пожеланиями, Vitaliy.

... 10.0 times 0.10 is hardly ever 1.00.
--- GoldED+/LNX 1.1.5-b20160201