[IGSTK-Developers] my "statement of state machines" is attached; tcon on Monday at 11 am EST

Sat Oct 22 08:35:12 EDT 2005

Hi everyone:

As you will see from the attached document (the text is also pasted below my
signature), I had some discussions with Luis and Kevin Gary the past two
days and came up with this plan to move the project forward. 

I am sure it is not the best plan but I think it is a reasonable compromise
at this point to keep moving ahead.

Please take a look and send any comments you may have to the mailing list
(or just to me if you don't want to share them with everyone yet).

We will have a tcon on Monday at 11 am EST to discuss this and we have new
tcon numbers that will only be used for this project (my colleagues at ISIS
don't have these numbers so we will not have any tcon collisions again like
last week). I also put these new numbers on the Wiki.

Conference Passcodes:

   Passcode:       646202

Conference Access:

   Toll Free:          1-800-308-9936 

   Toll:               1-913-643-0019 

I will absolutely limit the tcon to two hours on Monday: one hour for
discussion and one hour for making an action plan, including listing all
outstanding issues. We will also have our regular tcon this Thursday but at
3 pm East Coast time - those of us at MICCAI who are available will meet at
the hotel registration area at 11:55 am and we can go to my room for the
tcon. Finally, I will send some information about the November ITK class and
review meeting shortly, including hotel information.

Thanks.

Kevin

------------------------------------------------------------------
Kevin Cleary, Ph.D.                        Work phone: 202-687-8253
Associate Professor                        Work fax: 202-784-3479
Deputy Director  

Imaging Science and Information Systems (ISIS) Center
Department of Radiology                    Pager: 202-901-2033
Georgetown University Medical Center       Cell phone: 202-294-3409
2115 Wisconsin Avenue, Suite 603           Home phone: 301-299-0788
Washington, DC, 20007                      Home fax: 301-299-0789

ISIS center:  <http://www.isis.georgetown.edu/> www.isis.georgetown.edu
Research group:  <http://www.caimr.georgetown.edu/> www.caimr.georgetown.edu
WashCAS:  <http://www.washcas.org/> www.washcas.org
Email:  <mailto:cleary at georgetown.edu> cleary at georgetown.edu
-------------------------------------------------------------------

Statement on State Machines

Kevin Cleary

22 October 2005

As you are all aware, we have had many discussions about state machines and
how they will be implemented in IGSTK. In the interest of moving the project
forward, I had some discussions with Luis and Kevin Gary and am proposing
the following for the Monday tcon.

First, by way of background, we decided to use state machines early in the
project for these reasons that Luis outlined in "Purpose of State Machines
in IGSTK" on the Wiki. This was a major decision and in some ways I think
the use of state machines is one of the defining points of IGSTK. We are
breaking new ground here in my opinion and therefore it is not surprising
that we are struggling some here.

However, I still believe state machines are worth the effort and we actually
have made a lot of progress to date in starting to put in state machines at
the component level. From my discussions with Luis and Kevin Gary, there
seem to be three major issues with the state machines:

1)      Our design is getting complicated. This will make IGSTK hard to use
if we are not careful.

2)      We have not solved the problem of how the state machines will
interact together. This may be the major technical challenge of IGSTK in my
opinion and it seems we do not have examples of other systems that have been
built with state machines to go by. We can put state machines in the
components and in the application no doubt, but how will they interact
together?

3)      We have not agreed on a mechanism as to how the state machines will
communicate information with each other and how we will get information into
the state machine. Luis has introduced the idea of using an event/observer
mechanism to communicate information (similar to the slots/signals method of
Qt) rather than using Get() methods, but there is disagreement still as to
whether this is a good solution.

Therefore, at this point I propose the following:

1)      Regarding the design getting too complicated, this is just something
we need to pay attention to as we proceed. I would agree with Luis that code
safety is a higher priority than coder convenience, but I would not want to
build a toolkit that is so complex no one can use it. However, we can have
complexity in the internals of core components provided that the interface
is more straightforward. We can also help here with programming examples and
providing a few well known patterns of interaction as is the case with most
any control framework.

2)      Regarding the interaction between components, the dispatcher seems
like a reasonable solution. There are some issues with the dispatcher
implementation first suggested by Luis and Andinet at the tcon last week,
but in general this seems to be a good path to pursue. I recommend we
discuss this a little more on Monday, but plan to pursue this as the
solution for interaction between components in the next release of the
software.

3)      Regarding how the state machines will communicate with each other, I
am not ready to sign onto the event/observer mechanism at this point. I
think this should be discussed more at the board meeting / one year review
on Nov. 10. For now, I am OK with people using Get() methods to communicate
and I am OK with Luis/Andinet experimenting with the event/observer method
to see how it works in practice. 

Therefore, at the tcon on Monday, I will propose we move forward this way. I
will limit the tcon to two hours, with the first hour for discussion of
these issues and the second hour to make an action plan and summarize the
outstanding issues. We have some other things to discuss such as creating
consistent design patterns in the state machines, the use of exceptions, and
state machines in base versus derived classes but these are lower level
issues to me at the moment and we will see if there is time to discuss them
on Monday or not.

I certainly appreciate everyone's input on these issues and I feel we have a
very talented technical team, so it is natural that there may be some
differences of opinion. But I also feel that we need to move the project
forward so that is why I have stepped in (of course, if I have to start
coding again, then we are really in trouble and I recommend you all abandon
ship!). Any comments or suggestions are welcome.

(end)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/igstk-developers/attachments/20051022/43e74304/attachment-0002.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cleary statement of state machines 22 oct 2005.doc
Type: application/msword
Size: 33792 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/igstk-developers/attachments/20051022/43e74304/attachment.doc>