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

>> C>огромный плюс, превышающий копеечную экономию на сети.
>> Раз на раз не приходится. Я о принципиальной стороне сейчас говорил.
C>Так я и говорю — в большинстве случаев это непринципиально.

Но того принципа, в соответствии с которым гоняется ненужная документация, это не отменяет.

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

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

Да ладно, поверю на слово.

>> C>Бывают. Но сложные бинарные протоколы — они СЛОЖНЫЕ. Попробуй без
>> C>подробной документации на досуге написать парсер ASN.1 PER — занятие
>> еще то.
>> Что за глупость? Писать парсер без подробной документации по исходным
>> данным?
C>Неудачно выразился — попробуй написать парсер только по спеке, без примеров.

Час от часу...

C>Вообще, посмотри на ASN.1 — это такой супер-XML, который умеет делать
C>все. А потом подумай — почему оно почти никому не нужно.

Можем хоть новый топик открыть. Только встречный вопрос: а как это поможет опровергнуть моё высказывание о том, что "бинарные протоколы бывают разные"?

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

S>Ну, мне лично это не вполне понятно. В С++, вроде бы, стараются стандарту хотя бы не противоречить. А в в жизни используют эдакий "почти XML", который нельзя назвать XML с точки зрения стандарта.

Эта проблема не только XML. Последнее что я видел такого рода — это "почти HTTP", когда сессии свои придумали и аутентикацию — тоже свою, да ещё и с нарушением синтаксиса HTTP'шного. Случаются же такие вещи обычно даже не из худших побуждений, а от незнания: люди не осознают, что XML — это технология, которую используют из-за того, что к ней есть пачка инструментов для обработки; они думают, что XML — это "вот эти угловые скобочки" (молчу про XML infoset) и используется, "чтобы сделать данные читаемыми", и "улучшают" его, теряя все бенефиты XML.

Геннадий Васильев wrote:
> C>Вообще, посмотри на ASN.1 — это такой супер-XML, который умеет делать
> C>все. А потом подумай — почему оно почти никому не нужно.
> Можем хоть новый топик открыть. Только встречный вопрос: а как это
> поможет опровергнуть моё высказывание о том, что "бинарные протоколы
> бывают разные"?
Так я и не собирался. Я только говорю, что сложные бинарные протоколы —
обычно сложнее, чем аналогичные текстовые.

Sinclair wrote:
> C>Так фича в том, что в XML, большей частью, используют только
> C>подмножество стандарта. Примерно как в С++.
> Ну, мне лично это не вполне понятно. В С++, вроде бы, стараются
> стандарту хотя бы не противоречить. А в в жизни используют эдакий "почти
> XML", который нельзя назвать XML с точки зрения стандарта.
Не знаю, обычно базовый стандарт (правила квотирования, указание
DTD/Schema, один тэг верхнего уровня и т.п.) вполне соблюдается.

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

C>Вообще, посмотри на ASN.1 — это такой супер-XML, который умеет делать
C>все. А потом подумай — почему оно почти никому не нужно.
Насчет почти никому — да полно телекоммуникационных протоколов на нем построено:

