efl/src/lib/ecore_con/efl_net_control_technology.eo

100 lines
3.4 KiB
Plaintext
Raw Normal View History

enum Efl.Net.Control.Technology_Type {
efl_net_session and efl_net_control for ConnMan These are objects to allow control of networking devices (efl_net_control) as well as an application to request for connectivity (efl_net_session). They are loosely based on ConnMan.org, which we already use in Enlightenment Window Manager via DBus access with Eldbus. However they do not map 1:1 as the goal was to expose a viable subset of controls but in a simple and general way, thus nome strings were converted to enums, some arrays of strings were converted to bitwise flags, some names were made more general, such as "service" was turned into "access point" so it doesn't generate confusion with other "network services" (ie: http server), or "favorite" that was renamed to "remembered". Some behavior are slightly different (yet able to be implemented on top), such as "Service.MoveBefore" and "MoveAfter" were converted to a numeric "priority", calculated from service's list index, changing the priority will reoder the list and thus generate the MoveBefore and MoveAfter DBus commands. ConnMan was chosen not only because we already use it, but because its DBus API is sane and simple, with the server doing almost all that we need. This is visible in the efl_net_session, which is completely done in the server and do not require any extra work on our side -- aside from talking DBus and converting to Eo, which is a major work :-D NOTE: ConnMan doesn't use FreeDesktop.Org DBus interfaces such as Properties and ObjectManager, thus we cannot use eldbus_model_object. There are two examples added: - efl_net_session_example: monitors the connection available for an application and try to connect. You need a connman compiled with session_policy_local and a configuration file explained in https://github.com/aldebaran/connman/blob/master/doc/session-policy-format.txt to get a connection if nothing is connected. Otherwise it will just monitor the connectivity state. - efl_net_control_example: monitors, plays the agent and configure the network details. It can enable/disable technologies, connect to access points (services) and configure them. It's quite extensive as allows testing all of ConnMan's DBus API except P2P (Peers).
2016-09-15 17:43:19 -07:00
[[Technology types
@since 1.19
]]
unknown, [[Type: unknown]]
system, [[Type: system]]
ethernet, [[Type: ethernet]]
wifi, [[Type: WiFi]]
bluetooth, [[Type: Bluetooth]]
cellular, [[Type: cellular/mobile]]
gps, [[Type: GPS]]
vpn, [[Type: Virtual Private Network]]
gadget, [[Type: USB gadget]]
p2p, [[Type: Peer-2-Peer]]
efl_net_session and efl_net_control for ConnMan These are objects to allow control of networking devices (efl_net_control) as well as an application to request for connectivity (efl_net_session). They are loosely based on ConnMan.org, which we already use in Enlightenment Window Manager via DBus access with Eldbus. However they do not map 1:1 as the goal was to expose a viable subset of controls but in a simple and general way, thus nome strings were converted to enums, some arrays of strings were converted to bitwise flags, some names were made more general, such as "service" was turned into "access point" so it doesn't generate confusion with other "network services" (ie: http server), or "favorite" that was renamed to "remembered". Some behavior are slightly different (yet able to be implemented on top), such as "Service.MoveBefore" and "MoveAfter" were converted to a numeric "priority", calculated from service's list index, changing the priority will reoder the list and thus generate the MoveBefore and MoveAfter DBus commands. ConnMan was chosen not only because we already use it, but because its DBus API is sane and simple, with the server doing almost all that we need. This is visible in the efl_net_session, which is completely done in the server and do not require any extra work on our side -- aside from talking DBus and converting to Eo, which is a major work :-D NOTE: ConnMan doesn't use FreeDesktop.Org DBus interfaces such as Properties and ObjectManager, thus we cannot use eldbus_model_object. There are two examples added: - efl_net_session_example: monitors the connection available for an application and try to connect. You need a connman compiled with session_policy_local and a configuration file explained in https://github.com/aldebaran/connman/blob/master/doc/session-policy-format.txt to get a connection if nothing is connected. Otherwise it will just monitor the connectivity state. - efl_net_control_example: monitors, plays the agent and configure the network details. It can enable/disable technologies, connect to access points (services) and configure them. It's quite extensive as allows testing all of ConnMan's DBus API except P2P (Peers).
2016-09-15 17:43:19 -07:00
}
class Efl.Net.Control.Technology extends Efl.Loop_Consumer {
[[A technology that allows control of network access points.
efl_net_session and efl_net_control for ConnMan These are objects to allow control of networking devices (efl_net_control) as well as an application to request for connectivity (efl_net_session). They are loosely based on ConnMan.org, which we already use in Enlightenment Window Manager via DBus access with Eldbus. However they do not map 1:1 as the goal was to expose a viable subset of controls but in a simple and general way, thus nome strings were converted to enums, some arrays of strings were converted to bitwise flags, some names were made more general, such as "service" was turned into "access point" so it doesn't generate confusion with other "network services" (ie: http server), or "favorite" that was renamed to "remembered". Some behavior are slightly different (yet able to be implemented on top), such as "Service.MoveBefore" and "MoveAfter" were converted to a numeric "priority", calculated from service's list index, changing the priority will reoder the list and thus generate the MoveBefore and MoveAfter DBus commands. ConnMan was chosen not only because we already use it, but because its DBus API is sane and simple, with the server doing almost all that we need. This is visible in the efl_net_session, which is completely done in the server and do not require any extra work on our side -- aside from talking DBus and converting to Eo, which is a major work :-D NOTE: ConnMan doesn't use FreeDesktop.Org DBus interfaces such as Properties and ObjectManager, thus we cannot use eldbus_model_object. There are two examples added: - efl_net_session_example: monitors the connection available for an application and try to connect. You need a connman compiled with session_policy_local and a configuration file explained in https://github.com/aldebaran/connman/blob/master/doc/session-policy-format.txt to get a connection if nothing is connected. Otherwise it will just monitor the connectivity state. - efl_net_control_example: monitors, plays the agent and configure the network details. It can enable/disable technologies, connect to access points (services) and configure them. It's quite extensive as allows testing all of ConnMan's DBus API except P2P (Peers).
2016-09-15 17:43:19 -07:00
The @Efl.Net.Control.Manager is composed of multiple technologies, each
efl_net_session and efl_net_control for ConnMan These are objects to allow control of networking devices (efl_net_control) as well as an application to request for connectivity (efl_net_session). They are loosely based on ConnMan.org, which we already use in Enlightenment Window Manager via DBus access with Eldbus. However they do not map 1:1 as the goal was to expose a viable subset of controls but in a simple and general way, thus nome strings were converted to enums, some arrays of strings were converted to bitwise flags, some names were made more general, such as "service" was turned into "access point" so it doesn't generate confusion with other "network services" (ie: http server), or "favorite" that was renamed to "remembered". Some behavior are slightly different (yet able to be implemented on top), such as "Service.MoveBefore" and "MoveAfter" were converted to a numeric "priority", calculated from service's list index, changing the priority will reoder the list and thus generate the MoveBefore and MoveAfter DBus commands. ConnMan was chosen not only because we already use it, but because its DBus API is sane and simple, with the server doing almost all that we need. This is visible in the efl_net_session, which is completely done in the server and do not require any extra work on our side -- aside from talking DBus and converting to Eo, which is a major work :-D NOTE: ConnMan doesn't use FreeDesktop.Org DBus interfaces such as Properties and ObjectManager, thus we cannot use eldbus_model_object. There are two examples added: - efl_net_session_example: monitors the connection available for an application and try to connect. You need a connman compiled with session_policy_local and a configuration file explained in https://github.com/aldebaran/connman/blob/master/doc/session-policy-format.txt to get a connection if nothing is connected. Otherwise it will just monitor the connectivity state. - efl_net_control_example: monitors, plays the agent and configure the network details. It can enable/disable technologies, connect to access points (services) and configure them. It's quite extensive as allows testing all of ConnMan's DBus API except P2P (Peers).
2016-09-15 17:43:19 -07:00
can be disabled/enabled with @.powered property.
When powered, the technology will dynamically create and remove
access points in
@Efl.Net.Control.Manager.access_points.
efl_net_session and efl_net_control for ConnMan These are objects to allow control of networking devices (efl_net_control) as well as an application to request for connectivity (efl_net_session). They are loosely based on ConnMan.org, which we already use in Enlightenment Window Manager via DBus access with Eldbus. However they do not map 1:1 as the goal was to expose a viable subset of controls but in a simple and general way, thus nome strings were converted to enums, some arrays of strings were converted to bitwise flags, some names were made more general, such as "service" was turned into "access point" so it doesn't generate confusion with other "network services" (ie: http server), or "favorite" that was renamed to "remembered". Some behavior are slightly different (yet able to be implemented on top), such as "Service.MoveBefore" and "MoveAfter" were converted to a numeric "priority", calculated from service's list index, changing the priority will reoder the list and thus generate the MoveBefore and MoveAfter DBus commands. ConnMan was chosen not only because we already use it, but because its DBus API is sane and simple, with the server doing almost all that we need. This is visible in the efl_net_session, which is completely done in the server and do not require any extra work on our side -- aside from talking DBus and converting to Eo, which is a major work :-D NOTE: ConnMan doesn't use FreeDesktop.Org DBus interfaces such as Properties and ObjectManager, thus we cannot use eldbus_model_object. There are two examples added: - efl_net_session_example: monitors the connection available for an application and try to connect. You need a connman compiled with session_policy_local and a configuration file explained in https://github.com/aldebaran/connman/blob/master/doc/session-policy-format.txt to get a connection if nothing is connected. Otherwise it will just monitor the connectivity state. - efl_net_control_example: monitors, plays the agent and configure the network details. It can enable/disable technologies, connect to access points (services) and configure them. It's quite extensive as allows testing all of ConnMan's DBus API except P2P (Peers).
2016-09-15 17:43:19 -07:00
@since 1.19
]]
events {
changed: void; [[Called when some properties were changed.]]
efl_net_session and efl_net_control for ConnMan These are objects to allow control of networking devices (efl_net_control) as well as an application to request for connectivity (efl_net_session). They are loosely based on ConnMan.org, which we already use in Enlightenment Window Manager via DBus access with Eldbus. However they do not map 1:1 as the goal was to expose a viable subset of controls but in a simple and general way, thus nome strings were converted to enums, some arrays of strings were converted to bitwise flags, some names were made more general, such as "service" was turned into "access point" so it doesn't generate confusion with other "network services" (ie: http server), or "favorite" that was renamed to "remembered". Some behavior are slightly different (yet able to be implemented on top), such as "Service.MoveBefore" and "MoveAfter" were converted to a numeric "priority", calculated from service's list index, changing the priority will reoder the list and thus generate the MoveBefore and MoveAfter DBus commands. ConnMan was chosen not only because we already use it, but because its DBus API is sane and simple, with the server doing almost all that we need. This is visible in the efl_net_session, which is completely done in the server and do not require any extra work on our side -- aside from talking DBus and converting to Eo, which is a major work :-D NOTE: ConnMan doesn't use FreeDesktop.Org DBus interfaces such as Properties and ObjectManager, thus we cannot use eldbus_model_object. There are two examples added: - efl_net_session_example: monitors the connection available for an application and try to connect. You need a connman compiled with session_policy_local and a configuration file explained in https://github.com/aldebaran/connman/blob/master/doc/session-policy-format.txt to get a connection if nothing is connected. Otherwise it will just monitor the connectivity state. - efl_net_control_example: monitors, plays the agent and configure the network details. It can enable/disable technologies, connect to access points (services) and configure them. It's quite extensive as allows testing all of ConnMan's DBus API except P2P (Peers).
2016-09-15 17:43:19 -07:00
}
methods {
@property powered {
[[If $true the technology is available. If $false technology is disabled and if possible rfkill is used.]]
get { }
set { }
values {
powered: bool; [[$true if technology is powered, $false otherwise]]
efl_net_session and efl_net_control for ConnMan These are objects to allow control of networking devices (efl_net_control) as well as an application to request for connectivity (efl_net_session). They are loosely based on ConnMan.org, which we already use in Enlightenment Window Manager via DBus access with Eldbus. However they do not map 1:1 as the goal was to expose a viable subset of controls but in a simple and general way, thus nome strings were converted to enums, some arrays of strings were converted to bitwise flags, some names were made more general, such as "service" was turned into "access point" so it doesn't generate confusion with other "network services" (ie: http server), or "favorite" that was renamed to "remembered". Some behavior are slightly different (yet able to be implemented on top), such as "Service.MoveBefore" and "MoveAfter" were converted to a numeric "priority", calculated from service's list index, changing the priority will reoder the list and thus generate the MoveBefore and MoveAfter DBus commands. ConnMan was chosen not only because we already use it, but because its DBus API is sane and simple, with the server doing almost all that we need. This is visible in the efl_net_session, which is completely done in the server and do not require any extra work on our side -- aside from talking DBus and converting to Eo, which is a major work :-D NOTE: ConnMan doesn't use FreeDesktop.Org DBus interfaces such as Properties and ObjectManager, thus we cannot use eldbus_model_object. There are two examples added: - efl_net_session_example: monitors the connection available for an application and try to connect. You need a connman compiled with session_policy_local and a configuration file explained in https://github.com/aldebaran/connman/blob/master/doc/session-policy-format.txt to get a connection if nothing is connected. Otherwise it will just monitor the connectivity state. - efl_net_control_example: monitors, plays the agent and configure the network details. It can enable/disable technologies, connect to access points (services) and configure them. It's quite extensive as allows testing all of ConnMan's DBus API except P2P (Peers).
2016-09-15 17:43:19 -07:00
}
}
@property tethering {
[[Tethering allows the default access point to be bridged to all clients connected through the technology.
A common use case is to deploy the device as a router, such as
a tethered phone allowing a laptop to connect to a 4G
efl_net_session and efl_net_control for ConnMan These are objects to allow control of networking devices (efl_net_control) as well as an application to request for connectivity (efl_net_session). They are loosely based on ConnMan.org, which we already use in Enlightenment Window Manager via DBus access with Eldbus. However they do not map 1:1 as the goal was to expose a viable subset of controls but in a simple and general way, thus nome strings were converted to enums, some arrays of strings were converted to bitwise flags, some names were made more general, such as "service" was turned into "access point" so it doesn't generate confusion with other "network services" (ie: http server), or "favorite" that was renamed to "remembered". Some behavior are slightly different (yet able to be implemented on top), such as "Service.MoveBefore" and "MoveAfter" were converted to a numeric "priority", calculated from service's list index, changing the priority will reoder the list and thus generate the MoveBefore and MoveAfter DBus commands. ConnMan was chosen not only because we already use it, but because its DBus API is sane and simple, with the server doing almost all that we need. This is visible in the efl_net_session, which is completely done in the server and do not require any extra work on our side -- aside from talking DBus and converting to Eo, which is a major work :-D NOTE: ConnMan doesn't use FreeDesktop.Org DBus interfaces such as Properties and ObjectManager, thus we cannot use eldbus_model_object. There are two examples added: - efl_net_session_example: monitors the connection available for an application and try to connect. You need a connman compiled with session_policy_local and a configuration file explained in https://github.com/aldebaran/connman/blob/master/doc/session-policy-format.txt to get a connection if nothing is connected. Otherwise it will just monitor the connectivity state. - efl_net_control_example: monitors, plays the agent and configure the network details. It can enable/disable technologies, connect to access points (services) and configure them. It's quite extensive as allows testing all of ConnMan's DBus API except P2P (Peers).
2016-09-15 17:43:19 -07:00
network.
]]
get { }
set { }
values {
enabled: bool; [[When to enable or disable tethering for this technology.]]
identifier: string @optional; [[The name to identify the tethering. For WiFi this will translate to an SSID.]]
passphrase: string @optional; [[The passphrase for tethering access. For WiFi this will translate to WPA passphrase.]]
efl_net_session and efl_net_control for ConnMan These are objects to allow control of networking devices (efl_net_control) as well as an application to request for connectivity (efl_net_session). They are loosely based on ConnMan.org, which we already use in Enlightenment Window Manager via DBus access with Eldbus. However they do not map 1:1 as the goal was to expose a viable subset of controls but in a simple and general way, thus nome strings were converted to enums, some arrays of strings were converted to bitwise flags, some names were made more general, such as "service" was turned into "access point" so it doesn't generate confusion with other "network services" (ie: http server), or "favorite" that was renamed to "remembered". Some behavior are slightly different (yet able to be implemented on top), such as "Service.MoveBefore" and "MoveAfter" were converted to a numeric "priority", calculated from service's list index, changing the priority will reoder the list and thus generate the MoveBefore and MoveAfter DBus commands. ConnMan was chosen not only because we already use it, but because its DBus API is sane and simple, with the server doing almost all that we need. This is visible in the efl_net_session, which is completely done in the server and do not require any extra work on our side -- aside from talking DBus and converting to Eo, which is a major work :-D NOTE: ConnMan doesn't use FreeDesktop.Org DBus interfaces such as Properties and ObjectManager, thus we cannot use eldbus_model_object. There are two examples added: - efl_net_session_example: monitors the connection available for an application and try to connect. You need a connman compiled with session_policy_local and a configuration file explained in https://github.com/aldebaran/connman/blob/master/doc/session-policy-format.txt to get a connection if nothing is connected. Otherwise it will just monitor the connectivity state. - efl_net_control_example: monitors, plays the agent and configure the network details. It can enable/disable technologies, connect to access points (services) and configure them. It's quite extensive as allows testing all of ConnMan's DBus API except P2P (Peers).
2016-09-15 17:43:19 -07:00
}
}
@property connected {
[[If $true the technology has at least one access point connected.]]
get { }
values {
connected: bool; [[$true if technology is connected, $false otherwise]]
efl_net_session and efl_net_control for ConnMan These are objects to allow control of networking devices (efl_net_control) as well as an application to request for connectivity (efl_net_session). They are loosely based on ConnMan.org, which we already use in Enlightenment Window Manager via DBus access with Eldbus. However they do not map 1:1 as the goal was to expose a viable subset of controls but in a simple and general way, thus nome strings were converted to enums, some arrays of strings were converted to bitwise flags, some names were made more general, such as "service" was turned into "access point" so it doesn't generate confusion with other "network services" (ie: http server), or "favorite" that was renamed to "remembered". Some behavior are slightly different (yet able to be implemented on top), such as "Service.MoveBefore" and "MoveAfter" were converted to a numeric "priority", calculated from service's list index, changing the priority will reoder the list and thus generate the MoveBefore and MoveAfter DBus commands. ConnMan was chosen not only because we already use it, but because its DBus API is sane and simple, with the server doing almost all that we need. This is visible in the efl_net_session, which is completely done in the server and do not require any extra work on our side -- aside from talking DBus and converting to Eo, which is a major work :-D NOTE: ConnMan doesn't use FreeDesktop.Org DBus interfaces such as Properties and ObjectManager, thus we cannot use eldbus_model_object. There are two examples added: - efl_net_session_example: monitors the connection available for an application and try to connect. You need a connman compiled with session_policy_local and a configuration file explained in https://github.com/aldebaran/connman/blob/master/doc/session-policy-format.txt to get a connection if nothing is connected. Otherwise it will just monitor the connectivity state. - efl_net_control_example: monitors, plays the agent and configure the network details. It can enable/disable technologies, connect to access points (services) and configure them. It's quite extensive as allows testing all of ConnMan's DBus API except P2P (Peers).
2016-09-15 17:43:19 -07:00
}
}
@property type {
[[The technology type, such as "ethernet" or "wifi"]]
get { }
values {
type: Efl.Net.Control.Technology_Type; [[Technology type]]
efl_net_session and efl_net_control for ConnMan These are objects to allow control of networking devices (efl_net_control) as well as an application to request for connectivity (efl_net_session). They are loosely based on ConnMan.org, which we already use in Enlightenment Window Manager via DBus access with Eldbus. However they do not map 1:1 as the goal was to expose a viable subset of controls but in a simple and general way, thus nome strings were converted to enums, some arrays of strings were converted to bitwise flags, some names were made more general, such as "service" was turned into "access point" so it doesn't generate confusion with other "network services" (ie: http server), or "favorite" that was renamed to "remembered". Some behavior are slightly different (yet able to be implemented on top), such as "Service.MoveBefore" and "MoveAfter" were converted to a numeric "priority", calculated from service's list index, changing the priority will reoder the list and thus generate the MoveBefore and MoveAfter DBus commands. ConnMan was chosen not only because we already use it, but because its DBus API is sane and simple, with the server doing almost all that we need. This is visible in the efl_net_session, which is completely done in the server and do not require any extra work on our side -- aside from talking DBus and converting to Eo, which is a major work :-D NOTE: ConnMan doesn't use FreeDesktop.Org DBus interfaces such as Properties and ObjectManager, thus we cannot use eldbus_model_object. There are two examples added: - efl_net_session_example: monitors the connection available for an application and try to connect. You need a connman compiled with session_policy_local and a configuration file explained in https://github.com/aldebaran/connman/blob/master/doc/session-policy-format.txt to get a connection if nothing is connected. Otherwise it will just monitor the connectivity state. - efl_net_control_example: monitors, plays the agent and configure the network details. It can enable/disable technologies, connect to access points (services) and configure them. It's quite extensive as allows testing all of ConnMan's DBus API except P2P (Peers).
2016-09-15 17:43:19 -07:00
}
}
scan {
[[Explicitly trigger a scan.
The scan will happen asynchronously in the background,
with the results being delivered by events in the
technology, @Efl.Net.Control.Manager or @Efl.Net.Control.Access_Point
associated with the technology. For example, a scan on
WiFi will add and remove access points.
efl_net_session and efl_net_control for ConnMan These are objects to allow control of networking devices (efl_net_control) as well as an application to request for connectivity (efl_net_session). They are loosely based on ConnMan.org, which we already use in Enlightenment Window Manager via DBus access with Eldbus. However they do not map 1:1 as the goal was to expose a viable subset of controls but in a simple and general way, thus nome strings were converted to enums, some arrays of strings were converted to bitwise flags, some names were made more general, such as "service" was turned into "access point" so it doesn't generate confusion with other "network services" (ie: http server), or "favorite" that was renamed to "remembered". Some behavior are slightly different (yet able to be implemented on top), such as "Service.MoveBefore" and "MoveAfter" were converted to a numeric "priority", calculated from service's list index, changing the priority will reoder the list and thus generate the MoveBefore and MoveAfter DBus commands. ConnMan was chosen not only because we already use it, but because its DBus API is sane and simple, with the server doing almost all that we need. This is visible in the efl_net_session, which is completely done in the server and do not require any extra work on our side -- aside from talking DBus and converting to Eo, which is a major work :-D NOTE: ConnMan doesn't use FreeDesktop.Org DBus interfaces such as Properties and ObjectManager, thus we cannot use eldbus_model_object. There are two examples added: - efl_net_session_example: monitors the connection available for an application and try to connect. You need a connman compiled with session_policy_local and a configuration file explained in https://github.com/aldebaran/connman/blob/master/doc/session-policy-format.txt to get a connection if nothing is connected. Otherwise it will just monitor the connectivity state. - efl_net_control_example: monitors, plays the agent and configure the network details. It can enable/disable technologies, connect to access points (services) and configure them. It's quite extensive as allows testing all of ConnMan's DBus API except P2P (Peers).
2016-09-15 17:43:19 -07:00
Try to avoid explicit scans.
Rare exceptions to this rule include when the user requests them,
such as entering a configuration dialog which demands a fresh
state. Otherwise allow the system to perform
passive scans in a timely manner.
efl_net_session and efl_net_control for ConnMan These are objects to allow control of networking devices (efl_net_control) as well as an application to request for connectivity (efl_net_session). They are loosely based on ConnMan.org, which we already use in Enlightenment Window Manager via DBus access with Eldbus. However they do not map 1:1 as the goal was to expose a viable subset of controls but in a simple and general way, thus nome strings were converted to enums, some arrays of strings were converted to bitwise flags, some names were made more general, such as "service" was turned into "access point" so it doesn't generate confusion with other "network services" (ie: http server), or "favorite" that was renamed to "remembered". Some behavior are slightly different (yet able to be implemented on top), such as "Service.MoveBefore" and "MoveAfter" were converted to a numeric "priority", calculated from service's list index, changing the priority will reoder the list and thus generate the MoveBefore and MoveAfter DBus commands. ConnMan was chosen not only because we already use it, but because its DBus API is sane and simple, with the server doing almost all that we need. This is visible in the efl_net_session, which is completely done in the server and do not require any extra work on our side -- aside from talking DBus and converting to Eo, which is a major work :-D NOTE: ConnMan doesn't use FreeDesktop.Org DBus interfaces such as Properties and ObjectManager, thus we cannot use eldbus_model_object. There are two examples added: - efl_net_session_example: monitors the connection available for an application and try to connect. You need a connman compiled with session_policy_local and a configuration file explained in https://github.com/aldebaran/connman/blob/master/doc/session-policy-format.txt to get a connection if nothing is connected. Otherwise it will just monitor the connectivity state. - efl_net_control_example: monitors, plays the agent and configure the network details. It can enable/disable technologies, connect to access points (services) and configure them. It's quite extensive as allows testing all of ConnMan's DBus API except P2P (Peers).
2016-09-15 17:43:19 -07:00
]]
return: future<void> @owned; [[Future return for finished background scan]]
efl_net_session and efl_net_control for ConnMan These are objects to allow control of networking devices (efl_net_control) as well as an application to request for connectivity (efl_net_session). They are loosely based on ConnMan.org, which we already use in Enlightenment Window Manager via DBus access with Eldbus. However they do not map 1:1 as the goal was to expose a viable subset of controls but in a simple and general way, thus nome strings were converted to enums, some arrays of strings were converted to bitwise flags, some names were made more general, such as "service" was turned into "access point" so it doesn't generate confusion with other "network services" (ie: http server), or "favorite" that was renamed to "remembered". Some behavior are slightly different (yet able to be implemented on top), such as "Service.MoveBefore" and "MoveAfter" were converted to a numeric "priority", calculated from service's list index, changing the priority will reoder the list and thus generate the MoveBefore and MoveAfter DBus commands. ConnMan was chosen not only because we already use it, but because its DBus API is sane and simple, with the server doing almost all that we need. This is visible in the efl_net_session, which is completely done in the server and do not require any extra work on our side -- aside from talking DBus and converting to Eo, which is a major work :-D NOTE: ConnMan doesn't use FreeDesktop.Org DBus interfaces such as Properties and ObjectManager, thus we cannot use eldbus_model_object. There are two examples added: - efl_net_session_example: monitors the connection available for an application and try to connect. You need a connman compiled with session_policy_local and a configuration file explained in https://github.com/aldebaran/connman/blob/master/doc/session-policy-format.txt to get a connection if nothing is connected. Otherwise it will just monitor the connectivity state. - efl_net_control_example: monitors, plays the agent and configure the network details. It can enable/disable technologies, connect to access points (services) and configure them. It's quite extensive as allows testing all of ConnMan's DBus API except P2P (Peers).
2016-09-15 17:43:19 -07:00
}
}
implements {
Efl.Object.destructor;
Efl.Object.name { get; }
efl_net_session and efl_net_control for ConnMan These are objects to allow control of networking devices (efl_net_control) as well as an application to request for connectivity (efl_net_session). They are loosely based on ConnMan.org, which we already use in Enlightenment Window Manager via DBus access with Eldbus. However they do not map 1:1 as the goal was to expose a viable subset of controls but in a simple and general way, thus nome strings were converted to enums, some arrays of strings were converted to bitwise flags, some names were made more general, such as "service" was turned into "access point" so it doesn't generate confusion with other "network services" (ie: http server), or "favorite" that was renamed to "remembered". Some behavior are slightly different (yet able to be implemented on top), such as "Service.MoveBefore" and "MoveAfter" were converted to a numeric "priority", calculated from service's list index, changing the priority will reoder the list and thus generate the MoveBefore and MoveAfter DBus commands. ConnMan was chosen not only because we already use it, but because its DBus API is sane and simple, with the server doing almost all that we need. This is visible in the efl_net_session, which is completely done in the server and do not require any extra work on our side -- aside from talking DBus and converting to Eo, which is a major work :-D NOTE: ConnMan doesn't use FreeDesktop.Org DBus interfaces such as Properties and ObjectManager, thus we cannot use eldbus_model_object. There are two examples added: - efl_net_session_example: monitors the connection available for an application and try to connect. You need a connman compiled with session_policy_local and a configuration file explained in https://github.com/aldebaran/connman/blob/master/doc/session-policy-format.txt to get a connection if nothing is connected. Otherwise it will just monitor the connectivity state. - efl_net_control_example: monitors, plays the agent and configure the network details. It can enable/disable technologies, connect to access points (services) and configure them. It's quite extensive as allows testing all of ConnMan's DBus API except P2P (Peers).
2016-09-15 17:43:19 -07:00
}
}