В свете обострившейся шизофрении, выразившейся в суете вокруг альтернативных Янусу клиентов (да-да, я тоже ей подвержен ), возникает ряд вопросов, который меня интересует меня лично пока несколько теоретически.
Что из нижеследующего востребовано или может быть востребовано янусо(шиво-, сунайо-, оркасо-)водом? Что еще может быть востребовано?
Многопользовательность
Насколько в Янусе востребована поддержка нескольких гуи-клиентов на один янус-сервер?
Ситуации, где это может быть востребовано я вижу две:
— Офис, где несколько человек являются участниками РСДН
— Дом, где несколько пользователей на один компьютер
Поддержка других протоколов
— RSS, Atom, Jabber, ICQ, парсинг любых форумов по выбору, WordPress/Livejournal RPC (подчеркнуть, зачеркнуть, посолить по вкусу)
Дело в том, что в интернете я, например, пользуюсь только двумя-тремя сайтами (GMail, RSDN), RSS запускаю очень периодически, а возможность читать, скажем, программерские блоги без отрыва от RSDN я бы поприветствовал.
Синхронизация статуса баз между компьютерами
Чаще всего в связке работа-дом-работа, когда везде стоит любимый Янус, а статус прочитано-не прочитано везде разный
Компактность
Также известный, как "Янус на брелке". Возможность запускать Янус с (практически) любого носителя
Здравствуйте, Mamut, Вы писали:
M>Что из нижеследующего востребовано или может быть востребовано янусо(шиво-, сунайо-, оркасо-)водом? Что еще может быть востребовано?
M>Многопользовательность
ИМХО, маловостребовано.
M>Поддержка других протоколов
Интересно, но не более того.
M>Синхронизация статуса баз между компьютерами
ДА!!!
M>Компактность
ИМХО, если будет синхронизация статуса то не нужна.
А вот чего не хватает, так это проверки правописания.
Здравствуйте, Mamut, Вы писали:
M>В свете обострившейся шизофрении, выразившейся в суете вокруг альтернативных Янусу клиентов
Тогда усугубим.
M>Поддержка других протоколов M>- RSS, Atom, Jabber, ICQ, парсинг любых форумов по выбору, WordPress/Livejournal RPC (подчеркнуть, зачеркнуть, посолить по вкусу)
Возможность работы с форумами на движках ipb и phpbb.
M>Синхронизация статуса баз между компьютерами M>Компактность
Скорее будет интересна возможность использования одной базы под разными ОС в пределах одного локального компьютера.
M>Также известный, как "Янус на брелке". Возможность запускать Янус с (практически) любого носителя
Неплохо, но навернорное, актуальнее транспортабельность баз.
В задаче спрашивается:
Сколько вытечет портвейна из открытого бассейна?
Здравствуйте, Mamut, Вы писали:
M>Синхронизация статуса баз между компьютерами
И не только статуса, но и самих баз, то есть например сделать дамп за неделю, шоб дома не выкачивать заного, что на работе уже выкачал.
... << RSDN@Home 1.2.0 alpha rev. 655>>
"Бог не терпит голой сингулярности" -- Роджер Пенроуз
Здравствуйте, Mamut, Вы писали:
M>В свете обострившейся шизофрении, выразившейся в суете вокруг альтернативных Янусу клиентов (да-да, я тоже ей подвержен ), возникает ряд вопросов, который меня интересует меня лично пока несколько теоретически.
Я скоро выложу еще один.
M>Многопользовательность M>Насколько в Янусе востребована поддержка нескольких гуи-клиентов на один янус-сервер?
Как раз сейчас делаю янус-прокси. То есть как с обычного клиента, так и с альтернативного идет доступ по другому урлу. И каждый базу держит у себя. Востребовано нами именно в этом ключе. Хотя, если дать один янус клиент-сервер, можно подумать..
M>- Дом, где несколько пользователей на один компьютер
Дома редко янусом пользуюсь.
M>- RSS, Atom, Jabber, ICQ, парсинг любых форумов по выбору, WordPress/Livejournal RPC (подчеркнуть, зачеркнуть, посолить по вкусу)
Мне не надо ничего из этого.
M>Синхронизация статуса баз между компьютерами M>Чаще всего в связке работа-дом-работа, когда везде стоит любимый Янус, а статус прочитано-не прочитано везде разный
Да, репликация, конечно, интересная вещь, только еще не думал.
M>Компактность M>Также известный, как "Янус на брелке". Возможность запускать Янус с (практически) любого носителя
Здравствуйте, Mamut, Вы писали:
M>Что из нижеследующего востребовано или может быть востребовано янусо(шиво-, сунайо-, оркасо-)водом? Что еще может быть востребовано?
M>Многопользовательность
По личному опыту — не востребовано.
M>Поддержка других протоколов
Я буду делать плагины к шиве для популярных движков форумов. Собственно и к движкам форумов для шивы.
Ну и также для популярных порталов по согласию с "руководством" этого портала
M>Синхронизация статуса баз между компьютерами
имхо будет востребована гдето 30% пользователей.
M>Компактность
Ммм... кабы былабы у меня пальма, я бы сделал модуль синхронизации не с интерентом, а с клиентом...
Здравствуйте, Mamut, Вы писали:
M>Многопользовательность
M>Насколько в Янусе востребована поддержка нескольких гуи-клиентов на один янус-сервер?
Лично мне абсолютно без надобности. Даже с учетом наличия нескольких человек в одной конторе. Бо предпочитаю сам заниматься управлением базой, а, трафик у януса все таки не настолько большой, чтобы из-за его экономии идти на серьезное усложнение администрирования.
M>Поддержка других протоколов M>- RSS, Atom, Jabber, ICQ, парсинг любых форумов по выбору, WordPress/Livejournal RPC (подчеркнуть, зачеркнуть, посолить по вкусу)
Лично мне совершенно без надобности. Меня и отдельные клиенты устраивают.
M>Синхронизация статуса баз между компьютерами
M>Чаще всего в связке работа-дом-работа, когда везде стоит любимый Янус, а статус прочитано-не прочитано везде разный
Нужна, но тут много вопросов о том, как это будет выглядеть.
M>Компактность
M>Также известный, как "Янус на брелке". Возможность запускать Янус с (практически) любого носителя
Не выйдет. Большая БД януса потребует быстрый носитель.
M>>Компактность
M>>Также известный, как "Янус на брелке". Возможность запускать Янус с (практически) любого носителя
AVK>Не выйдет. Большая БД януса потребует быстрый носитель.
Когда я это писал, я имел в виду один янус, много баз данных, но только потом понял, что такая схема — это, по меньшей мере, глупо
Здравствуйте, Mamut, Вы писали:
M>Многопользовательность
Сам по себе Янус персонален, и ориентирован на личное использование. Однако в принципе можно выделить тексты сообщений в общее пользование. Это может быть как отдельный источник данных, так и много чего. Но реально Янус в таком режиме будут эксплуатировать единицы. В пересчёте на сжатый трафик это копейки — полная подписка тянет на 2-3 МБ в сутки в среднем.
Я прорабатывал (на бумаге и в реале) несколько вариантов разделения ЛБД с учётом быстродействия и многопользования. Делать 2 ЛБД (одну для тел сообщений, вторую для остальной персональной информации) довольно накладно и нелогично. Как раз таки хотелось бы, чтобы источник данных и ЛБД была одна.
Но можно пооптимизировать таблицы, например, отделить флажок прочтений от каждого сообщения. Но тут надо серьёзно пересматривать идеологию работы и перепроектировать. А времени, как обычно, мало.
M>Насколько в Янусе востребована поддержка нескольких гуи-клиентов на один янус-сервер?
Глупости это, по моему. Тут хотя бы один до ума довести, а ты про несколько говоришь.
M>Поддержка других протоколов
По моему, нафиг. Только головная боль. Да и есть же куча клиентов, превосходно заточенных под свою нишу — Квип, etc. Не надо брать на себя непосильный труд и "отбирать хлеб" у других.
Вопрос работы с др. форумами — это на самом деле вопрос их синхронизации с сервером РСДН. Помнишь, сколько вою было по одному только дружественному и очень идеологически похожему (только без оценок) ГДН? Пока не отделили их в свой инкубатор.
M>Дело в том, что в интернете я, например, пользуюсь только двумя-тремя сайтами (GMail, RSDN), RSS запускаю очень периодически, а возможность читать, скажем, программерские блоги без отрыва от RSDN я бы поприветствовал.
Ну, и я не только Янусом пользуюсь. Но смысла совмещать все мои инструменты в одном монстрике — смысла никакого нет.
M>Синхронизация статуса баз между компьютерами
А вот это да, я в таком режиме давно работаю, а ничего лучше пометки прочитанным до даты нет. Опять же, ты всегда будешь перед уходом с работы жмакать пункт меню, выгружать синхрофайл на флешь, а потом по приходу его загружать в др. копию Януса?
Я вот жуть как иногда ленивый бываю.
Мне вот больше интересна функция опердня в банке — типа выбрал дату (и время), и вижу только то, что было получено на эту дату, конечно, с поправкой на модераторов и пр. Но это как бы фильтры и поиск.
M>Компактность
M>Также известный, как "Янус на брелке". Возможность запускать Янус с (практически) любого носителя
ЛБД у Януса бывает весьма неслабенькая. И для работы она нужна в распакованном виде. Правда, есть задумка по сжатию тел сообщений, она обсуждалась и признана полезной. Вот у меня скоро SQLE достигнет критической отметки, чую, придётся внедрять сжатие. Ну, или расстаться с польной ЛБД, что "категорически непреемлимо".
A>Мне вот больше интересна функция опердня в банке — типа выбрал дату (и время), и вижу только то, что было получено на эту дату, конечно, с поправкой на модераторов и пр. Но это как бы фильтры и поиск.
сделать бы виртуальные папки (типа как в thunderbird), там заходишь в папку (с настроенными фильтрами), запускается поиск на БД писем и получаешь только удовлетворившие твоему запросу письма. Удобно.
Здравствуйте, Mamut, Вы писали:
M>Синхронизация статуса баз между компьютерами
M>Чаще всего в связке работа-дом-работа, когда везде стоит любимый Янус, а статус прочитано-не прочитано везде разный
IS A MUST! Задирает запускать SQL скрипты для backup/restore януса плюс таскать саму базу на флэшке не очень удобно — приходится жать.
в итоге отказался почти от пользования RSDN из дома —
M>Компактность
M>Также известный, как "Янус на брелке". Возможность запускать Янус с (практически) любого носителя
к сожалению не в курсе что имеется ввиду точно под концепцией "Янус на брелке", но вот мысли проходящего мимо:
запускать-то наверное можно Янус и сейчас хоть откуда — только базу-то где держать? вот если бы все за исключением каких-то "горячих" локальных веток было доступно в таком режиме онлайн — типа gmail, то тогда интересно. но для этого сейчас web-морда служит, не так ли? в чем соль сего пункта?
Опять же это должно быть вероятно как-то связано с пред. пунктом — чтобы синхронизация "брелочного" и основных янусов была. На брелке хранятся ветки за посл неделю-две + то что помечено как "невытесняемое" — чтобы размер был в норме. И постоянная синхронизация в т.ч. и с учетом лимитов по времени (посл 1-2 недели или только темы куда были ответы за посл 1-2 недели).
PS И еще вспомнилось: нафига столько мелких файлов в \buttons — их бы встроить в либу с ресурсами. По одной либе на скин-стиль?
Valery A. Boronin, RSDN Team, linkedin.com\in\boronin
R&D Mgmt & Security. AppSec & SDL. Data Protection and Systems Programming. FDE, DLP, Incident Management. Windows Filesystems and Drivers.
Здравствуйте, Valery A. Boronin, Вы писали:
VAB>в итоге отказался почти от пользования RSDN из дома -
Я не отказался, предпочитаю синхронизироваться раздельно. Цена вопроса — 1-2 МБ трафика и пометка прочитанным до даты-времени.
До этого пробовал сжимать ЛБД на флешку — надоело терять время по 10-15 мин.
VAB>запускать-то наверное можно Янус и сейчас хоть откуда — только базу-то где держать?
Вот-вот, куда серьёзнее пухлость ЛБД. И всё из-за сообщений, которые надо научится сжимать тем же gzip.
M>Синхронизация статуса баз между компьютерами
Это пожалуй единственной, чего мне сейчас не хватает.
Причем очень бы хотелось, чтобы статус прочитано/нет хранился на сервере, и каждый клиент брал его от туда. Думаю, что затраты трафика будут не очень большими, а функция будет очень востребована.
Я представляю это следующим образом
1. При каждом обновлении клиент отправляет список прочитанных сообщений и это запоминается на сервере.
2. При скачивании сообщений клиент получает и их статус.
3. Кроме того небходимо передать дополнительный пакет о темах прочитанных другим клиентом.
Здравствуйте, woof, Вы писали:
W>Причем очень бы хотелось, чтобы статус прочитано/нет хранился на сервере, и каждый клиент брал его от туда. Думаю, что затраты трафика будут не очень большими, а функция будет очень востребована.
Это уже несколько раз обсуждалось.. Проблема в том что RSDN -- сервер не резиновый и хранить инфу для каждого юзера о том что прочитано, а что нет очень затратно. Хотя если вспомнить что активный пользователей не так много, и хранить например только за последний месяц... Но если вспомнить про тормознутость сервера в часы пик (сейчас это временно пофикшено), то сразу как то не хочется его еще чем то нагружать
... << RSDN@Home 1.2.0 alpha rev. 655>>
"Бог не терпит голой сингулярности" -- Роджер Пенроуз
Здравствуйте, CiViLiS, Вы писали:
CVL>Это уже несколько раз обсуждалось.. Проблема в том что RSDN -- сервер не резиновый и хранить инфу для каждого юзера о том что прочитано, а что нет очень затратно. Хотя если вспомнить что активный пользователей не так много, и хранить например только за последний месяц... Но если вспомнить про тормознутость сервера в часы пик (сейчас это временно пофикшено), то сразу как то не хочется его еще чем то нагружать
Может, в этом случае поискать доброго самаритянина, который сможет предоставить небольшой кусочек сервера для этих целей? Да и таблица кажется будет не очень большой
id пользователя, id сообщения, дата, когда сообщение было прочитано.
Да если еще и по времени ограничить, то не так много должно получиться.
A>Сколько там, говоришь, миллионов сообщений на РСДН? А тысяч пользователей?
Не знаю, но мне это и не нужно, потому как число строк в таблице = количество установленных клиентов * количество прочитанных в клиенте сообщений, например за месяц, так что числа будут не такими уж и большими.
А если сделать эту фичу опциональной, ведь нужна она далеко не всем, то еще процентов на 50 можно уменьшить.
A>>Сколько там, говоришь, миллионов сообщений на РСДН? А тысяч пользователей?
W>Не знаю, но мне это и не нужно, потому как число строк в таблице = количество установленных клиентов * количество прочитанных в клиенте сообщений, например за месяц, так что числа будут не такими уж и большими.
W>А если сделать эту фичу опциональной, ведь нужна она далеко не всем, то еще процентов на 50 можно уменьшить.
В последний раз у меня только непрочитанных было 300 000 сообщений, а прочитанных и того больше. Ну, скажем, миллион. Если десяти пользователям такая фишка понадобится....
Есть также возможность применения нетривиальных алгоритмов. Например, я нажал "считать ветку прочитанной". Можно тогда в базе сохранить только id корневого сообщения с каки-нить флагом. Но если в эту ветку кто-нибудь что-нибудь напишет, что будем делать? И т.п.
), возникает ряд вопросов, который меня интересует меня лично пока несколько теоретически.
