Exchange Data Provider for Lightning

Bug #595551
Comment #32

Comment 32 for bug 595551

Revision history for this message

In Mozilla Bugzilla #247486, Mrmozilla (mrmozilla) wrote on 2010-04-25:

#32

I think I have the same desired behavior/UI in mind as every other user complaining about this bug, and this is it:

* I describe remote calendars to lightning as triples of:
    a) user-visible identifier (the name that shows up in Lightning UI)
    b) a URL for the resource
    c) a username/id for authentication
* When connecting to a calendar, Lightning asks me for the one remaining piece of missing information, a password.
* That's it.

I, the user of a calendar, do not care about what realm id happens to be returned by the remoter server over whatever wire protocol happens to be used to get to the calendar data. I just care that for *this* calendar, I am identified to the server with *this* id --- and for *that* calendar, I am identified with *that* id. The two servers might be the same; the two calendar URL's might even be the same.

I also don't want Lightning to pop up a dialog box that asks for both a password *and* a username. For any calendar that I have configured, I knew the intended authentication username when I configured it, and it's not going to change, so Lightning should never have to ask me for it. (I knew the password, too, but I might prefer to type that in for every new connection and not have it cached somewhere.)

In other words, I want Lightning to treat calendars the same way that Thunderbird treats email. I want to set up a named account that points to some folders on some server under the auspices of some identity. And I want to be able to do that multiple times, potentially using different identities for the same server and same folders. Maybe I want this because I'm ignorant of how ACL's work, or maybe the calendar service I am forced to use doesn't support ACL's... or maybe I know all about ACL's and I want to *test* them without setting up multiple independent thunderbird/lightning profiles. Nothing about this functionality prevents me from using ACL's properly to access Boss B's calendar under the guise of Assistant A --- the use of ACL's to relate resources to authentication id's is orthogonal to this bug.

No, I don't care if the underlying calendar resource is served via an HTTP-based protocol, or FTP, or telnet, or gopher. CalDAV vs WebDAV/ICS? I don't care --- I still want to be able to access the same server using multiple identities. Just like I can freely "ssh <email address hidden>" and "ssh <email address hidden>" without logging in to my laptop twice. If I happen to have two or more sets of credentials for accessing the same server/calendar/resource, I want to be able to use them all.

I really don't understand how this can issue can linger on for six years without being acknowledged as a plain old flaw in the interface. Is there something in the fundamental Lightning architecture that makes this dicey to fix?

I think I have the same desired behavior/UI in mind as every other user complaining about this bug, and this is it:

* I describe remote calendars to lightning as triples of:
    a) user-visible identifier (the name that shows up in Lightning UI)
    b) a URL for the resource
    c) a username/id for authentication
 * When connecting to a calendar, Lightning asks me for the one remaining piece of missing information, a password.
 * That's it.

I, the user of a calendar, do not care about what realm id happens to be returned by the remoter server over whatever wire protocol happens to be used to get to the calendar data.  I just care that for *this* calendar, I am identified to the server with *this* id --- and for *that* calendar, I am identified with *that* id.  The two servers might be the same; the two calendar URL's might even be the same.

I also don't want Lightning to pop up a dialog box that asks for both a password *and* a username.  For any calendar that I have configured, I knew the intended authentication username when I configured it, and it's not going to change, so Lightning should never have to ask me for it.  (I knew the password, too, but I might prefer to type that in for every new connection and not have it cached somewhere.)

In other words, I want Lightning to treat calendars the same way that Thunderbird treats email.  I want to set up a named account that points to some folders on some server under the auspices of some identity.  And I want to be able to do that multiple times, potentially using different identities for the same server and same folders.  Maybe I want this because I'm ignorant of how ACL's work, or maybe the calendar service I am forced to use doesn't support ACL's... or maybe I know all about ACL's and I want to *test* them without setting up multiple independent thunderbird/lightning profiles.  Nothing about this functionality prevents me from using ACL's properly to access Boss B's calendar under the guise of Assistant A --- the use of ACL's to relate resources to authentication id's is orthogonal to this bug.

No, I don't care if the underlying calendar resource is served via an HTTP-based protocol, or FTP, or telnet, or gopher.  CalDAV vs WebDAV/ICS?  I don't care --- I still want to be able to access the same server using multiple identities.  Just like I can freely "ssh user1@example.com" and "ssh user2@example.com" without logging in to my laptop twice.  If I happen to have two or more sets of credentials for accessing the same server/calendar/resource, I want to be able to use them all.

I really don't understand how this can issue can linger on for six years without being acknowledged as a plain old flaw in the interface.  Is there something in the fundamental Lightning architecture that makes this dicey to fix?