I always shudder when running a Java-based application in windows. Everything from Azureus to Open Office. Even FireFox leaves me feeling like it is a second-class application. They just don't "Feel" or behave as standard windows applications feel or behave. Instead, they behave like a mishmash of Linux, OSx, Windows, and a handful of "open-source" UI libraries, while at the same time inventing a whole new parody of UI bahaviors and visual cues.

I've always not liked Java applications for this reason. And other applications like RealPlayer, Windows Media Player, and other heavily-skinned applications leave me with the same bad taste in my mouth. Sure these applications can be tastfuly good looking (Except real player which feels the need to skin EVERYTHING differently). But they don't behave like the rest of my system.

Before, I'm not sure what was quite wrong with that. I just knew it was bad. From a usability standpoint, from a user experience standpoint. But now, I know the real reason.... None of those applications (And ESPECIALLY THE JAVA APPLICATIONS that use Swing or GTK) support standard accessibility guidelines. What happens if the user is using a screen reader, and your lables and text boxes are using some strange non-text-box or non-button to represent a UI cue? Will the blind reader be able to find your mishappen button? I doubt it.

Consistent UI provide a smoother user experience without jarring speed-bumps when moving from application to application. Handicaped users require special support....usually ignored in alternative UI libraries, while each platform has its standard. Once Windows starts supporting more dramatically themed UIs (like in Vista) I want my applications to automatically look like a vista application.....not like a 10-year-old Windows 95 application....and certainly NOT like a Swing or Java application. If I right-click on a text box, I fully expect my "Undo, Cut, Copy, Paste, Select All" menu to appear. But if I have an IME enabled for asian text input, I had better see my Unicode and Right-to-Left options in there. And my IME should at least WORK in every text box. You'd be suprised how many open-source applications just DON'T WORK with screen readers and asian text IMEs in Windows....

And these open-source people just don't understand why more people aren't supporting open-source..... Did you know that Asia has one of the slowest adoption rates of Open-Source software in the world, but at the same time it has the number 1 concentration of pirated software? I wonder why?

It's a little-known fact that NTFS supports folder linking....like mapping a drive letter to a folder on your C: drive, or mapping your My Documents folder to your M: drive. But did you know that you could map (link) any folder anywhere on your drive? I've been using shortcuts for this myself for the longest time, and they work well enough, but it's annoying that the shortcuts to folders aren't sorted in with the folders, they are sorted in with the files.

Well, you can't create these linked folders (or files) with the built-in Explorer commands. Thanks to HanselMinutes, I've found a way to create and make these links useful. You can use something called Junction from SysInternals (one of my favorite companies). But it's a command line tool. It's much cooler to have it in the windows GUI. So a really smart guy put it all together, and created this cool little utility which is an explorer shell extension. Using the Right-button-drag menu, you can create a link. Better yet, it overlays a little chain link graphic onto files or folders which are links! It dosn't get any better!

Windows does not support creating Links to folders on network shares, but when browsing a drive with links over the network, users should see the linked folder appear as expected. It's like DFS but better!

Last but not least, the old DOS "subst" command still exists for mounting a folder to a drive letter. But links are so much cooler!

Just think of what tools like these could do for complicated build processes that depend on hard-coded or configured paths!

You heard it here first. I just came up with the idea of an MMORPG, but integrated with all the Web 2.0 goodness that you all know and love.

Imagine playing that MMO game where you can take a screenshot or use an in-game camera-like accessory to take pictures and photo-blog them from within the game. You could blog about your Everquest Wedding, or your experiences in a certain dungeon. You could blog about that pirate that blew up your latest T2 ship.

But of course, blogging is not the only thing required to be Web 2.0. How about downloading new clothes (skins applied only to the clothed portion of your character) from the town weaver? Or allowing highly skilled "industrial" characters to publish RSS feeds. It could even turn into a system of mercenary recruiters? Pay a few credits to subscribe to a list of high-level players that will help noobs with difficult quests. A player-operated bounty feed? How about an "item wanted" feed? Seriously, this web 2.0 stuff could be it's very own market economy in-game.

People could even "blog from the spot" ... like when 50 friggates descide to take on the newest carrier (Eve), or maybe that gathering where 200 naked necromancers were dancing in sync (Guild Wars)?

