Hi, ________________________________________ From: [email protected] [[email protected]] On Behalf Of ext Nicola Mfb [[email protected]]
On Thu, Jun 17, 2010 at 10:14 AM, Thiago Macieira <[email protected]> wrote: > Em Quinta-feira 17 Junho 2010, às 09:19:21, [email protected] escreveu: [...] >>> Not necessarily with this plugin. Bearermanagement can only start and stop >>> already configured connections. >> >> It's also not the objective of the Bearer Management API to do system >> configuration. The objective is for applications to declare that they would >> like a network connection to be set up, and also to find out about changes to >> it. Some applications may modify their networking behaviour depending on >> whether you're on GPRS/3G or WiFi. Others also do that accoring to power >> state. >> >> System configuration belongs to the system and that includes whether the >> requests for bringing network bearers up or down will be honoured. >Why not? such type of abstraction should be perfect for the >qt/qt-mobility objective and bearer plugins may declare or not, with a >particular capability, if they are able to create/modify network >configurations (simply my suggestion is write system dialogs or a >"super connection manager gui" with qt-mobility too and reuse them >everywhere). When the bearer API design started (some 1.5 years ago) creation and modification was not on the list of requirements. In fact it was purposely excluded as we saw little value at the time. Our main use case for the API is to be able to just use QNetworkAccessManager without worrying about any connectivity state (including roaming). The second use case was to manually bring up connections for those apps which do their own socket handling. At the end of the day your suggestion would be some sort of API that manages key-value pairs plus some UI for it. Personally I have doubts about its usefulness - especially in a middleware layer API and more importantly how many apps would there be which would use such a feature. The effort vs gain ratio for UI elements would be particularly bad especially the UI is likely to be the distinguishing factor between the various apps wanting to provide such features. Generally you have a single system app doing this kind of business. This very much feeds into what Thiago already mentioned. -- Alex _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
