Здравствуйте, ironwit, Вы писали:

I>Здравствуйте, Mr.Chipset, Вы писали:

MC>>Привет всем!
I>тут подумалось... (в свете моего тоже перехода в линукс ) — может начать писать смотрелку которая будет брать данные для просмотра из аццесс БД (стандартной янусовой) и демона, который уже будет наполнять данными какие то БД конфигурируемые (mysql, FB..)?

I>З.Ы.
I>следую чисто шкурному интересу — могу синхронизировать на работе из под виндовс, а смотрел бы с удовольствием из линукса

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

Здравствуйте, Demiurg, Вы писали:

D>Здравствуйте, Mamut, Вы писали:

M>>Предлагаю следующее:

M>>Общий проект (демон+смотрелка) назвать Cornucopia (рог изобилия )
M>>Демона назвать Daimon

Автор: Mamut
Дата: 18.06.05

(полон знаний, связь между людьми и богами)
M>>Смотрельщика назвать Fontus

Автор: Mr.Chipset
Дата: 18.06.05

(сын Януса)

M>>На идею натолкнул БСС

Автор: БСС
Дата: 18.06.05

D> Ну так что — народ в самом деле собирается всерьез браться за проект? Интересно... Будем следить за событиями
ИМХО название это еще не работа... хотя я тоже следить буду Может чем и помогу... смотря на чем писать будут...

Здравствуйте, Mr.Chipset, Вы писали:

D>> Ну так что — народ в самом деле собирается всерьез браться за проект? Интересно... Будем следить за событиями

MC>Собираемся, собираемся..
MC>Ждём КуТю и Шеридана

Мне лично проект интересен из-за qt, а Линукс совсем нет (KDEvelop совсем не радует...) Будет время — посмотрим как сложится

Здравствуйте, WFrag, Вы писали:

D>> Ну так что — народ в самом деле собирается всерьез браться за проект? Интересно... Будем следить за событиями

WF>А тем временем, вышла ноль-ноль-первая версия вражеского проекта Forview! http://gzip.rsdn.ru/Forum/Message.aspx?mid=1233832&only=1

Автор: WFrag
Дата: 21.06.05

Плодятся проекты Здоровая конкуренция — это же хорошо

Здравствуйте, ironwit, Вы писали:

D>> Ну так что — народ в самом деле собирается всерьез браться за проект? Интересно... Будем следить за событиями
I>ИМХО название это еще не работа... хотя я тоже следить буду Может чем и помогу... смотря на чем писать будут...

Только не шарп, только не шарп...

Что-то мне подумалось... Перечитал вот эту подветку

Автор: Mamut
Дата: 15.06.05

.

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

Дальше идут ламерские размышлния, основанные на моем незнании предметной области

Итак, мы планируем демона, который будет способен отдавать данные любым клиентам, так? Пусть они будут написаны хоть на С++, хоть на Яве, хоть на Лиспе. Тогда сразу возникает вопрос — как их отдавать?

Просто двоичные данные отдать не удастся, как я понимаю, так? Вернее можно, но выдачу над все равно каким-нибудь образом стандартизировать. Ы?

Надо начать думать о структуре сообщений между демоном и клиентами.

И вообщ начинать думать

Здравствуйте, Mamut, Вы писали:

M>Просто двоичные данные отдать не удастся, как я понимаю, так? Вернее можно, но выдачу над все равно каким-нибудь образом стандартизировать. Ы?

Двоичные данные противоречат Unix way