What else makes web 2.0? Oh yeah! Tagging! In Eve, players can buy cargo pods and leave them in space. The higher your level, the longer your cargo pod can stay. People can always come and blow it up, but it's a crime. Unfortunatly, the most common use for such pods is as advertisements for joining player corporations. Seriously. Let us just tag the game world. "I died here", "Beware of dragon", treasure hunt riddles, "Vista Point", "Maximum Occupancy" for a small shop.

Some MMOs already integrate a lot of the ideas of a social network into the game. In EVE, players have standing relative to eachother, their corporation membership, the faction they belong to, their race, agents, and to other players. Then there's the security rating. Seriously, if I rate a bunch of people very low, then I should see other pepole start being rated low because players like me rated them low too (like movie ratings on Netflix). And preferred merchants: Your friends liked to shop at Joe's (Ebay and Netflix). Or "I see you already have 3 of the 4 items in this set, Sellers in have the 4th item." (Mixing Diablo with Amazon)

And here's the biggest kicker of all. None of these games allow people to trade real money for in-game cash or items .... BUT EVERYONE DOES IT ANYWAYS on ebay! Build it into the game. Make it so easy, that people can do it all the time. But keep an eye on the money-making loopholes (like macro-mining) and close them. Don't make it so easy to aquire super-rare in-game loot or massive quantities of credits so that it dosn't off-balance the economy, which is what most of these games are doing already. Let me put my paypal name or credit card number directly into the game, and let me do these transactions in-game.

And for god sakes, work with the instant messenger companies (MSN, Yahoo, AIM) and get instant messenger integrated into the game. (an integrated MP3 player would be nice too) So that I don't have to leave the game to answer my IMs.

It really surprised me when I played Guild Wars on my laptop and there was a battery status indicator in my HUD. What a great idea! I only wish more games would do this.

Lastly, display options.... Games hardly ever have widescreen resolutions in their options menu. I usually have to hack the config file or preferences, or command line to get my Laptop or LCDs native resolution working. And of course, the native resolution is a big problem. Who here has ever heard of pixel doubling? Would it really hurt you that much to offer that as an option if my laptop screen is super-high resolution and the graphics chip really couldn't handle it? It's so much better than running at a lower resolution, and either stretching everything horribly out of shape or squishing it into the center of my screen.

Oh, these are all my ideas. If you use them, buy me a beer.

CS-Wiki Licensing: To answer everyone's questions, I thought I had mentioned it, but the CS-Wiki project will be FREE (as in beer). The company I work for (db4objects) and I am releasing it under the GNU LGPL license. I work for db4objects full time (I love object databases!) and they are paying me to develop this CS-Wiki for our own uses. I wish I could modify the LGPL to state that anyone downloading CS-Wiki has to download and try out the db4o object database, but that isn't realistic.

CS-Wiki Requirements: Community Server 2.0 (currently, but it will require changes hopefully precompiled into CS 2.1), Microsoft .NET 2.0, IIS 6 or better (Windows XP or Server 2003). Community Server 2.0 also requires SQL Server 2000 or better.

CS-Wiki Release Schedule: Everyone wants to know when they can get it! The core functionality is DONE. The wiki is full and working as of now. A lot of my original wish-list features need implementation, but most are easily accomplished. I'm slated to roll it out live on http://developer.db4o.com in the next 2 weeks in time for the dUC 2006 db4o user conference in London durring which we will be using the CS-Wiki to take notes and publish conference topics. It will get a lot of testing. When I get back from the conference, I'll probably work on features for another week or two before the big public distribution. You'll be able to download your copy from any of these sites: http://communityserver.org, http://www.everylittlething.net/projects/CSwiki/, or http://developer.db4o.com.

Ok, now that all this is out of the way, what is done?

