On Thu, 2007-08-30 at 23:48 +0930, Dan Shearer wrote: > I think currently the logical separation between libmapi and > libmapiadmin is this: > > * libmapi exposes Exchange to users > * libmapiadmin exposes an Exchange view of AD to administrators > > Do I guess correctly that you wouldn't expect implementers to provide > both libraries to all end users, because end users should not need > libmapiadmin?
Right. > I propose we need another function very similar to those in > mapiadmin_user.c : > > mapiadmin_user_info(struct mapiadmin_ctx *); > > There is one case where unprivileged users need access to this function, > which is automatic profile generation. Users can provide valid AD > credentials, and mapiadmin_user_info can find the Exchange mailbox > location. > > One use for this would be: > > mapiprofile --autoprofile --aduser bla --adpassword bla --default > > which would create the profile and make it default. We can do it, but will have to provide DC address instead, unless we already have an existing profile (such as Administrator one) which is not what we want, right? Do not forget DC address can be different from Exchange one. User may not know about it and shouldn't be required to. > The are two reasons to implement this: > > 1. Users never need to know where their mailbox is kept, and in the > real world usually don't, and > > 2. Outlook 2007 does this when a user logs in for the first time. > > So, imagine this feature is added, what does this say about the design > split between libmapi and libmapiadmin? I think we should keep libmapi and libmapiadmin separated: - Classic profiles (ExchangeRPC) are created through NSPI - Auto-discovery facility is provided through LDAP in libmapiadmin Anyway, mapiprofile can perfectly be linked both to libmapi and libmapiadmin. -- Julien Kerihuel [EMAIL PROTECTED] OpenChange Project Manager GPG Fingerprint: 0B55 783D A781 6329 108A B609 7EF6 FE11 A35F 1F79
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list [email protected] http://mailman.openchange.org/listinfo/devel