The ASN.1 notation is extensively used in telecom industry (examples include cell networks' MMS (multimedia services) and telecom equipment CDR (Call Data Records), TAP3 (Transferred Account Procedure)), security protocols and data formats (PKIX/X.509) and other high-profile applications. If you are using SSL (HTTPS) to access a bank or email account, be sure the ASN.1 is involved too; it describes the structure of the server's identity certificate for verification by your Internet browser.

А распространен меньше чем XML потому что, вероятно, полностью реализовать слишком сложно и коммерческие реализации стоят дорого:

The question is: why not every programmer developing the network protocols and/or data formats is using the ASN.1? One of the answers is that the cost of commercial ASN.1 compiler is often prohibitive for small-to-medium sized projects.

(цитаты отсюда)

А также потому что он существовал уже давно и во время .com бума не стал модным buzzword в отличие от XML

А вот XML Infoset в упрощенной ASN.1 обертке — Fast Infoset имеет ИМХО весьма неплохие перспективы.

Андрей Хропов wrote:
> C>Вообще, посмотри на ASN.1 — это такой супер-XML, который умеет делать
> C>все. А потом подумай — почему оно почти никому не нужно.
> Насчет почти никому — да полно телекоммуникационных протоколов на нем
> построено
Ну так я, по-моему, сказал, что ASN.1 исторически используется в
телекоме. В SSL он очень рудиментарно используется, в основном для
представления сертификатов.

Недавно делал сертификат для сервера с несколькими vhost'ами. Как все
было бы проще, если бы сертификаты были в простом XML...

> А распространен меньше чем XML потому что, вероятно, полностью
> реализовать слишком сложно и коммерческие реализации стоят дорого:
Именно.

> А вот XML Infoset в упрощенной ASN.1 обертке — Fast Infoset
> <http://en.wikipedia.org/wiki/Fast_Infoset&gt; имеет ИМХО весьма неплохие
> перспективы.
Так это просто кодировка XML — то есть при работе с ней нужно почти
столько же ресурсов, сколько и с обычным XMLем. Так что у нее нет особых
преимуществ перед связкой xml+gzip.

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

>> А вот XML Infoset в упрощенной ASN.1 обертке — Fast Infoset
>> <http://en.wikipedia.org/wiki/Fast_Infoset&gt; имеет ИМХО весьма неплохие
>> перспективы.
C>Так это просто кодировка XML — то есть при работе с ней нужно почти
C>столько же ресурсов, сколько и с обычным XMLем. Так что у нее нет особых
C>преимуществ перед связкой xml+gzip.
У нее есть принципиальные преимущества, потому что сжатие происходит с учетом особенностей сжимаемой информации (а не просто универсальный gzip), что всегда выгоднее как с точки зрения компактности, так и с точки зрения обработки (например, возможно представлять xsd:float действительно как IEEE754 float, а не парсить в/из текста, удобней делать поиск (для gzip придется каждый раз разжимать и сериализовывать весь распакованный файл) и т.п.)

Собственно, насчет ресурсов — см. исследование здесь.

В общем-то я вообще считаю XML плохим стандартом, поскольку он неоптимален ни для людей:

1) Слишком многословен, людям ближе специализированные средства, позволяющие более удобно/компактно выражать свои мысли (языки программирования для программирования, Word для документов и т.д.) (хорошая иллюстрация — CSAML vs С#);

2) Не является языково-нейтральным. Схема (набор тегов) определяется, как правило, на определенном естественном языке. Соответственно, людям, не понимающим данный язык, он непонятен. Это также касается и представления дат и числительных.

...
ни для компьтеров:

1) Компьютеры оперируют бинарными данными, а не текстом (текст — это только частный случай). Зачем дополнительные операции сериализации/десериализации, в частности для чисел?

Я считаю, что оптимальным является достаточно простой открытый бинарный стандарт для иерархического (а в перспективе и графового — если записывать в нем RDF) представления информации, и, собственно, Fast Infoset — это правильный шаг в этом направлении.

АХ>Я считаю, что оптимальным является достаточно простой открытый бинарный стандарт для иерархического (а в перспективе и графового — если записывать в нем RDF) представления информации, и, собственно, Fast Infoset — это правильный шаг в этом направлении.

А почему не EBML?

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

S>Ну вот, к примеру: нельзя трактовать подветку XML как самостоятельный документ.

И в чем проблема? У нас вовсю в проекте такая фича используется.

S> А очень часто требуется именно это: построение композитных документов, где часть мало знает о целом, а целое — о частях.

Ага.

S> И что? Народ выкручивается: вытаскивает outerXml и приклеивает к нему заголовок. Бред? Бред.

Бред конечно.

S>Про ситуацию с неймспейсами я лучше умолчу, т.к. у меня недостаточно квалификации для полноценного обсуждения

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

M>А почему не EBML?

А кто за ним стоит? В плане того, кто его поддерживает и в каком количестве (и качестве) проектов он юзается?

