Kervin L. Pierre wrote: [snip]
This is just the point I was at when I had to start looking on the calendar protocol ( settled on CalDAV for now ). Part of the problem is that we simply need more hands.
I can't help much with calendaring, other than parroting my frustrations in using Thunderbird in an Outlook-centric workplace and dealing with calendaring issues.
The provider init method implementation is suppose to detect that previous objects have been initialized, and return that instead. It was not a problem, but I need to start nailing down how the connector will behave on the wire, and what server-side software would be needed, so I switched focus to that.
What I've done in the past is have new objects for both the IMSProvider and the IMsgStore objects and let IMsgStore create an interface to a shared back-end object during the Logon call. It occurs to me that it might make more sense to have the IMsgStore object itself be shared. Sometimes tried-and-true template programming isn't such a great idea. ;)
It might be a good starting point if you grab CVS and see where we're at.
Let me know what you think, Kervin
Will do. I'm unclear as to the goal of this portion of the project, though. As I understand it, the goal is to provide an API that exposes all the groupware functionality of Exchange, and the MAPI SP bit just exposes things that are already available...through MAPI. Is that a fair analysis?
Brent
------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ otlkcon-devel mailing list otlkcon-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/otlkcon-devel
