Frameworks for NIM code

[Jeffrey Altman]

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.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3355 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mailman.mit.edu/pipermail/kfwdev/attachments/20080416/1dfbb3c8/attachment.bin