{"action":"created","issue":{"url":"https://api.github.com/repos/tuhiproject/tuhi/issues/59","repository_url":"https://api.github.com/repos/tuhiproject/tuhi","labels_url":"https://api.github.com/repos/tuhiproject/tuhi/issues/59/labels{/name}","comments_url":"https://api.github.com/repos/tuhiproject/tuhi/issues/59/comments","events_url":"https://api.github.com/repos/tuhiproject/tuhi/issues/59/events","html_url":"https://github.com/tuhiproject/tuhi/issues/59","id":293275500,"number":59,"title":"Architectural comments","user":{"login":"hadess","id":769861,"avatar_url":"https://avatars1.githubusercontent.com/u/769861?v=4","gravatar_id":"","url":"https://api.github.com/users/hadess","html_url":"https://github.com/hadess","followers_url":"https://api.github.com/users/hadess/followers","following_url":"https://api.github.com/users/hadess/following{/other_user}","gists_url":"https://api.github.com/users/hadess/gists{/gist_id}","starred_url":"https://api.github.com/users/hadess/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/hadess/subscriptions","organizations_url":"https://api.github.com/users/hadess/orgs","repos_url":"https://api.github.com/users/hadess/repos","events_url":"https://api.github.com/users/hadess/events{/privacy}","received_events_url":"https://api.github.com/users/hadess/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":1,"created_at":"2018-01-31T19:05:56Z","updated_at":"2018-02-01T07:58:53Z","closed_at":null,"author_association":"NONE","body":"Good project!\r\n\r\nI've looked through the API, and had a few comments:\r\n- the D-Bus API seems to copy quite a bit of the bluetoothd API when it comes to pairing/unpairing/etc. Is this really needed if all the devices use the same Bluetooth LE transport? In any case, I'd move this functionality to the client, rather than expect the daemon to \r\n- is there any reason for the daemon not to live in the application, or at least in the Flatpak bundle? We could poke a hole through for that, or make a portal that would allow access to BLE devices with a particular GATT value. We can expect the bluetoothd API to stay stable, but the implementation talking to the devices to be refined over time, and expanded quickly. So it's better for it to live with the application (inside the Flatpak container) than in the OS (outside the Flatpak container).\r\n- it would be nice to add the battery support directly in bluetoothd, so that UPower can pick it up when the device is connected. This is the implementation for the generic profile: https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/profiles/battery/battery.c\r\n- I would also remove most of the duplicated metadata in the Device section, a D-Bus path in bluetoothd's D-Bus would likely give you all the metadata you'd want, including the ability to rename specific devices, and get metadata that's not available in the tuhi API **edit: filed as #60**\r\n\r\nI can file specific issues if you agree on a path forward."},"comment":{"url":"https://api.github.com/repos/tuhiproject/tuhi/issues/comments/362187116","html_url":"https://github.com/tuhiproject/tuhi/issues/59#issuecomment-362187116","issue_url":"https://api.github.com/repos/tuhiproject/tuhi/issues/59","id":362187116,"user":{"login":"bentiss","id":2705518,"avatar_url":"https://avatars0.githubusercontent.com/u/2705518?v=4","gravatar_id":"","url":"https://api.github.com/users/bentiss","html_url":"https://github.com/bentiss","followers_url":"https://api.github.com/users/bentiss/followers","following_url":"https://api.github.com/users/bentiss/following{/other_user}","gists_url":"https://api.github.com/users/bentiss/gists{/gist_id}","starred_url":"https://api.github.com/users/bentiss/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bentiss/subscriptions","organizations_url":"https://api.github.com/users/bentiss/orgs","repos_url":"https://api.github.com/users/bentiss/repos","events_url":"https://api.github.com/users/bentiss/events{/privacy}","received_events_url":"https://api.github.com/users/bentiss/received_events","type":"User","site_admin":false},"created_at":"2018-02-01T07:58:53Z","updated_at":"2018-02-01T07:58:53Z","author_association":"COLLABORATOR","body":"Few additions to what @whot said:\r\n- the *pairing* is more of a reverse-pairing if you compare it to bluez. The pairing here consists in registering the host (application) with the device and setting up the clock of the device. This clearly requires a deep knowledge of the internal protocol the device speaks and is not just a proxy over the regular Bluetooth `Pair()`\r\n- yes, we can imagine having both the daemon and the app in the same flatpak. After all, all we need is dbus communication with bluez, so it should be fairly trivial to open the required portals. Python 3.6 is an issue as there is some syntax sugar we prefer to use in 3.6 that makes the code much easier to read\r\n- the device already exports a standard battery GATT characteristic, and it's working fine with bluetoothd. However, the amount of time we connect to the device is to the order of one or two seconds. So basically, even if upowerd shows the device, it'll will just pop up and disappear immediately. This is less than ideal, and I do not think it matters a lot to keep the battery level in upower. The device is meant to be used unconnected, so not having the battery anywhere else outside of the client of tuhi is not an issue IMO.\r\nWhen used in live mode (the device can emulate a regular wacom tablet), the device will stay connected, and upower will show the meaningful information of the battery.\r\n- metadata: should be merged shortly :)"}}
{"actor":{"display_login":"bentiss"}}