linuxwacom/libwacom

RFC: Provide libwacom's information as static set of stable-api json files?

Opened this issue · 0 comments

whot commented

This is an RFC around an idea we had around a year or so ago but so far nothing has come out of it.

libwacom is a static database and the only dynamic part of it is libwacom_new_from_path() which looks up a device. Everything else is const.

libwacom is a C library and while this makes it easy to wrap in language bindings it also introduces a run-time dependency on a library (that uses glib) just to look up some static information.

Arguably we could ship what libwacom does as a single (or set of) json files1. Something like

{
  "version": "1.0.0",
  "tablets": [
     {
        "name": "blah blah",
        "model": "foo",
        "matches": [{ "bus": "usb", "vid": "056A", "pid": "123" }],
        ...
     }
  ],
  "styli": [
     ...
  ]
}

Notably, the content of the json is not the content of the .tablet files but matches the output of the C API. Our .tablet files remain an implementation detail.

The JSON format would have to be stable, same as the C API, the semver version field can help denote which fields one can expect, and clients are required to ignore unknown fields. Either way this would make using libwacom's data files from other languages easier than writing FFI bindings.

The main thing we'd lose is the ability to dynamically add files in /etc/libwacom but that can be worked around by having the json-generating tool pick those up and dump the combined output into /etc/libwacom/libwacom-database.json.

I'm not 100% sure there's a use-case for this - our (few) users already have the code for handling libwacom and there isn't a huge queue of new users. It's unlikely existing users would switch and we'd have to maintain the C library anyway.

Footnotes

  1. or some other easy-to-process file format