Hi,
Finally got the time to read through the Session API proposal. All in
all a nice API that seems to take care of our use cases - with
some comments below. You may have better plans currently, so some of the
comments may be invalid now.
On Tue, 2010-09-14 at 03:53 +0200, ext Marcel Holtmann wrote:
> We need to serialize them on low throughput
> connections.
That may work more or less well. What are the low throughput
connections, is 2G GPRS or ones GPRS subscription bandwidth parameters
one of them? If so, can we properly obtain them?
The next problem is if the low throughput connection can be maxed out by
one application only. If yes, no problem, if not then we're wasting more
power on waiting for applications finishing off their network updates.
Ok, this is kinda premature worrying at this point, serialization is
good in cases when we understand applications use of Session API better.
> The two new interface are Notification and Session of course. Creating a
> new session doesn't mean that it will be ever connected during the
> lifetime of an application. In theory it can happen that an application
> request a session for a specific bearer and the required hardware is not
> even attached to the system.
If we know we can't hotplug the hardware in question, should we fail
with an error instead?
> void Connect()
> This method returns when the connection has been
> established and it is online.
This needs the D-Bus timeout to be properly set in the application,
otherwise the application timeouts before ConnMan, which again is not
bad but perhaps undesirable.
> void Disconnect()
> This method indicates that the current session does
> not need a connection anymore.
>
> In most cases this method returns right away without
> any delays. However in some cases it might take a few
> seconds before a connection can be terminated.
ConnMan should not close the connection if there are other Sessions
active for the same connection, right? I assume that in this case this
method call returns immediately, if ConnMan closes the connection it
will take a few seconds more? Or actually, ConnMan could return almost
immediately anyway, and start closing the connection after that if it is
not needed by other Session anymore (or after a timeout, yet another
later optimization).
>
> boolean Priority [readwrite]
>
> This allows a session to mark itself as priority or
> not. In general application are not allowed to make
> themselves more important than others.
I would like to use this to inform ConnMan when an application really
needs a connection "now" due to e.g. UI actions or whether the
application merely hints that it could make use of a connection if there
are no additional constraints. A constraint could be roaming in 3G which
still costs a lot of money. For example an email application should set
Priority to FALSE if it goes checking for email in the background and
TRUE if the user clicks on the "Sync email now" button in the email UI.
Thus timer based email checking/syncing would not be allowed when
roaming in GPRS in order to avoid money loss added to the GPRS roaming
bill and only the "Sync email now" button presses would force the
connection on when roaming (with resulting money loss but that's what
the user wanted).
> An application that calls the method to connect
> a session is preferred over other sessions. This
> priority value is more for application that wanna
> push themselves up in the asychronization notification
> queue once a bearer becomes online.
That can be an effect of Priority as well.
> For example a streaming session should set the
> priority value. As soon as realtime data is involved
> then this should be set. An email client should not
> set this value.
>
> FIXME: Should this be renamed to Realtime?
This part sounds like another equally well needed setting to me. It's
not clear to me how this combines with the ordering and importance
described earlier.
> array{string} AllowedBearers [readwrite]
>
> A list of bearers that can be used for this session.
> In general this list should be empty to indicate that
> any bearer is acceptable.
Would it be easier for the application with only a bearer type (WLAN,
GPRS, WiMAX, etc) specified here? How does the average application
developer decide which bearers he can use?
> dict Proxy [readonly]
>
> Current proxy configuration. This settings is only
> valid when online is true as well. Otherwise an
> empty dictionary is reported.
Should we keep proxy handling with libproxy and pacrunner?
> boolean StayConnected [readwrite]
>
> This disables the idle timeout for this session. There
> is no guarantee and this should be used with care.
Same guarantees given for StayConnected could be given here.
> uint32 PeriodicConnect [readwrite]
>
> Indicate that a periodic connection attempt every
> n minutes should be made. The minutes value is a
> suggestion when to connection. There is not guarantee
> that it will be made of succeeds. A value of 0 disable
> this feature.
>
> This feature is interesting for applications that
> wanna check status on a regular interval. And instead
> of the application waking up and trying to connect,
> this can be centralized nicely and multiple wakeups
> avoid in case no connection is available.
>
> An example application would be an email client that
> wants to check for new emails every 10 minutes.
>
> On purpose the smallest setting is 1 minute here since
> waking up more often and trying to set up a connection
> seems rather pointless use case.
>
> If an interval step has passed this can be nicely
> rescheduled when any connection matching the bearer
> settings becomes available becomes available. Using
> this feature it is also easy to avoid congestions.
Hmm, I think this part should preferably be handled by ConnMan only. Any
numbers supplied could be taken in as hints, but could this part be
considered an optimization when we get real apps using the Session API?
ConnMan probably can (be made to) know better how useful it is to scan
and at which period depending on previously found networks, location,
etc. etc.
Cheers,
Patrik
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
