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

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

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

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

8 комментариев
bealex.livejournal.com 2009

Угу, я делаю два синхронизатора — с iCal и с Outlook, только тудушки. В икале у них десяток параметров, в аутлуке — около семидесяти. И так везде. (Просто как пример, понятно, что немного сбоку)

Евгений Степанищев (bolknote.ru) 2009

Комментарий для bealex.livejournal.com:

Там у них везде так — надо заполнить структуру со ссылокой на две структуры, которые ссылаются друг на друга и ещё на десяток других.

david-m.livejournal.com 2009

Возможно, он имел в виду «зачем так долго возиться с таки заведомо недружественным интерфейсом»?

Неужели есть задачи, которые никак иначе не решить, только через MAPI?

Евгений Степанищев (bolknote.ru) 2009

Комментарий для david-m.livejournal.com:

Да.

Евгений Степанищев (bolknote.ru) 2009

Комментарий для david-m.livejournal.com:

Я тут подумал как более развёрнуто ответить.

Наша группа занимается, помимо создания новых инструментов для интранета, ещё и интеграцией существующих инструментов. MS Exchange — уже существующий инструмент. И когда требуется его интегрировать с чем-то ещё, начинает работу наша группа.

david-m.livejournal.com 2009

Комментарий для Евгения Степанищева:

Понятно:(

sorgoz.ya.ru 2009

Может еще раз посмотрим на CDO?

Евгений Степанищев (bolknote.ru) 2009

Комментарий для sorgoz.ya.ru:

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

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

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

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

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

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

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