Kevin Koch wrote:
I'd like to start a discussion about frameworks. Currently, NIM is written to the Win32 API. What if it were written to use a framework?
Concerns with the use of frameworks:
1. backward compatibility 2. stability of the framework. can newer versions of the tools be used without requiring rewriting the application and breaking backward compatibility. 3. the mix and match problem. NIM providers are developed by organizations other than MIT and Secure Endpoints. They are distributed to users in separate installers. As NIM changes from its current framework, toMFC 7 to MFC 8 to MFC 9 or .NET 1.1 to .NET 2 to .NET 3, etc., can providers built with framework version X mix with providers built with framework version Y
and NIM built with framework version Z? 4. portability. will the framework impose a design model that is difficult to port to operating environments other than Windows.NIM is written in C. It uses the Win32 API for Windows specific functionality.
Of the approximately 316,000 lines of code that make up NIM, 50,000 of thatis Windows specific. Although NIM has not yet been ported to other operating systems and we expect there will be significant work necessary to make that happen, porting is something that is asked for by the majority of NIM using organizations. Linux and MacOS X users are jealous of the single sign-on functionality that their
Windows counterparts are the benefits of. NIM is its own framework. NIM messaging provides asynchronous communication between all of the loaded providers. It is specific to NIM and could not bereplaced by moving to a framework. A framework may hide the Windows event dispatch
loop, but it will not replace the NIM messaging system. The NIM messagingsystem would simply have to be reimplemented on top of the frameworks messaging
constructs. As the NIM Messaging System is already implemented on top of the Windows Event Dispatch model I do not see a benefit to reimplementation. I do not see how such a transition could be made at this point and not break backward compatibility with the existing providers. One of the major problems with designing a plug-in architecture around aframework is the requirement that not everyone be forced to develop with the same version of the framework. In particular, MFC and .NET do not behave well when mixing versions in the same application. Effectively that means that you must commit to a single toolset forever or each time you decide to upgrade to the latest toolset, require that all providers be updated as well. Requiring
that all providers be updated is a deployment nightmare and will be a significant burden on help desks. Jeffrey Altman Secure Endpoints Inc.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ kfwdev mailing list kfwdev@mit.edu http://mailman.mit.edu/mailman/listinfo/kfwdev