[Develop] Signal ideas

[Nick Nassar]

All of this sounds great.  We should also define threading semantics for
callbacks.

Maybe just something like: The backend callbacks into the frontend
should run in the frontend thread, and frontend callbacks into the
backend should run in the backend (database) thread.  That way, when the
frontend gets calls it can safely do frontend stuff, and when the
backend gets calls it can safely do backend (database) stuff.

I think we should change the API to facilitate this, so it's really hard
to do the wrong thing.  Maybe we require another parameter in
object.connect named "queue_function" that takes in a function like
eventloop.addIdle() which will put the callback on the event queue.

Nick

>>>>> "bdk" == Ben Dean-Kawamura <ben at pculture.org> writes:

    bdk> So the first part of my frontend-backend stuff is to add a
    bdk> signal/event system to Miro.  The main point is to make it so
    bdk> the frontend doesn't have to call into the backend, it just
    bdk> signals an event that the backend can catch if it wants.
    bdk> However, I think we should use it for slightly more than that.
    bdk> Here's my initial plan, what do people think?

    bdk> (This is a long email, but I don't think anything here is going
    bdk> to be hard to implement.  It should be easy to do in a day or
    bdk> two)

    bdk> The signal system is will pretty much follow the gobject model,
    bdk> but simpler.  Objects can derive from a SignalEmitter class,
    bdk> then they get a connect() method and a disconnect() method.  If
    bdk> you want to receive notifications for a signal you call:

    bdk> object.connect("signal-name", callback_function, *extra_args)

    bdk> When the object emits the signal, callback_function will be
    bdk> called.  The first argument will be the object emitting the
    bdk> signal, then there will be some signal-specific data, finally
    bdk> any extra arguments you passed into connect().

    bdk> To disconnect a callback, call:

    bdk> object.disconnect("signal-name", callback_function)

    bdk> On the other side of things, objects will get a create_signal()
    bdk> method that they should call in their constructor for any
    bdk> signals they will use.  Also they will get an emit() method to
    bdk> send signals.  Objects can pass additional arguments to emit(),
    bdk> those arguments will be passed to signal listeners.

    bdk> In a couple places we will want some kind of global signals
    bdk> that aren't tied to a particular object -- for example the
    bdk> "error" signal below.  We can handle this by creating a
    bdk> singleton object that emits system-wide signals.

    bdk> Here's places I think can use this system:

    bdk> 1) Error dialog box.  Instead of the backend call
    bdk> notifyUnknownException(), it can send an "error" signal"

    bdk> 2) Startup.  When we startup there are lots of errors that can
    bdk> happen.  This gets especially complicated because some will
    bdk> happen in the backend thread, so they are tricky to catch in
    bdk> the backend A clean way to handle this would be to create 2
    bdk> signals "startup-success" and "startup-failure".  The frontend
    bdk> would the connect to those 2 signals.  If it gets the success
    bdk> signal it would open the main window and go.  The failure
    bdk> signal would also have a message attached to it.  If the
    bdk> frontend caught that it would pop up a dialog with the message,
    bdk> then quit.

    bdk> 3) The database code.  Right now we already have a signal
    bdk> system, but a lot of code is duplicated, we have
    bdk> addRemoveCallback, addChangeCallback, addAddCallback, etc.
    bdk> Seems like we could easily change those to signals using the
    bdk> new system.

    bdk> I'd also like to add a "change" signal to DDBObjects.  When we
    bdk> build the new widget frontend, it could connect to that signal.
    bdk> In the current system when we want to do this we create a view
    bdk> with only a single object in it and add a change callback to
    bdk> that, which seems clunky to me.

    bdk> 4) Possibly httpclient.  We are basically using signals there
    bdk> too -- the readyCallback, openConnectionCallback, etc.
    bdk> However, I'm not sure I want to touch this code because it's
    bdk> gotten so complicated.
    bdk> _______________________________________________ Develop mailing
    bdk> list Develop at pculture.org
    bdk> http://participatoryculture.org/mailman/listinfo/develop