Привет всем!
После разговора с Sheridan'ом прояснились некоторые детали по сабжу.
В частности, есть идея разделить RSDN@Linux на две части:
1. Драйвер -- синх+драйвер к БД, скажем в виде демона.
2. Представление -- в данном случае это некий клиент который используеться драйвер для доступа к БД и синхронизации. К примеру это может быть веб-интерфейс на Джаве, десктопная программа просмотра, наподобие Janus'a или вообще плагин к FF
Так что сейчас требуеться лишь начать. Начать предлагаю с рефакторинга сервиса синхронизации Януса на С++ и к-платформенную библиотеку SOAP'a, наподобие gSOAP.
Всё в интересе со стороны C++'ников Linux'оидов.
СУВ.
... << А писал я этот бред на RSDN@Home 1.1.4 beta 7 rev. 447, под звуки Deep Purple — Sail Away>>
Здравствуйте, Mr.Chipset, Вы писали:
MC>Привет всем! MC>После разговора с Sheridan'ом прояснились некоторые детали по сабжу. MC>В частности, есть идея разделить RSDN@Linux на две части: MC>1. Драйвер -- синх+драйвер к БД, скажем в виде демона. MC>2. Представление -- в данном случае это некий клиент который используеться драйвер для доступа к БД и синхронизации. К примеру это может быть веб-интерфейс на Джаве, десктопная программа просмотра, наподобие Janus'a или вообще плагин к FF
Клиент не пользует синхронизацию, он может лиш попросить демона засинхронизироватся. Демон же читает /etc/janus.conf и оттуда узнает все что ему надо в том числе и когда и сколько синхронизировать... И решает выполнить ли просьбу клиента сейчас или ненада...
MC>Так что сейчас требуеться лишь начать. Начать предлагаю с рефакторинга сервиса синхронизации Януса на С++ и к-платформенную библиотеку SOAP'a, наподобие gSOAP.
имхо нужно пользовать qt (гуру, разрешат нам ее пользовать кутешники в данном контексте) и попробовать писать кроссплатформенно. Тобиш линуховый демон для винды переделывать в сервис для NT или просто экзешник для 9x... Гуя само собой...
Тоесть изначально хотелось бы почитать про объектную модель, и переписать ее на с++, затем братся собственно за демона (вплотную) и гую (по мере сил). По мере сил это потому что всетаки гуя в этом случае действительно может быть любая, от мода к апачу до standalone exe. Главное продумать как гуя будет с демоном работать.
MC>Всё в интересе со стороны C++'ников Linux'оидов. MC>СУВ.
MC>>Так что сейчас требуеться лишь начать. Начать предлагаю с рефакторинга сервиса синхронизации Януса на С++ и к-платформенную библиотеку SOAP'a, наподобие gSOAP. S>имхо нужно пользовать qt (гуру, разрешат нам ее пользовать кутешники в данном контексте) и попробовать писать кроссплатформенно. Тобиш линуховый демон для винды переделывать в сервис для NT или просто экзешник для 9x... Гуя само собой...
Для синхронизации с веб сервисом подойдет gSOAP, я его за вымя не трогал, просто покопался у них на сайте. Например, ихний WSDL compiler великолепно справляется с Янусовским веб-сервисом. И кросс-платформенный тож.
В стандартной поставке Qt нет инструментов для работы с Веб-сервисами, но при наличии gSOAP их и не надо, имхо.
Насчет демонов и сервисов... В Qt Solutions есть решение для создания *никсовских демонов и виндовых сервисов. Единственное но — Solutions — это платная вещь, хоть и можно ее достать бесплатно
Насчет Qt вообще... Можно, теоретически, начинать все это дело писать уже на Qt4, благо и под винду он будет GPL.
S>Тоесть изначально хотелось бы почитать про объектную модель, и переписать ее на с++, затем братся собственно за демона (вплотную) и гую (по мере сил). По мере сил это потому что всетаки гуя в этом случае действительно может быть любая, от мода к апачу до standalone exe. Главное продумать как гуя будет с демоном работать.
В Qt есть большой плюс — наличие драйверов к базам данным (в четвертой версии будет поддержка SQLite3, например). Думается мне, что если покопаться в исходниках, то можно драйвер к любой базе написать.
А главный минус — то, что виртуальный грид надо будет писать полностью с нуля, на основе QTable или, боже упаси, QGridView
А и еще — надо будет решить, использовать Сцинтиллу или обойтись QTextView с собственными QStyleSheet'ами...
Здравствуйте, Mamut, Вы писали:
M>А главный минус — то, что виртуальный грид надо будет писать полностью с нуля, на основе QTable или, боже упаси, QGridView
Что есть виртгрид? Если это messagetree то оно нам впринципе ненужно. Можно реализовать один из интерфейсов, описаных гдетотут... К томуже это дело интерфейса как все отображать...
Скажем — к демону будет 4 основных запроса относящихся к форуму.
1. Дай список форумов
2. Дай список самых верхних веток форума
3. Дай дерево начиная с такойто ветки
4. Дай тело сообщения
Дело демона дать что просят.
Дело вьювера какнибудь показать.
M>А и еще — надо будет решить, использовать Сцинтиллу или обойтись QTextView с собственными QStyleSheet'ами...
Скорее второе. Цинтила чета мне ненравица... Хотя будем посмотреть.
Здравствуйте, Mamut, Вы писали:
M>Насчет демонов и сервисов... В Qt Solutions есть решение для создания *никсовских демонов и виндовых сервисов. Единственное но — Solutions — это платная вещь, хоть и можно ее достать бесплатно
неужели демон такая сложная штука что для него нужно искать крякнутый "Qt Solutions"
M>Насчет Qt вообще... Можно, теоретически, начинать все это дело писать уже на Qt4, благо и под винду он будет GPL.
C++, Qt, QTable, QTextView..... зачем так сложно? авторы хотят научится всем этим пользоватся или получить работающий оффлайн клиент?(да и энтузиазм может закончиться раньше, ведь юниксоидам этот клиент нужен в основном для чтения флейма и анекдотов) Наваяйте выгребалку даных с вебсервиса на джаве, если нужно — сделайте на с++ демона который будет ее запускать (а можно и по скедулеру это делать ) и синхронизировать базу. ну а гуи клиент может быть уже на чем угодно
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Mamut, Вы писали:
M>>А главный минус — то, что виртуальный грид надо будет писать полностью с нуля, на основе QTable или, боже упаси, QGridView S>Что есть виртгрид?
, а также обсуждение в Qt Interest. Для Януса вон тоже отдельный грид написан.
S>Если это messagetree то оно нам впринципе ненужно.
Как это не нужен?
S>Можно реализовать один из интерфейсов, описаных гдетотут... К томуже это дело интерфейса как все отображать... S>Скажем — к демону будет 4 основных запроса относящихся к форуму. S>1. Дай список форумов S>2. Дай список самых верхних веток форума S>3. Дай дерево начиная с такойто ветки S>4. Дай тело сообщения S>Дело демона дать что просят. S>Дело вьювера какнибудь показать.
Вот в том-то и дело — как что показывать Ох, замучаемси
M>>А и еще — надо будет решить, использовать Сцинтиллу или обойтись QTextView с собственными QStyleSheet'ами... S>Скорее второе. Цинтила чета мне ненравица... Хотя будем посмотреть.
S>>Если это messagetree то оно нам впринципе ненужно.
M>Как это не нужен?
Яж говорил: S>>Можно реализовать один из интерфейсов, описаных гдетотут... К томуже это дело интерфейса как все отображать...
Скажем чтото типа этого: Re[3]: Мысли по поводу дерева
S>>>Если это messagetree то оно нам впринципе ненужно. M>>Как это не нужен? S>Яж говорил: S>>>Можно реализовать один из интерфейсов, описаных гдетотут... К томуже это дело интерфейса как все отображать... S>Скажем чтото типа этого: Re[3]: Мысли по поводу дерева
Ну так дык, я ж об том и говорю О том, что это все дело надо будет ручками выкраивать из QTable или QGridView, потому что даже близко подходящих к такому решений нет, а QListView загибается на большом количестве элементов.
Но это я впереди паровоза бегу. Нам-то еще определиться, что делать-то хотим
M>>Насчет демонов и сервисов... В Qt Solutions есть решение для создания *никсовских демонов и виндовых сервисов. Единственное но — Solutions — это платная вещь, хоть и можно ее достать бесплатно
C>неужели демон такая сложная штука что для него нужно искать крякнутый "Qt Solutions"
Шеридан хочет кроссплатформенное решение.
M>>Насчет Qt вообще... Можно, теоретически, начинать все это дело писать уже на Qt4, благо и под винду он будет GPL.
C>C++, Qt, QTable, QTextView..... зачем так сложно? авторы хотят научится всем этим пользоватся или получить работающий оффлайн клиент?(да и энтузиазм может закончиться раньше, ведь юниксоидам этот клиент нужен в основном для чтения флейма и анекдотов) Наваяйте выгребалку даных с вебсервиса на джаве, если нужно — сделайте на с++ демона который будет ее запускать (а можно и по скедулеру это делать ) и синхронизировать базу. ну а гуи клиент может быть уже на чем угодно
Ну вот пока и идет речь об отдельном демоне (кроссплатформенном) и отдельном гуи-клиенте (тоже кроссплатформенном). В общем, опять хочется странного Ну а раз кроссплатформенное, то Qt — это то, что надо, имхо и ишхо (ин шеридан'с хамбл опинион )
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Mr.Chipset, Вы писали:
MC>>Привет всем! MC>>После разговора с Sheridan'ом прояснились некоторые детали по сабжу. MC>>В частности, есть идея разделить RSDN@Linux на две части: MC>>1. Драйвер -- синх+драйвер к БД, скажем в виде демона. MC>>2. Представление -- в данном случае это некий клиент который используеться драйвер для доступа к БД и синхронизации. К примеру это может быть веб-интерфейс на Джаве, десктопная программа просмотра, наподобие Janus'a или вообще плагин к FF S>Клиент не пользует синхронизацию, он может лиш попросить демона засинхронизироватся. Демон же читает /etc/janus.conf и оттуда узнает все что ему надо в том числе и когда и сколько синхронизировать... И решает выполнить ли просьбу клиента сейчас или ненада...
Именно.
MC>>Так что сейчас требуеться лишь начать. Начать предлагаю с рефакторинга сервиса синхронизации Януса на С++ и к-платформенную библиотеку SOAP'a, наподобие gSOAP. S>имхо нужно пользовать qt (гуру, разрешат нам ее пользовать кутешники в данном контексте) и попробовать писать кроссплатформенно. Тобиш линуховый демон для винды переделывать в сервис для NT или просто экзешник для 9x... Гуя само собой...
Хм. Для демона тащить Qt? :\ S>Тоесть изначально хотелось бы почитать про объектную модель, и переписать ее на с++, затем братся собственно за демона (вплотную) и гую (по мере сил). По мере сил это потому что всетаки гуя в этом случае действительно может быть любая, от мода к апачу до standalone exe. Главное продумать как гуя будет с демоном работать.
Про какую обьектную модель ты говоришь? MC>>Всё в интересе со стороны C++'ников Linux'оидов. MC>>СУВ.
Здравствуйте, Mr.Chipset, Вы писали:
MC>Хм. Для демона тащить Qt? :\
Неее... Для гуя qt. Но я тут подумал... Мож попробовать в качестве гуя нарисовать мод к пхп... 3х зайцев прибить можна — и гуй настраиваемый как хотиш. И нарисовать лехко. И можно один синхродемон на контору пользовать...
MC>Про какую обьектную модель ты говоришь?
Дык как все в янусе то устроено? чтототам objectmodel тратата features тампарам
MC>>Хм. Для демона тащить Qt? :\ S>Неее... Для гуя qt. Но я тут подумал... Мож попробовать в качестве гуя нарисовать мод к пхп... 3х зайцев прибить можна — и гуй настраиваемый как хотиш. И нарисовать лехко. И можно один синхродемон на контору пользовать...
Надо посмотреть в сторону 4-го Qt, который мало того, что, вроде GPL под винду, так и было обещано большее разделение гуи и негуи частей. Благо, под KDE Qt есть сразу.
А насчет демона я думаю со вчерашнего вечера Мое воспаленное воображение нарисовало мне вот такое вот:
Сразу возникают вопросы. Что должны хранить клиенты в локальных базах? Как клиенты будут общаться с демоном? Как минимум, хочется производительность не хуже, чем у Януса (по построению веток, по отображению сообщений). Да еще и кроссплатформенное Ох, Шеридан, оно тебе надо?
В общем, считаю так:
— клиент должен хранить список форумов, на которые он подписан, outgoing сообщения и, наверное, статистику? Типа read-unread? Или только одно из них (остальное — по умолчанию)
— демон должен качать все и отдавать клиенту запрошенные деревья и сообщения.
Остается вопрос о том — как передавать данные клиенту. ХМЛ не предлагать Может, какой-нить EBML?
M>Сразу возникают вопросы. Что должны хранить клиенты в локальных базах? Как клиенты будут общаться с демоном? Как минимум, хочется производительность не хуже, чем у Януса (по построению веток, по отображению сообщений). Да еще и кроссплатформенное Ох, Шеридан, оно тебе надо?
Эх.. вашу бы энергию да на мирные цели Если на С++ чего нить писать охота, по вон переведите лучче сцайнтиллу на уникодные рельсы.
Здравствуйте, Mamut, Вы писали:
M>Надо посмотреть в сторону 4-го Qt, который мало того, что, вроде GPL под винду, так и было обещано большее разделение гуи и негуи частей. Благо, под KDE Qt есть сразу.
Угу... Эт хорошо...
M>А насчет демона я думаю со вчерашнего вечера Мое воспаленное воображение нарисовало мне вот такое вот:
А что. Вполне нарисовало Просто и понятно.
M>Сразу возникают вопросы. Что должны хранить клиенты в локальных базах?
Какие локальные базы? cfg файлы — больше ненада. Поясню физику.
Клиент хранит в cfg свои настройки (ну типа как янус сейчас).
Самже демон хранит записи пользователей(read / unread, подписано / неподписано). Я пока думаю как, но сайт то хранит записи какие сообщения я читал на сайте... Вроде...
Демон ясное дело еще хранит учетные записи пользователей, работающих с демоном. Ктото отряжается админом демона — он рулит конфигом (или просто сделать /etc/janus.conf хранить там конфиг демона и немучатся). Локальная бд вьювера некатит. Я например хочу web-based вьювер. Какая может быть бд?
M>Как клиенты будут общаться с демоном?
IP:port
M>Как минимум, хочется производительность не хуже, чем у Януса (по построению веток, по отображению сообщений). Да еще и кроссплатформенное Ох, Шеридан, оно тебе надо?
Надо, дядя, надо... Производительность зависит в основном от работы с бд и логики демона. Вьювер можно сделать хоть консольным. Его дело будет попросить демон тото и тото и нарисовать ответ на экране. Грубо говоря.
M>Остается вопрос о том — как передавать данные клиенту. ХМЛ не предлагать Может, какой-нить EBML?
иксмл ёбмл... Неужели все забыли про socketstream? Мусора нет. Парсинг ненужен. Производительность++.
HD>Эх.. вашу бы энергию да на мирные цели Если на С++ чего нить писать охота, по вон переведите лучче сцайнтиллу на уникодные рельсы.
Этим вроде Влад занимается. Насколько я понял из его различных сообщений он ее вообще переписал как managed что сразу же подразумевает уникод. Ждем премьеры
Здравствуйте, Andre, Вы писали:
A>Этим вроде Влад занимается. Насколько я понял из его различных сообщений он ее вообще переписал как managed что сразу же подразумевает уникод. Ждем премьеры
Ну насколько я понял, то что влад написал (или пишет еще) это что вроде примитивного визивигного html редактора/вьювера. Ну и что то меня сомнения берут, что AWK даст добро на использование его в янусе, по крайней мере в обозримом будущем.
HD>Ну насколько я понял, то что влад написал (или пишет еще) это что вроде примитивного визивигного html редактора/вьювера. Поживем увидим
HD>Ну и что то меня сомнения берут, что AWK даст добро на использование его в янусе, по крайней мере в обозримом будущем.
В качестве толкового редактора почему бы и нет. В текущей сцинтилке багов полно, и зачастую их исправления выливаются в уже ограничения managed кода, как, например, с уникодом.
АВК был против заменить им и вьювер и тут я с ним согласен на 100%.
M>>Сразу возникают вопросы. Что должны хранить клиенты в локальных базах? S>Какие локальные базы? cfg файлы — больше ненада. Поясню физику. S>Клиент хранит в cfg свои настройки (ну типа как янус сейчас). S>Самже демон хранит записи пользователей(read / unread, подписано / неподписано). Я пока думаю как, но сайт то хранит записи какие сообщения я читал на сайте... Вроде...
Не, это браузер запоминает, по каким ссылкам ты щелкнул В "Обсуждении сайта" было когда-то обсуждение о том, что неплхо было бы запоминать движения юзера по сайту, но, по-моему, идея была непринята
S>Демон ясное дело еще хранит учетные записи пользователей, работающих с демоном. Ктото отряжается админом демона — он рулит конфигом (или просто сделать /etc/janus.conf хранить там конфиг демона и немучатся). Локальная бд вьювера некатит. Я например хочу web-based вьювер. Какая может быть бд?
А, верно. Что-то я торможу
M>>Остается вопрос о том — как передавать данные клиенту. ХМЛ не предлагать Может, какой-нить EBML? S>иксмл ёбмл... Неужели все забыли про socketstream? Мусора нет. Парсинг ненужен. Производительность++.
Ну, этот самый стрим все равно парсить надо Ибо информация из него будет приходить очень разная — от списка деревьев до списка форумов до содержимого самого сообщения. То есть все равно остается вопрос о формате передаваемых данных. Предлагаешь просто сериализовать данные/объекты в поток?
"Всё что не убивает нас, делает нас сильнее..."
Может, какой-нить EBML? 
