What I learned from the DAL Project proposal was that it is not necessarily important for the DotNetNuke Core to adopt the code from a proposal as it is to adopt the “spirit” of the proposal. In the case of the DAL proposal, none of the proposed code was used, however the final implementation (the DAL+) achieved all the goals (reduction in code and complexity, supports multiple databases).

If the Core were to implement its version of IWeb today, here are the things I would say are the “spirit” of IWeb:

·         Simple AJAX Authentication – When you call a web service from an AJAX method, providing proper security for the method is not straightforward.  See this article for the IWeb solution. This solution achieves these goals:

o   The DotNetNuke password is never displayed on any page or transmitted over the network.

o   The encrypted password changes each time the page is accessed so a page (and the username / encrypted password combination) retrieved from the web browser cache (for example if the page were accessed at a public internet cafe) will contain a password that has either been changed, expired, or due to expire soon (the last username / encrypted password combination expires after 1 hour. This can be set to a lower number for greater security).

·         Web Service Method Security – It is easy to provide security for web service methods created a single application. However, if you want to share and reuse the web methods you are now required to implement a centralized security system. IWeb provides this.

·         Implement Common Methods – Authenticating a user requires that you first determine what portal the user is a member of. Next, you must make a series of calls to the DotNetNuke API to authenticate the user and retrieve information such as their current role (you never address the database directly because since it is constantly changing your code will likely break when the DotNetNuke site is upgraded). If most web methods need to perform these sorts of tasks, why not create methods that perform these steps for you? IWeb provides this.

If or when the Core adopts IWeb, it will be in a different namespace so you don’t have to worry about IWeb breaking or causing conflict. As it is implemented now, IWeb is just another module that carefully conforms to the DotNetNuke API.