Hi Daniel,
> > Also we might have applications that only care about a specific bearer
> > being active and online. If not they will sleep. Waking them up on every
> > bearer change is rather pointless and wasteful.
>
> Is bearer only things like '3g' or 'wifi'? Does VPN also belong to
> bearers?
I think we need to count VPN as bearer as well. Also my idea is to have
something like vendor bearer as mentioned later. Or maybe some
annotation of bearer. Something like "intel-vpn" so that an application
gets only notified when the VPN is up and running.
> Additional it could be very useful to know which
> service is currently used.
I considered that and no. With the API the application should not get
these kind of details. It tell you up front what it wants to know about
and that is what it gets.
> > Simple idea is that every application can create one (or even multiple)
> > session objects.
>
> Having multiple session object raises the question how several session
> object interact with each other. Or how the depend on each other.
>
> Let's assume following use case: an email agent wants to periodically
> look for new mails. Depending on the bearer it wants different
> periodic intervals. For wifi 10 minutes whereas for 3g only 20
> minutes. In this case I would create to session objects defining the
> two periodic intervals. But how do I tell connman which one should be
> choosen to connect first?
Actually ConnMan knows if two sessions belong to the same application
and then it could just sort them as it likes. Something WiFi before 3G
or something. Also 3G is special since it is always connected anyway.
Then on the other hand, I think an email application not using push
notification support or IMAP IDLE needs to be banned here ;)
But seriously, there will be some hard work inside ConnMan to make this
all as efficient as possible, but that is what we signed up in the first
place anyway. All core logic inside ConnMan. So we have to be smart
while our applications can be utterly stupid. And if they ask something
really stupid (conflicting) we just ignore them.
> > 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. Like a vendor bearer with a specific SIM
> > card or something alike.
>
> Wouldn't this vendor SIM uniquely identified by bearer only? Isn't a
> service unique identifier a better option for this?
I don't wanna mix the service in here. Since that could potentially
change over time. However this idea needs a bit more work anyway.
> Another thing which comes to be mind is the home/roaming thingy (jups,
> i'm still writing stats patches... :)). E.g. an application is only
> interested in connections when it's the home network.
We can add that as a simple setting. Say RoamingAllowed = false.
> > The notification agent is rather simple. It just will tell the
> > application when settings of the session have changed. The idea to do
> > this via an agent is to ensure it is race free and that only the
> > specific application gets woken up.
> >
> > Service unique name
> > Interface org.moblin.connman.Notification
> > Object path freely definable
> >
> > Methods void Release()
> >
> > This method gets called when the service daemon
> > unregisters the session. A counter can use it to do
> > cleanup tasks. There is no need to unregister the
> > session, because when this method gets called it has
> > already been unregistered.
> >
> > void Update(dict settings)
> >
> > Sends an update of changed settings. Only settings
> > that are changed will be included.
> >
> > Initially on every session creation this method is
> > called once to inform about the current settings.
>
> dict settings are the settings from the session object only?
Yes, only the session settings. Nothing else. The idea is to make this
part of the API self-contained and a bit more abstract.
That way ConnMan could delay delivering of the Update method for some
application and serialize the updates and hence Internet activity in
case you connection has bad latency or is just slow.
A bunch of these ideas will not come right away, since we need a bit
better kernel magic to support them, but the API has the power to allow
us to do this right.
> > Service org.moblin.connman
> > Interface org.moblin.connman.Session
> > Object path variable
> >
> > Methods void Destroy()
> >
> > Close the current session. This is similar to
> > DestroySession method on the manager interface. It
> > is just provided for convenience depending on how
> > the application wants to track the session.
> >
> > void Connect()
> >
> > If not connected, then attempt to connect this
> > session.
> >
> > The usage of this method depends a little bit on
> > the model if the application. Some application
> > should not try to any session at all. They should
> > just monitor if it becomes online or gets back
> > offline.
> >
> > Others might require an active connection right now.
> > So for example email notification should only check
> > for new emails when a connection is available. However
> > if the user presses the button for get email or wants
> > to send an email it should request to get online with
> > this method.
> >
> > Depending on the bearer settings the current service
> > is used or a new service will be connected.
> >
> > This method returns when the connection has been
> > established and it is online. Additionally an update
> > notification with the IP settings is sent.
> >
> > It is also not guaranteed that a session stays online
> > after this method call. It can be take offline at any
> > time. This might happen because of idle timeouts or
> > other reasons.
> >
> > It is safe to call this method multiple times. The
> > actual usage will be sorted out for the application.
> >
> > 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.
> >
> > void Change(string name, variant value)
> >
> > Change the value of a certain settings. Not all
> > settings can be changed. Normally this should not
> > be needed or an extra session should be created.
> > However in some cases it makes sense to change
> > a value and trigger different behavior.
> >
> > A change of a setting will cause an update notification
> > to be sent. Some changes might cause the session to
> > be moved to offline state.
> >
> > Settings string Bearer [readonly]
> >
> > This indicates the current bearer that is used
> > for this session. Or an empty string if no bearer
> > is available.
>
> Maybe a 'string Service' as I suggestion above?
Still no ;)
> > boolean Online [readonly]
> >
> > This indicates if the connection is online or
> > offline.
> >
> > This maps to the online service state. And it is
> > only valid for the selected bearer configuration.
> > Otherwise it will be reported as offline even if
> > the global state would be online.
> >
> > In addition the Online settings notification might
> > not happen right away. Notifications of online state
> > can be delayed based on the speed of the bearer. It
> > is done to avoid congestion on bearers like 3G etc.
> >
> > 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.
> >
> > The priority handling is done internally by usage
> > and first come, first serve order. By default this
> > settings is of course false.
> >
> > Internally there can be different priorities for
> > different application, but these are defined by a
> > configuration file and not via this interface.
> >
> > 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.
> >
> > This actual priority order also depends on the
> > allowed bearers and other factors. This is setting
> > is just a little indicator of one application being
> > notified before another one.
> >
> > 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?
> >
> > string Description [readonly]
> >
> > 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.
>
> Is this array priority based?
Nope. At least not that I planned, but we could make it like that.
As I said, a bunch of these still need a bit more work and better
explanations on their usage. Some of them might need to be split into
multiple settings.
> > dict IPv4 [readonly]
> >
> > Current IPv4 configuration. This settings is only
> > valid when online is true as well. Otherwise an
> > empty dictionary is reported.
> >
> > dict IPv6 [readonly]
> >
> > Current IPv6 configuration. This settings is only
> > valid when online is true as well. Otherwise an
> > empty dictionary is reported.
> >
> > dict Proxy [readonly]
> >
> > Current proxy configuration. This settings is only
> > valid when online is true as well. Otherwise an
> > empty dictionary is reported.
> >
> > boolean AvoidHandover [readwrite]
> >
> > By default this settings is false. It can be used
> > to indicate that a handover is currently not a good
> > idea. However no connection is guaranteed. So a
> > handover can happen anyway. This is just an indication
> > that the application would like to avoid it right now.
> >
> > It is a bad idea to always enable this settings and
> > actually it will be reset after a while to avoid
> > congestion.
> >
> > Main use case it for application that are currently
> > doing a specific tasks that it prefers to finish
> > before allowing handovers again. An example would
> > be sychronization.
> >
> > Never the less application needs to be aware that
> > handovers can happen at any time even if this is
> > set to true.
> >
> > boolean StayConnected [readwrite]
> >
> > This disables the idle timeout for this session. There
> > is no guarantee and this should be used with care.
> >
> > 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.
> >
> > Some of these session settings are obvious and others need a bit more
> > thinking about it. This is just an initial idea to cover as many
> > requirements as currently known.
> >
> > Please comment as much as possible.
Regards
Marcel
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
