Hi Marcel,
Thanks for writing the session idea up.
> 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?
Additional it could be very useful to know which
service is currently used.
> 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?
> 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?
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.
> 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?
>
>
> 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?
> 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?
> 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.
hth,
daniel
_______________________________________________
connman mailing list
[email protected]
http://lists.connman.net/listinfo/connman
