[IGSTK-Developers] "many simple specialized" components vs. "fewer, more complex and general components"

[Frank Lindseth]

Luis (and others),

We had a long discussion about "many simple specialized" components   
vs. "fewer, more complex and general components" after you had to  
leave the Tcon yesterday (we should probably have started with this  
topic).
It seems like the common opinion is that in order to make it simpler  
for the app. developer to satisfy the clinical user requirements   
it's sensible to move a little bit in the more general direction for  
some of the components, at the same time the components should not  
become so complex that it's not possible to test them in the ordinary  
way, we have to find the right balance.
I know you have strong feelings about this Luis, but do you (or  
anybody else for that matter) think that a compromise can be found  
somewhere along the simple comp./complex app - complex comp./simple  
app. line?
As you know, this has been my main IGSTK concern from day one, and I  
really need some input as to what to except as our "IGSTK practical  
trial period" is about to end and we have to take the big decision  
regarding what to base future IGS efforts on (it looks promising  
regarding other issues, e.g. the "coordinate system" challenge).

If we need to think in terms of concrete scenarios I believe that the  
slicer-comp. should be used (could be specialized both in terms of  
modality and functionality) .
Some background information / discussion can be found here:
http://public.kitware.com/IGSTKWIKI/index.php/ 
Talk:DesignChallenges#Slicing

A little scenario that can help to trigger some response to this e-mail:
User/surgeon would like to have an IGS system with a certain  
complexity in terms of required functionality (will increase over the  
years, I know...).
Such an app.  could be realized in different ways depending on the  
way the components are made:
A) Many, simple and specialized components -> Complex app. will be  
needed (many obj. , switching, etc.) in order to satisfy the user above.
B) Fewer, more complex and general components. -> Simple app.  (to  
satisfy user).
C) Balanced comp. -> Balanced app.  (to satisfy user).

List of points that can push the balance in one or the other direction:
= User/surgeon
-Overall safety (not the same as comp. safety):
* It's easier to test a comp. then it is to test an app. (as long as  
the comp. is not to complex, i.e. up to a certain level)
* A simple app. is safer and easier to test then a complex one.
* A complex comp. is of course more difficult to to test then a  
simple one, but we should think more like this: lets say that we have  
a complex comp. Ca that offers the same functionality as two simpler  
comp. Sa and Sb. As long as it's possible to test Ca, knowing that  
this comp. work properly has added more to the overall safety then  
testing Sa and Sb separately.
* etc. (feel free to add points to this list)

= App. developer:
* In terms of building a user community, the easier it is to build a  
app. with a certain functionality, the better it is. The extreme case  
being that the app. dev. only  connect the high level comp. needed  
and make everything accessible to the user trough a gui.
* etc. (feel free to add points to this list)

= Comp. developer:
* resources for dev. maintenance, doc. testing, etc.
* etc. (feel free to add points to this list)

Have a nice weekend everybody.
Regards,
Frank