libmapi: почему так долго?

Вчера один из моих читателей вскользь поинтересовался — неужели с libmapi так сложно работать.

Для примера, чтение данных переговорок (включая рекуррентные встречи), занимает сейчас у меня в «Пайтоне»: 1275 строк основного файла модуля, 647 строк файла описаний структур MAPI, 4046 строк констант MAPI, плюс 457 строк файла данных для Pid-свойств.

libmapi

Комментарии 8

bealex.livejournal.com № 1
Угу, я делаю два синхронизатора — с iCal и с Outlook, только тудушки. В икале у них десяток параметров, в аутлуке — около семидесяти. И так везде. (Просто как пример, понятно, что немного сбоку)
Евгений Степанищев (bolknote.ru) автор № 2
Там у них везде так — надо заполнить структуру со ссылокой на две структуры, которые ссылаются друг на друга и ещё на десяток других.
david-m.livejournal.com № 3
Возможно, он имел в виду «зачем так долго возиться с таки заведомо недружественным интерфейсом»?

Неужели есть задачи, которые никак иначе не решить, только через MAPI?
Евгений Степанищев (bolknote.ru) автор № 5
Я тут подумал как более развёрнуто ответить.

Наша группа занимается, помимо создания новых инструментов для интранета, ещё и интеграцией существующих инструментов. MS Exchange — уже существующий инструмент. И когда требуется его интегрировать с чем-то ещё, начинает работу наша группа.
sorgoz.ya.ru № 7
Может еще раз посмотрим на CDO?
Евгений Степанищев (bolknote.ru) автор № 8
Даже если не городить огород с хранением состояний и прокидкой только примитивных вызовов, проблем там немногим меньше.

Прежде всего — это всё абсолютно неуправляемо. Если упало, то упало и ничего тут не сделаешь. Открытых исходников нет и придётся просто шаманить. Сейчас я хотя бы читаю исходный код.

Во-вторых, какой-то транспорт выбирать всё равно придётся и надо будет учиться с ним работать.

В-третьих, возрастут задержки — данные придётся гонять с одной машины на другую (сейчас у нас всё на одной), а у нас они и сейчас немаленькие.

В-четвёртых, это программирование под Windows с использованием OLE, что для нас всех пахнет новыми, интересными граблями. Я когда-то давно программировал под Windows, причём несколько лет, а теперь вот программирую только под Linux и возвращаться не хочется. Именно из-за неадекватности и непрозрачности Винды (это я с позиции программиста, а не пользователя).

В-пятых, наш текущий опыт полезен — его можно использовать в других продуктах «Яндекса», опыт с CDO для остальных бесполезен. В свете возможной будущей интеграции двух известных тебе проектов, это очень немаловажно.

Большой минус текущего решения (который я правда поборол, изолировав библиотеку в отдельном процессе) — стабильность. Но это не всегда так будет. Текущая версия 0.8.2 должна быть уже очень стабильной, судя по changelog (жаль, мы её ещё не можем попробовать — пакета так и нет). Других ограничений, по сути, у нас нет.