Jesse Ezell piped up about what he saw as a design flaw in the Membership Provider that ships with Whidbey. Rob Howard then commented and blogged about the asp.net teams decision-making process there, saying that they had struggled over the same issues.

I've been doing some provider work myself, on a little pseudo-secret project I've been working on for a while, and I've come to my own conclusions on the issue. I think that the System.IO guys got it right with the Stream class. Instead of an IStream interface, or a IReadStream/IWriteStream/ISeekStream interface mess, they have an abstract Stream class that has the Read/Write/Seek methods. Of course, not every stream can support these ideas, but just trying to call them, waiting for a exception, isn't the right path, so they also included CanRead, CanWrite, CanSeek properties.

This model, where you can query the implementor for it's supported functionality, gives you a great story for both developing custom provider implementations that can't suppport everything, but support what you need, as well as extending the the base provider with new methods without fear of breaking current versions implementations.