The suggestion of using exchange for storing calendar information is great. We should think about going even further. If you look at the modules of OpenACS independently, you will see there is something out there that does the job better (look at webmail (IMP, fastmail), bboards (several PHP based ones), calendar (Yahoo {open to discussion...😊} )). The strength of OACS and therefore dotLRN lies in a combined data modell and integrated approach. If there was a port to .NET I'd assume a lot of the services that exist somewhere else and provide webservices using .NET architecture (or mono, or java or whatever else comes down the road. After all we are talking about IT, so things will change anyway every couple of years) would be used instead of going down the effort and really port modules. At least that would be economical, technical feasability and legal issues left aside.
Now, where does this leave dotLRN? Take into account that universities might not like the complete package but are keen on using a special BBoard or a cosy News and CMS package. What dotLRN should provide is the possibility to use these services instead, using well defined (by the TAB) interfaces. Furthermore, go the other way round as well, open up the modules to be queried by other websites/services. If a student does like to keep his calendar in Yahoo, allow Yahoo access to the dotLRN calendar. If they want to use fastmail, provide them access to the mail stored in the database.
Therefore, as my consecutive question, will the dotLRN movement consider opening up the architecture to allow webservices in both directions and is this something already on the list of desired features of the stakeholders especially in the EB {as this would most likely get funding first}.
That question has already been answered in part by Al, so no need to restate unless you see it even further 😊.
