Closed m0yellow closed 3 years ago
Does MS Exchange support caldav? In that case, calendar-cli should work without pulling in the exchangelib library. If the MS Exchange platform has a slightly broken support for the caldav-library, it may be within the scope of the caldav-library to add the tweaks needed to get it to work with Exchange.
Otherwise, the approach would probably be to make some wrapper library building on both the python-caldav library and the exchangelib, a library with an API compatible with the caldav library, so it can be used as a drop-in replacement for the caldav library. It may be doable. The test code for the caldav-library (and calendar-cli) can be used as it is. There are some few classes that needs to be inheritated and a handful of methods that needs to be overridden.
I'm both maintaining the python-caldav library and the calendar-cli, I can offer some help in this quest - like advises and cooperation, accepting merge-requests, making official support for Exchange in the calendar-cli library, making it less likely that exchange-compatibility will break when new versions of calendar-cli and the caldav library is released - but personally I have no interest in Microsoft products, so I don't want to put down a lot of work with this.
Thanks for the fast reply. I also have no interest in the Microsoft products other than this platform (github), but since it is the data source I'm using, I'm stuck. From other projects I learned Microsoft dropped CalDAV support with Exchange 2010 (unconfirmed). Exchangelib is using the the EWS interface to produce pythonesk-objects of the Exchange-Objects.
So if I understand you correctly, I would only have to try my luck to produce caldav-library-like output with a wrapping layer over exchangelib. This seems like a nice idea.
For now I'll try and hack something together. I'm learning more python in every step, so I might mess up with python versions and so on, it might take awhile.
Thanks for now. If you have any Ideas in this path, just drop them here, but I'll close it for now, as I have more todos than questions in this.
Came to think of it ... I suppose it would be good if the caldav library would handle alternative APIs/protocols making it possible to access different kind of calendars more or less seamlessly, even if it's a bit outside the primary scope of the caldav library.
There is a bit of the same with Google - they do have some sort of support for caldav, but it's quite lacking, and I believe they have some alternative google-API allowing all the things to be done. It could be an idea to implement workarounds in the caldav library allowing tools like calendar-cli to just work, regardless of weather the backend is Google, Microsoft, Apple, a good self-hosted caldav server, or another popular self-hosted calendar server with poor caldav support.
Hello, I'm researching how deep somebody would have to dive in, to hack something like calendar-cli for Exchange, as I have to observe a shared exchange calendar at work.
I'm playing around with https://github.com/ecederstrand/exchangelib
but now I'm thinking, wouldn't it be easier to hack exchangelib into calendar-cli as a backend? Did anybody think about it, or have tried it? I found there is an property in the calendar object, which looks like parsable ical format. When dumping the full object, it is wrapped into some xml.
From what I gathered from the source, I would need to get the object like caldav, then unwrap it. Please tell me if I'm on the right path.
Matthias