libmapi: почему так долго?
Вчера один из моих читателей вскользь поинтересовался — неужели с libmapi так сложно работать.
Для примера, чтение данных переговорок (включая рекуррентные встречи), занимает сейчас у меня в «Пайтоне»: 1275 строк основного файла модуля, 647 строк файла описаний структур MAPI, 4046 строк констант MAPI, плюс 457 строк файла данных для Pid-свойств.
Угу, я делаю два синхронизатора — с iCal и с Outlook, только тудушки. В икале у них десяток параметров, в аутлуке — около семидесяти. И так везде. (Просто как пример, понятно, что немного сбоку)
Комментарий для bealex.livejournal.com:
Там у них везде так — надо заполнить структуру со ссылокой на две структуры, которые ссылаются друг на друга и ещё на десяток других.
Возможно, он имел в виду «зачем так долго возиться с таки заведомо недружественным интерфейсом»?
Неужели есть задачи, которые никак иначе не решить, только через MAPI?
Комментарий для david-m.livejournal.com:
Да.
Комментарий для david-m.livejournal.com:
Я тут подумал как более развёрнуто ответить.
Наша группа занимается, помимо создания новых инструментов для интранета, ещё и интеграцией существующих инструментов. MS Exchange — уже существующий инструмент. И когда требуется его интегрировать с чем-то ещё, начинает работу наша группа.
Комментарий для Евгения Степанищева:
Понятно:(
Может еще раз посмотрим на CDO?
Комментарий для sorgoz.ya.ru:
Даже если не городить огород с хранением состояний и прокидкой только примитивных вызовов, проблем там немногим меньше.
Прежде всего — это всё абсолютно неуправляемо. Если упало, то упало и ничего тут не сделаешь. Открытых исходников нет и придётся просто шаманить. Сейчас я хотя бы читаю исходный код.
Во-вторых, какой-то транспорт выбирать всё равно придётся и надо будет учиться с ним работать.
В-третьих, возрастут задержки — данные придётся гонять с одной машины на другую (сейчас у нас всё на одной), а у нас они и сейчас немаленькие.
В-четвёртых, это программирование под Windows с использованием OLE, что для нас всех пахнет новыми, интересными граблями. Я когда-то давно программировал под Windows, причём несколько лет, а теперь вот программирую только под Linux и возвращаться не хочется. Именно из-за неадекватности и непрозрачности Винды (это я с позиции программиста, а не пользователя).
В-пятых, наш текущий опыт полезен — его можно использовать в других продуктах «Яндекса», опыт с CDO для остальных бесполезен. В свете возможной будущей интеграции двух известных тебе проектов, это очень немаловажно.
Большой минус текущего решения (который я правда поборол, изолировав библиотеку в отдельном процессе) — стабильность. Но это не всегда так будет. Текущая версия 0.8.2 должна быть уже очень стабильной, судя по changelog (жаль, мы её ещё не можем попробовать — пакета так и нет). Других ограничений, по сути, у нас нет.