NA> Если в двух словах. Я бы отошёл от каноничного "по поенту на каждое NA> устройство", а больше бы следовал идеалогии "клауда". Почему все эти NA> гуглы, фб, вк, .. можно заходить с любого устройства или с веба и будешь NA> видеть свои прочитанные и непрочитанные одинаково? Потому что они все NA> заходят в некую БД в клауде. Мой дизайн - типичная нода может обеспечить NA> тот самый клауд, ведь у неё обычно есть белый-ip, как-то она входящие NA> бинки же принимает? Сисоп на ноде не меняет ничего в своём любимом софте, NA> также есть мейлер, тоссер, и любимый редактор. Сисоп на ноде ставить сбоку NA> программулину, по типу jamnntpd, которая читает/пишет джам/сквишь базы и NA> отдаёт, например, по gRPC или REST клиентам. Гипотетический хотдог может NA> ходить на ноду по gRPC, как если бы он ходил в локальные свои базы, а при NA> этом сервер уже читает/пишет из общих баз. Таким образом сам сисоп мог бы NA> иметь прочитанные/непрочитанные ровно также, как и голдед их видет в базе. NA> Для поентов можно не натоссивать отдельные копии всех писем из базы, они NA> могут ходить в теже базы, только их ластридеры и прочитанные/непрочитанные NA> надо где-то ещё сбоку хранить, ну и нетмейл через perl-хук в отдельую "по NA> базе на каждого поента". Но ведь фидо это про оффлайновую работу, а я тут NA> про строгий онлайн при чтении/написании, так? Так-то так, но клиент всегда NA> может накэшировать впрок, и даже отключиться после этого, чем это не NA> оффлайн?
Вот, примерно так и работает tg_BBS. Только для всего этого используется уже существующее решение Телеграмчика и его ресурсы. Большой минус, сразу подмеченый Гремлином, в том, что это проприоритарная система и в любой момент нам может быть отказано.
Have nice nights. Stas Mishchenkov.
--- Не откладывайте на завтра - кладите на всё уже сегодня. * Origin: Lame Users Breeding. Simferopol, Crimea. (2:460/5858)
