Thanks for the feedback Manpreet - some comments below: JR & Michal
Manpreet Singh wrote: > Hi John and Michal, > > > [snip] > > > >> - Update the ProgressTracker to allow a client to derive from it and get >> whatever fine grained progress information they need. >> > > Could you please clarify what you mean by this? ProgressTracker can/must > be subclassed even now as I understand it. > That's true, but to fulfill all IPS GUI requirements we need a lot more fine grained information than is currently available. Once this information is available the subclassed GUIProgressTracker can then provide the GUI with all the info it needs. > >> - Add in support for canceling tasks. Currently IPS GUI uses a simple >> threading model to allow canceling at the file level. A better solution >> would be to allow canceling at any point in the download using an event >> based networking model aka twisted, but we may have to stick with the >> simple solution initially at least to get things back up and running for >> IPS GUI. >> >> > > Would a simpler solution be to allow vetoing of individual progress > events for this by returning False/True from the individual event > handler? Currently the Update Tool GUI simulates this by throwing > exception from the individual ProgressTracker handler methods. > We are invoking all the long running tasks in separate threads inside one gtk main thread. The GUI needs to inform these long running threads that user has canceled some operation (download as an example). If the download function within core IPS doesn't allow us to cancel this download operation we are stalled waiting until it finishes. To resolve this issue, we really need some mechanism to stop the download almost instantly. if the network is down during a download operation and the user clicks on the cancel button we will have to wait until a network timeout happens before we can cancel the task (though the UI is still responsive of course as this is all happening in separate threads). With the event based networking we can do this any time. > Could you elaborate on how the Twisted framework approach would work? > The Twisted framework provides an asynchronous network programming model, which allows us to more easily manage the handling and canceling of network tasks, using callbacks from the Gtk Main event loop. There are a number of Python frameworks to support this model also. However, even though when the user cancels the task and the callback is invoked, we need some way to stop the IPS action immediately such as download, even if the network connection has been broken. Currently we only get the chance to do this after each file is downloaded, but we need to be able to do it mid file. This would be possible if IPS gave us event notifications during the file download on a configurable chunk size setting. This would also allow us to give good user feedback during large file down loads, which we currently cannot do. Looking at Zero Install they actually do the downloads in a separate child process and when the callback is invoked signal the process with an I/O error and so it can stop in mid stride so to speak. (Note: it is using the rox library as opposed to Twisted for its non blocking callback support) > Thanks > Manpreet > _______________________________________________ pkg-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
