Hi Samuel,
> > diff --git a/doc/session-api.txt b/doc/session-api.txt
> > new file mode 100644
> > index 0000000..bede642
> > --- /dev/null
> > +++ b/doc/session-api.txt
> > @@ -0,0 +1,240 @@
> > +Service unique name
> > +Interface net.connman.Notification
> I would prefer a more verbose name, e.g. net.connman.Session.Notification
I kept it generic in my proposal since the information is generic and
might be re-used by other parts of the system that need unicast
notifications.
> > + 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.
> So, as discussed over IRC, I think this is not good enough if we really want
> to eventually do everything through sessions.
> We need to be able to specify a technology, along with an array of names
> linked to it. For example: [ "wifi", ["AP1", "AP2", "*"]], [ "3g", ["SFR"]]
>
> Marcel, do you think an array of structs (with the struct being a technology
> string, and an array of Name strings) would be a reasonable solution ?
The thing is that you want is simple enough to build these kind of
information from a client. If the API becomes to complex then we are
running into trouble.
We have a few magic bearer names like "wifi", "cellular" etc. and these
are fixed. However we might need to allow creation of custom bearers
like "marcel", "samuel", "internal", "intel", "bmw" or something alike
that.
And you only define these bearers once and then can also define possible
access to it. For example for "intel", you can say that is either if
connected via VPN or via 802.1x WiFi on the campus. These bearers can
then also inherit extra settings like proxy details or similar.
In most cases the user or sysadmin will define these only ones and then
they can be used by multiple applications. Every application defining
these by themselves is a bad idea. Especially if things are going to
change over time. Lets say that AP2 is no longer part of it.
Of course the more interesting part is when you want to connect to AP2
when it is WPA2 encrypted, but not connect when it only offers WEP or no
encryption to avoid rouge access points.
Regards
Marcel
_______________________________________________
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman
