Eric, I guess the opposite could be true. I too would suspect the module was not useful and not being used if no one commented. I am grateful for the comments, it demonstrates an active communitiy and that others are reviewing and trying to use the module. Often I see some opportunities to enhance/fix the module...however, I believe we've succeeded in providing basic event/calendaring functionality and a reference code sample that can be extended by others that need more. BTW, we have had others offer extensions (and fixes) and incorporated several of these.
The 3.3.8 version is fairly stable (although it may have some minor issues) and has been submitted for release. The source code will be available as soon as it passes our internal pacakaging/release qa.
I appreciate anyone taking up the banner to help in plan for future releases. What are the priorities? We can go in just about any direction that provides the most functionality for our community... What are the use cases for the module? What fixes/use cases we need to be addressed first (priorities)? Some functions like iCalendar implementation may cause a re-write for the module...however would provide for major extensions and functionality! So, lets hear from some that want to help define the module future and feature set...here's some ideas:
- review the latest 3.3.8 and define/prioritize issues that need to be addressed
- migrate the module to a full .NET 2.0 implementation. For you coders or folks that want to extend the module, would you prefer a .NET WAP or WSP implementaion for the code?
- improved security model for the module...including event role management and delegation
- full support for the iCalendar implementation import/export. This would support exchanging calendar information with most other web and desktop calendaring software, but may limit some of the extended features (ex. enrollment), since this is not supported by the iCalendar spec directly.
- better support for templating/skinning, if possible or general UI improvements. How? Specifics?
Remember whatever direction the community decides, the basic premise of DNN modules: must support localization/cultures, work within the existing DNN framework, etc. What would be cool is if someone might lead an effort to create a spec/use case document, get buy-in/consensus from the community, and submit it. We are willing to do the work.... It's just that often we hear conflicting issues/requirements...this is were the community can help police its self and allow us to do what we do best...deliver high-quality software that meets the stated requirements! Thanks again for your support!