[kronolith] Fwd: [Tickets #4982] Re: Expose Kronolith data via XML, emulating Sharepoint's XMLRPC Web Services for integration into Microsoft Outlook

[Jon Spriggs]

On 2/9/07, Jan Schneider <jan at horde.org> wrote:
> Zitat von Jon Spriggs <jon at spriggs.org.uk>:
>
> > On 2/9/07, Jan Schneider <jan at horde.org> wrote:
> >> Zitat von Jon Spriggs <jon at spriggs.org.uk>:
> >>> On 2/8/07, Jan Schneider <jan at horde.org> wrote:
> >>>> Zitat von Jon Spriggs <jon at spriggs.org.uk>:
> >>>>> Jan, (and CC'd to the list, incase anyone else is looking for the
> >>>>> same info)
> >>>>> Thanks for the very prompt response.
> >>>>> Just out of interest, how can I expose the calendar information? I ask
> >>>>> this because Sharepoint (my main rival for implementation) has a link
> >>>>> on the calendar which provides a unique url which opens the calendar
> >>>>> directly for read-only access in MS Outlook. (I'm just signing up for
> >>>>> a "free demo" somewhere to be able to provide an example of the URL
> >>>>> and later for an interactive example with the service or results of
> >>>>> accessing the URL - if it's appropriate).
> >>>>> Within Kronolith, I found the link under "manage my calendars" to
> >>>>> remotely access the calendar, but from examining the result of the
> >>>>> link, that seems to produce ical data rather than allowing me to open
> >>>>> the calendar under anything else.
> >>>> I don't follow. What else than the only existing calendar specific
> >>>> standard, iCalendar, should be used to provide calendar data to
> >>>> external clients? I know it's suprising but even Outlook understands
> >>>> this format.
> >>> Outlook 2003 and maybe earlier versions allow clicking on a URL which
> >>> looks like:
> >>> <snip>
> >>>
> >>> (I've modified this a little, showing the site and calendar specific
> >>> bits surrounded by []'s.)
> >>>
> >>> This resolves (eventually) to
> >>> http://[SERVERNAME]/Lists/Events/AllItems.aspx, which is a SOAP URL.
> >>> Outlook sends a couple of SOAP requests to the server. I've attached a
> >>> (trimmed and slightly modified for privacy) version of the wireshark
> >>> packet trace of the requests between Outlook and Sharepoint.
> >>>
> >>> I think this could be really good for Horde - and would definitely
> >>> differentiate this product from other groupware products on the
> >>> market... because, not only is it free (as in Gratis and Libre), and
> >>> running on an open platform (and I think supports more methods of
> >>> authentication than any other groupware out there), but would allow
> >>> direct interoperability with Microsoft Outlook.
> >> I still don't understand why you want this. And just in case I wasn't
> >> clear: we won't support this, because a) it is not necessary, since we
> >> have an iCalendar/DAV interface, and b) it is propriatary, whithout
> >> any additional benefit.
> >
> > Jan,
> >
> > I'm worrying that this may turn into a fight, which was never my
> > intention, so I thought I'd e-mail you off-list to explain my
> > reasoning, and hopefully persuade you to change your mind (although,
> > I'd be OK if I can't). I also want to ensure this ends on a good note,
> > either way.
>
> This is by no means a fight, so please let's keep this on the mailing
> list. Other people or developers might have different opinions than me.

Cool :) *wipes brow*

<snip>
> > My reason for wanting this is that the person who is making the
> > decision about whether to use Horde or Sharepoint doesn't care about
> > the cost of deployment, doesn't care about how easy or difficult it is
> > to contribute to the future development of the site and doesn't care
> > how Free (Gratis/Libre) it is, he just cares that with Horde, he can't
> > open the calendar for inspection in MS-Outlook!
>
> And that's the whole point. It's already possible. Without a
> propriatery, bloated method. With a standardized interface. For all
> clients. Not only Outlook. You get the same like with Sharepoint, and
> even more. There is no point in an additional interface that doesn't
> get us or you anything that doesn't exist already.

OK, so taking this from another tack... if I write the code, and
contribute it to the code base as a patch via bugs.horde.org, will it
be accepted into the base, even if it's natively disabled, and then
enabled with a switch which is marked as being "unstable" or "valid
only for version X of Microsoft Outlook"? Alternatively, how about if
it's contributed as a howto on the Wiki with warnings all over it
saying "Don't use this unless you're prepared to relinquish any
support from the team"?

I only ask, because it really is the only sticking point with my
management about implementing Horde, and I don't want to do this
locally, and then let the code get lost, and not be available to
anyone else.

Regards,

Jon