Насчет 8bit clean двунаправленого канала -- уже можно какой нибудь тупой вебсервис сделать. Вот не нужно делать свой протокол на таком низком уровне (по крайней мере на таком раннем этапе).
На этапе раннего прототипа я бы считал что мы можем показать все хранилище на FS через http, или дать rest api к нему (идеальным я бы считал прямой RO доступ, и RW чере апи)
Случаи когда есть только двунаправленый линк без http (или даже tcp) я бы рассматривал отдельно. Возможно там имеет смысл гонять бандлы (которые вообще transport agnostic)
Синхронизатор должен уметь работать с двумя хранилищами (либо на fs/fs+http, либо через апи). Потом можно будет добавить и свой протокол (для тех кому хочется/надо), и бандлы.
storage (формат) + синхронизатор + генератор статики по сообщениям базы + что-то динамически работающее с базой (просмотр/ответы) -- это уже тянет на MVP, особенно если есть хотя бы две реализации хранилища на разных языках.
Поэтому сообщения должны быть самодостаточны, и если ссылаться на другие объекты, то только на сообщения обладающие всеми свойствами сообщения (т.е. embedded метаинформацией и электронной подписью автора).
Вот по моему -- 1 файл на сообщение -- это тоже самоцель, во первых мы теряем возможность (дешевой) дедупликации аттачей/медиаконтента. 50 человек решат сделать пост с гигабайтным видео с котиком, и мы имеем 50 гиг трафика на ровном месте. И 50гиг на хранилищах у всех в эпсилон окрестности. (дедупликация на том же zfs -- это очень дорого по CPU и памяти, ОЧЕНЬ, я пробовал этот кактус на вкус)
во вторых -- мы теряем возможность протаскивать важное и актуальное через узкие линки -- если у нас упал терабитный спутниковый канал, и есть только модем лександ на 1200 бод, у нас поедут только тексты и метаданные. А видео с котиками приедут через неделю, когда прилетит новый спутник.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
branchandroot
no subject
Date: 2017-04-05 08:51 pm (UTC)На этапе раннего прототипа я бы считал что мы можем показать все хранилище на FS через http, или дать rest api к нему (идеальным я бы считал прямой RO доступ, и RW чере апи)
Случаи когда есть только двунаправленый линк без http (или даже tcp) я бы рассматривал отдельно. Возможно там имеет смысл гонять бандлы (которые вообще transport agnostic)
Синхронизатор должен уметь работать с двумя хранилищами (либо на fs/fs+http, либо через апи). Потом можно будет добавить и свой протокол (для тех кому хочется/надо), и бандлы.
storage (формат) + синхронизатор + генератор статики по сообщениям базы + что-то динамически работающее с базой (просмотр/ответы) -- это уже тянет на MVP, особенно если есть хотя бы две реализации хранилища на разных языках.
Вот по моему -- 1 файл на сообщение -- это тоже самоцель, во первых мы теряем возможность (дешевой) дедупликации аттачей/медиаконтента. 50 человек решат сделать пост с гигабайтным видео с котиком, и мы имеем 50 гиг трафика на ровном месте.
И 50гиг на хранилищах у всех в эпсилон окрестности. (дедупликация на том же zfs -- это очень дорого по CPU и памяти, ОЧЕНЬ, я пробовал этот кактус на вкус)
во вторых -- мы теряем возможность протаскивать важное и актуальное через узкие линки -- если у нас упал терабитный спутниковый канал, и есть только модем лександ на 1200 бод, у нас поедут только тексты и метаданные. А видео с котиками приедут через неделю, когда прилетит новый спутник.