[PATCH weston] compositor: Separate hardcoded backend related code from compositor

[Pekka Paalanen]

On Thu, 25 Jun 2015 00:31:56 +0900
JoonCheol Park <jooncheol at gmail.com> wrote:

> Thanks pq and all,
> 
> I didn't think this would be hot topic :-) All reply from all in this
> thread was very very helpful to understand current weston project for me.
> 
> 
> 2015-06-24 16:52 GMT+09:00 Pekka Paalanen <ppaalanen at gmail.com>:
> 
> > Hi all
> >
> > TL;DR:
> >
> > Everything is open, let's make small steps only, in priority order
> > determined by the intended audience. We have as many release cycles of
> > time to use for improving the code and interfaces as we want.


> > If you can propose a better interface for things you don't like in
> > Giulio's libweston patch series, please do! But I don't think "this is
> > not perfect" or even "this is not very good" are enough reason to block
> > that series, because we can work things out over time. It is quite
> > different from, say, protocol design.
> >
> >
> If you and Giulio felt like that, that is my fault.

Sorry, that was not for you personally.

I took this as an opportunity to write down what we mean with the
libweston effort, since it hasn't really been written down before. The
comments in this thread seemed to be more about libweston than your
patch. Apologies for hijacking this thread.

> Actually, I didn't know about libweston and plan regarding it when I create
> this patch. I'm true newbie :-)
> I just hope that my patch work could little help for this good project.

No worries, and I appreciate the effort. Just the timing is a little
awkward because we are looking into this major shift in the code
structure.

If we go with the generic config interface approach for libweston with
the backends as libweston internal details, then the command line
arguments become a property of the main program, which means that every
user of libweston could have different command line arguments for the
same things. It may seem silly at first, but if you think about
weston.ini and what all things third party projects may want to replace
that with, it becomes obvious that there will be incompatible ways to
set essentially the same parameters.


Thanks,
pq