• URL Parsing: I had reported in Phase 1 that the URLs were done. That wasn't so accurate. The new URL parsing system is much more viable and allows you to have multiple wikis on your CS site. So you can have specialized wikis for different topics, or a private company wiki. Some examples are mysite.com/Docs/ and mysite.com/Wiki/ and mysite.com/Private/. Urls are now in the format http://mysite.com//view.aspx//Topic?Revision=99
• Configuration: The configuration has been reworked. I now entirely use the CommunityServer.config file for all configuration settings.
• Topic Sets: Topics can be arranged into folders, which I call topic sets or namespaces. MediaWiki can't do this, but some of the others can, and I think that it is highly desirable if you want to keep a large system organized. (It makes sense that Wikipedia does NOT arrange their topics hierarchially since there is a lot of ambiguity when trying to arrange every topic in the world. But most corporate knowledge can be classified.)
• Permissions: The system allows permissions to be defined for each role (ASP.NET Membership Role or CS role) per topic set. This was the only way to keep it managable with large numbers of topics. Since Topic Sets can contain other Topic Sets, the permissions cascade down unless redefined deeper down the tree. If permissions for a Role are not defined, then a set of default permissions kick in (defined in the CommunityServer.config file). There are also a list of Topic Set Owners who are specified by name who have the "Owner" role assigned to them. Oh, did I mention that this all WORKS?!?? hahaha!
• Topic Editing: Uses the standard user-selected WYSIWYG text editor. CS shipps with FreeTextBox.NET included. (I've started using FCKeditor on http://develolper.db4o.com and I like it much better. It's much more usable, but I dislike that it is so JavaScript-heavy.) After editing, I run the user's modifications through the full array of standard CSModules using the standard events. So all the things that you expect to work, like Tokens, Smilies, Censorship and Html-Cleanup all work on Wiki topics.
• Topic Links: I already said that I got topic loading to work. But I'm now happy to say that I got topic linking to work using the standard double-bracket syntax. [[RelTopicPathDisplay Text]] Oh, and it works in Forum and Blog posts too!
• Topic Printing: It's not impressive, but of course, you can print any topic. It only required a different page without all the CS styling. But it was a good test of the TopicView control I developed, and of Url Rewriting.
• Topic Set Managment: You can manage the topic set. Currently, all the information on it is readonly, except the list of owners. I need to add a UI to manage Permissions to this page as soon as possible.

What's next?

• Topic Set Management Permissions UI - Allow anyone with "manage" permissions to modify the permissions of the topic set. Non-Admins will not be able to modify the "Owner" or "Administrator" roles or "manage" and "admin" permissions.
• Create Topic Set - A UI to create child topic sets.
• List topics page - Similar to the "All Pages" special page on wikipedia.
• List topic history page - Lists a link to all topic revisions.

What's not going to make it in time for the public release in late July?

• Search integration - use google site searches.
• History diff viewing.
• Topic/TopicSet renaming & merging.
• Orphan Topics

What's probably not going to make it into the first release?

• Individual themes/templates per TopicSet.
• Executable wiki topics - every Wiki Topic is supposed to be an ASCX control with the capability of hosting rich ASP.NET interactive controls like specialized info boxes.
• Auto-generated page contents.
• Topic Set discussions/comments
• Wiki Configuration UI - To admin the default permissions and root topic sets.

So I guess the first release is going to be a "feel good" beta. Don't wory about the features that aren't making it into the first round. They will definately be added shortly since they are highly desired by myself and my own team of testers and guinea pigs.

Seriously, I paid $3.29 per gallon this morning....
(Thanks Ryan for the image)

Some more news about the Community Server Wiki that I've been working on. Things are falling togther instead of apart. I got held up for a bit in part of the URL and link resolution, but it's turned out really sweet. The system is capable of creating new topics and linking between them! All while keeping the URLs nice and easy to read. Next is to add the permissions hooks and resolution, which shouldn't be too hard.

Come on. This isn't hard. Why is it that NO manufacturer can get it right. My requirements are simple: VPN PPTP access to my home network from a standard Windows XP machine with NO SOFTWARE INSTALLED via a solid-state router (no extra PC in the closet).

What's so hard about this? I've now purchased 4 or 5 VPN routers and returned them all. First I started off with the LinkSys WRV54G. This product was horribly underdocumented (as they all were) and had some super-silly limitation... I forget exactly what it was, but it was some silly limitation.

Now we move on. Next was the DI-824VUP. This product seemed like a dream come true. Fast wireless, VPN server, and Print server in one. Awesome combo. but... it fixes the IP addresses of the connecting computers in a seperate IP subnet from the local network. What the friggin' point is that!?!? A lot of playing arround, and I figured out eventually that the router routes traffic between the two networks... and you can do some things, but only if you access all the machines by IP address.

Ok. Moving on. D-Link tech support indicated that their VPN filewall line was much more flexible. I like D-Link products. I really do. So I gave them a second chance. The DFL-200...much better. At least it gave an IP address in the same subnet. But again, it did something wierd with the VPN client. The VPN client is given a subnet mask of 255.255.255.255. Basically it won't broadcast NetBIOS requests beyond itself. Effectively, only being able to access my server by IP address (or DNS).

