On Fri, 2008-01-11 at 21:08 +0100, Dirk Meyer wrote:
> >     try:
> >        do_callback()
> >     except Exception, exc:
> >       self.signals['exception'].emit(exc.__class__, exc, sys.exc_traceback)
> 
> We should make sure not tp break too much by adding this.

I can fix the spots in kaa if you take care of freevo. :)  Duncan
probably isn't using this yet in 1.x.

So the spots that would be affected are callbacks connected to
InProgress.exception_handler (and anything derived from InProgress:
YieldCallback and YieldLock) and Thread.signals['exception'].

While we're breaking stuff, we should look at unifying the API for async
status/exception handling between Thread and InProgress.  They both
essentially serve the same purpose: perform some task in the
"background" (for certain definitions of background) and return either
the status or an exception asynchronously.

We have a few options:
     1. Make InProgress like Thread, with 'completed' and 'exception'
        Signals in a signals dict.
     2. Make Thread like InProgress, and include Signal in its
        inheritance tree so that it has a connect method, and have an
        exception_handler signal member.  (Should we rename it to
        exception_signal?)
     3. Do something radically different

By 3 I mean completely change the signal stuff.  Pretty much all our
objects have one or more signals.  They are ubiquitous in kaa.  We could
follow gobject's model here and have a base class that provides the
signal functionality, and have all objects derive it.

It could work like gobject at the API level as well, and have a
connect() method for each object.  Or, maybe each object implements
__getitem__.  Some possibilities:
        obj.connect('result', handle_result)
        obj.connect('exception', handle_exception)
        
        # or with the __getitem__ way
        obj['result'].connect(handle_result)
        
The getitem stuff may be too invasive, though.  I just tossed it out as
an idea.  If this is all too radical, I do prefer #1 above.  As verbose
as it is to do inprogress.signals['result'].connect instead of
inprogress.connect, I do think we should try to be consistent in how we
provide signal hooks.

Jason.


-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Freevo-devel mailing list
Freevo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freevo-devel

Reply via email to