[Kolab-devel] Remote Microsoft Exchange freebusy fetching in Kolab_Freebusy
Gunnar Wrobel
wrobel at pardus.de
Thu Sep 10 17:41:34 CEST 2009
Hi Mathieu,
Quoting Mathieu Parent <math.parent at gmail.com>:
> Hello,
>
> Currently, retrieving freebusy information only works for users
> present in the LDAP directory and having an IMAP folder following
> Kolab XML format and annotations. I need to extend this to get
> freebusy data from Exchange 2007 servers which shares the same mail
> domain as our Kolab servers. This is a very specific request, but it
> is covered by two more general features :
> - retrieve freebusy information from servers outside the Kolab "cluster"
> - retrieve freebusy information from other formats
>
> Proposed implementation :
> - add an "Outlook Web Access" format in Kolab_Format for freebusy
> information (probably in lib/Horde/Kolab/Format/OWA.php, inheriting
> Horde_Kolab_Format_XML or not). More info on the format [owa-format]
> - change Horde_Kolab_FreeBusy_Access::_process to allow fallback when
> no user is found in LDAP and a hook is defined. The hook will return a
> freebusyserver and a freebusyservertype (owa for MS exchange, ifb for
> remote, imap for local) based on uid/mail
> - change Horde_Kolab_FreeBusy_Access::fetchRemote to redirect only if
> freebusyservertype is ifb, error only if freebusyserver is not set.
> - change Freebusy/Cache.php to use Horde_Kolab_FreeBusy_xx class (Imap
> or OWA) depending on freebusyservertype
> - create Horde_Kolab_FreeBusy_OWA class, using Horde_Kolab_Format_OWA
>
> With this proposal it will be possible in the future to add connectors
> for other mail servers.
>
> As this changes a lot of the existing code, I first need to know if
> the proposal is ok or if there is a better solution (I'm mostly asking
> Gunnar as the main developer of those horde parts).
As discussed on IRC this sounds good to me. You should probably add an
issue for this feature and post your patches there.
For completenes: our IRC discussion log.
17:15 <wrobel> sathieu: If I understand you correctly then the set of
users on the exchange server should be available to ALL
users on your Kolab server, right?
17:16 <sathieu> yes
17:17 <wrobel> sathieu: so I think it does not belong into the IMAP
folders. In principle the IMAP folders should store
information that is owned by the users (or a group of
users). System-wide data usually finds a better place
in LDAP.
17:17 <wrobel> sathieu: the other things look okay to me (the
extensions to the FreeBusy classes.
17:18 <wrobel> sathieu: especially having a hook extension possibility
for the remote f/b lists sounds good
17:18 <wrobel> sathieu: do you think you could store the required
information about remote exchange based f/b lists also
in LDAP?
17:19 <sathieu> what do you mean by "it does not belong into the IMAP
folders"? you are talking about the cache?
17:23 <wrobel> sathieu: ah, I misunderstood your first point. The fact
that you wanted to use Kolab XML format (which you
probably don't want) did make me believe you wanted to
store the user mapping as groupware objects in an IMAP
folder. But I see now that the Free/Busy format is in
XML.
17:26 <wrobel> sathieu: So I think the proposal makes sense. You
wanted to code this, right? What was your timeframe on
this?
17:26 <sathieu> what is the best solution, inherit
Horde_Kolab_Format_XML or not ?
17:26 <wrobel> sathieu: I guess it would not inherit from
Horde_Kolab_Format_XML. This class is specifically
meant for the Kolab groupware objects and I wouldn't
use it for general XML parsing.
17:28 <wrobel> sathieu: I think it makes sense if OWA parsing would
live in the Kolab_FreeBusy package.
17:28 <wrobel> sathieu: Or is it that common that it warrants its own
package?
17:29 <sathieu> I will code this at work, probably. We are planning
migration from M$ Exchange 5.5 to Kolab in the
beginning of 2010.
17:32 <sathieu> we will use Debian native packages, they lack some
stuff in the webclient part now....
17:33 <wrobel> sathieu: Okay, so you should code for Horde 3. I am
currently cleaning and restructuring the package for
Horde 4. I don't think it should be too hard to merge
your patches though.
17:33 <sathieu> wrobel: will kolab 2.3 be with horde 3 or 4?
17:38 <wrobel> sathieu: 2.3 will be horde3. I plan to have the first
set of test packages for Horde 4 in early 2010. But
this will be test stuff and not part of the current
server. Horde 4 is still in early alpha. The plan is to
support Horde3 until the middle of 2011 on the Kolab
Server (albeit it still has many shortcomings).
>
> Mathieu Parent
>
> [owa-format]:
> http://www.infinitec.de/post/2004/12/30/Retrieving-a-users-availability-(freebusy-data).aspx
> http://wiki.zimbra.com/index.php?title=Troubleshooting_Exchange_Freebusy_Interop
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>
--
______ http://kdab.com _______________ http://kolab-konsortium.com _
p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium
____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de Dr. Gunnar Wrobel
Tel. : +49 700 6245 0000 Bundesstrasse 29
Fax : +49 721 1513 52322 D-20146 Hamburg
--------------------------------------------------------------------
>> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/devel/attachments/20090910/bd49b6ef/attachment.sig>
More information about the devel
mailing list