По-моему, что-нибудь вроде формата record-jar будет самое оно (http://www.faqs.org/docs/artu/ch05s02.html#id2906931)

Я, правда, не совсем понял обязанности вашего демона...

M>>Просто двоичные данные отдать не удастся, как я понимаю, так? Вернее можно, но выдачу над все равно каким-нибудь образом стандартизировать. Ы?

WF>Двоичные данные противоречат Unix way

Ну или gzip'нутые текстовые Просто текст гонять по сетке будет накладно.

WF>По-моему, что-нибудь вроде формата record-jar будет самое оно (http://www.faqs.org/docs/artu/ch05s02.html#id2906931)

WF>Я, правда, не совсем понял обязанности вашего демона...

Сервис, синхронизирующийся с РСДНом, получающий оттуда и отправляющий туда данные. Только сервис, с которым могут общаться клиенты. Вроде как здесь

Автор: Mamut
Дата: 15.06.05

Здравствуйте, WFrag, Вы писали:

WF>Здравствуйте, Mamut, Вы писали:

M>>Просто двоичные данные отдать не удастся, как я понимаю, так? Вернее можно, но выдачу над все равно каким-нибудь образом стандартизировать. Ы?

WF>Двоичные данные противоречат Unix way

а собственно почему?
ведь это внутренние данные приложения, а не конфигурационный файл.

WF>По-моему, что-нибудь вроде формата record-jar будет самое оно (http://www.faqs.org/docs/artu/ch05s02.html#id2906931)

ИМХО, избыточный формат для наших целей. более того возможны ошибки при его использоваии, так как он резервирует некоторые последовательности символов.

Здравствуйте, avbochagov, Вы писали:

WF>>Двоичные данные противоречат Unix way

A>а собственно почему?
A>ведь это внутренние данные приложения, а не конфигурационный файл.

Я под впечатлением этой главы: http://www.faqs.org/docs/artu/textualitychapter.html



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> Только не шарп, только не шарп...
лучше С конечно.. сразу буду всех доставать вопросами "а как сделать это?"

Здравствуйте, Mamut, Вы писали:

M>Что-то мне подумалось... Перечитал вот эту подветку

Автор: Mamut
Дата: 15.06.05

.

M>Пока на руках нет, с чем работать, можно поразмышлять теоретически. Так сказать, устроить мозговой штурм сейчас, чем мучиться потом.
Согласен.
M>Дальше идут ламерские размышлния, основанные на моем незнании предметной области

M>Итак, мы планируем демона, который будет способен отдавать данные любым клиентам, так? Пусть они будут написаны хоть на С++, хоть на Яве, хоть на Лиспе.
Хотелось бы
M>Тогда сразу возникает вопрос — как их отдавать?

Sheridan что-то говорил насчёт filestream'a но я лучше в эту степь не буду лезть.

M>Просто двоичные данные отдать не удастся, как я понимаю, так? Вернее можно, но выдачу над все равно каким-нибудь образом стандартизировать. Ы?
Хм. Предлагаю пока просто сделать какой-либо набор RPC функций которые будут выдавать C++ приложению память класса: ветки, сообщения, конфига чёго там ещё. Что-то типа COM и маршаллинга.
M>Надо начать думать о структуре сообщений между демоном и клиентами.

M>И вообщ начинать думать

M>>Итак, мы планируем демона, который будет способен отдавать данные любым клиентам, так? Пусть они будут написаны хоть на С++, хоть на Яве, хоть на Лиспе.
MC>Хотелось бы
M>>Тогда сразу возникает вопрос — как их отдавать?

MC>Sheridan что-то говорил насчёт filestream'a но я лучше в эту степь не буду лезть.

Я тоже Просто не уверен, что файлстримы с легкостью можно будет вытянуть из других языков/программ (а вдруг я плагин к файрфокс захочу написать? )

M>>Просто двоичные данные отдать не удастся, как я понимаю, так? Вернее можно, но выдачу над все равно каким-нибудь образом стандартизировать. Ы?
MC>Хм. Предлагаю пока просто сделать какой-либо набор RPC функций которые будут выдавать C++ приложению память класса: ветки, сообщения, конфига чёго там ещё. Что-то типа COM и маршаллинга.

Ээээ.

Я тут буквально сегодня вспомнил о том, как данные сериализуются в РНР. Формат примерно такой (сорри за кривой EBNF):

serialize string = checksum ["::" identified_data [identified_data ...]]
identified_data = data | array_data
data = data_id ":" length ":" data ";"
array_data = array_id ":" element_count ":" "{" identified_data [ identified_data...] "}"
array_id = "a"
data_id = "s" | "i" | "d"...

Где i — integer, d — double, s — string, a — array и так далее

То бишь, выглядит это так:

af5226de830e766f03beac50bf63034c::a:4:{s:6:"extKey";s:7:"tt_news";s:7:"EM_CONF";a:26:{s:5:"title";s:4:"News";...

Примеры можно посмотреть здесь.

Оверхед по сравнению с тем же XML минимальный, а если это дело за-gzip-ить... Десериализация тоже несложная, в крйнем случае можно будет прямо из сырцов РНР вытянуть И, как оказалось, даже MIME-type для этого дела есть.

Здравствуйте, Mamut, Вы писали:

M>То бишь, выглядит это так:
M>

M>af5226de830e766f03beac50bf63034c::a:4:{s:6:"extKey";s:7:"tt_news";s:7:"EM_CONF";a:26:{s:5:"title";s:4:"News";...
M>

M>Оверхед по сравнению с тем же XML минимальный, а если это дело за-gzip-ить...

Не понимаю, почему бы не взять старый добрый XML?
Нафига один текстовый формат заменять на другой?
Слава богу XML понимают уже все, да и перетащить по локальной сетке несколько десятков килобайт никому не больно.

HD>Не понимаю, почему бы не взять старый добрый XML?
HD>Нафига один текстовый формат заменять на другой?
HD>Слава богу XML понимают уже все, да и перетащить по локальной сетке несколько десятков килобайт никому не больно.

Это, в принципе, зависит от того, сколько данных мы будем перегонять. Сама по себе работа с XML мне жутко не нравится. Там еще и оверхед такой иногда, что уууу... Никакой сетки не хватает. У меня сейчас на компьютере крутится. Решил на свою голову передавать данные ХМЛем. Единичные запросы — без проблем, уходят и почти не чуствуются вполне внушительные запросы.

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

Самый смак начинается, когда клиент из всего этого дела список начинает составлять... Беготня по DOM'у длится довольно долго.

Здравствуйте, Mamut, Вы писали:

M>Самый смак начинается, когда клиент из всего этого дела список начинает составлять... Беготня по DOM'у длится довольно долго.

Это все понятно, текстовое представление оно всегда предразумевает некоторые проблемы с обработкой.
Просто я не понимаю к чему брать какой то экзотический формат, который также является по сути дела "XML" но хитро форматированный? Или ты думаешь что пара тысяч рекордов "закодированная" в виде

af5226de830e766f03beac50bf63034c::a:4:{s:6:"extKey";s:7:"tt_news";s:7:"EM_CONF";a:26:{s:5:"title";s:4:"News";...

будет шустрее десериализоваться, меньше тереть диском или на худой конец лучше паковаться в зип чем теже данные в виде XML?

К чему я все веду то... если брать "текстовый" формат для передачи данных то по компатибельности ничего лучше XML нет. Если не текстовый, то это уже не является темой этой дискуссии.

Но это мое IMHO.

Как там говориться... каждый человек сам себе злой буратино ?

Здравствуйте, HotDog, Вы писали:

HD>К чему я все веду то... если брать "текстовый" формат для передачи данных то по компатибельности ничего лучше XML нет.

А если не текстовый, то реализовывать все равно лучше что то стандартное, а не самопал.

HD>>К чему я все веду то... если брать "текстовый" формат для передачи данных то по компатибельности ничего лучше XML нет.

AVK>А если не текстовый, то реализовывать все равно лучше что то стандартное, а не самопал.

Вот так всегда. Хочешь сделать велосипед, а придут злые дяди и скажут — низзя

Ладно. Типа определились. Пусть будет ХМЛ (еще бы мнение Шеридана услышать).

Надо думать дальше. Что именно и как мы будем передавать. То есть начинать думать над структурой коммуникаций. Начало здесь

Автор: Mamut
Дата: 15.06.05

Здравствуйте, Mamut, Вы писали:

AVK>>А если не текстовый, то реализовывать все равно лучше что то стандартное, а не самопал.

M>Вот так всегда. Хочешь сделать велосипед, а придут злые дяди и скажут — низзя

M>Ладно. Типа определились. Пусть будет ХМЛ (еще бы мнение Шеридана услышать).

Если мы говорим об обмене демона и клиента, то зачем тут XML? кто-нибудь может объяснить?