1. My personal inclination would be to use REST for a read-only interface. SOAP requires the setup and tear-down of a session and that's really only advantageous if you're doing a lot of interaction with the server (e.g. migrating data into Zimbra). REST is dead-simple - you have a static URL that you can use to access a particular set of data, and that URL never has to change
Originally Posted by saki
2. Zimlets really are for integrating into the Zimbra UI. It sounds like you want to built your own web pages, but populate them with data from Zimbra, so you're going to be looking at a back-end service that sucks its data from Zimbra (either in real-time when the user tries to view the page, or at scheduled intervals, depending on how dynamic the data is.
3. If you don't actually have a predefined "look" that your UI must have, you may want to just play with the HTML 'view' into Zimbra's calendars. These can be exposed to the public so that no authentication is necessary.
For example, here's my public calendar in html format
Public: January 2009
If you want the same thing as an RSS or a .ics file, just change the suffix from .html to .rss or .ics, respectively.
It may not be necessary to write much code at all -- even if you don't like Zimbra's "public" view, you might be able to find a GNU tool that produces a view you like and populate it using the .ics file (retrieved via REST)
4. That depends *entirely* on how complex you make it, how much you have to parse the data, what you intend to import it into, etc.
5. Zimbra's REST interface is documented, to some extent, in the zimbra source (in the ZimbraServer/docs directory). There are also some blog posts and Wiki articles that cover some of their REST. I noticed in the notes for 5.0.12 that some docs are being rolled into the binary distrib too
Simon Fraser University