D-Link lost my money again. So much for being all VPNC certified and stuff. Next.... the NetGear FVG318. Another interesting product....if only it worked. The first-rate tech support absolutely assured me that PPTP was an option on this router and that it worked as a PPTP endpoint, etc, etc. HA! ummm. NO! it doesn't. This would all be sooooo eassy if I wanted to use IPSec with their special software. But I want to be able to use a standard XP install to connect.

Well, back to where I started. Cisco has been pouring money into LinkSys, and the attractive little LinkSys RV042 in the new LinkSys business solutions product line. It is supposed to be an entire Cisco PIX firewall packed into a little metal case and made all consumerish. It held a lot of promise. The IPSec options and the included client software (thank god they give you a half dozen client access licenses) seem to work well enough, but I immediately took them off. After patching the firmware, I noticed that it has a PPTP server. Excelent. Oh, and I can connect to it. Wonderful. And the IP is in the same subnet as my private network. Another plus. But, it still gives me a subnet mask of 255.255.255.255. :( too bad. And of course, NetBIOS completely chokes up. I'm in a chat session now with their tech support. I've been describing to them for 30 minutes now that I have the VPN router set up between 2 computers here on my network AND THEY CAN'T TALK....but I can ping by IP.

What in the world do they feed these people to make them so dumb? And do any of the developers for these manufacturers expect anyone to actually use their products?

One of my longtime goals has been to see a book on db4o available on the common bookstore shelf. To me, this is one of the best indications that a technology has become viable in the mainstream for common consumption. Technologies like AJAX, POJOs, Ruby, and Hibernate didn't recieve their share of industry attention until the books started hitting the sleves. In a way, the release of books is like an indicator that a technology is aproaching critical mass. If you don't know what db4o is, go download the completely free (and open-source) SDK, and go buy the book. If you visit this link, you can download a few sample chapters too.

When I started this project, I had really intended it to be an adaptation of the Perspective wiki engine.... well, I'll just come out with it... This is a whole new wiki. I'm building it on top of CommunityServer, and about 60% of the framework is provided by CommunityServer. Another 20 or 30% of the system is patterned after CommunityServer, the rest is self-created, but inspired by MediaWiki, DocuWiki, and FlexWiki, and I've got features in my mind inspired by JotSpot that I also want to integrate. If this turns out even half as good as it is in my mind, this is going to rival the popularity of all of the big Wiki systems...but better, because it will be completely integrated with CommunityServer too.

Over the weekend, I descided to revamp some of the configuration organization. One of the design parameters that I'm working with, is that a CommunityServer site must be able to host more than one wiki "zone". Since Wiki topics can be templated, it only goes to say that a site may want to have the topics following one template to be promoted to their own section.... I won't go into too much detail, but you'll see why up at http://developer.db4o.com when July comes.

Oh, fans of CommunityServer will be nice to know that I got all of the wiki topics formatting and processing through the standard formatting CSModules. I've even been able to create a new module to resolve wiki links in the forums! You'll be able to to put [[Wiki Links]] directly into your forum postings!

The reason I never relased the source code to GlobalResource was because I had to use some commercial controls to build it. Thus for anyone else to be able to compile it, you'd have to own a copy of the Infragistics WinForms controls.

I do believe it's time for a GlobalResource 2.0...based on the new .NET 2.0 DataViewGrid control. I think it will actually be possible to make it work better too. Unfortunately I don't have lots of time to make this change. If someone is interested in undertaking this project, let me know, and I'll share the source with them.

Vista is still over the horizon, but .NET 3.0 just got bumped up.... As reported on Slashdot and eweek: What everyone was calling .NET 3.0 is now 4.0.... The WinFX framework is now part of .NET 3.0. The Wikipedia entry for WinFX has already been updated.

Many sources are reporting this namechange alongside the release of "MSDN Wiki Beta". I am happy to say that the MSDN "Wiki" is not a wiki, but a glorified comment system. The system is already live here: http://msdnwiki.microsoft.com/ browse to a few pages, and you'll see a section at the bottom labeled "add new content". Your additions will just go into the bottom of the page. About the only improvement over the old comment system is that they give you a WYSIWYG editor, and that the comments are visible to other users, and that you can edit other people's comments. So each comment is supposed to be an atomic piece of useful information to live on its own. Very interesting.

Using a wiki for documentation is not a new idea. Nor is Microsoft's approach to "bolt-on-topics" a new one. On the other hand, I think it's a great approach, as long as they give the system enough staff to maintain and process the edits. I like it because the core documentation is canon for most Microsoft developers. Anything which could cause topics to possibly become more ambiguous is shunned and burned at the mention. But this keeps the core content clear and useful. Hopefully their editors will migrate useful user comments into canon.

Wow. Google is at it again. Want to know which cabbie agency has more cabbies in your area? Just look at the map!

http://labs.google.com/ridefinder?z=8&near=San%20Francisco%2C%20CA&src=1

So...3 days have past. I have to say that the Community Server guys really built a system that has everything. So much, that it's almost larger than the .NET Framework itself. I only wish it was as well organized. There is so much functionality scattered arround, that you find yourself digging through code. I start in the UI layouts, and say, I know they must do something with a piece of data here...then I have to dig my way up their chain of content to find the source of that data. It's very frustrating, but you learn a lot about how it is built. I really dislike that they made Community Server 2.0 backwards compatible with .NET 1.1. They should have gone the whole way to .NET 2.0. There's a lot they could have made better.... Formatting dates is one of them. In .NET 1.1, you could convert a DateTime to UTC, but there was no easy way to go forwards. Plus, there was no easy way to tell if the date that you had was UTC or not. In .NET 2.0, they added the DateTime.Kind property and some extra formatters. In CommunityServer, the same functionality is split up between a Formatter helper object, UserTime helper object, and the User and User's profile.

The wiki so far is doing GREAT! I've got a lot of infrastructure in place, and it's working like a charm. Here's a short list of features working so far:

• Community Server page layout: The wiki pages are all displayed within a CommunityServer master page layout. (Hopefully CS 3.0 will upgrade to .NET 2.0 master pages)
• URL Rewriting: No ugly URLs here. URLs will be formatted like /wiki/view.aspx/CollectionName/TopicName. Tested extensivly to make sure they're working. (Another CS feature that I had to figure out how to use by trial and error.)
• WikiContext: Topic and Namespace resolution. Since each page views precisely one topic or one namespace, then the static context object is responsible for parsing the correct IDs from the URL.
• Topic and Namespace loading: Modular providers are in place for reading the topic files from disk. SQL providers can be written later, since I'm coding to an interface. I'm also using the standard CS Provider framework to configure and resolve the providers. Topics and Namespaces are objects serialized into an XML per topic, each Namespace in a seperate folder. All is working. Topic content is stored in CDATA objects.
• Configuration: Since I want to be able to host multiple Wikis on our site, I didn't want a global wiki configuration, so the Wiki configuration couldn't be stored within the CommunitySerer.config file. Configuration is in the Web.Config using custom section objects. FileSystem Storage is configured in a seperate custom section. This way you can put a web.config in each folder where you want a wiki to appear.
• Topic Viewing: Yes, topics are being displayed! A lot more needs to be done here, but they are coming up onto the screen.
• "Ambient" Info controls: Controls which will appear on every page: The breadcrumb, About This Topic (topic data like last modified by, revision number), and Topic Actions (links to edit, print, history pages). All are tested and working.

Wow. That's a lot. And it's GREAT code. Modular enough to be totally maintainable, yet easily understood and not overbuilt. Something that the CS guys will be very proud of. So what's next?

• Getting the page edit control working and assembling the edit layout. The edit control I use will be your standard CommunityServer edit control. I like that option because the user can select their desired control via their Profile page, and administrators can integrate their favorite. (CommunityServer comes with FreeTextBox integrated by default, my favorite right now is FCKeditor)
• The permission system is about half done. It still needs serializing/deserializing.
• The providers need to version the files as they save topics.

Once those are done, I'm going to put the code in which will enable the pages to run as ASP.NET UserControls. (like ASCX files) It's a huge security risk, so I'll have to also include a "whitelist" of allowable controls. I'll also build an "include" control to show a wiki page within a wiki page. I hope I won't have too much trouble with the editors. having them return proper code will be a pain. Worst case is that if the users want to insert ASPX or wiki includes, then they'll have to either use a BBcode-like syntax or edit in HTML view.

Wish me luck and stay tuned for the next entry in this project!

Well, my previous blog post might have convinced you that I was 100% against wikis. They do have their uses, but I believe that many people over-use them as a general knowledge-management wild-card. Ward Cunningham, the creator of the first wiki, describes them as "The simplest online database that could possibly work." (wiki.org) Of course this description is pretty vauge. Wikis have become the wild-card do-everything CMS. You can put up an empty wiki, and start filling it with content immediately. You can use it to take notes for meetings. Or you can use a protected version as your corporate or project website. Rss Bandit is a perfect example of why you should NOT use a wiki as your entire website... Navigation and consistency is horrible accross the entire site.

When is a wiki usable? If you follow the base description, it's not very usable in a corporate environment. What happens if you develop any project in business with a definition like that of the wiki? "Just do it as simply as possible, as long as it works." If you've worked in business at all in the last few years, you'll note that anything that starts with "As simple as possible" is almost never acceptable unless you follow it with a long list of requirements. And no engineer ever builds "as simple as possible" unless he fully expects to never see it again.

But after all of that, there are some patterns in business which indicate that a Wiki does have a place here. Take email discussions for example. The thread of messages in a long chain of emails diverges endlessly, and increases exponentially with the inclusion of more recipients. Colaboration on evolving documents is a perfect use case for a wiki. Blogs and meeting notes are not. In fact, I'd almost call them wiki-spam since they generate large numbers of low-value pages.

Wikis have one feature which everyone seems to agree contributes invaluably to knowledge collection and management: automatic page creation with link maintenance. This is great for creating webs of related information, but only for clearly defined topics like an encyclopedia. If topics are not well-known, the system will end up with many overlapping topic pages ... a headache for content moderators, and a nightmare for unsuspecting users.

Lastly, there's the "Simplest possible solution that works" aspect of it that I am trying to build: Editable pages which arrange themselves into a usable and navigable structure. The idea is simple: Allow content creators to create pages within certain topic-spheres. The pages will then arrange themselves into an editable navigation structure. It's still possible for the user to create pages off of the navigation, but they must remove the page from the topic tree. Now information is easy to create, yet is also easy to find and locate. The user will have a good idea of where he is when moving from topic to topic, and will also be able to easily find related information without the editors spending tons of time on link maintenance.

A new feature that I will be adding is templated content. JotSpot is a wiki-like series of web applications. They take the true meaning of wikis to heart: The simplest possible solution. But they apply that to a number of common business forms and applications. Wiki-based bug management, a blog application, group calendar, project management. All of these take the form of a templated wiki...pages with editable areas of content. I think this is key to enabling the wiki concept for practical business use.

In the past, I've avoided the use of wikis in my workplace. In fact, I've staunchly argued against using them. I believe that my reasons are pretty common: Wikis are just a big pot for storing knowledge in a pool. The only advantage it has to a bucket of post-its is that it's electronic, searchable, and anyone can go digging through the post-its whenever they like. Wikis are so unorganized, unstructured, and if they get too big, completely unmaintainable. Look at Wikipedia: They've got so many topics that they have to have a full-time team of editors to go through and edit and organize all their topics. If they have to have a full team of editors, that means that even if you're running a small organization, and if your wiki gets utilized at even a fraction of its' potential, you'll still probably need one full-time person to maintain it. For small teams, it just doesn't make sense.

Ok, those are all the reasons why I've avoided Wikis. Why am I talking about this? Because I've started rolling my own wiki now within db4objects. I'm not really rolling my own. I'm not starting from scratch. I had my choice between FlexWiki and other .NET-based Wiki projects. So I decided on Perspective. Well, seriously unusable FlexWiki wasn't much of a solution. Way overbuilt and complicated. It had a few ideas that I've come to really like, and I will definitely be integrating those ideas into our new Perspective-based solution.

The new db4o Wikis will be used for a number of upcoming community features on our site. I won't tell you what they will be, but you can see for yourself what features I will be adding to Perspective:

• Upgrading your code to ASP.NET 2.0
• Getting full URL-Rewriting to work
• Integrating ASP.NET 2.0 membership controls (and thus CommunityServer membership)
• Master Pages
• Content Templating
• Namespaces/Folders
• Embedded ASP.NET tags (ASP.NET controls within Wiki pages)
• Community Server integration (discussion pages will use CS Forums)

This is going to be a pretty fun project, and I've been looking forward to it for a number of weeks now. The source code will be made available on http://developer.db4o.com and http://www.everylittlething.net/. Hopefully, the author of Perspective will allow us to release it under the GNU LGPL license. I hope so, because then the CommunityServer folks can integrate it, or leave some hooks for me without requiring them to adopt a new license.