I love the internet. The community factor is what makes it stand out and drive us forward and see things in a new light (well, at least for me). Tuesdays post on comparing DotNetNuke and SharePoint was about the features each offered. In that post, both Rob Howard (Community Server) and Shaun Walker (DotNetNuke) made some interesting comments.
Rob corrected me about Community Server:
DNN and SharePoint are both portals - we (Community Server folk) are not positioning Community Server as a portal. Rather, Community Server is a platform used to enable community applications. We just had a team in Redmond last week at a SharePoint lab. Furthermore, Community Server has been designed, architectually, to scale out; easily supporting multi-server environments as well as the ability to off-load search (we actually offer an Enterprise Search in 2.0) that is completely file system based. Community Server is designed to empower sites such as www.hive.net and blogs.msdn.com.
Shaun Walker posted a couple of messages about DotNetNuke:
DotNetNuke is not a portal. DotNetNuke is a Web Application Framework. You can use the services in the framework to build portals, but you can also use them to build many other types of applications including standard ASP.NET web applications, community sites, intranets, extranets, and vertical market application service provider ( ASP ) applications. In reality, it is a rich service layer on top of ASP.NET which eliminates much of the mundane coding required to build a web application from the ground up
This really gets my noodle cooking as it starts to question what we think of as a web application, a framework, and a portal doesn't it?
Rob Howard said that CS was a framework as well, and you could build web apps from it and basically leverage what they've already done in CS. Saying DNN is a framework isn't any different than saying WSS is one, or SPS (although zealots will argue that WSS is the framework/platform and SPS is the product).
I mean I can build a web app inside of SharePoint and leverage all the features it has. I can ignore the default.aspx page that comes with a site definition and completely create my own (in fact I can create lists and everything else programatically and not both with xml). For example if I don't want to use SQL database tables to store my app data, I can create everything using lists and just never expose the interface to the user. And if lists are too restrictive (no referential integrity, size limits, performance, etc.) I can still use my own table for some of these things (after all, SQL is available to me in the infrastructure). My web application can be just a bunch of web parts that read and write to SharePoint lists and render out from a single Default.aspx page. In fact I could build DotNetNuke (with less code) using SharePoint (which is odd if both of them are a framework).
The problem is (with SharePoint, DNN, and CS) is that you would have to really do a LOT of customization to any one of these "frameworks" to build a vertical market application, at least if you took the subtractive approach and tried to build something by removing what you get OOTB. I agree that it is a rich layer on top of ASP.NET but it's not much different than any one of the vast number of UI tools (Infragistics, etc.) that enhance say DataGrids and Web Forms with additioinal functionality. Sure, these are enhancements to base controls in the .NET framework rather than consuming services but it could be considered mincing words. With each of these come restrictions and I'm sure (although I haven't looked) I would have the same with DNN if I tried to build something other than a DNN site with it.
Maybe I'm wrong but we seem to get back to say ASP.NET 2.0 with all it's features (membership, roles, web parts, master pages) can provide what we need, so what exactly are you really getting from any of these other services? Grant you, if I want to have say alerts sent to me when an item is updated in a document library, the SharePoint services handle that for me. If I was building in ASP.NET 2.0 I would have to have my own component doing this (and something to store the documents, etc.). The same for DNN as it provides some services you can use, but again to build say an eCommerce application on top of SharePoint/DNN/CS is a lot of work (grant you, less work than building it from scratch but still no walk in the park).
Windows SharePoint Services, the foundation piece that provides structured lists, notifications, search, etc. is something that can be leveraged as a platform to build web applications from but most people don't see it that way (the same way most people don't see DNN or CS as anything but a community site or set of forums). I think that's the sweet spot we can get to where you can leverage these things as services so rather than building a new Web App in Visual Studio, why not have a new "DotNetNuke Application" or "Community Server Application" or "Windows SharePoint Services Appliation" as an option? Ahh, the lightbulb comes on.
I think the DNN Starter Kit that they've built with version 4 starts down this path. So why not say have a new item in Visual Studio that addresses this for SharePoint. I'm not talking about building a new Web Part as we have that template, but something bigger. Imagine starting up Visual Studio and seeing "Windows SharePoint Services Application" in the list of C# Project types available. This would a) create a top level site on a server running WSS b) create a new project for you with a default.aspx page, much like what you get with creating a new ASP.NET Web Application c) add new items to the system like Web Part, Web Part Page, etc. Now that would be a web application framework.
However it does pave the way for looking at WSS, DNN, or CS in a different light and rather than building little doofers that connect to each other, what we might be missing is the glue that binds it together. Actually, we've had the glue all along, we just need to repackage it so it's more useful.