xml rpc либы каике мене глючны?

Используем пару лет http://xmlrpcpp.sourceforge.net/ - пока полет нормальный - только она не развивается! Зато простая и понятная.

axis-rpc

http://xmlrpc-c.sourceforge.net мой выбор :-)

на qt, но все-таки http://code.google.com/p/qtxmlrpc/

Почему-то никто не посоветовал самый очевидный выход: не использовать XML. Бинарный протокол по методологии TLV рулит и педалит.

> Бинарный протокол по методологии TLV рулит и педалит.

Главное, чтобы не получилось как в OSCAR. 8))

Вообще, есть некая сермяжная правда в human-readable протоколе. Правда, xml хуман-ридабле не является...

На всякий случай напоминаю, что по протоколам общаются приложения (роботы), а не люди. jabber с его gzip'нутыми костылями являет собой пример истории неуспеха xml-based протокола.

> На всякий случай напоминаю, что по протоколам общаются приложения (роботы), а не люди.

А отлаживают люди. Отлаживать tlv -- задача не то, чтобы для сильных духом, не некоторое неудобство привносит.

> jabber с его gzip'нутыми костылями являет собой

jabber -- он как юникс. Говно говном, но лучше пока не придумали. 8))

> пример истории неуспеха xml-based протокола

А у 'xml-based протоколов' бывает история успеха? xml ж для таких вещей уникален по сути своей -- сочетает только отрицательные черты текстового человекочитаемого и бинарных протоколов, не взяв ни одной хорошей черты.

Основной пойнт был в том, чтобы не получилось, как в OSCAR'е -- там в пределах одного(!) пакета два(!) раза меняется endianess. BE -> LE -> BE. Ненависть!!!

Да, совсем забыл:

> Почему-то никто не посоветовал самый очевидный выход: не использовать XML

Наверное, потому что вопрос был "какие xml-rpc либы наименее глючные"? 8)) Очень эротично общаться со сторонним сервером, который только xml-rpc и умеет, с помощью TLV-based протокола. 8)))

s/ не некоторое/ но некоторое/

>Основной пойнт был в том, чтобы не получилось, как в OSCAR'е -- там в пределах одного(!) пакета два(!) раза меняется endianess. BE -> LE -> BE. Ненависть!!!

На всякий случай хочу напомнить, что концепция TLV вообще не затрагивает, каким образом должны храниться эти самые T, L и V. Главное, что T и L едины для всех. Не стоит перекладывать огрехи AOL на всю концепцию.

Странно, а я распарсил запрос топикстартера как: "Хочу сделать самопальный RPC протокол, посоветуйте XML библиотеку".

к стати, на счет TLV.
как быть если нужно задавать длины\колличество полей в конфиге...
т.е. например в одном случае
len id data
в другом нужно
len id nun_tags tag_data tag_data
или наоборот вроде...
len data id
при .том я разделяю это по разным портам, т.к. последовательности могут быть разные.

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

Например, так

Пакет:

T: packet_id
L: packet_len
V:
    T: tag_id
    L: tag_len
    V: tag_value
    ...

Никаких сложностей, в общем-то, нет.

>Например, так
>Никаких сложностей, в общем-то, нет.
да, с этим проблем нет.
проблема больше всего в дизайне кода что-ли.
у меня то выходит много переменных, то много повторений xmlStrcmp, при сравнении или циклов, на чайла в xml tree приходится делать отдельный цикл(1).
конфигурация у меня выглядит так...
<dev><proto>udp</proto><port>1111</port><ack><field val="0x5D">1</field><field val="0x2A5F">2</field></ack></dev>
ну и так далее для всех девайсов...

char *dev[]={"proto","port"};
int dev_n;
static void elementes(xmlNode *a_node){
int s;
xmlNode *node = NULL;
for (node = a_node; node; node = node->next) {
if (node->type == XML_ELEMENT_NODE && (xmlStrcmp(node->name, (xmlChar *)"dev" ))== 0 ){
dev_n++;
}
for(s=0;s<2;s++){ // <-(1)
if (node->type == XML_ELEMENT_NODE && (xmlStrcmp(node->name, (xmlChar *)dev[s] ))== 0 ){
store.set[dev_n][store.shift[dev_n][s]] = (char *)xmlNodeGetContent(node);
store.shift[dev_n][s]++;
}
}


elementes(node->children);
}
}