On Mon, Jan 18, 2010 at 3:09 PM, Richard Purdie <[email protected]> wrote:
> I've been looking at ways of trying to handle events sanely within
> bitbake. There are several problems, some of which I've heard others
> talk about:
>
> 1. The getName() function call
>
> This just looks horrid, we can come up with better semantics.
>
We already have better semantics, we just don't use it. isinstance() can be
used for this.
> 2. Text string comparisons in the event handlers (name.startswith('x'))
>
> I don't really object to this as such, I think having text strings
> representing the event makes sense. I did see someone disliking it
> though. Now is an opportunity to point me at a better way of doing this,
> I can't find one.
>
isinstance can operate against an iterable of classes, or a base class:
if isinstance(e, (TaskStarted, TaskSucceeded)):
works great.
> 3. Inclusion of the data dictionary within every event
>
> This messes up the bitbake client/server code no end since if you want
> to pickle or otherwise transport the event via IPC, it has the whole
> data dictionary in it. We need the event objects to be marshallable
> ideally.
>
Is there a reason we can't customize the serialization process for these
objects to exclude the reference to the datastore?
> 4. The pointless return values
>
> These should just die, they're useless.
>
Agree wholeheartedly.
> As always, its pointless to complain about something without a plan to
> fix it. I therefore propose we add a new style of event handlers which
> take a new form of event. These event handlers are functions called with
> three parameters - an event name as a text string, event data and the
> data dict separately. There is no return value.
>
I don't really see the gain of separating the name from the data rather than
using an object here, but I don't have a very strong opinion either way.
The events themselves would be made marshallable.
>
> Any objections or better suggestions?
>
> Also, anything else we need to fix about the events whilst we're
> changing things?
The only other thing that might be nice as a feature add would be the
ability to express the events you're interested in via a variable flag,
rather than conditionals, just to reduce the boilerplate code in the various
event handlers, but that could also reduce flexibility, so that would be
both arguable, and something that could be visited / discussed at a later
time, rather than as part of this effort.
--
Chris Larson
clarson at kergoth dot com
clarson at mvista dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Software Engineer
MontaVista Software, Inc.
_______________________________________________
Bitbake-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/bitbake-dev
