On 10/16/07, Thomas Wood <[EMAIL PROTECTED]> wrote: > > On Tue, 2007-10-16 at 17:31 +0200, pHilipp Zabel wrote: > > On 10/16/07, Nuutti Kotivuori <[EMAIL PROTECTED]> wrote: > > > Thomas Wood wrote: > > > > On Friday, Mickey mentioned to me that libmokogsmd would probably not be > > > > used in the final software stack. Instead, he would prefer a d-bus based > > > > interface to GSMD. Yesterday, Rob, Chris and I sat down around a > > > > whiteboard and came up with some thoughts on how the phone functionality > > > > in GUI applications might be managed. > > > > > > I wholeheartedly applaud this decision. I was about to write a long > > > mail with just about the same idea - good thing I don't have to :-) > > > > > > > PhoneKit > > > > *Kit naming seems to be popular nowadays :) > > Well, the other contenders were PhoneD and PhoneManager. We decided > PhoneKit probably fitted best. Plus what you mentioned.
Agreed, that was just an observation. > > I wonder how feasible it would be to specify this dbus API so that it > > could be used as a Connection Manager (Voice Channel type) for the > > Telepathy framework. > > Sounds like a good idea. Do you know what is necessary to do this? I've only read the telepathy spec, I don't have any background in Telepathy. But when I saw "The Telepathy project aims to provide a unified framework for all forms of real time conversations, including [...] voice calls [...]" on telepathy.freedesktop.org, I wondered why this should be limited to sip+VoIP. As far as I understand, the PhoneKit part would just have to supply implementations of the ConnectionManager, Connection and Channel interfaces. AFAIU there'd need to be a new protocol (gsm, cellular, or something like that) and a new simple channel type for voicecalls where the sound isn't transported by the host CPU like with the StreamedMedia channel type. For the ConnectionManager interface, network operator selection could be a bit awkward, as the current RequestConnection method only specifies account name / password / server fqdn, maybe a non-standard operator parameter would have to be used. Also, they intend the ConnectionManager to be a D-Bus service. I guess we wouldn't need that on the phone, where PhoneKit should be running all the time anyway. Most optional interfaces of the Connection (Avatars, Presence, etc.) of the spec don't apply here. Maybe some of them (Forwarding, Privacy) could be adapted to the corresponding GSM functionality, though. PhoneKit would have to keep a VoiceCall Channel object for a running call. Again, maybe some of the optional interfaces (DTMF, Group, Transfer) could be used to add dtmf tone generation, call forwarding or conference call functionality later. SMS sending/receiving could be wrapped by the Channel.Type.Text interface. I expect that an additional interface is necessary if the sms storage selection and things like that are to be exported, too. cheers Philipp
