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, to
MFC 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 that
is 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 be
replaced 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 messaging
system 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 a
framework 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.



Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
kfwdev mailing list
kfwdev@mit.edu
http://mailman.mit.edu/mailman/listinfo/kfwdev

Reply via email to