M>>А почему не EBML?

L>А кто за ним стоит? В плане того, кто его поддерживает и в каком количестве (и качестве) проектов он юзается?

За ним стоит формат "матрешка"(matroska) для видео файлов. И больше, по-моему, никто

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

S>Здравствуйте, Тычеблин, Вы писали:
Т>>какая? где? при коннекте происходит согласование версии протокола обмена. тоже мне бином ньютона...
S>Ну объясни мне тогда, почему между Триллианом и ICQ кириллица в одну сторону ходит, а в другую — нет?

Странно. У меня триллиан, у моего коллеги ICQ, общаемся без проблем. Правда, он там в настройках ICQ что-то поменял

L>>А кто за ним стоит? В плане того, кто его поддерживает и в каком количестве (и качестве) проектов он юзается?

M>За ним стоит формат "матрешка"(matroska) для видео файлов. И больше, по-моему, никто

Тогда связываться с ним буду разве что совсем по безнадёге

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

PD>Странно.
Ничего странного. У меня с некоторыми людьми кириллица ездит:
— в обе стороны
— только от меня
— только ко мне
— от меня вообще ничего не ездит, ни кириллица, ни латиница — пустышки приходят.

Это и есть чудеса бинарного протокола: нет нормального способа поддерживать разные версии на разных концах соединения.

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

S>Ничего странного. У меня с некоторыми людьми кириллица ездит:
S>- в обе стороны
S>- только от меня
S>- только ко мне
S>- от меня вообще ничего не ездит, ни кириллица, ни латиница — пустышки приходят.

S>Это и есть чудеса бинарного протокола: нет нормального способа поддерживать разные версии на разных концах соединения.

В триллиане другая прелесть есть. До поры до времени у меня была версия 0.x, она логи писала в 1251. Потом они ее заменили на 3.x, эта пишет логи в UTF8. Так что у меня логи теперь в начале в 1251, а в конце — UTF8.

А насчет бинарного протокола — не совсем согласен. Версии поддерживать можно, если это в структуру заложено. Читает же Word все .doc файлы — а это , по сути, то же самое. Кто им мешал в ICQ протоколе поле VERSION завести ? Даже из 4 частей можно было, как в .Net

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

EK>Альтернатива -- писать байтовый поток в платформонезависимом виде, а потом долго-долго ручками выписывать stream_read_dword() / convert_network_to_host_dword() и так далее.
А если чутка подумать? Хоть в С++ с метапрограммированием и хреново но на эту задачку его хватит.
Допилить до кондиции напильником

template<int N>
struct GenericIO
{
    template<class Stream, class Type>
    static void writeLittleEndian(Stream& stream, Type const& t)
    {
        stream.writeByte(((char*)&t)[sizeof(Type) - N]);
        GenericIO<N - 1>::writeLittleEndian(stream, t);
    }
    template<class Stream, class Type>
    static void writeBigEndian(Stream& stream, Type const& t)
    {
        stream.writeByte(((char*)&t)[N - 1]);
        GenericIO<N - 1>::writeBigEndian(stream, t);
    }

    template<class Stream, class Type>
    static void readLittleEndian(Stream& stream, Type& t)
    {
        stream.readByte(((char*)&t)[sizeof(Type) - N]);
        GenericIO<N - 1>::readLittleEndian(stream, t);
    }
    template<class Stream, class Type>
    static void readBigEndian(Stream& stream, Type& t)
    {
        stream.readByte(((char*)&t)[N - 1]);
        GenericIO<N - 1>::readBigEndian(stream, t);
    }
};

template<>
struct GenericIO<0>
{
    template<class Stream, class Type>
    static void writeLittleEndian(Stream& stream, Type const& t){}
    template<class Stream, class Type>
    static void writeBigEndian(Stream& stream, Type const& t){}
    template<class Stream, class Type>
    static void readLittleEndian(Stream& stream, Type& t){}
    template<class Stream, class Type>
    static void readBigEndian(Stream& stream, Type& t){}
};

