[Develop] Signal ideas
Nick Nassar
nassar at pculture.org
Mon Oct 29 11:28:51 EDT 2007
I think #1 is fine. It's ok if we think of the threads as "database"
and "UI" instead of the "backend" and "frontend" threads. It makes
sense for some frontend stuff to happen in the database thread.
Option #2 doesn't seem like a good idea to me. It's a lot of extra code
for little advantage.
Option #3 is probably a good idea. I like the fact that it open the door
to radically different database backends. The problem is it requires
enough invasive changes that we can't realistically implement it until
after I've made my widget changes. Changing the database callback
system and the widgets at the same time would be a mess.
>>>>> "Ben" == Ben Dean-Kawamura <ben at pculture.org> writes:
Ben> Hmmm, after thinking about #2 and #3 more, I realize that it
Ben> would be a big project to make it work with the HTML template
Ben> code. Maybe I could just add the hooks and when we switch to
Ben> widgets you could them, Nassar?
Ben> Ben
Ben> On Fri, Oct 26, 2007 at 03:05:52PM -0400, Ben Dean-Kawamura
Ben> 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
Ben> _______________________________________________ Develop mailing
Ben> list Develop at pculture.org
Ben> http://participatoryculture.org/mailman/listinfo/develop
More information about the Develop
mailing list