[Develop] Signal ideas

[Ben Dean-Kawamura]

I think this makes sense.

I'm going to try to make it so that there's no callbacks from the frontend to
the backend.  The goal is to make the backend self-contained and minimize the
amount of things the frontend needs to provide.

One issue is that there will probably be callbacks from the backend to the
backend.  In some of those cases we probably don't want to queue the call, we
want to make it directly.  What's a nice API that can allow both?

Also, this gets into another thing that we should think about.  Many frontend
operations currently have to be done in the backend thread because they access
the database data.  I have a couple of ideas on how we can handle this:

1) Do nothing.  Some of the frontend callbacks happen in the backend thread.
This should require very little code.

2) Copy the data.  When the frontend receieves a callback for database data,
it gets a copy of the data.  We'd need a bit of code to make this work.  One
change would be the insert callback needs to pass in not only the object that
was inserted, but also the next object in the list.  This is because the
frontend code won't be able to call getNext() on the view that the object is
in.

3) Higher level API.  Instead of the frontend communicating with the database
directory, we add a couple callbacks to feeds, items, etc.  For example, 
Feeds would get callbacks for "item-added", "item-removed", "item-changed"
etc.  I like this better than 2 because it lets us change things without
changing the DB code -- we would be adding a layer on top instead.  Also, it
should make it easier for change the database code down the line (sqlite
baby!!!)

Personally I'd like to do #3, but I could live with #1 for now and trying to
make the changes later.

Ben

On Thu, Oct 25, 2007 at 03:44:20PM -0400, Nick Nassar wrote:
> 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