Hello Mark,
Sorry you fell behind on your thesis. I am
working on my masters thesis as well I can
relate a bit. Good luck with getting done
in time.
It would be great to use what you and your
lab partner have done. Right now the
transport provider is the main focus. I am
currently writting CalDAV routines that use
MSXML Object. We could switch to a Neon based
solution if it saves a lot of work.
Thanks for all your time and effort you've
put into our project. They are very much
appreciated.
Regards,
Kervin
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
otlkcon-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/otlkcon-devel
