>Exchange — это чуть ли не самый офигенный продукт IT от Microsoft, по моему мнению, конкурентов у него нет.
Вы правы. Я думаю также.
>Во-первых, ну неужели вы реально получаете кайф от такого программирования?
Да, но не всегда ;). Бывают моменты, когда хочется все послать т.к. помощи нет, информации нет, и т.д. Но как показала практика, если решение есть, то оно обязательно находится, если есть время плюс громадное желание. Во всем можно разобраться, вопрос только во времени и нашем желании его так потратить.
Плюс подобные задачи имеют уникальную способность «вставлять» на место мозги по разным вопросам, что потом возвращается с троицей из мест казалось бы совершенно с этим не связанных.
>Почему не «open source»
Не знаю, как-то вот не сложилось. Круг знакомых тоже не способствует, все в весьма «закрытых» конторах. Вот так и выходит, что тема для меня совершенно неизвестная. )
>Во-вторых, почему возникает потребность доступа к Exchange? Неужели экосистема от Microsoft вокруг Exchange неполна и возникает нужда в чём-то ещё?
Полна, пока вам не захочется сделать что-нибудь выходящее за рамки ее ответственности. Например, антивирусы, встроенные в сами механизмы по работе с письмами, системы миграции, резервного копирования или системы аудита, способные узнать, что один из 50000 пользователей поменяли буковку в поле subject одного из миллионов хранящихся на сервере писем..., да много разного можно придумать.
Не совсем так, Ontrack PowerControls не использует протоколы приведенные nobodyzzz, т.к. они, повторюсь клиентские. Ontrack работает с демонтированной базой, а следовательно никакие протоколы вам не помогут.
Они так же используют ESE, т.к. это единственный способ доступа к внутреннему содержимому базы, но примеров реализации вы не найдете, т.к. это закрытый продукт.
> размер страницы можно программно вычитывать из хидера edb файла(это 1я страница в файле) — это DWORD по смещению 0xEC.
Не знал, спасибо.
>Ну и MS начали открывать некоторые секреты внутреннего устройства базы данных.
Да, читал и кое-что уже реализовал по этой доке. Но там больше про клиентскую часть EcDoRpcExt2 и подобные, т.е. это все же на один уровень выше, и будем полезным, например, если захочется написать свой MAPI. В документации все для этого готово, все форматы Rop'ов (бинарный формат используемый Exchange'ем для общения с клиентами через Rpc, например, MFCMapi, Outlook, etc.)
>Я так понял, что для ESE нужно иметь физический доступ к файлу?
Да
>А как узнать через ESE в каком именно файле нужная мне база или он один на каждого отдельного пользователя?
Он один на всю Exchange базу, т.е. кол-во файлов = кол-во почтовых баз.
Посмотреть можно в Exchange Management Console, там же можно узнать к какой базе привязан пользователь.
Ответил выше, EWS и т.п. это высокоуровневые функции, они предназначены разработчикам, а ESE это как CREATE TABLE… и т.п. для MS SQL в сравнении, например, с LINQ to SQL.
Т.е. это родное API, если есть, что-то что нельзя сделать, например, через EWS, то через ESE можно сделать, все, что может сделать сам Exchange.
Можно, а также и через EWS или прямо Rop RPC и еще целой кучей способов, но там есть свои ограничения. А здесь мы имеем доступ на самом низком уровне, а следовательно можем сделать все, что угодно, без каких-либо ограничений, это самый низкоуровневый raw API, который использует сам Exchange, т.е. все вызовы, в том числе и MAPI, в итоге превращаются в ESE вызовы.
>Как правило, ценность логов начинаешь понимать только когда заказчик матерясь отсылает лог на почту и просит засабмитить фикс через 5 минут.
В данном случае логи в релизной версии видимо есть и о вопросе оверхеда стоит подумать т.к. иначе от такого логирования можно получить больше проблем, чем пользы.
Автор и не говорит, что что-то работает неправильно. Просто есть вероятность получить поведение отличное от ожидаемого.
Писать свой AsyncTask не хочется, т.к. изобретение велосипеда. Идея же доработать в имеющемся AsyncTask то, что не устраивает (в данном случае поведение cancel()) звучит логично.
Ok. Про протокол, не знаю, об этом информации нет. Если говорить про уровень приложения то скорее всего это какой-то их собственный протокол, который более нигде не применяется, если говорить про уровень транспорта, то похоже, что это HTTPS, но это все мои догадки.
Служба? Вас имя, отвечающего за это, процесса интересует, зачем? Не интересовался, т.к. для разработчика эти данные не нужны, на офф. сайте информации тоже нет.
Насчет синхронизации, да, должно работать, т.к. такого требования нет в сисреках, и из логики, странно бы было отказывать в получении нотификаций приложениям, которые ничего не знаю про настройки аккаунтов у пользователя.
Простите, если я не правильно понял ваш вопрос. Для передачи сообщений на устройство используется C2DM, а GoogleTalk/Jabber в этом посте не применяется, хотя, возможно, они и используют C2DM в своем работе.
Вы правы. Я думаю также.
>Во-первых, ну неужели вы реально получаете кайф от такого программирования?
Да, но не всегда ;). Бывают моменты, когда хочется все послать т.к. помощи нет, информации нет, и т.д. Но как показала практика, если решение есть, то оно обязательно находится, если есть время плюс громадное желание. Во всем можно разобраться, вопрос только во времени и нашем желании его так потратить.
Плюс подобные задачи имеют уникальную способность «вставлять» на место мозги по разным вопросам, что потом возвращается с троицей из мест казалось бы совершенно с этим не связанных.
>Почему не «open source»
Не знаю, как-то вот не сложилось. Круг знакомых тоже не способствует, все в весьма «закрытых» конторах. Вот так и выходит, что тема для меня совершенно неизвестная. )
>Во-вторых, почему возникает потребность доступа к Exchange? Неужели экосистема от Microsoft вокруг Exchange неполна и возникает нужда в чём-то ещё?
Полна, пока вам не захочется сделать что-нибудь выходящее за рамки ее ответственности. Например, антивирусы, встроенные в сами механизмы по работе с письмами, системы миграции, резервного копирования или системы аудита, способные узнать, что один из 50000 пользователей поменяли буковку в поле subject одного из миллионов хранящихся на сервере писем..., да много разного можно придумать.
Они так же используют ESE, т.к. это единственный способ доступа к внутреннему содержимому базы, но примеров реализации вы не найдете, т.к. это закрытый продукт.
Не знал, спасибо.
>Ну и MS начали открывать некоторые секреты внутреннего устройства базы данных.
Да, читал и кое-что уже реализовал по этой доке. Но там больше про клиентскую часть EcDoRpcExt2 и подобные, т.е. это все же на один уровень выше, и будем полезным, например, если захочется написать свой MAPI. В документации все для этого готово, все форматы Rop'ов (бинарный формат используемый Exchange'ем для общения с клиентами через Rpc, например, MFCMapi, Outlook, etc.)
Да
>А как узнать через ESE в каком именно файле нужная мне база или он один на каждого отдельного пользователя?
Он один на всю Exchange базу, т.е. кол-во файлов = кол-во почтовых баз.
Посмотреть можно в Exchange Management Console, там же можно узнать к какой базе привязан пользователь.
Т.е. это родное API, если есть, что-то что нельзя сделать, например, через EWS, то через ESE можно сделать, все, что может сделать сам Exchange.
В данном случае логи в релизной версии видимо есть и о вопросе оверхеда стоит подумать т.к. иначе от такого логирования можно получить больше проблем, чем пользы.
Ждем с нетерпением.
Писать свой AsyncTask не хочется, т.к. изобретение велосипеда. Идея же доработать в имеющемся AsyncTask то, что не устраивает (в данном случае поведение cancel()) звучит логично.
Служба? Вас имя, отвечающего за это, процесса интересует, зачем? Не интересовался, т.к. для разработчика эти данные не нужны, на офф. сайте информации тоже нет.
Насчет синхронизации, да, должно работать, т.к. такого требования нет в сисреках, и из логики, странно бы было отказывать в получении нотификаций приложениям, которые ничего не знаю про настройки аккаунтов у пользователя.
Где это обсуждение можно почитать?