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

bealex.livejournal.com (bealex.livejournal.com)
29 апреля 2009, 13:20

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

bolk (bolknote.ru)
29 апреля 2009, 13:46, ответ предназначен bealex.livejournal.com:

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

david-m.livejournal.com (david-m.livejournal.com)
30 апреля 2009, 00:20

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

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

bolk (bolknote.ru)
30 апреля 2009, 09:51, ответ предназначен david-m.livejournal.com:

Да.

bolk (bolknote.ru)
30 апреля 2009, 12:17, ответ предназначен david-m.livejournal.com:

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

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

david-m.livejournal.com (david-m.livejournal.com)
1 мая 2009, 22:58, ответ предназначен bolk (bolknote.ru):

Понятно:(

sorgoz.ya.ru (sorgoz.ya.ru)
8 мая 2009, 17:53

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

bolk (bolknote.ru)
9 мая 2009, 00:49, ответ предназначен sorgoz.ya.ru:

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

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

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

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

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

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

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