(03:56:04 IST) develneubee: jhe: ping
(04:12:17 IST) fdalleau [n=Dalleau@1-111.252-81.static-ip.oleane.fr] entered the room.
(04:12:26 IST) fdalleau left the room (quit: Client Quit).
(04:19:28 IST) jhe: develneubee: pong
(04:20:20 IST) develneubee: jhe: the audio-service will register some methods as callbacks with the plugin right ?
(04:22:10 IST) jhe: develneubee: not sure what you mean
(04:22:42 IST) jhe: develneubee: btw, to avoid confusion don't use the term "method" unless you're talking about D-Bus
(04:23:57 IST) develneubee: jhe: ok. the audio-service would register some callback functions with the plugin, so when some event occurs in the plugin these callbacks will be called. right ?
(04:24:49 IST) develneubee: jhe: ill give an ecample - if the battery indicator changes, the plugin would call "update_batt_status" in the method
(04:24:53 IST) jhe: develneubee: yes, the plugin needs to be able to call functions in the audio service when some event occurs in the plugin
(04:25:57 IST) develneubee: jhe: now would the service register these functions, or would the plugin use standard service method names ?
(04:26:32 IST) jhe: why do you still keep on using terms like "register" and "method"? this has nothing to do with D-Bus
(04:26:50 IST) develneubee: jhe: there is no dbus involved
(04:28:00 IST) jhe: but to get back to the point, since the plugin cannot before-hand know the memory addresses of the functions in the audio service, the audio service needs to pass it those using function pointers, maybe a similar VTable that the plugin itself implements. Or does someone have a better idea how to do this?
(04:28:52 IST) jhe: holtmann: any suggestions how you'd like to do this?
(04:30:07 IST) develneubee: jhe: yeah. another Q - u mentioned that the functions in the plugin would correspond to the procedures in the spec. right ?
(04:30:30 IST) jhe: the functions that the plugin exposes to the audio service, yes
(04:40:26 IST) develneubee: jhe: just for clarification the role of AG will be played by the audio service and the telephony related suff will be delegated to the plugin , right ?
(04:41:42 IST) jhe: I didn't realize that those could be separated
(04:42:00 IST) jhe: the role of the plugin is to act as an adapter to the local telephony subsystem. that's all.
(04:44:11 IST) develneubee: jhe: now "answer a incoming call" procedure can be executed from the HF (ATA) or from the AG itself
(04:46:26 IST) develneubee: jhe: in case of Answer a incoming call from AG , we would have to expose such a method (thru dbus) since the AG is the audio service.
(04:47:41 IST) fdalleau [n=Dalleau@1-111.252-81.static-ip.oleane.fr] entered the room.
(04:48:50 IST) jhe: develneubee: no we don't. if some controling entity (e.g. a GUI) on the device decides to answer a call, the status of the telephony subsystem would change and the plugin would get informed about it (since it is in direct contact with this subsystem)
(04:51:29 IST) develneubee: jhe: so then the role of the AG will be played by the plugin.
(04:52:42 IST) develneubee: if AG has no authority to call/answer call/reject call/terminate call/ then there is not AG as such :)
(04:55:06 IST) jhe: I don't understand what you think the term "AG" means. To me it's just one of two possible roles a Bluetooth device that participates in a HFP connection can act as.
(04:58:17 IST) develneubee: jhe: the AGs role is played by the audio-service in blueZ, right ?
(04:58:46 IST) jhe: and what is needed to implement the requirements of this role is not provided by a single entity but the whole set of components that the system provides (audio service, hfp plugin, telephony subsystem, alsa/gstreamer, etc)
(05:01:04 IST) develneubee: jhe: ok. so the audio service is not exporting any Call related dbus methods.
(05:01:51 IST) jhe: develneubee: at least right now I don't see a need for it since the plugin should be able to handle that part. however if someone demostrates that it is useful we can add them later.
(05:03:34 IST) develneubee: jhe: ok. this actually simplifies a lot of things. handling call functions like accepting a call, rejecting & terminating it from AG would make it complex.