Ok...I am sure they have and I know there have been some spin offs, but I didn't follow any since I saw Shaun's (Should we call him Mr. Walker now? ha ha ) wisdom in advising against the spin offs so I didn't follow any of them.  It's late and based on my current project it looks like I will be in DNN land for a year or so - so I figured I would go legit this time and begin to "interact" with the community at large, lol and stop just reading the forums and throw some ideas out there for discussion at large.

I had this concept working on a project about 2 years ago under a web service using a modified DNN 3.x core - but for other reasons the project was discontinued early on.  But it was cool ( and performant) to call up a UI and switch customer x to a given implementation of a dll on the fly while others ran a different implementation.

  The attraction was in a nutshell to allow multiple implementations of a provider to run concurrently based on factors like the Customer ID...say for instance you are dealing with API's - for sake of argument say a billing component with complex business logic whose abstract provider definition sits in it's own assembly.  You run one implementation for a few months, years, etc then the rules change - but the current customers are grandfathered in under those rules so the original implementation is still in effect and new customers will be subject to the new rules.  By moving the provider information into the data store and setting a configurable path to look for applicable providers (that were of the abstract interface type) - I could put a very friendly UI in the application itself allowing admins to control what implementation of business rules various Audience types (Roles, customers, etc - be creative) used...and configuring these provider's options was easier than cryptic web.config settings which have no good way to indicate multiple providers on a per customer basis or discover their own providers by interrogating assemblies in a known, trusted location for that matter.  In that case I needed some customers to have there own physical db store and have their own implementation of business logic potentially (more like groups of customers on the implementation) and to have this configurable within the site itself...the core provider interface was steady though was implemented via super classes to afford backward compatibility.

Anyhow the specter has raised it's head again so I wanted to put the question to the community out of curiousity...go ahead and call me crazy

I also am hoping to see the codesmith templates for VS 2005 and 4.x show up soon on smart-thinker, (Rod if your listening , ha ha) - I appreciate the ease of the dynamic custom modules - but on everything I do it involves an external class library for re use (rather than a code base in the app_code folder when that code base could be leveraged domain wide in smart clients, windows services, etc). 

  I have not seen a single walk through, article, video, etc on building a custom module in 4.x that is loosely coupled from the core (without setting references in the DNN web project) that leverages an external BLL assembly that will run against a clean install of VS 2005.  The Compiled module project template requires a VS add on to change back to the .net 1.1 compilation model and I haven't had the time to checked it out yet - does it force all future web apps to use this model or is it just an option, how cleanly is it implemented, etc anyone know?

  I need complete separation of data from the core portal data, complete separation of my bll logic into it's own assembly without any modification of the core dnn to allow for smooth future upgrades - I can rig it myself but was surprised there are no articles on this I could find - am I missing the boat or does anyone know of any?

Ideally I would like to implement an MVP pattern with a provider sitting in the model portion as well (haven't seen anything on this applied to DNN personally either - anyone?) 

 For my next hare brained contentious though - I have often leaned toward a dual abstract provider model - one for the DAL strategy that takes idatareader and returns objects that insulates against using various stores and another abstract provider to insulate against multiple business logic strategies - whereas classic DNN marries the two into a single component...but perhaps that's a different discussion. 

be kind in your responses please , - something more than you're loony for instance

Hutch