[IPython-dev] Notes on SciPy discussion about Notifications in IPython
Wed Sep 17 14:51:56 CDT 2008
Thank you for summarizing the discussion; I'm sorry I missed it! I
like the way you lay things out and I agree with your conclusions. I
came out hard on the side of the notification-center style so that
in-process and networked interactions could be as similar as possible,
but I'm happy we've reached a common middle ground and am looking
forward to trying to make both styles work for developers and users.
As soon as I can 1) clean up the bugs in the frontendbase test code
and 2) get the Cocoa frontend into a more useable state, I would like
to have a crack at the network-aware notification problem... unless
someone goes ahead and implements it first ;)
On Tue, Sep 16, 2008 at 4:19 PM, Brian Granger <email@example.com> wrote:
> A while back Barry Wark developed a nice prototype of a notification
> center for IPython. There was lots of discussions about that versus
> other models and then things died off with the 0.9 release.
> Gael, Fernando and I picked up this topic in person at SciPy and I
> wanted to summarize our conclusions for the list (especially Barry).
> We feel all feel that there are two types of "notification" models
> that we want to support:
> * Something like Barry's notification center, where observers register
> that they want to recieve certain types of notification events.
> * Objects with interfaces based model. In this model, the "observer"
> provides an object that obeys a certain interface (like a dict, for
> example) and then someone just uses that object. The notifiations
> happen because the observer has put its own custom hooks in the object
> that handle the notifications.
> An example will hopefully clarify this. The user namespace is a
> perfect example of this second type of pattern. Let's say someone
> wants to receive notifications of when a new variable appears in the
> namespace. If that someone give the interpreter a dict-like object to
> use as the namespace, that object can have custom logic that notifies
> the someone when the events occur.
> Our conclusion (I guess it is not that profound) is that we want to
> support *both* of these models as much as possible. Thus any time
> notifications are wanted, we should work *very hard* to try to
> implement both ways. Some further points:
> * In some cases one type of notification will be implemented on top of
> the other.
> * The object based model tends to be useful for highly coupled
> situations, where the notifications are very static (always
> * The notification center works in a very transient context, when
> notifications are very dynamic (observers come and go).
> * The notification center approach is very much needed to allow
> notifications to be propagated over network connections.
> * The object based model is very nice for developing frontends based
> on technologies like enthought.traits, which already have
> notifications buildin.
> * Handling notifications both ways will force us to get the abstractions right.
> * The notification center type design should be preferred over designs
> that rely on heavy subclassing to implement notifications (this type
> of design is common in GUI programming, but we need to be really
> careful to avoid this when possible as it leads to coupling that is
> too strong for us).
> Gael and Fernando, does this accurately reflect our conclusions? Comments.
> I think the only conclusion is that there are places in the current
> frontend, where a more formal notification setup could be used =
> IPython-dev mailing list
More information about the IPython-dev