[oe] RFC: Bitbake and UIs

[Richard Purdie]

On Fri, 2006-12-08 at 22:06 +0100, Holger Freyther wrote:
> > 2. Have bin/bitbake error if its version is not equal to the lib/bb
> > version. This should stop people who've installed old versions from
> > having issues.
> 
> hmm, do people still hit this? I thought I have prepended everything  
> to the python path.

Not sure, it just makes me nervous.

> How do you define that core and bin/bitbake are compatible? If the  
> version numbers just match?

Yes.

> I will blow up released badly as I will only upgrade one version and  
> not both :)

You'd test before releasing and the error check would catch this though?

> > 4. Rewrite (remove) the TmpHandler(e) code as it makes me feel ill  
> > (and
> > has a hidden embedded tab that will bite us one day). If you agree to
> > use a global method scope for handlers, we could do something  
> > similar to
> > the anonymous handlers? any ideas/gotchas here zecke?
> >
> 
> Hmm we had some disagreement on this on IRC today. We will write down
> our thoughts and try to find a solution. In worst case you are  
> invited to a death match at FOSDEM :)

:)

> 
> Basicly my questions are:
> 	-Do we want to continue to have handlers per BitBake file or a list  
> of to be used event handlers

We will need a list of "system" event handlers for things like each
connected UI etc.

> 	-Do we want persistance. Currently there is no way to store  
> information across two events.

I think this is a bad idea and I don't know how it would work in
practise. When would this data get reset? Thinking tinderclient here and
it might be that becomes a "UI" to bitbake which would let it have other
ways of storing persistence data. The disadvantage is it becomes more
than a .bbclass and moves from OE into bitbake :-/.

I honestly don't see a workable way of having persistent class data
though.

> 	  Both tinderclient.bbclass and icecc.bbclass could benefit from  
> this one
> 	-Do we want return values for events. In this case an event handler  
> could do decisions as well

The problem with return values is that the handler is totally unaware of
what else might also want to see the event and has no way to know what
else is listening. I'd therefore say return values are a definite no.

> > We also need to consider where the initial configuration will come  
> > from
> > and how/where it gets stored. At the moment its generated by bin/ 
> > bitbake
> > but should we modularise that too?
> 
> yes but not now?

Agreed. On the "to do sometime list" :)

Cheers,

Richard