What I urge you to think about is the following: if we can obtain funding and resources from Microsoft to strengthen dotLRN but using .NET in some way. Should we accept? If so, how should the funding and resources be used?
This is an excellent way of framing the issue, Al. Like many, I am very uncomfortable with the thought of a C# port. However, there are some things that I would like to see:
- Integration with .NET applications would be great, provided that (a) the integration is optional and not part of the core dotLRN stack, and (b) the integration can be done with purely Open, non-Microsoft code. Integration with Outlook/Exchange is one great idea. I'd also love to see dotLRN interoperate with Groove, and I wouldn't mind seeing it interoperate with Blackboard Transaction Server. As I see it, if we stick with SOAP and other standards, we can integrate with Java, or whatever, just as easily. The .NET stuff would just be a first test of the concept.
- I also wouldn't mind seeing dotLRN running on Windows servers. Again, I wouldn't want this to be a requirement [shudder]; just an option for those who want it.
- As a hedge, it wouldn't be a bad thing to see some kind of nsmono like there's an nsjava (except have it actually work). I wouldn't want to see the dotLRN code depend on it, but having it there would eliminate one more argument against adoption for those who need to run .NET.
- Finally, SQL Server compatibility wouldn't be a bad thing.
All of these suggestions have some common characteristics. First, they bring .NET to dotLRN/OpenACS rather than the other way around. Second, they make sure that .NET is not required to run dotLRN. Third, they increase user choices.
