Очередная вариация на тему distributed blog

[vitus_wagner]

Тут случайно сегодня попалась информация о существовании pump.io - распределенной социальной сети, поддерживающей репликацию, федерацию и тому подобные интересные фишки. Конечно, оно так же как и diaspora больше заточено под twitter-like чем под ЖЖ-like стиль общения

Comments

[shaplov]

https://tent.io/docs -- видел?

Вот я себя подумываю на него переводить...

[vitus_wagner]

Там как-то не очень ориентировано на доступ простых людей с простыми браузерами.

[vitus_wagner]

И врообще идея "to store all your data in one place that you control." мне категорически не нравится. Я хочу чтобы существовало возможно больше (лучше тысячи) мест, где хранятся копии моих публичных постов, чтобы в случае если одно навернется, всегда было откуда восстановить.

[qkowlew]

Я бы даже согласился на логику:
- все, кто прочли мой пост целиком, гарантируют его хранение в течение ... срока.
- все, кто дали ссылку на мой пост, гарантируют его хранение вечно (в смысле - пока есть техническая возможность)

[amarao_san]

Не могу сказать насчёт производительности, но монга и redis много менее удачные места для надёжного хранения данных, чем мускуль.

[vitus_wagner]

Весь прикол распределенных социальных сетей в том, что надежность каждого конкретного узла абсолютно не критична.

[qkowlew]

Надёжность по пропаданию информации - не критична.
А вот по искажению структуры и связности - может быть.

[taris_marh]

Редиска жрёт память, иначе в ней толку никакого, а монга - тормоз из-за своей структуры. То есть, где-то полезна, но не самый удобный вариант, мне кажется. Если придерживаться идеологии "много читают, мало пишут" и при этом ставить на машину пользователя минимум софта, то оптимально выглядит, на мой взгляд, питон, у которого в стандартной поставке есть SQLite, вполне пригодный для хранения структурированных данных при таком режиме работы, и GDBM для индексов. При том, что это чудо будет большую часть времени просто спать в свопе. К тому же, на самом питоне можно нарисовать вполне неплохой сервер: держать бешенные нагрузки ему всё равно нафиг не сдалось и в подавляющем большинстве случаев он неплохо справится с работой. А если вдруг кому большой публичности захочется и прямых ссылок, то можно и апача поднять, и nginx. Сервер в стандартных библиотеках есть, хотя и кастрированный до минимализма. Или можно попробовать выдрать из Django, только его надо будет допилить, чтобы многопоточным был, а то он под разработку заточен и потому

[messirvoland]

> написано оно не на php, а на node.js
Ви так говорите какбудтобы это хорошо
Так как имел опыт использования библиотек и фреймворков на обоих - это просто сорта.

[qkowlew]

ППКС.
Не вижу никакой разницы, в конечном итоге.

[anonim_legion]

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

[vitus_wagner]

Команда панков это PHP разрабатывали. в Node.js там по крайней мере в основе лежит нормальный язык - ECMAScript сделанный умными людьми. Да и реализация его взята из Chrome. Тоже не самое худшее что есть на белом свете.

Вот что у них получилось в качестве объектной модели - это смотреть надо. Но насколкьо я успел увидеть, там везде There is more than one way to do it. Например, для работы с файловой системой есть альтернативные реализации.

[qkowlew]

IMHO:
сколько-нибудь завоюет мир это только при условии, что будет:
- запускаться, не инсталлируясь, "в один клик и вводим авторизационную информацию" под любую операционку.

[vitus_wagner]

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

[yurikhan]

Из опыта работы с mongodb получается, что её писали вредители. Абсолютно весь API и дизайн заточен под то, чтобы как можно сильнее оградить клиентский код от возможности делать полезные запросы к базе и увеличить вероятность непреднамеренного уничтожения данных.

Типичный симптом при использовании mongo - приложение работает, пока объём или количество документов в базе не превышает некоторого эпсилона, достаточно большого, чтобы проблемы не возникали в тестировании.

Обосную при необходимости.

[stiv_sigmal]

А если не сложно, обоснуйте? Или ткните в более-менее тезисную/обзорную статью на тему.

[yurikhan]

OK. Я не буду утверждать, что все перечисленные проблемы актуальны для приложения «распределённый блог» - я просто выпишу всё, что меня (и мою команду) раздражает в Mongo. Можно читать/комментировать в Dreamwidth или в ЖЖ.

[stiv_sigmal]

Я ж не спора ради, мне действительно интересно.