Exchange Data Provider for Lightning

Bug #595551
Comment #12

Comment 12 for bug 595551

Revision history for this message

In Mozilla Bugzilla #247486, bvdbos (bvdbos) wrote on 2007-04-19:

#12

for qa-discussion:
I have been thinking about this (sorry Pete: have been thinking for quite some time). This is a valid user-case which should be solved if we want to provide (more failsafe) support for sharing calendars. If we use external webdav-providers over which users have no control (pete says messagingengine.com, I know icalx and there are numerous others) people won't be able to set the permissions for different users (hence they can't use one username for accessing calendars for multiple users).

I have a remote webdav for which I set the url to http://user1@domain/cal.ics. After lightning (2007041205) asks me for my password I can see the calendar and the password is stored as "domain (realm)". Everytime I restart I'm asked again for the username and password (both are empty while the password-manager shows the correct username and password). If after a restart I login with the credentials of user2 which has the same rights as user1 strangely enough there's no problem anymore after restarting. I would expect the same behaviour as with user1 which could be caused by checking "user1@domain" against "domain" in the password-manager but apparantly something else is going on?

All problems with realms etc could be avoided by including the username* in the url for password-manager (and don't add the password if this is included in the url). The only disadvantages I can think of are that we use multiple connections to one server where we -might- be able to use just one and that the credentials for the server have to be entered and stored in the password-manager once for each account.

other providers:
The same sort of thing applies to caldav-provider if I read bug 371753 and
http://forums.mozillazine.org/viewtopic.php?p=2848310
correctly. I don't know wether there are external caldav-providers already? gdata-provider names the server the same as the username, so no problem with that (no multiple usernames for one server and/or realm). ftp does this correctly already (including username in url). I don't know exactly how wcap handles this (I have no wcap-server).

* let me refer to bug 273478 comment #3 where it's usefull to ask for a username when creating the calendar. We could do that also with webdav and caldav, gdata does this already.

for qa-discussion: 
I have been thinking about this (sorry Pete: have been thinking for quite some time). This is a valid user-case which should be solved if we want to provide (more failsafe) support for sharing calendars. If we use external webdav-providers over which users have no control (pete says messagingengine.com, I know icalx and there are numerous others) people won't  be able to set the permissions for different users (hence they can't use one username for accessing calendars for multiple users).

other providers:
The same sort of thing applies to caldav-provider if I read bug 371753 and
http://forums.mozillazine.org/viewtopic.php?p=2848310 
correctly. I don't know wether there are external caldav-providers already? gdata-provider names the server the same as the username, so no problem with that (no multiple usernames for one server and/or realm). ftp does this correctly already (including username in url). I don't know exactly how wcap handles this (I have no wcap-server).

* let me refer to bug 273478 comment #3 where it's usefull to ask for a username when creating the calendar. We could do that also with webdav and caldav, gdata does this already.