When to use libweston plugin registry

[Pekka Paalanen]

Hi Armin,

I didn't manage to catch you online, so here is re:
https://paste.debian.net/hidden/ac601ed5/

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.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 811 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20160720/6efb2ac6/attachment.sig>