[Develop] Signal ideas

[Ben Dean-Kawamura]

Hmmm, after thinking about #2 and #3 more, I realize that it would be a big
project to make it work with the HTML template code.  Maybe I could just add
the hooks and when we switch to widgets you could them, Nassar?

Ben

On Fri, Oct 26, 2007 at 03:05:52PM -0400, Ben Dean-Kawamura wrote:
> 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
> _______________________________________________
> Develop mailing list
> Develop at pculture.org
> http://participatoryculture.org/mailman/listinfo/develop