Привет всем!
После разговора с 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? Мусора нет. Парсинг ненужен. Производительность++.
Ну, этот самый стрим все равно парсить надо Ибо информация из него будет приходить очень разная — от списка деревьев до списка форумов до содержимого самого сообщения. То есть все равно остается вопрос о формате передаваемых данных. Предлагаешь просто сериализовать данные/объекты в поток?
Здравствуйте, Mamut, Вы писали:
M>Не, это браузер запоминает, по каким ссылкам ты щелкнул В "Обсуждении сайта" было когда-то обсуждение о том, что неплхо было бы запоминать движения юзера по сайту, но, по-моему, идея была непринята
Чтож тогда либо каждому юзеру табличку либо одну табличку на всех...
M>Ну, этот самый стрим все равно парсить надо Ибо информация из него будет приходить очень разная — от списка деревьев до списка форумов до содержимого самого сообщения. То есть все равно остается вопрос о формате передаваемых данных. Предлагаешь просто сериализовать данные/объекты в поток?
гм... Че его парсить? К примеру возьмем какойть абстрактный стрим...
UDataType Type = dtMessage;
SMessage Msg;
...
// заполняем
...
CStream *Stream = new Cstream();
Stream->Write(Type,sizeof(UDataType));
Msg->WriteToStream(Stream);
Ну и так далее, заполняем структуру SData, отсылаем сокетом... надеюсь ясно. При чтении наоборот. С тем что читаем сначала тип и по свичу типизируем, читаем, и все...
Что только взять в качестве "_данные_" и что взять в качестве стрима....
Здравствуйте, HotDog, Вы писали:
HD>Эх.. вашу бы энергию да на мирные цели Если на С++ чего нить писать охота, по вон переведите лучче сцайнтиллу на уникодные рельсы.
Жизненноважно!
К томуже я перехожу в линух дома. Пару месяцев винду уже даже и не вгружал ниразу... К томуже траффик жалко... Что меньше траффика сделает — 1 синхродемон на серваке + его клиенты или когда каждый синхронится самостоятельно?
К томуже я наблюдал ситуации когда доступ вовне порезан с локальных машин хотя (гдетотам) сервак в интернет смоттрич и вполне могут поставить этого синхродемона на ем. ПФР, налоговая...
[потоптано ] S>Ну и так далее, заполняем структуру SData, отсылаем сокетом... надеюсь ясно. При чтении наоборот. С тем что читаем сначала тип и по свичу типизируем, читаем, и все...
Как мне выделенное не нравится... Как только понадобится возможность это дело расширить, как Что-то подумалось. Может, надо ... эээ ... абстрагироваться от понятий "список форумов", "список сообщений", а оставить просто "иерархический список (jagged aray?)"(список топиков в форуме, например), "плоский список"(например, список форумов) и "текстовая информация" (например, инфа про пользователя, тело сообщения)? Таким образом можно отсылать клиенту просто что-нибкдь типа
// типа псевдо-код
HierList/*topicList*/{
id = 1; // по этому ИД клиент может понять, что это - список топиков в форуме
// или можно даже ID = "forum_list"
data...
}
HierList/*favouritesList*/{
id = 2; // или можно даже ID = "fav_list"
data...
}
PlainList/*availableTopics*/{
id = 3;
data...
}
Ну и так далее. Ых?
S>Что только взять в качестве "_данные_" и что взять в качестве стрима....
Здравствуйте, Mamut, Вы писали:
M>Ну и так далее. Ых?
А я про что? Я практически тоже самое и предложил.
Подумалось вот... Что кому пересылать...
Демон -> клиент.
1. Сообшение. (только текст)
2. Заголовок сообщения. (Caption, дата, оценки...)
3. Пользователь.
4. Форум.
5. Списки id для форумов, верхних веток форума или непосредсвенных дочерей какойто ветки.
клиент -> Демон.
1. Новое сообщение.
2. Оценка.
3. Того что возвращает демон
Это наверное еще не все нада думать....
Приблизительный обмен... Интерфейс скажем типа сейчашнего (-> клиент, <- демон)
-> Вотон я мой uid такойто
<- Лови список id форумов
-> Дай инфу о форуме [id]
<- Лови инфу о форуме [id]
...
-> Дай инфу о форуме [id]
<- Лови инфу о форуме [id]
[построили список форумов]
[выделяется верхний форум]
-> Дай список id верхних веток форума
<- Лови список id верхних веток форума
-> Дай инфу о ветке [id]
<- Лови инфу о ветке [id]
...
-> Дай инфу о ветке [id]
<- Лови инфу о ветке [id]
[нарисовали верхние ветки]
[аналогично при разворачивании ветки]
[хотим почитать]
-> Дай текст сообщения ветки [id]
<- Лови текст сообщения ветки [id]
Думаю все понятно... Не надо ничего усложнять передавая списки целиком сразу... Я просто могу сделать страничнвй вывод топиков и мне не нужны будут сразу все данные, а вот просто список id будет к месту — кол-во страниц вычислю
Здравствуйте, Mr.Chipset, Вы писали:
MC>Привет всем! MC>После разговора с Sheridan'ом прояснились некоторые детали по сабжу. MC>В частности, есть идея разделить RSDN@Linux на две части: MC>1. Драйвер -- синх+драйвер к БД, скажем в виде демона. MC>2. Представление -- в данном случае это некий клиент который используеться драйвер для доступа к БД и синхронизации. К примеру это может быть веб-интерфейс на Джаве, десктопная программа просмотра, наподобие Janus'a или вообще плагин к FF MC>Так что сейчас требуеться лишь начать. Начать предлагаю с рефакторинга сервиса синхронизации Януса на С++ и к-платформенную библиотеку SOAP'a, наподобие gSOAP. MC>Всё в интересе со стороны C++'ников Linux'оидов. MC>СУВ.
посмотрите в сторону Mono + Gtk#. Тем более, что писать и отлаживать можно и под виндой, в студии (об этом — здесь). В Моно 1.1.7 уже все довольно серьезно. Там даже Windows.Forms уже неплохо развиты. Честно говоря, не знаю, как там обстоят дела с веб-программированием, но GUI уже делать можно. Правда, Mono любит Gnome...
P.S.Через некоторое время выложу в форум небольшой триллер, о том как на Gtk# портировался VirtualGrid из соседней ветки форума. Получилось кроссплатформенное решение — один и тот же код на шарпе работает и в виндовс и в линуксе.
M>>Ну и так далее. Ых? S>А я про что? Я практически тоже самое и предложил.
Меня просто switch напугал
S>Подумалось вот... Что кому пересылать...
[skip] S>Думаю все понятно... Не надо ничего усложнять передавая списки целиком сразу... Я просто могу сделать страничнвй вывод топиков и мне не нужны будут сразу все данные, а вот просто список id будет к месту — кол-во страниц вычислю
Что-то подумалось — а не много ли слишком данных туда-сюда по сетке? Особенно если есть таки список топиков и какую-нибудь ветку решили развернуть. Правда, это обходится просто разделением вызовов типа "getTopicList" и "getTopic"...
*охохонюшки — куда это я ввязываюсь. я ж и программист-то весьма посредственный...*
AK>посмотрите в сторону Mono + Gtk#. Тем более, что писать и отлаживать можно и под виндой, в студии (об этом — здесь). В Моно 1.1.7 уже все довольно серьезно. Там даже Windows.Forms уже неплохо развиты. Честно говоря, не знаю, как там обстоят дела с веб-программированием, но GUI уже делать можно. Правда, Mono любит Gnome...
Хм... Интересно было бы посмортерть, насколько можно Янус портировать на Моно. А мы (вернее, Шеридан, я просто работаю провокатором ), хотим "пойти другим путем" и "свой, новый мир построить" Просто на .NET уже проект есть — Янус. Интересно было бы попробовать сделать похожее (такое же, превосходящее — нужное подчеркнуть) с другим инструментарием.
За одно будем популяризировать Qt в массах
AK>P.S.Через некоторое время выложу в форум небольшой триллер, о том как на Gtk# портировался VirtualGrid из соседней ветки форума. Получилось кроссплатформенное решение — один и тот же код на шарпе работает и в виндовс и в линуксе.
А вот это было бы очень интересно посмотреть. Ждем
Здравствуйте, Sheridan, Вы писали:
S>Что меньше траффика сделает — 1 синхродемон на серваке + его клиенты или когда каждый синхронится самостоятельно? S>К томуже я наблюдал ситуации когда доступ вовне порезан с локальных машин хотя (гдетотам) сервак в интернет смоттрич и вполне могут поставить этого синхродемона на ем. ПФР, налоговая...
Да я не спорю, что подобные юзкейсы возможны. Просто, на мой взгляд, тут огромнейший фронт работ, начиная от сервера (демона) до клиента, которые надо начинать с нуля. А на сях, да еще под линухом это просто
Может для начала ограничится демоном который для клиента является нюьс сервером? По крайней мере тогда над клиентом не надо будет голову ломать, а взять что то готовое (я имею ввиду ньюс ридер)
При этом потеряются такие фичи как оценки, данные о юзерах, но в принципе это тоже можно обьехать, запихав, к примеру, пользователя в отдельную ньюс группу и "прилинковать" его как сообщение.
Кстати тут на рсдн я уже видел даже что то подобное для виндов (NNTP клиент или что то вроде этого), т.е опять таки уже не с нуля ковырять.
А на счет линуха ... у меня ситуация наоборот: основное время сижу в виндах (по работе), пацан всякие там Halo, Unreal играет, жена фильмы смотрит (пока я не успел на DVD скинуть, чтоб на телике посмотреть), т.е без форточек никуда. Ну а побаловаться запускаю Дебиана или Suse, но это так.. для души.
M>Хм... Интересно было бы посмортерть, насколько можно Янус портировать на Моно. А мы (вернее, Шеридан, я просто работаю провокатором ), хотим "пойти другим путем" и "свой, новый мир построить" Просто на .NET уже проект есть — Янус. Интересно было бы попробовать сделать похожее (такое же, превосходящее — нужное подчеркнуть) с другим инструментарием.
Понимаю. Что касается меня, то у меня есть намерение показать, что на C# можно программировать для разных платформ.
M>За одно будем популяризировать Qt в массах
Тогда мне остается проповедовать Gtk#
Кстати, на шарпе есть обвязка и для Qt — qtcsharp, но, насколько я вижу, этот проект не обновлялся уже около года.
Здравствуйте, Mr.Chipset, Вы писали:
MC>Привет всем! MC>После разговора с Sheridan'ом прояснились некоторые детали по сабжу.
А если попробовать проект mono? тогда не надо будет создавать новую сущность, а, возможно, хватит небольших переделок существующего клиента?
Здравствуйте, ironwit, Вы писали:
I>Здравствуйте, Mr.Chipset, Вы писали:
MC>>Привет всем! MC>>После разговора с Sheridan'ом прояснились некоторые детали по сабжу. I>А если попробовать проект mono? тогда не надо будет создавать новую сущность, а, возможно, хватит небольших переделок существующего клиента? Re: RSDN@Linux 2
M>>Хм... Интересно было бы посмортерть, насколько можно Янус портировать на Моно. А мы (вернее, Шеридан, я просто работаю провокатором ), хотим "пойти другим путем" и "свой, новый мир построить" Просто на .NET уже проект есть — Янус. Интересно было бы попробовать сделать похожее (такое же, превосходящее — нужное подчеркнуть) с другим инструментарием. AK>Понимаю. Что касается меня, то у меня есть намерение показать, что на C# можно программировать для разных платформ.
Ваше дело — предложить, наше — пощупать пациента за вымя Кто знает, вдруг нас удастся совратить С#'ом или даже портировать Янус под Моно — было бы здорово.
M>>За одно будем популяризировать Qt в массах AK>Тогда мне остается проповедовать Gtk#
AK>Кстати, на шарпе есть обвязка и для Qt — qtcsharp, но, насколько я вижу, этот проект не обновлялся уже около года.
Увы Я так надеялся, что дело у них сдвинется с мертвой точки, но увы
Здравствуйте, ironwit, Вы писали:
I>Здравствуйте, Mr.Chipset, Вы писали:
MC>>Привет всем! MC>>После разговора с Sheridan'ом прояснились некоторые детали по сабжу. I>А если попробовать проект mono? тогда не надо будет создавать новую сущность, а, возможно, хватит небольших переделок существующего клиента?
Честно скажу: шарп недолюбливаю изза того что оно всетаки интерпритатор... Мне например будет интересно сравнить шарп и с++ в деле...
Здравствуйте, Mamut, Вы писали:
M>Что-то подумалось — а не много ли слишком данных туда-сюда по сетке? Особенно если есть таки список топиков и какую-нибудь ветку решили развернуть. Правда, это обходится просто разделением вызовов типа "getTopicList" и "getTopic"...
С одной стороны конечно тудасюда столько гонять не совсем хорошо есть, с другой стороны мы развязываем руки при написании клиента. Можно конечно и запрос списков подвязать и запрос веток... Но имхо всетаки вот такой начальный протокол следует принять как "атом". Из него уже можно строить "молекулы" запросов к демону. Скажем — дай мне мол вот эту ветку — а демон возвращает соответствующий набор атомов, может быть уже упорядоченный.
M>*охохонюшки — куда это я ввязываюсь. я ж и программист-то весьма посредственный...*
А что ты думаеш — я крут?
Здравствуйте, HotDog, Вы писали:
HD>Да я не спорю, что подобные юзкейсы возможны. Просто, на мой взгляд, тут огромнейший фронт работ, начиная от сервера (демона) до клиента, которые надо начинать с нуля. А на сях, да еще под линухом это просто
Согласен. Работы много. Один я непотяну даже пятую часть. Но и янус тоже не с неба свалился.
HD> т.е опять таки уже не с нуля ковырять.
С нуля надо начинать. И первым делом конверт бд и рисовать просмотрщика. Потом можно братся за синхронизатора и следом за постинг сообщений и оценок. Это в общем.
HD>жена фильмы смотрит (пока я не успел на DVD скинуть, чтоб на телике посмотреть), т.е без форточек никуда.
Игры да, в винду. Фильмы... xine ставь... HD>Ну а побаловаться запускаю Дебиана или Suse, но это так.. для души.
В федоре 3й сижу. Жду когда 4ю привезут.
Здравствуйте, Mamut, Вы писали:
M>Ваше дело — предложить, наше — пощупать пациента за вымя Кто знает, вдруг нас удастся совратить С#'ом или даже портировать Янус под Моно — было бы здорово.
За моно братся небуду. Вся фишка в том что хочется именно скомпилировать и чтобы оно само работало. не прося всяких там интерпритаторов дособрать себя итд. С++ имхо однозначно.
AK>>Кстати, на шарпе есть обвязка и для Qt — qtcsharp, но, насколько я вижу, этот проект не обновлялся уже около года. M>Увы Я так надеялся, что дело у них сдвинется с мертвой точки, но увы
И слава богу.
Здравствуйте, Mr.Chipset, Вы писали:
MC>Привет всем! MC>После разговора с Sheridan'ом прояснились некоторые детали по сабжу. MC>В частности, есть идея разделить RSDN@Linux на две части: MC>1. Драйвер -- синх+драйвер к БД, скажем в виде демона. MC>2. Представление -- в данном случае это некий клиент который используеться драйвер для доступа к БД и синхронизации. К примеру это может быть веб-интерфейс на Джаве, десктопная программа просмотра, наподобие Janus'a или вообще плагин к FF MC>Так что сейчас требуеться лишь начать. Начать предлагаю с рефакторинга сервиса синхронизации Януса на С++ и к-платформенную библиотеку SOAP'a, наподобие gSOAP. MC>Всё в интересе со стороны C++'ников Linux'оидов. MC>СУВ.
Прочитав ветку, сделал следующие выводы.
В памяти на сервере висит демон януса, который
1 связыватся периодически (в зависимости от заданных настроек) с центральным сервером и скачивает обновления.
2 кладет скачанные обновления в какую-то СУБД, например MySQL (может быть сделана независимость от конкретной СУБД, благо это просто).
3 обслуживает запросы клиентов, с использованием, например, SOAP, выдавая им XML-ки с результатами конкретных запросов.
Клиент, который может быть вовсе на другой машине в локальной сети, делает следущее
1 при запуске связывается с демоном, авторизуется, и получает от него список форумов и список тем в текущем форуме.
2 при просмотре сообщения получает от демона текст этого сообщения.
3 при отправке сообщения связывается с демоном и передает данные для отправки.
База данных хранится в одном экземпляре на сервере.
В общем, вроде бы, типичное 3-tier приложение, разве что несколько громоздко выглядит...
Вопросы:
Я все правильно понял?
Где можно посмотреть, как сейчас Янус взаимодействет с сервером?
Metallica — Devil's Dance
Какая странная планета! — подумал Маленький принц. — Совсем сухая,
вся в иглах и соленая. И у людей не хватает воображения. Они только
повторяют то, что им скажешь...
Здравствуйте, Rebus83, Вы писали:
R> 3 обслуживает запросы клиентов, с использованием, например, SOAP, выдавая им XML-ки с результатами конкретных запросов.
Ну не xml а всетаки думаю "по старинке" — socketstream пользовать...
R> Вопросы: R> Я все правильно понял?
ну.. на 85-87% правильно
R> Где можно посмотреть, как сейчас Янус взаимодействет с сервером?
В исходниках которые лежат в subversion репозитории януса. Почитай здесь — там гдето вроде написано...
АВК, ну хотябы сказал чтонибудь... А то улыбаешся загадочно както... Интересно всетаки и тебя былобы послушать. Проект в стадии задумки и на этой стадии имхо важны всетаки мнения Старших Или ты нехочеш переносить янус в линукс?
R>> Где можно посмотреть, как сейчас Янус взаимодействет с сервером? S>В исходниках которые лежат в subversion репозитории януса. Почитай здесь — там гдето вроде написано...
Здесь возникают некоторые как бы проблемсы из-за использования s:any и авторизации, но, если использовать, скажем, тот же gSOAP, то эти проблемы решаемы. Блин, надо бы покопать еще SOAP из Qt Solutions...
M>>Но имхо всетаки вот такой начальный протокол следует принять как "атом". Из него уже можно строить "молекулы" запросов к демону. Скажем — дай мне мол вот эту ветку — а демон возвращает соответствующий набор атомов, может быть уже упорядоченный.
M>>*охохонюшки — куда это я ввязываюсь. я ж и программист-то весьма посредственный...* S>А что ты думаеш — я крут?
S>АВК, ну хотябы сказал чтонибудь... А то улыбаешся загадочно както... Интересно всетаки и тебя былобы послушать. Проект в стадии задумки и на этой стадии имхо важны всетаки мнения Старших Или ты нехочеш переносить янус в линукс?
Кстати, если проект все же оживет, то именно его нужно будет назвать Янусом — из-за его кроссплатформенности
Здравствуйте, Sheridan, Вы писали:
R>> Где можно посмотреть, как сейчас Янус взаимодействет с сервером? S>В исходниках которые лежат в subversion репозитории януса. Почитай здесь — там гдето вроде написано...
Исходники скачал ТЧК Читаю ТЧК Страшно ВСКЛ
Ария — Кастлевания
Какая странная планета! — подумал Маленький принц. — Совсем сухая,
вся в иглах и соленая. И у людей не хватает воображения. Они только
повторяют то, что им скажешь...
Здравствуйте, Mamut, Вы писали:
MC>>>Хм. Для демона тащить Qt? :\ S>>Неее... Для гуя qt. Но я тут подумал... Мож попробовать в качестве гуя нарисовать мод к пхп... 3х зайцев прибить можна — и гуй настраиваемый как хотиш. И нарисовать лехко. И можно один синхродемон на контору пользовать...
M>Надо посмотреть в сторону 4-го Qt, который мало того, что, вроде GPL под винду, так и было обещано большее разделение гуи и негуи частей. Благо, под KDE Qt есть сразу.
На сайте разработчика есть пока только RC1 для Linux. Виндовой GPL-версии нет — обещают к выпуску релиза. Судя по опыту предыдущих версий, стабильной четвертая ветка станет, в лучшем случае, через годик. Стоит ли начинать сейчас сразу с неё?
Играет Metallica — St. Anger
Какая странная планета! — подумал Маленький принц. — Совсем сухая,
вся в иглах и соленая. И у людей не хватает воображения. Они только
повторяют то, что им скажешь...
Здравствуйте, Sheridan, Вы писали:
S>АВК, ну хотябы сказал чтонибудь... А то улыбаешся загадочно както... Интересно всетаки и тебя былобы послушать. Проект в стадии задумки и на этой стадии имхо важны всетаки мнения Старших
А я уже говорил — не сделаете вы его. Если бы вы делали на mono или Java, да не трехзвенку, а обычного клиента, то небольшие шансы еще были бы. А так их 0 с минусом.
S>Или ты нехочеш переносить янус в линукс?
Мне пофигу. Лично мне линкс абсолютно неинтересен.
R> На сайте разработчика есть пока только RC1 для Linux. Виндовой GPL-версии нет — обещают к выпуску релиза. Судя по опыту предыдущих версий, стабильной четвертая ветка станет, в лучшем случае, через годик. Стоит ли начинать сейчас сразу с неё?
Ну, судя по тому, что проект наш все равно долгоиграющий, можно начать щупать за вымя, имхо.
S>>АВК, ну хотябы сказал чтонибудь... А то улыбаешся загадочно както... Интересно всетаки и тебя былобы послушать. Проект в стадии задумки и на этой стадии имхо важны всетаки мнения Старших
AVK>А я уже говорил — не сделаете вы его. Если бы вы делали на mono или Java, да не трехзвенку, а обычного клиента, то небольшие шансы еще были бы. А так их 0 с минусом.
А какие преимущества .net или Java перед Qt в разработке приложения, подобного Янусу?
Формочки ваять? Ну, они и в кути есть. Библиотеки? Тоже есть? И для работы с базами данных (ODBC, Oracle, SQLite, MySQL — out of the box), и для сетки (FTP, HTTP), и для XML'я, если его захочется использовать. Unicode — out of the box, вьюер (QTextBrowser, да еще и хитро расширяемый) — out of the box. Что еще надо для щастья?
На самом деле было бы интересно наваять хитрого демона, а за вьюером дело не заржавеет.
M> А какие преимущества .net или Java перед Qt в разработке приложения, подобного Янусу?
Самое большое примущество .net это то что под ним уже есть клиент и он работает который год
M>Формочки ваять? Ну, они и в кути есть. Библиотеки? Тоже есть? И для работы с базами данных (ODBC, Oracle, SQLite, MySQL — out of the box), и для сетки (FTP, HTTP), и для XML'я, если его захочется использовать. Unicode — out of the box, вьюер (QTextBrowser, да еще и хитро расширяемый) — out of the box. Что еще надо для щастья?
Список технологий абсолютно неважен. Главное результат. Мне как и АВК от линукса не холодно и не жарко. Интересно будет если что то у вас получится, хотя тоже гложут сомнения. Уж сильно крутой список задач вы себе поставили. Я бы определился все таки с чем то более локальным. Может лучше начать с простых вещей а потом расширяться?
Здравствуйте, Mamut, Вы писали:
M> А какие преимущества .net или Java перед Qt в разработке приложения, подобного Янусу?
Больше шансов что будет что то работающее.
M>Формочки ваять? Ну, они и в кути есть. Библиотеки? Тоже есть? И для работы с базами данных (ODBC, Oracle, SQLite, MySQL — out of the box), и для сетки (FTP, HTTP), и для XML'я, если его захочется использовать. Unicode — out of the box, вьюер (QTextBrowser, да еще и хитро расширяемый) — out of the box. Что еще надо для щастья?
Здравствуйте, WFrag, Вы писали:
WF>А сейчас он уже работает? Имеет смысл использовать его вместо старого?
Нет, не имеет, так как не оттестирован и череват глюками.. может оказаться вообще не рабочим.
M>> А какие преимущества .net или Java перед Qt в разработке приложения, подобного Янусу? A>Самое большое примущество .net это то что под ним уже есть клиент и он работает который год
Ну, не в обиду разработчикам будет сказано, но клиент этот очень долго шел к тому, чем он сейчас является. Мы же тоже не планируем прям сразу завтра выпустить клиент с такой же функциональностью
M>>Формочки ваять? Ну, они и в кути есть. Библиотеки? Тоже есть? И для работы с базами данных (ODBC, Oracle, SQLite, MySQL — out of the box), и для сетки (FTP, HTTP), и для XML'я, если его захочется использовать. Unicode — out of the box, вьюер (QTextBrowser, да еще и хитро расширяемый) — out of the box. Что еще надо для щастья? A>Список технологий абсолютно неважен. Главное результат. Мне как и АВК от линукса не холодно и не жарко. Интересно будет если что то у вас получится, хотя тоже гложут сомнения. Уж сильно крутой список задач вы себе поставили. Я бы определился все таки с чем то более локальным. Может лучше начать с простых вещей а потом расширяться?
Ну, так, по идее и будет. Тут где-то Шеридан предлагал
С нуля надо начинать. И первым делом конверт бд и рисовать просмотрщика. Потом можно братся за синхронизатора и следом за постинг сообщений и оценок. Это в общем.
Мы сейчас нахожимся в стадии превентивного планирования То есть, гоняем пургу, из которой выцеживаем потихоньку ценные идеи. Как только идеи накопятся, мы их кинем в воду общественного мнения и подберем выплывшие. А там — видно будет. Вот, пойду домой, подумаю, может к завтра какую-нибудь идею придумаю
HD>> т.е опять таки уже не с нуля ковырять. S>С нуля надо начинать. И первым делом конверт бд и рисовать просмотрщика. Потом можно братся за синхронизатора и следом за постинг сообщений и оценок. Это в общем.
ИМХО, все же надо разобраться с демоном. Структура базы, синхронизация, выдача данных. На первом этапе, пока разрабатывается демон, вьюер нужен простейший — пара кнопок, чтобы запросы слал.
На первом месте — это выдача данных и база. Первое должно быть наиболее стандартизировано и неменяемо (но расширяемо), а второе — наиболее эффективно. Это надо много думать.
Второй этап — вьюер. Вьюер на Qt — это плевое дело при условии грамотно спроектированного и реализованного демона. Ладно, не плевое, там граблей много (в частности — списки, но и это решаемо).
Если это веб-клиент (для корпоративных сетей ), то встает вопрос написания — оп! — еще одного демона, присосавшегося к первому
Поэтому, имхо, надо двигаться так:
1. демон
2. QT клиент
3. Любые другие извращения
Здравствуйте, akasoft, Вы писали:
M>>>Янусовский WSDL лежит здесь: http://www.rsdn.ru/ws/service.asmx?WSDL, само описание сервиса здесь: http://www.rsdn.ru/ws/service.asmx.
M>>Янусовский сервис лежит
A>Где лежит Янус, положим, я знаю, а это что за хрень? Про которую Мамут написал.
A>Что за форматированные статьи, их списки и прочая "секретная тайна".
Здравствуйте, akasoft, Вы писали:
A>И PostFile — это же способ загрузки файла в персональную область прямо из Януса. Дискриминация нашей религии по файловому признаку.
Этот функционал добавлен относительно недавно, для того чтобы пихать туда аттачменты из NNTP-клиентов. Можно прикрутить такое и к янусу, есди попросить Merle поправить сервис.
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Mr.Chipset, Вы писали:
MC>>Хм. Для демона тащить Qt? :\ S>Неее... Для гуя qt. Но я тут подумал... Мож попробовать в качестве гуя нарисовать мод к пхп... 3х зайцев прибить можна — и гуй настраиваемый как хотиш. И нарисовать лехко. И можно один синхродемон на контору пользовать...
Ну вот, а раз демон будет без х.., гуя, то зачем тянуть Qt solutions, не проще/легче ли на gSOAP?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Sheridan, Вы писали:
S>>АВК, ну хотябы сказал чтонибудь... А то улыбаешся загадочно както... Интересно всетаки и тебя былобы послушать. Проект в стадии задумки и на этой стадии имхо важны всетаки мнения Старших
AVK>А я уже говорил — не сделаете вы его. Если бы вы делали на mono или Java, да не трехзвенку, а обычного клиента, то небольшие шансы еще были бы. А так их 0 с минусом.
Раздразниваешшь? Программистский максимализм он страшен!
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, akasoft, Вы писали:
A>>Улыбку вызывает вот это. У меня даже ухмылку с ехидным "ню-ню"...
S>Ну так поправь. Что есть ассембли?
А, ну всё [г,р]авно отделят ветку...
C# не интерпретационный язык.
# В области информационных технологий, интерпретация — процесс выполнения текста программы без предварительной компиляции, «на лету».
Компиляция присутствует.
IL же, да.
Да и то, вроде-бы IL компилируеться в машинный код в первый запуск.
MC>>>Хм. Для демона тащить Qt? :\ S>>Неее... Для гуя qt. Но я тут подумал... Мож попробовать в качестве гуя нарисовать мод к пхп... 3х зайцев прибить можна — и гуй настраиваемый как хотиш. И нарисовать лехко. И можно один синхродемон на контору пользовать...
MC>Ну вот, а раз демон будет без х.., гуя, то зачем тянуть Qt solutions, не проще/легче ли на gSOAP?
. Qt, особенно из 4-го (Qt Core) или покоцанный третий(TinyQ) нужен для кросс-платформенности (треды, доступ к фалам, к базам данных и т.п.) Solutions был просто упомянут, как альтернатива
Здравствуйте, Mr.Chipset, Вы писали:
MC>>>Хм. Для демона тащить Qt? :\ S>>Неее... Для гуя qt. Но я тут подумал... Мож попробовать в качестве гуя нарисовать мод к пхп... 3х зайцев прибить можна — и гуй настраиваемый как хотиш. И нарисовать лехко. И можно один синхродемон на контору пользовать...
MC>Ну вот, а раз демон будет без х.., гуя, то зачем тянуть Qt solutions, не проще/легче ли на gSOAP?
Наверное проще. Вот только никак не могу с ним разобраться. Какие-то либы все время не линкуются. Попробую ещё завтра — после защиты.
Играет Линда — Ворона
Какая странная планета! — подумал Маленький принц. — Совсем сухая,
вся в иглах и соленая. И у людей не хватает воображения. Они только
повторяют то, что им скажешь...
Здравствуйте, Mamut, Вы писали:
MC>>>>Хм. Для демона тащить Qt? :\ S>>>Неее... Для гуя qt. Но я тут подумал... Мож попробовать в качестве гуя нарисовать мод к пхп... 3х зайцев прибить можна — и гуй настраиваемый как хотиш. И нарисовать лехко. И можно один синхродемон на контору пользовать...
MC>>Ну вот, а раз демон будет без х.., гуя, то зачем тянуть Qt solutions, не проще/легче ли на gSOAP?
M>Это я уже предлагал
. Qt, особенно из 4-го (Qt Core) или покоцанный третий(TinyQ) нужен для кросс-платформенности (треды, доступ к фалам, к базам данных и т.п.) Solutions был просто упомянут, как альтернатива
Признаю свою вину, меру, степень, глубину
Я как-то не подумал што демона будет тяжело переносить на Windows. Если Qt можно будет без гуя тащить (QtCore), то можно и не делать сборную солянку, наподобие:
boost::threads+boost::filesystem+gSOAP+FireBird/MySQL.
Кстати, кто что думает насчёт юзывания птиц? Огненных.
Здравствуйте, Rebus83, Вы писали:
R>Здравствуйте, Mr.Chipset, Вы писали:
MC>>>>Хм. Для демона тащить Qt? :\ S>>>Неее... Для гуя qt. Но я тут подумал... Мож попробовать в качестве гуя нарисовать мод к пхп... 3х зайцев прибить можна — и гуй настраиваемый как хотиш. И нарисовать лехко. И можно один синхродемон на контору пользовать...
MC>>Ну вот, а раз демон будет без х.., гуя, то зачем тянуть Qt solutions, не проще/легче ли на gSOAP?
R> Наверное проще. Вот только никак не могу с ним разобраться. Какие-то либы все время не линкуются. Попробую ещё завтра — после защиты.
Стяну Qt -- поразбираюсь как оно что где когда с SOAP, может попробую посинхронизить с Янусовым веб-сервисом, благо АВК дал
MC>Я как-то не подумал што демона будет тяжело переносить на Windows. Если Qt можно будет без гуя тащить (QtCore), то можно и не делать сборную солянку, наподобие: MC>boost::threads+boost::filesystem+gSOAP+FireBird/MySQL. MC>Кстати, кто что думает насчёт юзывания птиц? Огненных.
Тута я что-то подумал... К демону все равно жлателен ГУИ — менять настройки там, прямой ввод SQL запросов, например. Другое дело, что этот интерфейс можно вынести в плагин, например. Ну, это я опять впереди паровоза бегу...
Здравствуйте, Mamut, Вы писали:
MC>>Признаю свою вину, меру, степень, глубину
M>
MC>>Я как-то не подумал што демона будет тяжело переносить на Windows. Если Qt можно будет без гуя тащить (QtCore), то можно и не делать сборную солянку, наподобие: MC>>boost::threads+boost::filesystem+gSOAP+FireBird/MySQL. MC>>Кстати, кто что думает насчёт юзывания птиц? Огненных.
M>Все будет Есть такая вешчь, как SQL drivers в Qt, а также возможность создания своих собственных. То есть, теоретически, все возможно.
Тогда я спокоен!
M>Тута я что-то подумал... К демону все равно жлателен ГУИ — менять настройки там, прямой ввод SQL запросов, например. Другое дело, что этот интерфейс можно вынести в плагин, например. Ну, это я опять впереди паровоза бегу...
Очень неплохая идея, только может вынести настройки все в cfg файл, а уже его редактировать с помощью утилиты, типа rsdn-linux-config? Хочеться очень минимальным сделать демон, вот что я думаю.
Здравствуйте, Mr.Chipset, Вы писали:
R>> Наверное проще. Вот только никак не могу с ним разобраться. Какие-то либы все время не линкуются. Попробую ещё завтра — после защиты.
MC>Стяну Qt -- поразбираюсь как оно что где когда с SOAP, может попробую посинхронизить с Янусовым веб-сервисом, благо АВК дал
описание оного, а то ковырять исходники Януса мне как-то соффсем влом..
Угу. Я попытался пойти тем же путем. Пока успехи не очень... Кстати, в QT3-GPL я что-то ничего связанного с SOAP не нашел. Есть куча классов для работы с XML, но это не совсем то...
Играет ...
Какая странная планета! — подумал Маленький принц. — Совсем сухая,
вся в иглах и соленая. И у людей не хватает воображения. Они только
повторяют то, что им скажешь...
R> Угу. Я попытался пойти тем же путем. Пока успехи не очень... Кстати, в QT3-GPL я что-то ничего связанного с SOAP не нашел. Есть куча классов для работы с XML, но это не совсем то...
Есть Qt Solutions, в принципе, здесь, но на самом деле — только для зарегистрированных пользователей Qt здесь
Здравствуйте, Mamut, Вы писали:
R>> Угу. Я попытался пойти тем же путем. Пока успехи не очень... Кстати, в QT3-GPL я что-то ничего связанного с SOAP не нашел. Есть куча классов для работы с XML, но это не совсем то...
M>Есть Qt Solutions, в принципе, здесь, но на самом деле — только для зарегистрированных пользователей Qt здесь
Спасибо за ссылочку, обязательно посмотрю.
Играет ...
Какая странная планета! — подумал Маленький принц. — Совсем сухая,
вся в иглах и соленая. И у людей не хватает воображения. Они только
повторяют то, что им скажешь...
Здравствуйте, Mamut, Вы писали:
R>> Угу. Я попытался пойти тем же путем. Пока успехи не очень... Кстати, в QT3-GPL я что-то ничего связанного с SOAP не нашел. Есть куча классов для работы с XML, но это не совсем то...
M>Есть Qt Solutions, в принципе, здесь, но на самом деле — только для зарегистрированных пользователей Qt здесь
Здравствуйте, Mamut, Вы писали:
M>На первом месте — это выдача данных и база. Первое должно быть наиболее стандартизировано и неменяемо (но расширяемо), а второе — наиболее эффективно. Это надо много думать.
Все есть это у януса...
M>Если это веб-клиент (для корпоративных сетей ), то встает вопрос написания — оп! — еще одного демона, присосавшегося к первому
Нипонял... Зачем демон? Мод к пхп надо, а на пхп уже писать.
M>Поэтому, имхо, надо двигаться так: M>1. демон M>2. QT клиент M>3. Любые другие извращения
+
Здравствуйте, Mr.Chipset, Вы писали: MC>Кстати, кто что думает насчёт юзывания птиц? Огненных.
Дык я уже голос сорвал криками "Даваайте переходить..." И АВК непротив...
Здравствуйте, Mamut, Вы писали:
M>Тута я что-то подумал... К демону все равно жлателен ГУИ — менять настройки там, прямой ввод SQL запросов, например. Другое дело, что этот интерфейс можно вынести в плагин, например. Ну, это я опять впереди паровоза бегу...
За каким ему гуй? ы? Можно конечно со временем написать отдельную софтину для правке конфига, но имхо она ненужна. Особенно если задокументировать параметры в конфиге и с проектом ложить рабочий пример с комментами.
Здравствуйте, Mr.Chipset, Вы писали:
MC>А, ну всё [г,р]авно отделят ветку... MC>C# не интерпретационный язык. MC>
MC># В области информационных технологий, интерпретация — процесс выполнения текста программы без предварительной компиляции, «на лету».
MC>Компиляция присутствует.
В бинарный код компилируется чтоли? При чем тут тогда их псевдоассемблер, инкапсуляция классов в результат? MC>IL же, да.
вот-вот MC>Да и то, вроде-бы IL компилируеться в машинный код в первый запуск.
угу, и во второй и в 3й... строчечка за строчечкой..
Здравствуйте, Mamut, Вы писали:
M>А насчет демона я думаю со вчерашнего вечера Мое воспаленное воображение нарисовало мне вот такое вот:
M>[img]http://www.rsdn.ru/File/9088/RSDN_at_Linux.png[/img]
Если не секрет, то в чём это тебе таком изображение рисовало?
Здравствуйте, Mr.Chipset, Вы писали:
MC>Привет всем! MC>После разговора с Sheridan'ом прояснились некоторые детали по сабжу. MC>В частности, есть идея разделить RSDN@Linux на две части: MC>1. Драйвер -- синх+драйвер к БД, скажем в виде демона. MC>2. Представление -- в данном случае это некий клиент который используеться драйвер для доступа к БД и синхронизации. К примеру это может быть веб-интерфейс на Джаве, десктопная программа просмотра, наподобие Janus'a или вообще плагин к FF MC>Так что сейчас требуеться лишь начать. Начать предлагаю с рефакторинга сервиса синхронизации Януса на С++ и к-платформенную библиотеку SOAP'a, наподобие gSOAP. MC>Всё в интересе со стороны C++'ников Linux'оидов. MC>СУВ.
Привет всем,
с интересом все почитал...
хочеться присоединиться к разработке. но она видимо пока не началась
Сам под Линукс новичок — но очень хочеться освоить.
Может для начала сформулировать список средств разработки, чтобы можно было поставить, попробовать, потестировать...
А к процессу разработки (мои пять копеек):
может написать простенький синхронизатор БД с сервером? (я так понимаю это сразу же работа с БД, XML, сеть что еще?) Типа заготовку для демона. Можно даже для упрощения сделать его запуск ручным.
Пока структуру БД сделать такую же как в Янусе (только не Access — умоляю...).
A>хочеться присоединиться к разработке. но она видимо пока не началась A>Сам под Линукс новичок — но очень хочеться освоить.
A>Может для начала сформулировать список средств разработки, чтобы можно было поставить, попробовать, потестировать...
A>А к процессу разработки (мои пять копеек): A>может написать простенький синхронизатор БД с сервером? (я так понимаю это сразу же работа с БД, XML, сеть что еще?) Типа заготовку для демона. Можно даже для упрощения сделать его запуск ручным. A>Пока структуру БД сделать такую же как в Янусе (только не Access — умоляю...).
A>Сразу же пойдут вопросы по делу...
Шеридан предложил, а я поддеожал идею использовать в этом деле Qt.
Плюсы.
— Стабильный кроссплатформенный фреймворк, использумый как в Линуксе (KDE), так и в Винде (Skype, Opera, вроде тоже на Qt написана). Более полный список — на http://www.trolltech.com/.
— Большое количество компонентов самого фреймворка (работа с сетью, с XML, наличие SQL драйверов к различным базам данных и прочая и прочая)
— Компилируется в нативный код для каждой системы (по принципу write once, compile everywhere)
— Легкость в использовании
Минусы.
— Версии <4 версия очень даже платны для винды. Лекарство, безусловно, существует, поэтому это как бы не проблема (хоть и некрасиво). Версия 4 — GPL под все системы, но она пока бета, а под винду выйдет только с релизом.
— Версии <4 сильно завязаны на ГУИ, придется таскать совсем немаленькую библиотеку. Это порядка 5-и мегабайтов, если .dll и не менее мегабайта, если .lib. В случае с .lib нельзя будет использовать систему плагинов, предлагаемую Qt, что делает невозможным использование custom SQL drivers. Можно посмотреть в сторону TinyQ, которая предлагает покоцанный вариант Qt, но это надо щупать пациента за вымя.
Для работы с SOAP скорее всего будет использован gSOAP.
В качестве базы данных — пока неизвестно (скорее всего, firebird, как я понимаю).
В отношении базы данных ее структуру еще надо будет обдумать, потому что, если будет проектироваться именно демон с поддержкой нескольких пользователей, то в структуру надо будет вносить изменения.
Вроде, так. Надо, чтобы Шеридан, как неофициальный руководитель RSDN@Linux сказал свое веское слово
Здравствуйте, Mamut, Вы писали:
M>Шеридан предложил, а я поддеожал идею использовать в этом деле Qt.
Согласен на 100%.
Компилятор какой? то что GCC понятно, но от какой версии плясать?
Например в Fedore 4 стоит уже GCC 4.0.0.8...
В какой среде? (KDevelop или из ком.строки)
и т.д.
[skip]
M>В качестве базы данных — пока неизвестно (скорее всего, firebird, как я понимаю).
меня почему-то больше тянет в сторону SQL-Lite
M>В отношении базы данных ее структуру еще надо будет обдумать, потому что, если будет проектироваться именно демон с поддержкой нескольких пользователей, то в структуру надо будет вносить изменения.
Может пока просто для одного пользователя сделать. Освои реструктуризатор, gSOAP, сеть, БД.
По моему и так уже не плохо для начала. Вроде крутых линуксоидов пока не видно
M>Вроде, так. Надо, чтобы Шеридан, как неофициальный руководитель RSDN@Linux сказал свое веское слово
Может он страничку заведет на эту тему. Похоже у проекта есть будущее...
M>>Шеридан предложил, а я поддеожал идею использовать в этом деле Qt. A>Согласен на 100%. A>Компилятор какой? то что GCC понятно, но от какой версии плясать? A>Например в Fedore 4 стоит уже GCC 4.0.0.8... A>В какой среде? (KDevelop или из ком.строки) A>и т.д.
ИМХО, не имеет значения. Например, я если и буду участвовать, то буду пользовать VS.NET 2003 Буду ... эээ... windows release manager
А если серьезно, то под Линухом это, скорее всего, будет gcc + KDevelop.
A>[skip]
M>>В качестве базы данных — пока неизвестно (скорее всего, firebird, как я понимаю).
A>меня почему-то больше тянет в сторону SQL-Lite
Меня тоже , но поставляемый с Qt 3.x драйвер поддерживает только SQLite 2, поддержка 3-го появится только в четвертой кути. А человеческих реализаций доступа к SQLite, да еще и кросс-платформенных, и нет (чтобы обернуть их в качестве драйвера). Главный минус скулита — это отсутствие bidirectional cursors (есть только forward курсоры). А всякие fetch_table работают довольно медленно на сколь-нибудь больших объемах данных. Второй минус — это отсутствие человеческого ALTER TABLE.
Если первая (главная) проблема может не такая и главная (зависит от имплементации демона), то вторая может стать серьезным препятствием при реструктуризации базы данных большого объема.
M>>В отношении базы данных ее структуру еще надо будет обдумать, потому что, если будет проектироваться именно демон с поддержкой нескольких пользователей, то в структуру надо будет вносить изменения.
A>Может пока просто для одного пользователя сделать. Освои реструктуризатор, gSOAP, сеть, БД. A>По моему и так уже не плохо для начала. Вроде крутых линуксоидов пока не видно
Лучше уж сразу делать по-человечески, имхо. Как я тут где-то уже писал, гуи-часть — это ерунда при условии человеческого демона ("человеческий демон" — этакий оксюморон получился )
M>>Вроде, так. Надо, чтобы Шеридан, как неофициальный руководитель RSDN@Linux сказал свое веское слово A>Может он страничку заведет на эту тему. Похоже у проекта есть будущее...
Мож, сразу на sourceforge? Но это к Шеридану/Чипсету
Здравствуйте, Mamut, Вы писали:
M>ИМХО, не имеет значения. Например, я если и буду участвовать, то буду пользовать VS.NET 2003 Буду ... эээ... windows release manager
M>А если серьезно, то под Линухом это, скорее всего, будет gcc + KDevelop.
A>>[skip]
M>[skip]Главный минус скулита — это отсутствие bidirectional cursors (есть только forward курсоры). А всякие fetch_table работают довольно медленно на сколь-нибудь больших объемах данных. Второй минус — это отсутствие человеческого ALTER TABLE.
Они вроде активно двигаются в этом направлении...
M>Если первая (главная) проблема может не такая и главная (зависит от имплементации демона), то вторая может стать серьезным препятствием при реструктуризации базы данных большого объема.
Может тогда начать с MySQL
M>>>В отношении базы данных ее структуру еще надо будет обдумать, потому что, если будет проектироваться именно демон с поддержкой нескольких пользователей, то в структуру надо будет вносить изменения.
Заодно и реструктуризатор отработаем
M>Лучше уж сразу делать по-человечески, имхо. Как я тут где-то уже писал, гуи-часть — это ерунда при условии человеческого демона ("человеческий демон" — этакий оксюморон получился )
По человечски все равно сразу не получиться, IMHO.
Иожет лучше в бой, а там посмотрим?
M>>>Вроде, так. Надо, чтобы Шеридан, как неофициальный руководитель RSDN@Linux сказал свое веское слово A>>Может он страничку заведет на эту тему. Похоже у проекта есть будущее...
M>Мож, сразу на sourceforge? Но это к Шеридану/Чипсету
Здравствуйте, Mamut, Вы писали:
M>>Вроде, так. Надо, чтобы Шеридан, как неофициальный руководитель RSDN@Linux сказал свое веское слово
M>Хотя, собственно, почему Шеридан, а не Mr.Chipset? Вы там разберитесь, а то у мен ябардак в голове
Народ, пожалейте меня.. я не смогу одновременно программить и руководить Тем более шо идея то Шеридановская
Народ, а когда Qt 4 выйдет? Предлагаю писать только на ней, если она выйдет, ну хотя-бы до осени а в обратном случае предлагаю делать демона на жосоапе+файрбёрд+буст.
Просто тащить ради демона всю кутю как-то...
... << А писал я этот бред на RSDN@Home 1.1.4 beta 7 rev. 447, под звуки тишины>>
A>Привет всем, A>с интересом все почитал...
A>хочеться присоединиться к разработке. но она видимо пока не началась A>Сам под Линукс новичок — но очень хочеться освоить.
Аналогично A>Может для начала сформулировать список средств разработки, чтобы можно было поставить, попробовать, потестировать...
А какая разница. То-ж кутя, а она хорошо под разными компилерами работает.
A>А к процессу разработки (мои пять копеек): A>может написать простенький синхронизатор БД с сервером? (я так понимаю это сразу же работа с БД, XML, сеть что еще?) Типа заготовку для демона. Можно даже для упрощения сделать его запуск ручным.
Я как раз это и начинал делать, пытался синхронизить жСОАПом. A>Пока структуру БД сделать такую же как в Янусе (только не Access — умоляю...).
Нафик Access, MS, и прочие шурупы... (злобно ухмыляюсь) A>Сразу же пойдут вопросы по делу...
... << А писал я этот бред на RSDN@Home 1.1.4 beta 7 rev. 447, под звуки тишины>>
Здравствуйте, Mr.Chipset, Вы писали:
MC>Здравствуйте, Mr.Chipset, Вы писали:
MC>Народ, а когда Qt 4 выйдет? Предлагаю писать только на ней, если она выйдет, ну хотя-бы до осени а в обратном случае предлагаю делать демона на жосоапе+файрбёрд+буст. MC>Просто тащить ради демона всю кутю как-то...
The Qt 4 library will be split so that it will be possible to link to Qt's non-GUI functionality without linking to the GUI parts. This means that non-GUI applications such as servers and command line tools can be built using Qt's tool and container classes, event loops and timers, networking access, XML, database access, and so on, without including unwanted GUI code.
Вообще, читаешь тот текст и заливаешься слюнями Но, как кто-то тут уже сказал, стабильной эта версия скорее всего станет только через год. С другой стороны, мы и не торопимся никуда
We anticipate releasing Qt 4.0 in late June, 2005.
Насколько это верно, я не знаю, но знаю, что готовится KDE3.5, а те, скорее всего, уже пользуют 4-ую версию. Более того, здесь:
Should I use the Qt 4 Release Candidate to develop applications?
Yes, you can. While we do not recommended use of the Release Candidate for end user deployment, it is ready for development use. Please inform qt-bugs@trolltech.com if you find stability issues in the Release Candidate.
You can also start porting your Qt 3 based projects over to Qt 4. The Porting Guide and the qt3to4 porting tool will help you in the process.
Здравствуйте, Mr.Chipset, Вы писали:
MC>Здравствуйте, avbochagov, Вы писали:
A>>Может для начала сформулировать список средств разработки, чтобы можно было поставить, попробовать, потестировать... MC>А какая разница. То-ж кутя, а она хорошо под разными компилерами работает.
ой не скажите батенька... тут недавно простенький шаблон пытались откимпилировать под GCC — так на трех версиях три разных варианта.
Пришлось ifdef-ом отмазывать.
требования, предъвляемые проекту перед тем, как проекту будет отведено место на сайте.
Для начала наверное нужно определится что за проект. Если мы решим его поддержать, то нужно будет следующее:
1) Название (русское), краткое описание проекта, имя проекта (английское, идентификатор)
2) Аннотацию проекта. Примерно 1 абзац текста с кратким описанием целей.
3) Статью с подробным описанием проекта в формате RSDN ML.
4) Список логинов и паролей для доступа к репозиторию по записи.
Требования к проекту примерно такие:
1) Желателен свободный доступ к исходникам, потому что иначе непонятно какой интерес в этом rsdn.
2) Наличие людей с желанием и возможностью заниматься проектом.
3) Разрешение размещать материалы проекта на дисках к RSDN Mag.
4) Лицензионная чистота.
Здравствуйте, Mamut, Вы писали:
M>Здравствуйте, Mr.Chipset, Вы писали:
MC>>Здравствуйте, Mr.Chipset, Вы писали:
MC>>Народ, а когда Qt 4 выйдет? Предлагаю писать только на ней, если она выйдет, ну хотя-бы до осени а в обратном случае предлагаю делать демона на жосоапе+файрбёрд+буст. MC>>Просто тащить ради демона всю кутю как-то...
M>здесь: M>
M>Better support for non-GUI applications
M>The Qt 4 library will be split so that it will be possible to link to Qt's non-GUI functionality without linking to the GUI parts. This means that non-GUI applications such as servers and command line tools can be built using Qt's tool and container classes, event loops and timers, networking access, XML, database access, and so on, without including unwanted GUI code.
M>Вообще, читаешь тот текст и заливаешься слюнями Но, как кто-то тут уже сказал, стабильной эта версия скорее всего станет только через год. С другой стороны, мы и не торопимся никуда
Да, если выйдет в июне то я согласен. Как раз обоссудим всё это дело.
Всё сходиться как нельзя лучше
... << А писал я этот бред на RSDN@Home 1.1.4 beta 7 rev. 447, под звуки тишины>>
требования, предъвляемые проекту перед тем, как проекту будет отведено место на сайте.
M>
M>Для начала наверное нужно определится что за проект. Если мы решим его поддержать, то нужно будет следующее:
M>1) Название (русское), краткое описание проекта, имя проекта (английское, идентификатор)
Предлагаю простенько так RSDN@Home LE (т.е. Linux Edition)
M>
M>2) Аннотацию проекта. Примерно 1 абзац текста с кратким описанием целей.
M>3) Статью с подробным описанием проекта в формате RSDN ML.
M>4) Список логинов и паролей для доступа к репозиторию по записи.
M>Требования к проекту примерно такие:
M>1) Желателен свободный доступ к исходникам, потому что иначе непонятно какой интерес в этом rsdn.
M>2) Наличие людей с желанием и возможностью заниматься проектом.
M>3) Разрешение размещать материалы проекта на дисках к RSDN Mag.
M>4) Лицензионная чистота.
Здравствуйте, Mamut, Вы писали:
M>Надо начинать думать...
А чего тут думать. Для Януса репозиторий давно есть.
Заводите себе папочку дополнительную, и продолжаете. В крайнем случае, АВК можно попросить сделать ещё один бренч. Дёшево и сердито. Чем потом хоронить мертворождённого.
требования, предъвляемые проекту перед тем, как проекту будет отведено место на сайте.
M>>
M>>Для начала наверное нужно определится что за проект. Если мы решим его поддержать, то нужно будет следующее:
M>>1) Название (русское), краткое описание проекта, имя проекта (английское, идентификатор)
A>Предлагаю простенько так RSDN@Home LE (т.е. Linux Edition)
Боюсь будет путаница. Прожка то новая, и даже на другом языке..
Можно как сабж, типа: RSDN@Linux, или Lanus, или ещё как нить
требования, предъвляемые проекту перед тем, как проекту будет отведено место на сайте.
M>>
M>>Для начала наверное нужно определится что за проект. Если мы решим его поддержать, то нужно будет следующее:
M>>1) Название (русское), краткое описание проекта, имя проекта (английское, идентификатор)
A>Предлагаю простенько так RSDN@Home LE (т.е. Linux Edition)
Здравствуйте, Mr.Chipset, Вы писали:
MC>Можно как сабж, типа: RSDN@Linux, или Lanus, или ещё как нить
Янус — очень осмысленное и символическое название в отличие от скажем RSDN4Lin или ещё какого либо RSDN@TUX. Янус в римской мифологии — бог любого начала (по имени Януса был назван первый месяц — январь). Имя "Янус" означает "ворота", "двери" (отсюда эпитет: "отпирающий"). Янус изображался двуликим как символ осмотрительности, необходимой для начала любого дела. Исходя из выше сказанного наверно стоит серьёзно покумекать над названием, может тоже что-нибудь из мифологии — типа Tartar (место наказания в Аиде для всех грешников) как символ того что создателям клиента придётся помучиться во время его создания . А можно DioGen, ну Диоген считал, что человек должен жить, удовлетворяя свои естественные потребности наиболее простым путём, избегая удобств (для демона ни какого гуя!, только конфиг). Впрочем меня чего-то понесло... Короче название должно быть: 1. Осмысленным (RSDN@Linux). 2. Красивым на слух (Янус). Вообщем — "как вы лодку назовёте так она и поплывёт". Есть тут знатоки мифологии (любой, хоть финской, хоть японской), что-бы придумать название?
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, Mamut, Вы писали:
A>>>Предлагаю простенько так RSDN@Home LE (т.е. Linux Edition)
M>>Может, RSDN@Home CE (Cross-Platform Edition) ?
WF>А вам не кажется, что использование уже раскрученной марки для совсем другого продукта это как-то... некрасиво, что-ли.
Я поддерживаю.
... << А писал я этот бред на RSDN@Home 1.1.4 beta 7 rev. 447, под звуки тишины>>
БСС>...Вообщем — "как вы лодку назовёте так она и поплывёт". Есть тут знатоки мифологии (любой, хоть финской, хоть японской), что-бы придумать название?
Daimon is the Greek derivative for the term demon. In this sense the term "demon" means "replete with knowledge." The term 'daimon' means "divine power," "fate" or "god." Daimons, in Greek mythology, included deified heroes. They were considered intermediary spirits between men and the gods.
Между людьми и всемогущим РСДНом
Только чур, уговор, всякими там Эросами не называться
Здравствуйте, БСС, Вы писали:
БСС>Здравствуйте, Mr.Chipset, Вы писали:
MC>>Можно как сабж, типа: RSDN@Linux, или Lanus, или ещё как нить >> Есть тут знатоки мифологии (любой, хоть финской, хоть японской), что-бы придумать название? http://en.wikipedia.org/wiki/Janus_(mythology)
He supposedly came from Thessaly in Greece and shared a kingdom with Camese in Latium. They had many children, including Tiberinus. Janus and his later wife, Juturna, were the parents of Fontus. He had another wife named Jana. Historically, however, he was one of the few Roman gods who had no ready made Greek counterpart, or analogous mythology.
Tiberinus или Fontus? Мне Фонтус нравиться
... << А писал я этот бред на RSDN@Home 1.1.4 beta 7 rev. 447, под звуки Кино — Стук>>
Здравствуйте, Mr.Chipset, Вы писали:
MC>Tiberinus или Fontus? Мне Фонтус нравиться
Демон и клиент будут под одним названием? Если нет, то можно для демона — Diamon, для клиента Fontus
Здравствуйте, Demiurg, Вы писали:
A>>Предлагаю простенько так RSDN@Home LE (т.е. Linux Edition)
D> Почему Linux-то? Он же кроссплатформенный задумывается? Значит PE — Portable Edition
Здравствуйте, Mr.Chipset, Вы писали:
MC>Привет всем!
тут подумалось... (в свете моего тоже перехода в линукс ) — может начать писать смотрелку которая будет брать данные для просмотра из аццесс БД (стандартной янусовой) и демона, который уже будет наполнять данными какие то БД конфигурируемые (mysql, FB..)?
З.Ы.
следую чисто шкурному интересу — могу синхронизировать на работе из под виндовс, а смотрел бы с удовольствием из линукса
... << RSDN@Home 1.1.4 beta 7 rev. 474>>
играет судя по всему — работаю ибо тишина.
D> Ну так что — народ в самом деле собирается всерьез браться за проект? Интересно... Будем следить за событиями
Ждем выхода Qt4 (самый конец июня). Чуствуется, возьмутся за это дело Шеридан и Mr.Chipset. Я, возможно, подключусь только к августу, если все будет хорошо.
Здравствуйте, Mamut, Вы писали:
D>> Ну так что — народ в самом деле собирается всерьез браться за проект? Интересно... Будем следить за событиями
M>Ждем выхода Qt4 (самый конец июня). Чуствуется, возьмутся за это дело Шеридан и Mr.Chipset. Я, возможно, подключусь только к августу, если все будет хорошо.
Все может быть плохо?
M>Буду надеяться, что все получится
Демоны вы там понапридумывали, в винде это сервисы будут? По-хорошему, неплохо было бы сделать продукт, что его можно было поставить и пользоваться на машине без админских прав. Не знаю — возможно это сделать со службами?
M>>Ждем выхода Qt4 (самый конец июня). Чуствуется, возьмутся за это дело Шеридан и Mr.Chipset. Я, возможно, подключусь только к августу, если все будет хорошо.
D> Все может быть плохо?
Ага Я пока еще не знаю, как у меня со временем будет. Но поучаствовать хочется...
M>>Буду надеяться, что все получится
D> Демоны вы там понапридумывали, в винде это сервисы будут? По-хорошему, неплохо было бы сделать продукт, что его можно было поставить и пользоваться на машине без админских прав. Не знаю — возможно это сделать со службами?
Здравствуйте, Demiurg, Вы писали:
D>Здравствуйте, Mamut, Вы писали:
D> Ну так что — народ в самом деле собирается всерьез браться за проект? Интересно... Будем следить за событиями
Собираемся, собираемся..
Ждём КуТю и Шеридана
... << А писал я этот бред на RSDN@Home 1.1.4 beta 7 rev. 447, под звуки тишины>>
Здравствуйте, ironwit, Вы писали:
I>Здравствуйте, Mr.Chipset, Вы писали:
MC>>Привет всем! I>тут подумалось... (в свете моего тоже перехода в линукс ) — может начать писать смотрелку которая будет брать данные для просмотра из аццесс БД (стандартной янусовой) и демона, который уже будет наполнять данными какие то БД конфигурируемые (mysql, FB..)?
I>З.Ы. I>следую чисто шкурному интересу — могу синхронизировать на работе из под виндовс, а смотрел бы с удовольствием из линукса
А это кстати очень злободневный вопрос, ибо я, к примеру, сижу и под линуксом и под виндузом, а хочеццо чтобы база была одна.
... << А писал я этот бред на RSDN@Home 1.1.4 beta 7 rev. 447, под звуки Offspring — Gone Away>>
Здравствуйте, Demiurg, Вы писали:
D>Здравствуйте, Mamut, Вы писали:
M>>Предлагаю следующее:
M>>Общий проект (демон+смотрелка) назвать Cornucopia (рог изобилия ) M>>Демона назвать Daimon
D> Ну так что — народ в самом деле собирается всерьез браться за проект? Интересно... Будем следить за событиями
ИМХО название это еще не работа... хотя я тоже следить буду Может чем и помогу... смотря на чем писать будут...
... << RSDN@Home 1.1.4 beta 7 rev. 474>>
играет Faktor-2 — Ну, так иди же сюда
Здравствуйте, Mr.Chipset, Вы писали:
D>> Ну так что — народ в самом деле собирается всерьез браться за проект? Интересно... Будем следить за событиями
MC>Собираемся, собираемся.. MC>Ждём КуТю и Шеридана
Мне лично проект интересен из-за qt, а Линукс совсем нет (KDEvelop совсем не радует...) Будет время — посмотрим как сложится
Здравствуйте, WFrag, Вы писали:
D>> Ну так что — народ в самом деле собирается всерьез браться за проект? Интересно... Будем следить за событиями
WF>А тем временем, вышла ноль-ноль-первая версия вражеского проекта Forview! http://gzip.rsdn.ru/Forum/Message.aspx?mid=1233832&only=1
Здравствуйте, ironwit, Вы писали:
D>> Ну так что — народ в самом деле собирается всерьез браться за проект? Интересно... Будем следить за событиями I>ИМХО название это еще не работа... хотя я тоже следить буду Может чем и помогу... смотря на чем писать будут...
Пока на руках нет, с чем работать, можно поразмышлять теоретически. Так сказать, устроить мозговой штурм сейчас, чем мучиться потом.
Дальше идут ламерские размышлния, основанные на моем незнании предметной области
Итак, мы планируем демона, который будет способен отдавать данные любым клиентам, так? Пусть они будут написаны хоть на С++, хоть на Яве, хоть на Лиспе. Тогда сразу возникает вопрос — как их отдавать?
Просто двоичные данные отдать не удастся, как я понимаю, так? Вернее можно, но выдачу над все равно каким-нибудь образом стандартизировать. Ы?
Надо начать думать о структуре сообщений между демоном и клиентами.
Здравствуйте, Mamut, Вы писали:
M>Просто двоичные данные отдать не удастся, как я понимаю, так? Вернее можно, но выдачу над все равно каким-нибудь образом стандартизировать. Ы?
M>>Просто двоичные данные отдать не удастся, как я понимаю, так? Вернее можно, но выдачу над все равно каким-нибудь образом стандартизировать. Ы?
WF>Двоичные данные противоречат Unix way
Ну или gzip'нутые текстовые Просто текст гонять по сетке будет накладно.
WF>По-моему, что-нибудь вроде формата record-jar будет самое оно (http://www.faqs.org/docs/artu/ch05s02.html#id2906931)
WF>Я, правда, не совсем понял обязанности вашего демона...
Сервис, синхронизирующийся с РСДНом, получающий оттуда и отправляющий туда данные. Только сервис, с которым могут общаться клиенты. Вроде как здесь
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, Mamut, Вы писали:
M>>Просто двоичные данные отдать не удастся, как я понимаю, так? Вернее можно, но выдачу над все равно каким-нибудь образом стандартизировать. Ы?
WF>Двоичные данные противоречат Unix way
ИМХО, избыточный формат для наших целей. более того возможны ошибки при его использоваии, так как он резервирует некоторые последовательности символов.
Здравствуйте, avbochagov, Вы писали:
WF>>Двоичные данные противоречат Unix way
A>а собственно почему? A>ведь это внутренние данные приложения, а не конфигурационный файл.
WF>>По-моему, что-нибудь вроде формата record-jar будет самое оно (http://www.faqs.org/docs/artu/ch05s02.html#id2906931)
A>ИМХО, избыточный формат для наших целей. более того возможны ошибки при его использоваии, так как он резервирует некоторые последовательности символов.
Ну как обычно, \ испоьзуется в качестве эскейп-символа.
Здравствуйте, WFrag, Вы писали:
WF>>>По-моему, что-нибудь вроде формата record-jar будет самое оно (http://www.faqs.org/docs/artu/ch05s02.html#id2906931)
A>>ИМХО, избыточный формат для наших целей. более того возможны ошибки при его использоваии, так как он резервирует некоторые последовательности символов.
WF>Ну как обычно, \ испоьзуется в качестве эскейп-символа.
и получается что надо всеь текст при приеме просканировать на предмет наличия эскейп-последовательностй... зачем?
Здравствуйте, Demiurg, Вы писали:
D>Здравствуйте, ironwit, Вы писали:
D>>> Ну так что — народ в самом деле собирается всерьез браться за проект? Интересно... Будем следить за событиями I>>ИМХО название это еще не работа... хотя я тоже следить буду Может чем и помогу... смотря на чем писать будут...
D> Только не шарп, только не шарп...
лучше С конечно.. сразу буду всех доставать вопросами "а как сделать это?"
... << RSDN@Home 1.1.4 beta 7 rev. 474>>
играет судя по всему — работаю ибо тишина.
.
M>Пока на руках нет, с чем работать, можно поразмышлять теоретически. Так сказать, устроить мозговой штурм сейчас, чем мучиться потом.
Согласен. M>Дальше идут ламерские размышлния, основанные на моем незнании предметной области
M>Итак, мы планируем демона, который будет способен отдавать данные любым клиентам, так? Пусть они будут написаны хоть на С++, хоть на Яве, хоть на Лиспе.
Хотелось бы M>Тогда сразу возникает вопрос — как их отдавать?
Sheridan что-то говорил насчёт filestream'a но я лучше в эту степь не буду лезть.
M>Просто двоичные данные отдать не удастся, как я понимаю, так? Вернее можно, но выдачу над все равно каким-нибудь образом стандартизировать. Ы?
Хм. Предлагаю пока просто сделать какой-либо набор RPC функций которые будут выдавать C++ приложению память класса: ветки, сообщения, конфига чёго там ещё. Что-то типа COM и маршаллинга. M>Надо начать думать о структуре сообщений между демоном и клиентами.
M>И вообщ начинать думать
... << А писал я этот бред на RSDN@Home 1.1.4 beta 7 rev. 447, под звуки тишины>>
M>>Итак, мы планируем демона, который будет способен отдавать данные любым клиентам, так? Пусть они будут написаны хоть на С++, хоть на Яве, хоть на Лиспе. MC>Хотелось бы M>>Тогда сразу возникает вопрос — как их отдавать?
MC>Sheridan что-то говорил насчёт filestream'a но я лучше в эту степь не буду лезть.
Я тоже Просто не уверен, что файлстримы с легкостью можно будет вытянуть из других языков/программ (а вдруг я плагин к файрфокс захочу написать? )
M>>Просто двоичные данные отдать не удастся, как я понимаю, так? Вернее можно, но выдачу над все равно каким-нибудь образом стандартизировать. Ы? MC>Хм. Предлагаю пока просто сделать какой-либо набор RPC функций которые будут выдавать C++ приложению память класса: ветки, сообщения, конфига чёго там ещё. Что-то типа COM и маршаллинга.
Ээээ.
Я тут буквально сегодня вспомнил о том, как данные сериализуются в РНР. Формат примерно такой (сорри за кривой EBNF):
Оверхед по сравнению с тем же XML минимальный, а если это дело за-gzip-ить... Десериализация тоже несложная, в крйнем случае можно будет прямо из сырцов РНР вытянуть И, как оказалось, даже MIME-type для этого дела есть.
M>Оверхед по сравнению с тем же XML минимальный, а если это дело за-gzip-ить...
Не понимаю, почему бы не взять старый добрый XML?
Нафига один текстовый формат заменять на другой?
Слава богу XML понимают уже все, да и перетащить по локальной сетке несколько десятков килобайт никому не больно.
HD>Не понимаю, почему бы не взять старый добрый XML? HD>Нафига один текстовый формат заменять на другой? HD>Слава богу XML понимают уже все, да и перетащить по локальной сетке несколько десятков килобайт никому не больно.
Это, в принципе, зависит от того, сколько данных мы будем перегонять. Сама по себе работа с XML мне жутко не нравится. Там еще и оверхед такой иногда, что уууу... Никакой сетки не хватает. У меня сейчас на компьютере крутится. Решил на свою голову передавать данные ХМЛем. Единичные запросы — без проблем, уходят и почти не чуствуются вполне внушительные запросы.
Но когда надо подряд отдать пару десятков даже мелких запросов или запрос состоящий, например, из сотни элементов — уууу. Сервак гыр-гыр, сетка вжик-вжик, клиент "мама, не дайте мне повиснуть" Не спорю, фактор кривых ручек присутствует, но, имхо, не очень большой.
Самый смак начинается, когда клиент из всего этого дела список начинает составлять... Беготня по DOM'у длится довольно долго.
Здравствуйте, Mamut, Вы писали:
M>Самый смак начинается, когда клиент из всего этого дела список начинает составлять... Беготня по DOM'у длится довольно долго.
Это все понятно, текстовое представление оно всегда предразумевает некоторые проблемы с обработкой.
Просто я не понимаю к чему брать какой то экзотический формат, который также является по сути дела "XML" но хитро форматированный? Или ты думаешь что пара тысяч рекордов "закодированная" в виде
будет шустрее десериализоваться, меньше тереть диском или на худой конец лучше паковаться в зип чем теже данные в виде XML?
К чему я все веду то... если брать "текстовый" формат для передачи данных то по компатибельности ничего лучше XML нет. Если не текстовый, то это уже не является темой этой дискуссии.
Но это мое IMHO.
Как там говориться... каждый человек сам себе злой буратино ?
Здравствуйте, HotDog, Вы писали:
HD>К чему я все веду то... если брать "текстовый" формат для передачи данных то по компатибельности ничего лучше XML нет.
А если не текстовый, то реализовывать все равно лучше что то стандартное, а не самопал.
HD>>К чему я все веду то... если брать "текстовый" формат для передачи данных то по компатибельности ничего лучше XML нет.
AVK>А если не текстовый, то реализовывать все равно лучше что то стандартное, а не самопал.
Вот так всегда. Хочешь сделать велосипед, а придут злые дяди и скажут — низзя
Ладно. Типа определились. Пусть будет ХМЛ (еще бы мнение Шеридана услышать).
Надо думать дальше. Что именно и как мы будем передавать. То есть начинать думать над структурой коммуникаций. Начало здесь
Здравствуйте, Mamut, Вы писали:
AVK>>А если не текстовый, то реализовывать все равно лучше что то стандартное, а не самопал.
M>Вот так всегда. Хочешь сделать велосипед, а придут злые дяди и скажут — низзя
M>Ладно. Типа определились. Пусть будет ХМЛ (еще бы мнение Шеридана услышать).
Если мы говорим об обмене демона и клиента, то зачем тут XML? кто-нибудь может объяснить?
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 поднимать/сохранять. Не знаю, правда, его фич и насколько он гибок.
M>>QDom в Qt очень медленный. Как-никак, на каждый элемент создается по QDomElement, да еще с постоянными кастами из QDomNode в QDomElement и обратно Не знаю, может в 4-ой там чуть изменилось это дело. Правда, я ихнюю имплементацию SAX руками не трогал (QXmlSimpleReader).
WF>ИМХО, работать руками что через DOM, что через SAX — слишком низкоуровневое занятие. Я бы в такой ситуации поискал маппинг XML->объекты Вот, например, boost::serialization вроде умеет XML поднимать/сохранять. Не знаю, правда, его фич и насколько он гибок.
Тут надо сразу разделиться. Демону такая обработка XML не нужна — по вполне понятным причинам. Но она, возможно, может понадобиться клиенту. Буст... Не знаю, не знаю. Половина РСДН им пользуется и нарадоваться не может. Надо будет пощупать....
Не надо забывать о том, что Шеридан категорически против ХМЛя, настаивая на сериализации напрямую в поток. Другой вопрос — а можно ли будет безпроблем считать этот поток из других сред — Явы там, Питона...
Здравствуйте, Mamut, Вы писали:
M>>>Шеридан предложил, а я поддеожал идею использовать в этом деле Qt. A>>Согласен на 100%. A>>Компилятор какой? то что GCC понятно, но от какой версии плясать? A>>Например в Fedore 4 стоит уже GCC 4.0.0.8...
Ну вы чего? Нафига так сильно то? Считаю что должно компиляться на 3.3 ну крайняк
3.4. Ибо есть еще FreeBSD та же. Солярки всякие. Зачем же только на линух
ориентироваться?
A>>В какой среде? (KDevelop или из ком.строки) A>>и т.д.
M>ИМХО, не имеет значения. Например, я если и буду участвовать, то буду пользовать VS.NET 2003 Буду ... эээ... windows release manager M>А если серьезно, то под Линухом это, скорее всего, будет gcc + KDevelop.
Может более кардинально подойти? CMake например. Умеет создавать проекты для разных сред в том
числе (вроде) и для KDeveloper. И что интересно и под VC 6/2003. Более того KDE активно его использует. www.cmake.org
M>>>В качестве базы данных — пока неизвестно (скорее всего, firebird, как я понимаю). A>>меня почему-то больше тянет в сторону SQL-Lite M>Меня тоже , но поставляемый с Qt 3.x драйвер поддерживает только SQLite 2, поддержка 3-го появится только в четвертой кути. А человеческих реализаций доступа к SQLite, да еще и кросс-платформенных, и нет (чтобы обернуть их в качестве драйвера). Главный минус скулита — это отсутствие bidirectional cursors (есть только forward курсоры). А всякие fetch_table работают довольно медленно на сколь-нибудь больших объемах данных. Второй минус — это отсутствие человеческого ALTER TABLE.
А зачем подвязываться на конкретную базу? Может быть OTL подойдет. Там хоть на оракле подымай (например на работе на продакшине ).
M>Если первая (главная) проблема может не такая и главная (зависит от имплементации демона), то вторая может стать серьезным препятствием при реструктуризации базы данных большого объема.
+
A>>Может пока просто для одного пользователя сделать. Освои реструктуризатор, gSOAP, сеть, БД. A>>По моему и так уже не плохо для начала. Вроде крутых линуксоидов пока не видно
M>Лучше уж сразу делать по-человечески, имхо. Как я тут где-то уже писал, гуи-часть — это ерунда при условии человеческого демона ("человеческий демон" — этакий оксюморон получился )
+
Здравствуйте, aka50, Вы писали:
A>Ну вы чего? Нафига так сильно то? Считаю что должно компиляться на 3.3 ну крайняк A>3.4. Ибо есть еще FreeBSD та же. Солярки всякие. Зачем же только на линух A>ориентироваться?
Чтоото мешает обновится?
Хотя в принципе согласен...
A>А зачем подвязываться на конкретную базу? Может быть OTL подойдет. Там хоть на оракле подымай (например на работе на продакшине ).
А никто и не будет затачивать под БД... Будем скорее всего следовать какому либо стандарту sql — томуже sql92 к примеру. А от бд я изначально предлагал абстрагироватся.
Кстати есть предложение указывать БД еще при сборке (на #ifdef'ах разрулить) чтоб не терять в скорости...
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, aka50, Вы писали:
A>>Ну вы чего? Нафига так сильно то? Считаю что должно компиляться на 3.3 ну крайняк A>>3.4. Ибо есть еще FreeBSD та же. Солярки всякие. Зачем же только на линух A>>ориентироваться? S>Чтоото мешает обновится?
Если вся система построена 3.4 зачем одну вещь строить 4-кой. К тому же не известно
когда она до stable доживет. Но при этом бонус остается — то что компиляется 3.3/3.4
будет (90%) компиляться и 4-кой. Это как под виндой программу только под например Longhorn
затачивать . Область использование резко сужается.
A>>А зачем подвязываться на конкретную базу? Может быть OTL подойдет. Там хоть на оракле подымай (например на работе на продакшине ). S>А никто и не будет затачивать под БД... Будем скорее всего следовать какому либо стандарту sql — томуже sql92 к примеру. А от бд я изначально предлагал абстрагироватся. S>Кстати есть предложение указывать БД еще при сборке (на #ifdef'ах разрулить) чтоб не терять в скорости...
Дык это OTL и позволяет делать. ИМХО вполне адекватная либа.
1. Похожа на STL
2. Поддерживает достаточно большое количество БД:
The current version of the OTL supports Oracle 7 (natively via OCI7), Oracle 8 (natively via OCI8), Oracle 8i (natively via OCI8i), Oracle 9i (natively via OCI9i), Oracle 10g (natively via OCI10g), DB2 (natively via DB2 CLI), ODBC 3.x as well as ODBC 2.5 compliant data sources in MS Windows and Unix (e.g. Oracle, MS SQL Server, Sybase, MySQL, DB2, Interbase / Firebird, PostgreSQL, SQLite, etc.). The list of supported database backends is constantly growing.
#include <iostream>
using namespace std;
#include <stdio.h>
#define OTL_ODBC_MYSQL // Compile OTL 4/MyODBC
// #define OTL_ODBC_UNIX // uncomment this line if UnixODBC is used#include <otlv4.h> // include the OTL 4 header file
otl_connect db; // connect objectvoid select()
{
otl_stream i(1, // buffer size"select * from test_tab",
// SELECT statement
db // connect object
);
// create select stream
otl_column_desc* desc;
int desc_len;
desc=i.describe_select(desc_len);
for(int n=0;n<desc_len;++n){
cout<<"========== COLUMN #"<<n+1<<" ==========="<<endl;
cout<<"name="<<desc[n].name<<endl;
cout<<"dbtype="<<desc[n].dbtype<<endl;
cout<<"otl_var_dbtype="<<desc[n].otl_var_dbtype<<endl;
cout<<"dbsize="<<desc[n].dbsize<<endl;
cout<<"scale="<<desc[n].scale<<endl;
cout<<"prec="<<desc[n].prec<<endl;
cout<<"nullok="<<desc[n].nullok<<endl;
}
}
int main()
{
otl_connect::otl_initialize(); // initialize ODBC environmenttry{
db.rlogon("uid=scott;pwd=tiger;dsn=mysql"); // connect to ODBC
otl_cursor::direct_exec
(
db,
"drop table test_tab",
otl_exception::disabled // disable OTL exceptions
); // drop table
otl_cursor::direct_exec
(
db,
"create table test_tab(f1 int, f2 varchar(30), f3 text)"
); // create table
select(); // select records from table
}
catch(otl_exception& p){ // intercept OTL exceptions
cerr<<p.msg<<endl; // print out error message
cerr<<p.stm_text<<endl; // print out SQL that caused the error
cerr<<p.var_info<<endl; // print out the variable that caused the error
}
db.logoff(); // disconnect from ODBCreturn 0;
}
Здравствуйте, aka50, Вы писали:
A>Если вся система построена 3.4 зачем одну вещь строить 4-кой. К тому же не известно A>когда она до stable доживет. Но при этом бонус остается — то что компиляется 3.3/3.4 A>будет (90%) компиляться и 4-кой. Это как под виндой программу только под например Longhorn A>затачивать . Область использование резко сужается.
Ок, согласен. Раз 4ка не стабл занчит делать со стаблем.
A>Дык это OTL и позволяет делать. ИМХО вполне адекватная либа. A>1. Похожа на STL A>2. Поддерживает достаточно большое количество БД:
Бесплатна ? пости линк в БД
Здравствуйте, Sheridan, Вы писали:
S>А никто и не будет затачивать под БД... Будем скорее всего следовать какому либо стандарту sql — томуже sql92 к примеру. Это утопия.
A>>Дык это OTL и позволяет делать. ИМХО вполне адекватная либа. A>>1. Похожа на STL A>>2. Поддерживает достаточно большое количество БД: S>Бесплатна ? пости линк в БД
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, HotDog, Вы писали:
HD>>К чему я все веду то... если брать "текстовый" формат для передачи данных то по компатибельности ничего лучше XML нет.
AVK>А если не текстовый, то реализовывать все равно лучше что то стандартное, а не самопал.
+
Здравствуйте, Sheridan, Вы писали:
S>АВК, ну хотябы сказал чтонибудь... А то улыбаешся загадочно както... Интересно всетаки и тебя былобы послушать. Проект в стадии задумки и на этой стадии имхо важны всетаки мнения Старших Или ты нехочеш переносить янус в линукс?
Лично моя улыбка за эту чущь:
шарп недолюбливаю изза того что оно всетаки интерпритатор
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
S>>АВК, ну хотябы сказал чтонибудь... А то улыбаешся загадочно както... Интересно всетаки и тебя былобы послушать. Проект в стадии задумки и на этой стадии имхо важны всетаки мнения Старших
AVK>А я уже говорил — не сделаете вы его. Если бы вы делали на mono или Java, да не трехзвенку, а обычного клиента, то небольшие шансы еще были бы. А так их 0 с минусом.
Не, ну, если им постоянно напоминать, что они его не сделают, то глядишь что-то они да сделают. Вот только можно ли будет этим полноценно пользоваться и насколько это чудо сможет развиваться?
В общем, согласен, что куда проще было бы перетащить Янус под Моно или переписать на Яве. А это все баловство.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sheridan, Вы писали:
ехидным "ню-ню"...
S>Ну так поправь. Что есть ассембли?
Давай я поправлю.
Если не хочешь выглядить шутом гороховым, то просто не трепись о том, в чем вообще ничего не понимашь. На этом сайте информации о производительности дотнета и том, что в нем применяется JIT-компиляция море. Зайди в раздел статей по дотнету... Сделай поиск по форумам. Глядишь в следущющий раз никто смеяться не будет.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sheridan, Вы писали:
MC>>Да и то, вроде-бы IL компилируеться в машинный код в первый запуск. S>угу, и во второй и в 3й... строчечка за строчечкой..
Если твои познания в С++ столь же глубоки, то этот проект ждет бльшое будущее... вот в этом форуме.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В общем, согласен, что куда проще было бы перетащить Янус под Моно или переписать на Яве. А это все баловство.
Тоесть знание серьезного языка и написание на ем софта — баловство? Нет я понимаю что шарпы с явами и дотнетом это простА крутА, эта вааапче паааследнее слово науки и техники. Можете назвать меня старым маразматиком но я не вижу крутизны. Я понимаю что ява кроссплатформена и дотнет в принципе тоже кроссплатформен, но меня никогда не убедиш что это будет работать быстрее бинарника. Да, можно конечно и часто бывает что написанный деревянной головой софт на с++ тормозит неподетски, но я всетаки надеюсь что гуру нам будут помогать всетаки хотябы советом. К томуже профилеры не простотак придуманы. Можете назвать меня велосипедистом но я не хочу цеплять какуюто либу дабы вытянуть оттуда 2-3 функции. Как вы думаете почему сейчас растет размер софта? Да именно поэтому. Вспомните хотябы софт пяти-шестилетней давности не говоря уже про софт 92-95 годов. Да, древний. Но по большой части чем оно отличается? Рюшечками в основном. А свою работу делает.
Не обижайтесь но наболело. Тяжко видеть когда напишут на делфях всяких очередной нотепад а он 18 с копейками мегабайт весит. И не хочу я ставить чтотоеще дабы иметь возможность запустить софтину. Программа должна разархивироватся и запускацца а не расскладывать вокруг себя подушки перед стартом.
Смешно — смейтесь. Смех он жизнь продлевает, и это хорошо. Может через десяток лет и сам посмеюсь. Но покачто наоборот плакать хочется...
Здравствуйте, VladD2, Вы писали:
AVK>>А если не текстовый, то реализовывать все равно лучше что то стандартное, а не самопал. VD>Вот только нахрен здесь не текстовый если основной объем занимает текст сообщения и заголовок?
Здравствуйте, Sheridan, Вы писали:
S>Тяжко видеть когда напишут на делфях всяких очередной нотепад а он 18 с копейками мегабайт весит.
За больной мозоль тебе прочерк. Не в Дельфях счастье, а в ейных передовых на то время технологиях.
S> И не хочу я ставить чтотоеще дабы иметь возможность запустить софтину. Программа должна разархивироватся и запускацца а не расскладывать вокруг себя подушки перед стартом.
Наличие операционной системы и всякой хрени железной и мягкой тебя при этом не напрягает. А необходимость качать и ставить пакеты считается нормальным. А я вот хочу иметь 1 (один) CD или DVD, позволявший мне развернуть рабочую конфигурацию на любом (*) компьютере в приемлемое время в N минут.
* — в разумных пределах, для "IBM-совместимых".
Короче, дело всё в том, что Майкрософт, зная сырость первых версий дотнета, побоялся дефолтом ставить в WinXP дотнет 1.0 на пользовательский компьютер, хотя и включил его на установочный диск. Тот же directx и ADO — не побоялся.
Шеридан, ты ведь недавно стал инженером, у тебя ещё бурлит кровь, а мозги не забиты всяким дерьмом, позволяя тебе думать, что ты в состоянии переделать любой велосипед. Я был таким. Что-то даже сделал.
Счастье — оно не только в велосипедировании, оно и в умении складывать кубики. Детская такая игра, для младенцев. Говорят, они гораздо умнее и гораздо счастливее в то время.
Ты думаешь, что стал взрослее со вступлением в инженеры? Нет, ты стал жестянщиком. И твоё стремление набить собственные шишики на уже заживших у нас местах тому порука...
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, VladD2, Вы писали:
VD>>В общем, согласен, что куда проще было бы перетащить Янус под Моно или переписать на Яве. А это все баловство.
S>Тоесть знание серьезного языка и написание на ем софта — баловство?
Знание не баловство. Баловство пытаться создать открытый проект на совсем общественных началах, без особой необходимости, с наполеоновскими замашками, и на средствах которые в описанных условиях приведут к усложнению проетка и куче багов.
S> Нет я понимаю что шарпы с явами и дотнетом это простА крутА, эта вааапче паааследнее слово науки и техники. Можете назвать меня старым маразматиком но я не вижу крутизны.
А нет крутизны. Есть набор характеристик резко упрощающих создание проектов разнородным коллективом содержащим как опытных программистов так и множество скажем так не очень поытных.
S> Я понимаю что ява кроссплатформена
Именно. По тому я солидарен с АВК, что это был бы разумный выбор для создания потрируемой версии Януса.
S> и дотнет в принципе тоже кроссплатформен,
К сожалению больше в принципе. Боюсь, что перенос на ГТК потребует не мло времени, но все же меньше чем создание такого проекта с нуля.
S> но меня никогда не убедиш что это будет работать быстрее бинарника.
Это от недостатка информации и нежелания ее пополнить. Да вам и нужно быстрее. Вам нужно с приемлемой скоростью. По сикрету скажу, что все тормоза Януса упираются в "бинарный" Jet. Ну, да это уже очень старая песня.
К тому же я даже не обсуждаю скоростные характиристики. Я говорю о принципиальной возможности реализации этого проекта такими средствами, такими силами и при такой организации.
Я даже не сомневаюсь, что если за проект сядут орлы из топа плюсового форума, возмут в команду хороших проектировщиков, потратят пол года своего времени и т.п., то получится очень неплохой продукт который даже возможно чем-то будет лучше Хоума. Но вот в то, что это случится я не то что бы не верю. Я уверен в том, что это не случится. И не помту что С++ так плох. Просто такое количество факторов принципиально не собрать в открытом бесплатном проекте.
S> Да, можно конечно и часто бывает что написанный деревянной головой софт на с++ тормозит неподетски, но я всетаки надеюсь что гуру нам будут помогать всетаки хотябы советом.
Расстрою тебя. Они скорее еще пару недель проведут во флэйме С++ вс. Ххх# .
S> К томуже профилеры не простотак придуманы. Можете назвать меня велосипедистом но я не хочу цеплять какуюто либу дабы вытянуть оттуда 2-3 функции.
Можем. Но дело даже не в этом. Ты просто убъешь все время на разработку собственных "либ".
S> Как вы думаете почему сейчас растет размер софта?
Видимо объем кода прибавляется. В общем, меня это не трогает. У меня два винта по 160 гиг и 256-килобитный интернет. Дистрибьютив же януса занимает 1-2 метра.
S> Да именно поэтому. Вспомните хотябы софт пяти-шестилетней давности не говоря уже про софт 92-95 годов. Да, древний. Но по большой части чем оно отличается? Рюшечками в основном. А свою работу делает.
Вспомнил. в 95 году я ставил Вынь 95 с 25 дискет (если не ошибаюсь). Через год с одного CD. Давича ставил XP 64-бит с одного сидюка. Разницы не ощутил. Через год буду ставить Лонгхорн с одного DVD и снова мне будет по барабану.
S>Не обижайтесь но наболело. Тяжко видеть когда напишут на делфях всяких очередной нотепад а он 18 с копейками мегабайт весит. И не хочу я ставить чтотоеще дабы иметь возможность запустить софтину. Программа должна разархивироватся и запускацца а не расскладывать вокруг себя подушки перед стартом. S>Смешно — смейтесь. Смех он жизнь продлевает, и это хорошо. Может через десяток лет и сам посмеюсь. Но покачто наоборот плакать хочется...
Я вообще не понял к чему вся эта аргументация. Проблем в размере дистрибьютива Януса нет. Вы затеяли ЛунуксоЯнус не ради уменьшения размера дистрибютива. Не так ли? Вы хотите создать переносимую версию. Ну, так что обсуждать производительность и размеры дистрибьютивов?
Мы с АВК сомневаемся не в характиристиках, а в том, что вы вообще что-то путное сделать сможете. Вы недооцениваете объем работы. Более того вы мечтаете о каких-то малонужных вещах даже не задумываясь над созданием хотя бы базовой реализации. Ну, а когда это все умножится на объем глюков проект просто рассыпится.
Я не буду уговаривать вас поступать так как вам говорит АВК (хотя он говорит разумные вещи). Делайте все так как делаете. Тем будет интереснее.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Sheridan, Вы писали:
AVK>>>А если не текстовый, то реализовывать все равно лучше что то стандартное, а не самопал. VD>>Вот только нахрен здесь не текстовый если основной объем занимает текст сообщения и заголовок?
S>std::string?
25
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Rebus83, Вы писали:
R>> Где можно посмотреть, как сейчас Янус взаимодействет с сервером?
Смотрю я на описание WSDL и очень удивяюсь этому:
<s:element minOccurs="0" maxOccurs="1" name="msgIds">
<s:complexType>
<s:sequence>
<s:element ref="s:schema"/>
<s:any/>
</s:sequence>
</s:complexType>
</s:element>
И не пониаю, как посылать msgIds. Посмотрель в сниффере И вижу вот такой ужас:
<xs:schema id="NewDataSet">
<xs:element name="NewDataSet" msdata:IsDataSet="true" msdata:Locale="ru-RU">
<xs:complexType> и тд...
Пытаюсь, откуда всё это? В WSDL описаниее этого нет, хотя веб-сервис должен полностью им описоваться.
Посмотрел исходники( с очень скудными комментариями(()
req.subscribedForums = DatabaseManager.GetSubscribedForums(true);
Но вот что за <diffgr:diffgram> до сих пор понять не могу Может кто-нить объяснить из Создателей
И ещё вопрос: что такое ratingRowVersion, forumRowVersion, lastRatingRowVersion и тд
Здравствуйте, krum1, Вы писали:
K>Но вот что за <diffgr:diffgram> до сих пор понять не могу Может кто-нить объяснить из Создателей
Формат сериализации в ХМЛ датасета. Его исходники есть на Шарпе. Формат в общем-то довольно простой. Повторить можно.
K>И ещё вопрос: что такое ratingRowVersion, forumRowVersion, lastRatingRowVersion и тд
Если не ошибаюсь версии последней скаченной записи. При синхронизации они отправляются на сервер, чтобы тот отфильтровал все более старые записи. Ну, чтобы не качать все от забора.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, krum1, Вы писали:
K>>Но вот что за <diffgr:diffgram> до сих пор понять не могу Может кто-нить объяснить из Создателей
VD>Формат сериализации в ХМЛ датасета. Его исходники есть на Шарпе. Формат в общем-то довольно простой. Повторить можно.
Вопрос: зачем???? Я конечно понимаю, что формат простой, и сделать можно хоть реактивный велосипед, но зачем?
Некошерно получается Хм... можно самлму дописать wsdl и скормить уго wsdl2java
Здравствуйте, krum1, Вы писали:
K>Вопрос: зачем???? Я конечно понимаю, что формат простой, и сделать можно хоть реактивный велосипед, но зачем?
За тем, что так было проще. Датасет уеж есть. Оставалось засунуть его в сервис и принять на второй стороне. Кросплатформность была не нужна.
K>Некошерно получается Хм... можно самлму дописать wsdl и скормить уго wsdl2java
Гы. Ты ветки внимательно читал? Это Ява не кошерно. Тут народ серьезный. Без подготовки серьезный проект не начент. Вот сейчас свой протокол сбацают. Потом линукс мальца подправят, а потом все перепишут на плюсах. А Ява — это для неудачников.
Ну, а датасет... Да какая разница как солнце в ручную закатывать... на С++ то?
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
С другой стороны, есть идея использовать сочетание Axis+Castor, тем более что схема для any все-таки есть, только она в рантайме передается. Возможно, это сочетание позволит сделать вызов сервиса более прозрачным (хочется чистого и прозрачного декларативного описания маппинга).
В общем, сильно близко к сердцу не принимай. Наверняка можно качественно улучшить.
Здравствуйте, Sheridan, Вы писали:
S>Тоесть знание серьезного языка и написание на ем софта — баловство? Нет я понимаю что шарпы с явами и дотнетом это простА крутА, эта вааапче паааследнее слово науки и техники.
Нет, все наоборот. Баловство — это как раз шарпы с дотнетом. Потому как на них можно эдак балуясь, в свободное от работы время собрать проект типа RSDN@Home.
А плюсы — это как раз круто и хардкор. Особенно если игнорировать готовые библиотеки, изобретать свои транспортные форматы, делать многопотоковый персистентный сторадж...
Я совершенно уверен, что таким способом можно создать шедевр. Он будет летать (точнее, работать на несколько процентов быстрее .Net — версии — ребята, плюсы не заставят ваш винт крутиться быстрее. Не надо думать, что аксесс писали уж совсем идиоты.), он будет занимать меньше памяти и места на диске.
Вот только человеколет на него уйдет — немеряно. Именно поэтому твой подход встречает такой скепсис. Даже планы написания Offline клиента на 1С и то кажутся более реалистичными.
... << RSDN@Home 1.1.4 beta 5 rev. 395>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Кстати, я тут наткнулся на интересный пакет. Называется RealBASIC здесь
Далее цитата:
Cross-platform compilation
REALbasic Professional Edition lets you create software for Windows, Linux and Macintosh from a single code base. Supported versions are:
Windows 98/NT/ME/2000/XP
Mac OS X and Classic Mac OS X
Any Linux x86 distribution that provides GTK+ 2.0 (or higher),
Glibc-2.3 (or higher) and CUPS (Common UNIX Printing System). This includes:
Red Hat Enterprise 3
SuSE Linux 8.1 (and higher)
Mandrake Linux 9.1 (and higher, including Mandriva)
Extended database support
REALbasic Professional Edition adds the ability to connect to multi-user database servers like Oracle, Microsoft SQL Server, FileMaker Server, MySQL, Sybase, Openbase, Frontbase, 4D Server or any ODBC data source. Note: Microsoft SQL Server ODBC drivers for Mac OS X are available from Actual Technologies.
и т.д.
Я конечно понимаю, что вам легких путей не надо но в общем неплохо, а ?
элемент s:any на схему, которая передается сервисом/клиентом (я ловил Ethereal-ом ). Так как схема не меняется (не часто, по крайней мере), эту операцию нужно сделать один раз. После этого сделать обычный импорт WSDL2xxx.
В общем, меньше дня работы. Ну плюс каждый раз при смене WSDL нужно его допиливать до нужного состояния.
Здравствуйте, Sheridan, Вы писали:
S>Можете назвать меня велосипедистом но я не хочу цеплять какуюто либу дабы вытянуть оттуда 2-3 функции. Как вы думаете почему сейчас растет размер софта? Да именно поэтому.
Remember the Rule of Economy. Re-inventing fire and the wheel for every new project is terribly wasteful. Thinking time is precious and very valuable relative to all the other inputs that go into software development; accordingly, it should be spent solving new problems rather than rehashing old ones for which known solutions already exist. This attitude gives the best return both in the "soft" terms of developing human capital and in the "hard" terms of economic return on development investment.
Reinventing the wheel is bad not only because it wastes time, but because reinvented wheels are often square. There is an almost irresistible temptation to economize on reinvention time by taking a shortcut to a crude and poorly-thought-out version, which in the long run often turns out to be false economy.
—Henry Spencer
The most effective way to avoid reinventing the wheel is to borrow someone else's design and implementation of it. In other words, to reuse code.
Unix supports reuse at every level from individual library modules up to entire programs, which Unix helps you script and recombine. Systematic reuse is one of the most important distinguishing behaviors of Unix programmers, and the experience of using Unix should teach you a habit of trying to prototype solutions by combining existing components with a minimum of new invention, rather than rushing to write standalone code that will only be used once.
The Art of Unix Programming, By Eric Steven Raymond
Chapter 16. Reuse: On Not Reinventing the Wheel
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
It's kind of fun to do the impossible (Walt Disney)
Здравствуйте, Sheridan, Вы писали:
S>Здравствуйте, Mamut, Вы писали:
S>>>и разрулить что надо
M>>А получится?
S>В чем сложность? В разрулении типа данных по первому байту пакета? В чтении из потока? Или Настоящие Программисты must be use xml ибо звучит красиво?
Text streams are a valuable universal format because they're easy for human beings to read, write, and edit without specialized tools. These formats are (or can be designed to be) transparent.
Also, the very limitations of text streams help enforce encapsulation. By discouraging elaborate representations with rich, densely encoded structure, text streams also discourage programs from being promiscuous with each other about their internal states and help enforce encapsulation. We'll return to this point at the end of Chapter 7 when we discuss RPC.
When you feel the urge to design a complex binary file format, or a complex binary application protocol, it is generally wise to lie down until the feeling passes. If performance is what you're worried about, implementing compression on the text protocol stream either at some level below or above the application protocol will give you a cleaner and perhaps better-performing design than a binary protocol (text compresses well, and quickly).
The Art of Unix Programming, By Eric Steven Raymond
5.1 The Importance of Being Textual
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
It's kind of fun to do the impossible (Walt Disney)
S>>Согласен, но не вижу смысла.
A>К тому же для передачи специфичных данных (например тот же FTP) не обязательно использовать текстовый формат.
A>Чего так все уцепились за текстовый формат???
Ну, вон Шеридан против. Я, в принципе, тоже. Народ предлагал ICE использовать.
Здравствуйте, Mr.Chipset, Вы писали:
MC>После разговора с Sheridan'ом прояснились некоторые детали по сабжу. MC>В частности, есть идея разделить RSDN@Linux на две части: MC>1. Драйвер -- синх+драйвер к БД, скажем в виде демона.
Здравствуйте, 0rc, Вы писали:
0rc>Здравствуйте, Mr.Chipset, Вы писали:
MC>>После разговора с Sheridan'ом прояснились некоторые детали по сабжу. MC>>В частности, есть идея разделить RSDN@Linux на две части: MC>>1. Драйвер -- синх+драйвер к БД, скажем в виде демона.
0rc>А где можно скачать драйвер?
нигде, проект оказался не нужен и тихо умер
Здравствуйте, hVostt, Вы писали:
V>Здравствуйте, cencio, Вы писали:
0rc>>>А где можно скачать драйвер? C>>нигде, проект оказался не нужен и тихо умер
V>Mono?
под моно не работает не хватает каких то методов. пробовал на убунту.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, ironwit, Вы писали:
I>>под моно не работает не хватает каких то методов. пробовал на убунту.
AVK>Дело не в методах, а в том что в янусе куча интеропа. Для работы под Моно нужно как минимум переписывать весь интерфейс под GTK#.
пчально. посидел в убунту. ну почти все есть кроме януса и содегира
Здравствуйте, ironwit, Вы писали:
AVK>>Дело не в методах, а в том что в янусе куча интеропа. Для работы под Моно нужно как минимум переписывать весь интерфейс под GTK#. I>пчально. посидел в убунту. ну почти все есть кроме януса и содегира
Поставь Wine, может заработает.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, AndrewVK, Вы писали:
I>>под моно не работает не хватает каких то методов. пробовал на убунту. AVK>Дело не в методах, а в том что в янусе куча интеропа. Для работы под Моно нужно как минимум переписывать весь интерфейс под GTK#.
Кроссплатформенность .NET на лицо А если отрубить поддержку Jet/MSSQL , оставив SQLite, FireBird, тогда потянет? Что там еще может интеропиться..
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, ironwit, Вы писали:
AVK>>>Дело не в методах, а в том что в янусе куча интеропа. Для работы под Моно нужно как минимум переписывать весь интерфейс под GTK#. I>>пчально. посидел в убунту. ну почти все есть кроме януса и содегира
AVK>Поставь Wine, может заработает.
wine сразу гвоорит, что это софт дотнетный и надо пользоватся моно. и вываливается.
Здравствуйте, hVostt, Вы писали:
V>Кроссплатформенность .NET на лицо
А ты используй в Java JNI, и посмотришь, какой она обладает кроссплатформенность. Кроссплатформенным софт сам по себе нигде не получается, если не прилагать для этого специальных усилий.
V> А если отрубить поддержку Jet/MSSQL , оставив SQLite, FireBird, тогда потянет?
Нет.
V> Что там еще может интеропиться..
UI прежде всего.
... << RSDN@Home 1.2.0 alpha rev. 725 on Windows Vista 6.0.6000.0>>
Здравствуйте, Mamut, Вы писали:
V>>Кроссплатформенность .NET на лицо А если отрубить поддержку Jet/MSSQL , оставив SQLite, FireBird, тогда потянет? Что там еще может интеропиться..
M>Internet Explorer для отображения сообщений. И как там ситуация с WinForms в Mono?
Черт, да, совсем про IE забыл. Тогда никак даже теоретически. Жаль что так привязались к платформе.
А WinForms 2.0 полет нормальный. Глюков на базовых ситациях не замечено. Хотя были жалобы.
Здравствуйте, AndrewVK, Вы писали:
V>>Кроссплатформенность .NET на лицо AVK>А ты используй в Java JNI, и посмотришь, какой она обладает кроссплатформенность. Кроссплатформенным софт сам по себе нигде не получается, если не прилагать для этого специальных усилий.
Если к платформе не привязываться, или заранее об этом позаботиться, мне кажется можно.
Oracle клиент, Eclipse, хорошие монстрообразные тому примеры.
V>> А если отрубить поддержку Jet/MSSQL , оставив SQLite, FireBird, тогда потянет? AVK>Нет.
V>> Что там еще может интеропиться.. AVK>UI прежде всего.
Прежде всего отвязаться от IE. Хотя понимаю что в данном случае это бред.
V>>>Кроссплатформенность .NET на лицо А если отрубить поддержку Jet/MSSQL , оставив SQLite, FireBird, тогда потянет? Что там еще может интеропиться.. M>>Internet Explorer для отображения сообщений. И как там ситуация с WinForms в Mono? V>Черт, да, совсем про IE забыл. Тогда никак даже теоретически. Жаль что так привязались к платформе.
Здравствуйте, hVostt, Вы писали:
V>>> Что там еще может интеропиться.. AVK>>UI прежде всего. V>Прежде всего отвязаться от IE. Хотя понимаю что в данном случае это бред.
"Всё что не убивает нас, делает нас сильнее..."
Может, какой-нить EBML? 
Что-то подумалось. Может, надо ... эээ ... абстрагироваться от понятий "список форумов", "список сообщений", а оставить просто "иерархический список (jagged aray?)"(список топиков в форуме, например), "плоский список"(например, список форумов) и "текстовая информация" (например, инфа про пользователя, тело сообщения)? Таким образом можно отсылать клиенту просто что-нибкдь типа
Мы уже победили, просто это еще не так заметно...
