Hi Marcel, On 18.10.2011 18:08, Marcel Holtmann wrote: >>>>> So we have 99% of application that should only be notified when they are >>>>> really online. Telling them that we are ready, but not online, just >>>>> wakes them up for no real reason. >>>> >>>> I am 67,6% sure your numbers are not correct. >>>> >>>>> The only 1% that might care about link local connections are the DLNA >>>>> type of application for your home entertainment. Similar to what Apple >>>>> does with AirPlay. However we already have Avahi for this stuff. Why >>>>> would we need another set of notifications? >>>> >>>> Okay, let's leave the "connecting" state away, what about the "suspend" >>>> one? Would you prefer to model it as new Setting instead of merging this >>>> one into Online? >>> >>> Lets think about application wakeups first. Why do you wanna wake up an >>> application for this. I do not see the need for it. >> >> The application is already running (or in a running state) in this >> scenario. > > it already knows that it is in connecting state since it called Connect > in the first place. So this state is rather pointless.
I agree and it can be easily done with a timer on the application side. >>> To be honest this all sounds fine on the surface, but once I look at the >>> implications I am having problems to come up with a good reason on doing >>> this. I am currently not seeing this need. >> >> If an application knows that the data link is suspended it could stop >> all timeout timers because it doesn't make sense to keep them running. >> >> If the link resumes the timer can also be resumed. This is what I have >> heard is working quite good for our current implementation here and >> hence the request to have something similar around. >> >> I see that oFono exports this information through the Suspended property >> in the ConnectionManager API. I didn't see anything like this on the >> BlueZ APIs (when ConnMan uses PAN). So this information is already there >> and can be used at least for real modems. I don't really understand your >> argument about the implications. > > The oFono Suspended property is different. That is a GPRS network > specific details of suspended data connection when you get a phone call. > It is a limitation of being on a GSM network. And that one is just > present so the UI can tell the user that its connection got suspended. This is what I was trying to explain what I want to signal to the application. > Keep in mind that this is also only useful for a limited amount time > where the network holds your IP details and your TCP connection timeout > did not kick in. If we are talking of 1 hour phone call you are just out > of luck anyway. Sure, for short phone calls it should work although. > So far enough, GSM networks can signal a suspended state while > potentially keeping the IP address (TCP connection might still timeout). > > Where else do you see this? I am not sure if this kind of information would accessible over Bluetooth if we have a smartphone connected to the head unit and we are doing HFP and PAN at the same time. Need to dig into the standards first. cheers, daniel _______________________________________________ connman mailing list [email protected] http://lists.connman.net/listinfo/connman