template<class Stream>
void writeLittleEndian(Stream& stream, int i)
{
    GenericIO<sizeof(int)>::writeLittleEndian(stream, i);
}

template<class Stream>
void writeBigEndian(Stream& stream, int i)
{
    GenericIO<sizeof(int)>::writeBigEndian(stream, i);
}

template<class Stream>
void readLittleEndian(Stream& stream, int& i)
{
    GenericIO<sizeof(int)>::readLittleEndian(stream, i);
}

template<class Stream>
void readBigEndian(Stream& stream, int& i)
{
    GenericIO<sizeof(int)>::readBigEndian(stream, i);
}

struct TestWriteStream
{
    template<class T>
    TestWriteStream& operator()(T const& t)
    {
        writeBigEndian(*this, t);
        return *this;
    }

    void writeByte(char b)
    {
        std::cout << std::hex << (int)b << " ";
    }
};

struct TestReadStream
{
    template<class T>
    TestReadStream& operator()(T& t)
    {
        readBigEndian(*this, t);
        return *this;
    }

    void readByte(char& b)
    {
        int n;
        std::cin >> std::hex >> n;
        b = n;
    }
};

struct Test
{
    int i;
    int j;
};

template<class Stream>
void testStream(Stream& stream, Test& test)
{
    stream
        (test.i)
        (test.j)
        ;
}

int main()
{
    TestReadStream rs;
    TestWriteStream ws;
    Test t = {12314, 3643};
    testStream(ws, t);
    testStream(rs, t);
    testStream(ws, t);
    return 0;
}

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

АХ>>Я считаю, что оптимальным является достаточно простой открытый бинарный стандарт для иерархического (а в перспективе и графового — если записывать в нем RDF) представления информации, и, собственно, Fast Infoset — это правильный шаг в этом направлении.

M>А почему не EBML?

Не знаю, а насколько он соответствует XML Binary Characterization Properties?

Сравнение тех форматов, которые им предоставили Analysis of the EXI Measurements.

Самым крутым по сжатию получается Efficient XML, который разработан компанией AgileDelta, и основан на Knowledge Based Compression (здесь). Интервью с создателем здесь. Вроде как они пока спецификацию не открыли, но пророчат ее на роль W3C стандарта (тогда типа откроем — здесь).

А на самом деле самое лучшее для обычного XML это как я выяснил (хотя у самого подобные мысли были) — XML Screamer, в общем надо замутить реализацию этого дела для Немерле, который отлично для этого подходит .

А еще лучше объединить этот самый Screamer c каким-нибудь из бинарных стандартов XML (когда в W3C наконец примут таки его) .

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

PD>В триллиане другая прелесть есть. До поры до времени у меня была версия 0.x, она логи писала в 1251. Потом они ее заменили на 3.x, эта пишет логи в UTF8. Так что у меня логи теперь в начале в 1251, а в конце — UTF8.
Я это тоже пережил.

PD>А насчет бинарного протокола — не совсем согласен. Версии поддерживать можно, если это в структуру заложено. Читает же Word все .doc файлы — а это , по сути, то же самое.
О, вот еще один плохой пример. Попробуй открыть в Word 6.0 файл от Word 97 — будешь неприятно удивлен. То, что Word 2003 читает все .doc файлы — заслуга Word, а не .doc.

Насколько я знаю, в протоколе ICQ поле Version как раз есть. Нету каких-то других полей, которые позволили бы, к примеру, корректно указывать кодировку строк.
Эти проблемы, конечно, не вполне связаны с бинарностью, но они, имхо, ей усугубляются.

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

S>Насколько я знаю, в протоколе ICQ поле Version как раз есть. Нету каких-то других полей, которые позволили бы, к примеру, корректно указывать кодировку строк.
S>Эти проблемы, конечно, не вполне связаны с бинарностью, но они, имхо, ей усугубляются.

Ну если мы решим с тобой обмениваться текстовыми файлами на русском языке по ftp , смотреть их в FAR без плагинов, то тоже хорошего мало будет