When to use libweston plugin registry

[Armin Krezović]

On 20.07.2016 09:45, Pekka Paalanen wrote:
> Hi Armin,
> 
> I didn't manage to catch you online, so here is re:
> https://paste.debian.net/hidden/ac601ed5/
> 

Hi Pekka,

Sorry for not being available in the past few days. I will be
once again available full time starting tomorrow afternoon.

> Yes, that's the mechanics of using the plugin registry, but I
> didn't think of using it for those particular entries.
> 
> For libweston-core <-> backend APIs using the plugin registry seems
> like an unnecessary detour. I don't see it benefiting anything.
> Libweston-core loads the backend directly and communicates with it
> directly. We also wouldn't want to expose interfaces meant only for
> the use of libweston-core. libweston-core is non-optional, so the
> flexibility is not useful.
> 
> Originally plugin registry was written for plugins to interface
> with other plugins, so that we don't need to keep adding new
> plugin-specific APIs or relays to (lib)weston-core or the
> compositor.
> 
> Another use case in my mind is offering optional interfaces from
> libweston and anything below it to the compositor. It might be seen
> as a layering violation since we skip over libweston-core rather
> than plumbing things through it, but in this case I think it's for
> the better.
> 
> E.g. DRM-backend specific APIs might want to use libdrm, libudev or
> libinput types. If these were exposed from libweston proper, we
> would have libweston depend on all of them, regardless whether the
> compositor actually wanted the DRM-backend. It would be even more
> glaring if x11-backend had some API using XCB or X11 types,
> causing libweston to depend on libxcb. When we use the plugin
> registry for these, we don't need the extra dependencies on the
> libweston-core. The extra dependencies can be pulled in by the
> backends and the interface headers used with the plugin registry as
> needed instead of always.
> 
> In summary, I'd like to see the plugin registry used for optional
> interfaces that might also come with a cost (e.g. extra
> dependencies) if offered straight from libweston proper.
> 
> I still consider it optional even if it is mandatory for using a
> specific backend or feature, because compositors are free to choose
> the backend(s) and features they use.
> 

When we discussed API for configuring outputs, you mentioned that
I should consider using plugin-registry to call backend specific
functions to configure an output.

We already have API's calling into backend specific code via
function pointers (mode switching comes to mind), so I think
it's safe to use same approach for output configuration (backend
specific parts only).

So, to be sure, I don't need plugin-registry for such features?

> 
> Thanks,
> pq
> 

Cheers.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 855 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160720/fb275525/attachment.sig>