M>>Ладно. Типа определились. Пусть будет ХМЛ (еще бы мнение Шеридана услышать).
A>Если мы говорим об обмене демона и клиента, то зачем тут XML? кто-нибудь может объяснить?
Просто клиент не обязательно будет на С++. Вернее, наш клиент-то будет Но вдруг кому-то захочется написать клиента на Яве?
Здравствуйте, Mr.Chipset, Вы писали:
MC>Привет всем! MC>После разговора с Sheridan'ом прояснились некоторые детали по сабжу. MC>В частности, есть идея разделить RSDN@Linux на две части: MC>1. Драйвер -- синх+драйвер к БД, скажем в виде демона.
Зачем демон? И без него можно обойтись. Сделать синхронизатор частью приложения вместо демона. Да, каждый пользователь будет иметь свою копию форумов. Ну и что? Диски сейчас большие пошли. Места хватит на всех.
Зато какая простота! Не нужно думать о том, как этот демон будет функционировать, взаимодействовать с клиентами и БД.
Да, кстати, зачем полноценная БД? Berkley DB вполне подойдет. Встраиваемая, памяти мало отнимает, работает быстро. Не нужно устанавливать и настраивать отдельную базу данных.
MC>2. Представление -- в данном случае это некий клиент который используеться драйвер для доступа к БД и синхронизации. К примеру это может быть веб-интерфейс на Джаве, десктопная программа просмотра, наподобие Janus'a или вообще плагин к FF MC>Так что сейчас требуеться лишь начать. Начать предлагаю с рефакторинга сервиса синхронизации Януса на С++ и к-платформенную библиотеку SOAP'a, наподобие gSOAP.
Про gSoap согласен. Но есть еще и Apache Axis.
Насчет GUI. Gtk imho лучше, чем QT. Gtk полностью под LGPL, работает как на Linux, так и на Windows. C++ bindings для Gtk тоже есть.
MC>Всё в интересе со стороны C++'ников Linux'оидов.
Широко и далеко замахнулись для первой версии. Проект может не взлететь. Сначала нужно сделать упрощенный вариант, где всё в одной программе. Никаких демонов и баз данных. Про кроссплатформенность тоже нужно забыть для начала. Если это получится, то потом всяких разных фенечек поприкручивать всегда можно будет.
Здравствуйте, alexeiz, Вы писали:
A>Здравствуйте, Mr.Chipset, Вы писали:
MC>>Привет всем! MC>>После разговора с Sheridan'ом прояснились некоторые детали по сабжу. MC>>В частности, есть идея разделить RSDN@Linux на две части: MC>>1. Драйвер -- синх+драйвер к БД, скажем в виде демона.
A>Зачем демон? И без него можно обойтись. Сделать синхронизатор частью приложения вместо демона. Да, каждый пользователь будет иметь свою копию форумов. Ну и что? Диски сейчас большие пошли. Места хватит на всех.
Ну, тогда это будет клон Януса, а хочеся "свой, новый мир построить"
A>Зато какая простота! Не нужно думать о том, как этот демон будет функционировать, взаимодействовать с клиентами и БД.
A>Да, кстати, зачем полноценная БД? Berkley DB вполне подойдет. Встраиваемая, памяти мало отнимает, работает быстро. Не нужно устанавливать и настраивать отдельную базу данных.
MC>>2. Представление -- в данном случае это некий клиент который используеться драйвер для доступа к БД и синхронизации. К примеру это может быть веб-интерфейс на Джаве, десктопная программа просмотра, наподобие Janus'a или вообще плагин к FF MC>>Так что сейчас требуеться лишь начать. Начать предлагаю с рефакторинга сервиса синхронизации Януса на С++ и к-платформенную библиотеку SOAP'a, наподобие gSOAP.
A>Про gSoap согласен. Но есть еще и Apache Axis.
О! Надо посмотреть
A>Насчет GUI. Gtk imho лучше, чем QT. Gtk полностью под LGPL, работает как на Linux, так и на Windows. C++ bindings для Gtk тоже есть.
Помню, когда-то Gtk под винды был настолько убого-выглядещим...
MC>>Всё в интересе со стороны C++'ников Linux'оидов.
A>Широко и далеко замахнулись для первой версии. Проект может не взлететь. Сначала нужно сделать упрощенный вариант, где всё в одной программе. Никаких демонов и баз данных. Про кроссплатформенность тоже нужно забыть для начала. Если это получится, то потом всяких разных фенечек поприкручивать всегда можно будет.
В том-то и дело, что добавление новых фич не всегда легкий процесс. Тем более учитывая, что хочется имено разделить синхронизатор и клиент.
На самом деле, если идти по примерно следующему плану, то проблем с распылением сил не должно быть
- Демон и только демон
-- синхронизация с РСДН, получение/отправка данных
-- структура базы данных и работа с ней
-- разработка и фиксация АПИ для работы с демоном из других приложений
-- набор тестов (консольных, например), тестирующих предыдущие три пункта
Только после стабилизации работы демона и устаканивания принципов работы с ним:
- Клиент
-- ???
Одна из причин, почему я лично поддерживаю такое разделение — тот факт, что в Янусе очень сильно зависишь от того, работает ли сейчас приложение с базой данных или нет. Хочется максимально облегчить представление данных, полностью отделив их от непосредственной обработки. Вот.
А кроссплатфоремнность придется поддерживать сразу Потому что часть будет сидеть на Линуксах, а часть — на Виндах Ну, заодно и опыт разработки кросс-платформенных приложений получим.
Здравствуйте, Mamut, Вы писали:
M>>>Ладно. Типа определились. Пусть будет ХМЛ (еще бы мнение Шеридана услышать).
A>>Если мы говорим об обмене демона и клиента, то зачем тут XML? кто-нибудь может объяснить?
M>Просто клиент не обязательно будет на С++. Вернее, наш клиент-то будет Но вдруг кому-то захочется написать клиента на Яве?
Неужели Ява не умеет работать с бинарным потоком???
Здравствуйте, alexeiz, Вы писали:
A>Здравствуйте, Mr.Chipset, Вы писали:
MC>>Привет всем! MC>>После разговора с Sheridan'ом прояснились некоторые детали по сабжу. MC>>В частности, есть идея разделить RSDN@Linux на две части: MC>>1. Драйвер -- синх+драйвер к БД, скажем в виде демона.
A>Зачем демон? И без него можно обойтись. Сделать синхронизатор частью приложения вместо демона. Да, каждый пользователь будет иметь свою копию форумов. Ну и что? Диски сейчас большие пошли. Места хватит на всех.
A>Зато какая простота! Не нужно думать о том, как этот демон будет функционировать, взаимодействовать с клиентами и БД.
A>Да, кстати, зачем полноценная БД? Berkley DB вполне подойдет. Встраиваемая, памяти мало отнимает, работает быстро. Не нужно устанавливать и настраивать отдельную базу данных.
Приложение довольно большой кусок, демон маленький кусок. Так больше логика итеративного программирования.
MC>>2. Представление -- в данном случае это некий клиент который используеться драйвер для доступа к БД и синхронизации. К примеру это может быть веб-интерфейс на Джаве, десктопная программа просмотра, наподобие Janus'a или вообще плагин к FF MC>>Так что сейчас требуеться лишь начать. Начать предлагаю с рефакторинга сервиса синхронизации Януса на С++ и к-платформенную библиотеку SOAP'a, наподобие gSOAP.
A>Про gSoap согласен. Но есть еще и Apache Axis.
ПаСиПиПа! A>Насчет GUI. Gtk imho лучше, чем QT. Gtk полностью под LGPL, работает как на Linux, так и на Windows. C++ bindings для Gtk тоже есть.
Чессна гря мне не хочеться его юзать. MC>>Всё в интересе со стороны C++'ников Linux'оидов.
A>Широко и далеко замахнулись для первой версии. Проект может не взлететь. Сначала нужно сделать упрощенный вариант, где всё в одной программе. Никаких демонов и баз данных. Про кроссплатформенность тоже нужно забыть для начала. Если это получится, то потом всяких разных фенечек поприкручивать всегда можно будет.
Да нормально, демон синхронизирующий для первой версии, немного ж ведь?
... << А писал я этот бред на RSDN@Home 1.1.4 beta 7 rev. 447, под звуки тишины>>
Здравствуйте, Mamut, Вы писали:
M>Минусы. M>- Версии <4 версия очень даже платны для винды. Лекарство, безусловно, существует, поэтому это как бы не проблема (хоть и некрасиво). Версия 4 — GPL под все системы, но она пока бета, а под винду выйдет только с релизом.
Лекарств применять небудем... Скорее всего придется ждать релиза или писать на чемнибудь еще.
M>- Версии <4 сильно завязаны на ГУИ, придется таскать совсем немаленькую библиотеку. Это порядка 5-и мегабайтов, если .dll и не менее мегабайта, если .lib. В случае с .lib нельзя будет использовать систему плагинов, предлагаемую Qt, что делает невозможным использование custom SQL drivers.
Гм а дотнет фреймворк весит сколько? Насколько я помню — больше...
M> Можно посмотреть в сторону TinyQ, которая предлагает покоцанный вариант Qt, но это надо щупать пациента за вымя.
Надо будет позебать...
M>В качестве базы данных — пока неизвестно (скорее всего, firebird, как я понимаю).
Однозначно firebird хотя с другой стороны планируется абстрагироватся от конкретного типа БД.
M>В отношении базы данных ее структуру еще надо будет обдумать, потому что, если будет проектироваться именно демон с поддержкой нескольких пользователей, то в структуру надо будет вносить изменения.
Именно демон + вьюверы.
M>Вроде, так. Надо, чтобы Шеридан, как неофициальный руководитель RSDN@Linux сказал свое веское слово
Дык...
Здравствуйте, avbochagov, Вы писали:
A>Здравствуйте, Mamut, Вы писали:
M>>Шеридан предложил, а я поддеожал идею использовать в этом деле Qt. A>Согласен на 100%. A>Компилятор какой? то что GCC понятно, но от какой версии плясать? A>Например в Fedore 4 стоит уже GCC 4.0.0.8...
В последнем. Причем желательно следить за обновлениями имхо.
A>В какой среде? (KDevelop или из ком.строки)
Кто в чем. Из винды в студии из линуха скорее всего в kdevelop или еще в чемнибудь поддерживающем проекты.
A>меня почему-то больше тянет в сторону SQL-Lite
Насколько оно соответствует хотябы SQL92?
A>Может пока просто для одного пользователя сделать. Освои реструктуризатор, gSOAP, сеть, БД. A>По моему и так уже не плохо для начала. Вроде крутых линуксоидов пока не видно
Народ, изначально надо делать демон с вьювером.
A>Может он страничку заведет на эту тему. Похоже у проекта есть будущее...
Пообщатся и здесь можно...
Здравствуйте, Sheridan, Вы писали:
S>В чем сложность? В разрулении типа данных по первому байту пакета? В чтении из потока? Или Настоящие Программисты must be use xml ибо звучит красиво?
Текстовый протокол отлаживать проще. Например, можно так сделать:
Можно, например, вместо команды "janux-demon" вьюверу подсунуть команду "validate-xml janux-in.xsd | janux-demon | validate-xml janux-out.xml", которая будет проверять все входящие и выходящие данные схемой.
Ну и прочие извращенные радости
Также текстовый протокол парсить проще. В Java, например, можно Digester запользовать — вот тебе и скорость SAX, и удобство DOM. Само все в объекты поднимется. Для LISP-а (вдруг кому плагин к GNUS-у захочется , с фенечками RSDN-а типа оценок) — тоже XML скорее всего проще будет разобрать.
Если вся проблема в боязни того, что будет медленно — сделайте тест.
[skip]
WF>Если вся проблема в боязни того, что будет медленно — сделайте тест.
QDom в Qt очень медленный. Как-никак, на каждый элемент создается по QDomElement, да еще с постоянными кастами из QDomNode в QDomElement и обратно Не знаю, может в 4-ой там чуть изменилось это дело. Правда, я ихнюю имплементацию SAX руками не трогал (QXmlSimpleReader).
Главный аргумент за использование XML — это то, что его можно считать и обработать практически чем угодно, будь то С++, Ява или РНР.
Минус — оверхед там может быть просто диким (правда, его можно сжимать).
При использовании чего-нить двоичного придется все равно это самое двоичное парсить.
Здравствуйте, Mamut, Вы писали:
БСС>>...Вообщем — "как вы лодку назовёте так она и поплывёт". Есть тут знатоки мифологии (любой, хоть финской, хоть японской), что-бы придумать название?
M>Насчет мифологии сюда.
M>Как вариант можно вот: M>[q] M>Daimon
Ну тогда логично в стиле Unix-way: RSDNd
И как вариант добавять GUI + DB Backend + OS, типа
RSDNd v0.1 GTK/Firebird on Linux 2.4.27-2-686-smp #1 SMP i686 GNU/Linux
[flame]
Ну и для особых любителей померяцца :
RSDNd v0.1 Emacs/MBox on FreeBSD 4.0 uptime 5 years 10 days 10 minutes 1 second
Здравствуйте, Mamut, Вы писали:
M>QDom в Qt очень медленный. Как-никак, на каждый элемент создается по QDomElement, да еще с постоянными кастами из QDomNode в QDomElement и обратно Не знаю, может в 4-ой там чуть изменилось это дело. Правда, я ихнюю имплементацию SAX руками не трогал (QXmlSimpleReader).
ИМХО, работать руками что через DOM, что через SAX — слишком низкоуровневое занятие. Я бы в такой ситуации поискал маппинг XML->объекты Вот, например, boost::serialization вроде умеет XML поднимать/сохранять. Не знаю, правда, его фич и насколько он гибок.
Но вдруг кому-то захочется написать клиента на Яве?
Ну, заодно и опыт разработки кросс-платформенных приложений получим.
"Всё что не убивает нас, делает нас сильнее..."
Не знаю, может в 4-ой там чуть изменилось это дело. Правда, я ихнюю имплементацию SAX руками не трогал (QXmlSimpleReader).
