[IPython-dev] Notes on SciPy discussion about Notifications in IPython

[Barry Wark]

Brian,

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 ;)

barry

On Tue, Sep 16, 2008 at 4:19 PM, Brian Granger <ellisonbg.net at gmail.com> wrote:
> Hi,
>
> 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
> on/wanted).
> * 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 =
> notificationcenter+objects.
>
> Cheers,
>
> Brian
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://lists.ipython.scipy.org/mailman/listinfo/ipython-dev
>