(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.