Idea Accepted

So I got over the first big hurdle yesterday. I had a 4 hour meeting that went until 7:30 last night with all the main system architects, including the CEO of the company.

So here's the concept:

There will be a main web application architecture that will host "applets". Each applet is nothing more than a page with four possible points of functionality and it's own assembly. Each assembly will derive from a super-class that the framework will provide. The Framework will also provide the security context, security roles, application management and basic Framework functionality.

Think of it this way: A user logs into a web application with a username, password and domain name (I'll explain that some other time). Once he is authenticated the Framework loads up his last application. In some cases a client will only have one application. In other cases clients may have multiple applications. An application is nothing more than a security context.

Each Application has it's own set of Roles. Each page and page functionality adheres to the roles for that application for that page for that functionality.

The Framework because nothing more than a delivery method. A way for use to have a group of developers create applications and not every have to worry about the security context for that client.

I am working on a database schema right now. As I go along and discover the gotchas, I'll report back here!

DotNetNuke - The Web of the Future > Home ( DNN 3.0.12 ) - Just not yet!

DotNetNuke - The Web of the Future > Home ( DNN 3.0.12 )

I would like to start off by stating that I like all of the concepts of DNN. I like DNN for personal use, but maybe not as a container for such an ambitious application that I was given.

I have been playing around with DNN for several weeks now. My final opinion- use it at your own risk. This week alone I have had to reload the application from scratch (DNN 3.0.12) because some funky situation happened that completely locked my application with some generic error message.

After discussing this with my bosses (yeah, most of us have them ;)), we have decided to write our own. I will now shift my discussion to the new application architecture that I am about to embark on. I have used bits and pieces of it before, but not in one giant app like this. Unfortunately, since I am writhing this on the behalf of my employer I cannot divulge any real source code, only snippets. Maybe we will sell it someday as an architecture ;).

DNN Chronicles

Not so long ago, in a galaxy called DFW there was a need. A company wanted to deliver a software product using a single codebase for multiple tenants. The trick was that they wanted to do as much of it as possible over the web.

During one of our many design meetings, someone mentioned looking at DotNetNuke. We needed to deliver something that was almost like a portal, except that it was intended to deliver a set of functionality, not content. So I looked.

I was overly cautious about it at first. I always am about freeware. I have always felt that you get what you pay for. But from the release of DNN 3 this weekend, on this one I was wrong.

We have taken the step to declare that we are going to use DNN 3 as our platform. So over the next few weeks I will report the experience here. I hope that you get something out of it.

Here is a list of what our basic requirements:

1. Must be a multi-tenant system.
2. Must provide a better-than-average security framework, roles based.
3. Must be able to deliver new functionality with ease.
4. Must be able to support functionality in a single codebase across all tenants.
5. Must be able to manage different functionality to different tenants based on tenants needs.
6. Must implement industry best practices.
7. Must be highly preferment.
8. Would be nice to have some control over look and feel per tenant.
9. Would be nice to give some control over content to each tenant.
10. Would be nice to have a path to deliver the same functionality to devices other than a browser.
11. Must be able to support multiple languages from a single codebase.

There is a long grocery list of extended functionality that is specific to our service, so I won't expose those here. These 11 are the core points that made our decision to use DNN.

At first, I was thinking I would just write it myself. I have written web software that does all of this before. But the developers of DNN have really saved me tons of time, as well as delivering a state-of-the-art system. I have to admit that the way they did certain things is not how I would, but most of it is.

So, I have to get back to coding now, but when I get time I will start dissecting and checking off this list.

-Brian

Test Balloon

Here's the idea:

I want to build a generic XML based standard for providing a publish/subscribe scenario for calendars. I want to turn this into a discussion board for it. I may eventually move it off to a workspace, such as GotDotNet.com or SourceForge.com.

Details:

There are tons of calendar applications. There's personal calendars (Hotmail), corporate (Exchange), and community (DotNetNuke). The inherit problem is that almost all of the calendar applications that exist today are all sealed systems. There no goodway to get information out or in them, and you can forget syncing calendars together. Plus, there really needs to be some common programming interface for using these valuable resources in programs today.

An example of the latter would be a scenario where you had to communicate with a resource. Let's say that you wanted to chat with me, but didn't know why I wasn't responding. If I could publish my Exchange Calendar information in a way that you could subscribe to it via MS IM, then you would know that not only am I not available, but I will not be available for another 2 hours.

So, Here's what I want to do:

1. Develop an XML standard communication format
2. Develop a standard communications process.
3. Develop a web service with a plugin architecture that will allow people to add the publisher to there system.
4. Develop some applications that consume and subscribe to the service.

Any suggestions? Ideas?