[IGSTK-Developers] tcon this morning at 11 am: note new numbers
Kevin Cleary
cleary at georgetown.edu
Mon Oct 24 09:37:46 EDT 2005
Hi everyone:
Just a reminder that we will have a tcon at 11 am this morning to discuss
the state machine and develop a plan to move forward for the November board
meeting. My feeling is that we will not resolve all the issues at this point
and I may postpone some of the discussion until the board meeting. But I
want to move ahead with building sample applications and finishing the
current release before the board meeting.
My agenda for today is:
* Kevin Cleary to review the status (see statement on state machines
below and posted on the Wiki at
http://public.kitware.com/IGSTKWIKI/index.php/Statement_on_State_Machines_Di
scussion_Kevin_Cleary_24_Oct_2005
* Kevin Gary to discuss the state transition analysis he posted on the
web and issues with consistency of patterns in state machines
* Some general discussion about state machines and issues as outlined
in my memo:
* State machine dispatcher
* Event/observer model
* If it turns out that the discussion is not productive at this time,
I will cut it off (sorry) and we will table some of this until the board
meeting - I just want to know the implications for the project if I decide
to table these issues
* I will limit it to one hour for the discussion and then one hour for
action plans - including a list of to-dos and issues for the future and also
a review of the preliminary board meeting agenda on the Wiki at
http://public.kitware.com/IGSTKWIKI/index.php/One_Year_Project_Review_Board_
Meeting_and_ITK_Course_at_Georgetown
Finally, note the new teleconference numbers that have been posted on the
Wiki as well:
Conference Access:
Toll Free: 1-800-308-9936
Toll: 1-913-643-0019
Passcode: 646202
Talk to you at 11 am East Coast Time -
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
-------------------------------------------------------------------
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/20051024/5696b7fc/attachment-0001.html>
More information about the IGSTK-Developers
mailing list