Hi Kervin (and others),
I have good news and bad news.
I'll start with the bad news first: after talking with my advisor
about my progress on the message transport, we've decided I need to
get back to my actual Ph.D. work (this was a related but totally
separate project) or jeopardize my chances of having a solid Ph.D.
project and dissertation. In theory I was supposed to be done some 4
- 6 weeks ago, but I don't like giving up before I've finished what I
set out to and I convinced my advisor (and myself) that with just a
few more weeks, I could get something working. Unfortunately, that
has turned out not to be the case and I can't keep working on this
into the new year.
But in good news, my lab-mate, Kai Pan, and I make progress towards
the end goal. Kai's work early on extended the open source neon
library (http://www.webdav.org/neon/) with CalDAV functionality and
we're hoping his changes will be merged in the near future;
currently, they're only in the message provider's source code tree.
As of this week, his altered code is incorporated into the Visual
Studio project I have for the Message Transport and successfully
builds, links, and runs, giving the Message Transport access to HTTP,
WebDAV, and CalDAV. I've also fleshed out a working Message Transport
plugin that seems to play well with Outlook. It should be clean
enough to follow the code and either drop into the OpenConnector
project or use as a guide when implementing an OpenConnector-specific
Message Transport. Note that either way, you should replace the Log()
function calls with OpenConnector's OTLKCON_LOG_PRINTF() as the Log
function I used came directly from MSDN sample code (it was just
shorter to type ;).
There's a lot that remains to be done, which is why I won't be able
to stay around to finish it:
- Determining how many new messages for upload and download there are
(this step will be much easier with a local message store to sync
with... I was contemplating custom properties on each event to flag
it when it was downloaded).
- Downloading events (simply a GET request for that event's URL)
- Uploading new and updated events (simply a PUT request for a URL,
as documented in the CalDAV spec)
- Translating the MAPI Message objects into iCalendar data. Henry
Gusakovsky had this to say about this process:
There is undocumented COM component that converts iCalendar to
MAPI and vice versa. Its interface is available in tlb. Function
names are rather self exlanatory.
The component is located in MIMEDIR.DLL. 've added spying of
IMDCvt_iCal interface to MAPISpy. To see logs you need to enable
spying CoCreateInstance function.
I have a repository with my work here at UCSC and I'll be putting up
a "Release" zip archive with all my code in a day or two. When I do,
you'll find it at:
http://dforge.cse.ucsc.edu/projects/caldavxp/
You may be able to use Subversion to check the current repository out
(see the "SVN" tab on the project page for details), but that may be
reserved for those with an account on the dforge machine; that's why
I'll be making the zip file. First though, I want to more fully
document the code, especially in the places where I know work still
needs to be done.
If anyone has questions about the code, please don't hesitate to
email me. I wish you the best of luck with the OpenConnector project.
I know a lot of people are looking forward to Outlook support for
CalDAV.
Mark
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
otlkcon-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/otlkcon-devel
