Procedure for adding new APIs

[donny-dont]

I'm wondering if there is a procedure for adding new APIs to libWPE.

Currently in WebKit there are a couple instances where I would potentially want to extend WPE's functionality for our PlayStation implementation and I think some things might be general enough to be of use for libWPE in general.

Currently this is what I was thinking for WebCore related functionality.

• PlatformScreen just has some magic numbers for the screen's attributes.
• For our User Agent we have stuff about the system software version and other things. Feels like there might be a use for getting some system information.

Can open separate issues for each but wanted to see how something like this might work. Thanks!

[aperezdc]

Something that crossed my mind before is using the mailing list ([email protected]), which is what we have done before for WebKitGTK+ new API proposals. That being said, I have nothing against using GitHub, and actually it has some niceties like syntax highlighting and formatting for the written text.

My concerns are that people who are subscribed to the mailing list might be left out of the discussion, and that I would rather not have the discussion tied to a proprietary platform. That being said, I am open to try using GitHub issues as long as we give a heads up in the mailing list when API discussions start here.

Any other opinions?

[aperezdc]

An intermediate option could be what the Rust folks do: a repository of RFCs, where the proposals themselves are written as text documents, changes posted as PRs, and the discussion happening in GitHub comments there. It's still tied to GitHub, but at least it would be possible to clone the repository. Maybe it would feel a bit like “too much bureocracy” as well, so I am not very convincing in foing that way either 🤔

[zdobersek]

@donny-dont I agree with adding new APIs, but we have to set up some guardrails about what things we should be providing API for.

Initial APIs primarily covered the graphics stuff (renderer_backend_egl, renderer_backend_egl_target, renderer_host, view_backend). There's also key mapping stuff, and something around pasteboard that in retrospect I think ideally we wouldn't have added that early.

In essence, all this API (and any future one) is there to provide better integration of WPE into the target environment. APIs that cover screen dimensions or system info are obvious inclusions. As a rule of thumb, we should be considering providing APIs for anything that in WebKit is implementable in platform-specific fashion. But we should really be reviewing new additions on a case-by-case basis, as the need comes up.

My other concern about this is how to handle all these interfaces in libwpe in terms of declaration, definition, integration with users, and API stability.

• declaration & definition: instead of writing out all the code by hand, I would prefer something that's automatically generated from some easier-to-write format. Wayland protocol generation is one example, where all the protocol details are specified in an XML file which then gets translated to C code.

• integration with users: by "users" I mean the WebKIt port, backend implementation libraries and applications that utilize WebKit and/or backend-specific API. This is done the usual way right now, there's a pkg-config file that's installed along with libwpe library and headers, which enables compiling and linking against libwpe. This works, maybe doesn't need to change, but it's still IMO too rigid when adding new API.

• API stability: sure it's useful, but again, it can get in a way when trying to fix APIs that we get wrong (which we will).