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

[Jan Schneider]

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.

> Firstly, in your response, you say "we won't support this" - do you
> mean, you won't support a software solution, based upon the
> development of code to interface Horde from MS Outlook, or do you
> mean, you aren't prepared to sign-off the creation of code to allow
> this interface?
>
> If you mean that you're not happy supporting the software solution,
> then I understand your choice with regards the changes I'm proposing.
> I'm not going  to contest this, as it's not my place to ask you to
> support something you're not comfortable with, and also if I were in
> your position, I wouldn't expect to support it either - at least until
> the code were stable and proven, and even then, would carry some
> caveats - for example "This code is only tested for version X of MS
> Outlook, and against version Y of Horde"... but, as I said, I'm not
> going to try and change your position.
>
> If it's that you aren't prepared to sign-off the creation of this
> code, then I'm slightly confused. You say that it's proprietary, and
> yet, it should be just a series of SOAP requests that are documented
> on the Microsoft Website, asking for particular data which
> Horde/Kronolith should be able to provide. If it is because you're
> uncomfortable asking someone to code an interface which may mean they
> aren't working on something else, then I'm happy to put the work in
> myself, but I won't be able to get this fantastic creation into my
> target environment, because I can't code it in time with my lack of
> knowledge. I'm also slightly worried that even if I do put the work
> it, it will only ever be used by me for any subsequent projects
> because you're uncomfortable with the code I want to produce.
>
> 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! As I work in the team

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.

> that will be using this solution, and will probably end up supporting
> the product, I want something that I know I can contribute back to the
> community, where I actually have a chance of developing additional
> solutions for my team, and where I know how to read the code. I really
> want to use Horde, and the lack of this single feature which seems to
> be a dealbreaker for my decision maker has lead to my creation of the
> feature request and my subsequent dogged persistence to get this
> request considered.
>
> I'm sorry for writing War and Peace! Whatever happens, I'm really glad
> I discovered Horde - It is a great piece of software, and I'm really
> impressed with it. I've already suggested it to a number of friends
> for projects they are working on and even if this patch doesn't
> happen, I'm still looking forward to using and contributing to Horde
> in the future.
>
> Regards,
>
> Jon
>



Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/