Meeting on September 21, 2009
Agenda
- Attendance
- Announce agenda
- Approve September 8, 2009 Meeting Notes. Ask for review and address any problems seen in the notes.
- Discuss Progress enhancements as they related to OPTICKS-599 and future Progress improvements.
- Open Questions
- Summary and closing
Notes
Attendance
- tclarke
- dadkins
- rforehan
- dsulgrov
- raevans
- kstreith (late arrival)
Summary
Progress reporting was discussed as it related to OPTICKS-599. It was decided to add a hasAbort(), abort(), isAborted(), SIGNAL(abort) to Progress. ProgressDlg would use this instead of directly accessing plug-in abort methods.
Suggestions on long term progress reporting were presented and held for future discussing.
Decisions
The proposed OPTICKS-599 Progress changes are approved. No vote was held, no dissenting opinions were expressed.
Logs
2009-09-21T11:00:29 <tclarke> here
2009-09-21T11:00:30 <dadkins> here
2009-09-21T11:01:39 <rforehan> Here
2009-09-21T11:01:40 <dsulgrov> here
2009-09-21T11:01:40 <raevans> here
2009-09-21T11:01:53 <tclarke> 1. Attendance
2009-09-21T11:01:53 <tclarke> 2. Announce agenda
2009-09-21T11:01:53 <tclarke> 3. Approve September 8, 2009 Meeting Notes. Ask for review and address any problems seen in the notes.
2009-09-21T11:01:53 <tclarke> 4. Discuss Progress enhancements as they related to OPTICKS-599 and future Progress improvements.
2009-09-21T11:01:53 <tclarke> 5. Open Questions
2009-09-21T11:01:53 <tclarke> 6. Summary and closing
2009-09-21T11:02:00 <tclarke> please review the notes from last time and address and concerns
2009-09-21T11:02:00 <tclarke> https://wiki.ballforge.net/confluence/display/opticksChat/September+8%2C+2009+Meeting+Notes
2009-09-21T11:02:12 <tclarke> ok, the main item on this week's agenda deals with progress reporting
2009-09-21T11:02:25 <tclarke> progress reporting has some problems in general and there is a more specific problem relating to OPTICKS-599
2009-09-21T11:03:52 <tclarke> the specific problem is that there is no way to support the "Abort' feature of progress unless the Progress object is being accessed by a plugin via ::execute()
2009-09-21T11:04:05 <tclarke> this presents a problem for things like AEB installation and file download (download is the issue addressed in OPTICKS-599)
2009-09-21T11:04:13 <tclarke> so the main question for today is how to enable this for 599
2009-09-21T11:04:31 <tclarke> I'd like to entertain some general discussion about future enhancements to progress reporting so that the immediate solution fits into future enhancements
2009-09-21T11:04:47 <tclarke> the proposed solution in 599 maintains current behavior for plug-ins but adds a method to explicitly enable abort
2009-09-21T11:05:59 <tclarke> when that happend, a SIGNAL is emitted when the abort button is pressed
2009-09-21T11:06:03 <tclarke> code can create a Slot to handle the abort
2009-09-21T11:06:07 <tclarke> thoughts? alternatives?
2009-09-21T11:06:07 <tclarke> .
2009-09-21T11:08:06 <dsulgrov> If we want to allow aborting in Progress object, perhaps we should move capability from the progress dialog to the Progress object where the dialog would simply call something like abort() on theProgress object
2009-09-21T11:08:23 <dsulgrov> the dialog could then query hasAbort() on the Progress object to determine whether to enable the button
2009-09-21T11:08:30 <dsulgrov> The plug-in pointer could then be removed from the dialog
2009-09-21T11:08:46 <dsulgrov> and the Progress object could simply query or be initiated with values from the plug-in
2009-09-21T11:08:47 <tclarke> I'm checking the 599 implementation now
2009-09-21T11:08:52 <tclarke> that's essentially what's happening in the 599 implementation
2009-09-21T11:08:56 <tclarke> the names of methods are a little different
2009-09-21T11:08:58 <dsulgrov> well, only half way
2009-09-21T11:10:21 <dsulgrov> the progress dialog could be simplified quite a bit
2009-09-21T11:10:37 <tclarke> are you suggesting reimplementing the current PlugIn behavior using the new interfaces and code?
2009-09-21T11:10:54 <dsulgrov> current PlugIn behavior in the progress dialog?
2009-09-21T11:11:03 <rforehan> Is there a need for batch mode abort? For example, if a batch process has a time-out check and implementor wants code to cancel and exit?
2009-09-21T11:11:06 <tclarke> i.e. call abort() on a plug-in when the button is hit and query hasAbort()?
2009-09-21T11:12:36 <dsulgrov> I'm suggesting expanding the new Progress interface to have hasAbort(), isAborted(), and abort() and perhaps removing the signal...
2009-09-21T11:12:43 <tclarke> rforehan...the current achitecture supports this...I'm not sure if the batch reporter listens for SIGKILL or anything to check this
2009-09-21T11:12:43 <dsulgrov> the progress dialog then needs to know nothing about the plug-in
2009-09-21T11:12:55 <dsulgrov> and can simply call the new interface methods on the Progress object to enable its button and perform the abort
2009-09-21T11:12:58 <tclarke> fyi, the changeset refered to is here: https://opticks.ballforge.net/source/browse/opticks?view=rev&revision=7888
2009-09-21T11:13:03 <tclarke> for those who have not looked at 599
2009-09-21T11:13:13 <tclarke> that's sort of what I was getting at....collapse the two code paths into 1
2009-09-21T11:14:45 <tclarke> I like that idea...simplifies the interface so I think it moves us closer to a better reporting framework
2009-09-21T11:14:54 <tclarke> I'd have to do a little to maintain binary compat but I think that's possible
2009-09-21T11:15:09 <dsulgrov> the current 599 implementation still leaves logic of performing an abort in the progress dialog
2009-09-21T11:15:18 <tclarke> yes...that would be collapsed into the Progress
2009-09-21T11:15:24 <dsulgrov> If we want to make the Progress object be the primary object for handing abort, then let's change the dialog now
2009-09-21T11:15:30 <tclarke> I think I'd like to leave the SIGNAL tho....I think there's benefit to having a signal and an isAborted()
2009-09-21T11:15:33 <tclarke> for different algorithm designs
2009-09-21T11:15:36 <dsulgrov> sure, I can agree with that
2009-09-21T11:16:46 <tclarke> ok.,...what do others think about this?
2009-09-21T11:16:58 <rforehan> I'm for collapse and keep signal
2009-09-21T11:17:06 <tclarke> this fits with the direction I'd like progress to move....here's a brief overview of my thoughts
2009-09-21T11:17:10 <dadkins> so wipe out the abort from the dialog?
2009-09-21T11:17:19 <dsulgrov> no...
2009-09-21T11:17:21 <tclarke> it would be there
2009-09-21T11:17:24 <tclarke> but it would just call abort() on the Progress
2009-09-21T11:17:34 <dsulgrov> the ability to abort will still be in the dialog, but it would query the progress object to determine if it should be allowed
2009-09-21T11:17:40 <tclarke> this fits well with step 1 of my plan which is to strengthen the model/view separation in progress reporting
2009-09-21T11:17:42 <dadkins> ok – and add a signal?
2009-09-21T11:19:02 <dsulgrov> when the user clicks the button, abort() would be called on the Progress object instead of on the plug-in directly
2009-09-21T11:19:08 <tclarke> dadkins: yes...it would have a flag check (isAborted() )and a signal
2009-09-21T11:19:15 <dsulgrov> the progress object would then call abort() on a plug-in (if it had one)
2009-09-21T11:19:24 <dadkins> that makes sense...i'm for it
2009-09-21T11:19:39 <tclarke> ok....any further questions or dissenting opinions?
2009-09-21T11:19:45 <tclarke> I don't think we need to vote on this....seems unanimous
2009-09-21T11:19:54 <tclarke> step 2 of my broader plan is to make Progress work more like MessageResource
2009-09-21T11:21:20 <tclarke> get rid of ProgressTracker and use resource objects to track object
2009-09-21T11:21:31 <dsulgrov> I am in favor of removing ProgressTracker
2009-09-21T11:21:32 <tclarke> there would always be a Progress active...at least a top level one for general info reporting
2009-09-21T11:21:44 <tclarke> creating a ProgressResource would (based on options...details to be worked out) either report to the existing Progress
2009-09-21T11:21:49 <tclarke> or sub-divide it like ProgressTracker does now
2009-09-21T11:21:59 <tclarke> that way we don't need to pass Progress between plug-ins....a plug-in just creates a progress "step" and reports as necessary
2009-09-21T11:22:04 <rforehan> That would get rid of a lot of if (pProgress != NULL) statements
2009-09-21T11:22:08 <tclarke> when it's done, the resource is destroyed and progress is marked as finished
2009-09-21T11:22:11 <tclarke> rforehan: yes, that's one benefit
2009-09-21T11:22:18 <tclarke> the view portion would not be restricted to ProgressDlg
2009-09-21T11:23:48 <tclarke> if in a plug-in, etc. it would usually use that...but reporting tile generation progress, for example, would use Progress which would be displayed in the status bar
2009-09-21T11:23:56 <kstreith> here, if that matters at this point
2009-09-21T11:24:03 <tclarke> a plug-in would be allowed to suggest reporting capabilities such as a modal reporter or a "background" reporter
2009-09-21T11:24:32 <kstreith> i'm good with the earlier progress discussion
2009-09-21T11:26:05 <tclarke> ok...sounds like everyone here is ok with the 599 changes
2009-09-21T11:26:22 <tclarke> any thoughts on the future progress reporting? I'm hoping to start people thinking about it now but not asking anyone to settle on a design at this point
2009-09-21T11:28:19 <tclarke> I'll leave it open a minute or two more...if there are any other topics to discuss, feel free to bring them up now
2009-09-21T11:28:21 <rforehan> Would there be any need for something like an RSS feed? Say fro
2009-09-21T11:28:27 <tclarke> that would be a possible View interface to progress
2009-09-21T11:28:36 <rforehan> fro-> for monitoring process from remote user
2009-09-21T11:30:01 <tclarke> the two may goals I have are to separate the model and view (partly met by 599 now) and to have a single progress reporting hierarchy instead of a number of one-off progress reporters
2009-09-21T11:30:13 <rforehan> Good goal.
2009-09-21T11:30:21 <tclarke> ok, last chance for topics