So since this may not happen for a while I figure I can give a shot.
But I'm curious where we should get our country alpha2 from? Does LSB
define a country has to be somewhere? Maybe the locale? Timezone?
Anyway, in the end the user should be able to change the country too.
I'm thinking to start by just letting the user pick a country for now.
We can figure out where the hell it gets the country by default later
but if you have ideas that'd be great. It seems reasonable to ask for
this upon installation time (?)
Luis
On Mon, Sep 29, 2008 at 4:53 PM, Marcel Holtmann
<[email protected]> wrote:
> Hi Luis,
>
>> > I hesitate to try and specify an LSB-standard file anywhere for this,
>> > not sure we need that. NM might want to store this value
>> > per-connection, or might want to store the value system-wide, or
>> > whatever. I don't really see the value in standardizing the location of
>> > alpha2 config.
>>
>> The only reason why I was thinking of having a standard place for it
>> is that there may be more than one device which can help update the
>> country based on data it has (GPS, user, etc) and the fact that if we
>> are going to set this somewhere perhaps some other things can make use
>> of this as well?
>
> don't go that way. It will cause to many problems. We can add an option
> to the wpa_supplicant file if you really wanna store it (for the command
> line guys).
Stuffing it into wpa_supplicant.conf is fine. You're the one who
suggested a location manager :)
> Leave the rest to NetworkManager.
Alright.
Luis
Hi Luis,
> >> > I hesitate to try and specify an LSB-standard file anywhere for this,
> >> > not sure we need that. NM might want to store this value
> >> > per-connection, or might want to store the value system-wide, or
> >> > whatever. I don't really see the value in standardizing the location of
> >> > alpha2 config.
> >>
> >> The only reason why I was thinking of having a standard place for it
> >> is that there may be more than one device which can help update the
> >> country based on data it has (GPS, user, etc) and the fact that if we
> >> are going to set this somewhere perhaps some other things can make use
> >> of this as well?
> >
> > don't go that way. It will cause to many problems. We can add an option
> > to the wpa_supplicant file if you really wanna store it (for the command
> > line guys).
>
> Stuffing it into wpa_supplicant.conf is fine. You're the one who
> suggested a location manager :)
I know and at some point we might start working it, but that is future
stuff and far from reality right now.
Regards
Marcel
Hi Dan,
> > So since this may not happen for a while I figure I can give a shot.
> > But I'm curious where we should get our country alpha2 from? Does LSB
> > define a country has to be somewhere? Maybe the locale? Timezone?
> > Anyway, in the end the user should be able to change the country too.
> >
> > I'm thinking to start by just letting the user pick a country for now.
> > We can figure out where the hell it gets the country by default later
> > but if you have ideas that'd be great. It seems reasonable to ask for
> > this upon installation time (?)
>
> My suggestion: use the current timezone as a fallback unless the user
> has specified the locale somewhere. That can obviously be done in NM or
> lower, ideally we delegate this sort of thing to the supplicant and just
> pass the alpha2 when NM adds the interface to the supplicant. The
> addInterface() call args are just a dict, so it would be trivial to add
> another item in that dict for country code. Since the country code is
> global to the machine it's probably something we should just store in
> the system settings service, and it's also something that probably
> requires privileges to change.
I would prefer if wpa_supplicant gets a global method for setting the
alpha2 value. It should be dynamic and for me wpa_supplicant is the
right place to handle this value.
The question on how we set this value is a little bit more trickier.
What we do need is a Location Manager that can use multiple source to
get our current location (WiFi, GSM/UMTS, GPS etc.).
Regards
Marcel
On Mon, 2008-09-29 at 11:33 -0700, Luis R. Rodriguez wrote:
> On Sat, Sep 27, 2008 at 11:56:15PM -0700, Marcel Holtmann wrote:
> > Hi Dan,
> >
> > > > So since this may not happen for a while I figure I can give a shot.
> > > > But I'm curious where we should get our country alpha2 from? Does LSB
> > > > define a country has to be somewhere? Maybe the locale? Timezone?
> > > > Anyway, in the end the user should be able to change the country too.
> > > >
> > > > I'm thinking to start by just letting the user pick a country for now.
> > > > We can figure out where the hell it gets the country by default later
> > > > but if you have ideas that'd be great. It seems reasonable to ask for
> > > > this upon installation time (?)
> > >
> > > My suggestion: use the current timezone as a fallback unless the user
> > > has specified the locale somewhere. That can obviously be done in NM or
> > > lower, ideally we delegate this sort of thing to the supplicant and just
> > > pass the alpha2 when NM adds the interface to the supplicant. The
> > > addInterface() call args are just a dict, so it would be trivial to add
> > > another item in that dict for country code. Since the country code is
> > > global to the machine it's probably something we should just store in
> > > the system settings service, and it's also something that probably
> > > requires privileges to change.
> >
> > I would prefer if wpa_supplicant gets a global method for setting the
> > alpha2 value. It should be dynamic and for me wpa_supplicant is the
> > right place to handle this value.
>
> Since it seems nm uses wpa_supplicant for most work then it seems
> reasonable to stuff it in there for now, if possible, and if agreeable
> by Jouni.
Yeah, I'd rather do it through the supplicant too. So Marcel's
suggestion is the way to go, and NM will then just figure out what the
alpha2 ought to be, and set that alpha2 via the supplicant's D-Bus
method.
> > The question on how we set this value is a little bit more trickier.
>
> Well setting should be an option from NM or any system preference
> option on a system which lets you update your country.
I'd expect it's both: NM can certainly store a user-specified value
somewhere, and if that's absent make one up from other system
information.
> > What we do need is a Location Manager that can use multiple source to
> > get our current location (WiFi, GSM/UMTS, GPS etc.).
>
> I suppose we don't have anything like this yet so this seems to be
> a new goal. I'll go poke lsb-discuss mailing list. For now I think its
> as easy as deciding on flatfile where an alpha2 can be put. Later on
> we can worry about all the ways this can be updated.
I hesitate to try and specify an LSB-standard file anywhere for this,
not sure we need that. NM might want to store this value
per-connection, or might want to store the value system-wide, or
whatever. I don't really see the value in standardizing the location of
alpha2 config.
Dan
On Mon, Sep 29, 2008 at 1:39 PM, Dan Williams <[email protected]> wrote:
> I hesitate to try and specify an LSB-standard file anywhere for this,
> not sure we need that. NM might want to store this value
> per-connection, or might want to store the value system-wide, or
> whatever. I don't really see the value in standardizing the location of
> alpha2 config.
The only reason why I was thinking of having a standard place for it
is that there may be more than one device which can help update the
country based on data it has (GPS, user, etc) and the fact that if we
are going to set this somewhere perhaps some other things can make use
of this as well?
Luis
On Fri, Sep 26, 2008 at 7:43 AM, Dan Williams <[email protected]> wrote:
> On Fri, 2008-09-26 at 00:24 -0700, Luis R. Rodriguez wrote:
>> So since this may not happen for a while I figure I can give a shot.
>> But I'm curious where we should get our country alpha2 from? Does LSB
>> define a country has to be somewhere? Maybe the locale? Timezone?
>> Anyway, in the end the user should be able to change the country too.
>>
>> I'm thinking to start by just letting the user pick a country for now.
>> We can figure out where the hell it gets the country by default later
>> but if you have ideas that'd be great. It seems reasonable to ask for
>> this upon installation time (?)
>
> My suggestion: use the current timezone as a fallback unless the user
> has specified the locale somewhere.
Can this tell us the alpha2 they are in reliably? Is the locale
targeted for language only or can we use it for real geographical
localization as well?
Another neat idea is if a Linux has a GPS device for it to get an
alpha2 based on its coordinates and use that but I guess that can be
added later, and I guess you would need to be outdoors too.
> That can obviously be done in NM or
> lower, ideally we delegate this sort of thing to the supplicant and just
> pass the alpha2 when NM adds the interface to the supplicant.
Hm, I suppose it then depends on where this can be pulled from. So
from what you are suggesting NM would only use the alpha2 for
informational purposes?
What I was thinking too is to be able to let the nm-applet let you
select a country too, what do you think?
> The
> addInterface() call args are just a dict, so it would be trivial to add
> another item in that dict for country code. Since the country code is
> global to the machine it's probably something we should just store in
> the system settings service,
That would be good indeed. Anyone know if LSB has a place for such a
thing? Do we just define one?
> and it's also something that probably
> requires privileges to change.
Yes, absolutely.
Luis
On Fri, 2008-09-26 at 00:24 -0700, Luis R. Rodriguez wrote:
> So since this may not happen for a while I figure I can give a shot.
> But I'm curious where we should get our country alpha2 from? Does LSB
> define a country has to be somewhere? Maybe the locale? Timezone?
> Anyway, in the end the user should be able to change the country too.
>
> I'm thinking to start by just letting the user pick a country for now.
> We can figure out where the hell it gets the country by default later
> but if you have ideas that'd be great. It seems reasonable to ask for
> this upon installation time (?)
My suggestion: use the current timezone as a fallback unless the user
has specified the locale somewhere. That can obviously be done in NM or
lower, ideally we delegate this sort of thing to the supplicant and just
pass the alpha2 when NM adds the interface to the supplicant. The
addInterface() call args are just a dict, so it would be trivial to add
another item in that dict for country code. Since the country code is
global to the machine it's probably something we should just store in
the system settings service, and it's also something that probably
requires privileges to change.
Dan
On Sat, Sep 27, 2008 at 11:56:15PM -0700, Marcel Holtmann wrote:
> Hi Dan,
>
> > > So since this may not happen for a while I figure I can give a shot.
> > > But I'm curious where we should get our country alpha2 from? Does LSB
> > > define a country has to be somewhere? Maybe the locale? Timezone?
> > > Anyway, in the end the user should be able to change the country too.
> > >
> > > I'm thinking to start by just letting the user pick a country for now.
> > > We can figure out where the hell it gets the country by default later
> > > but if you have ideas that'd be great. It seems reasonable to ask for
> > > this upon installation time (?)
> >
> > My suggestion: use the current timezone as a fallback unless the user
> > has specified the locale somewhere. That can obviously be done in NM or
> > lower, ideally we delegate this sort of thing to the supplicant and just
> > pass the alpha2 when NM adds the interface to the supplicant. The
> > addInterface() call args are just a dict, so it would be trivial to add
> > another item in that dict for country code. Since the country code is
> > global to the machine it's probably something we should just store in
> > the system settings service, and it's also something that probably
> > requires privileges to change.
>
> I would prefer if wpa_supplicant gets a global method for setting the
> alpha2 value. It should be dynamic and for me wpa_supplicant is the
> right place to handle this value.
Since it seems nm uses wpa_supplicant for most work then it seems
reasonable to stuff it in there for now, if possible, and if agreeable
by Jouni.
> The question on how we set this value is a little bit more trickier.
Well setting should be an option from NM or any system preference
option on a system which lets you update your country.
> What we do need is a Location Manager that can use multiple source to
> get our current location (WiFi, GSM/UMTS, GPS etc.).
I suppose we don't have anything like this yet so this seems to be
a new goal. I'll go poke lsb-discuss mailing list. For now I think its
as easy as deciding on flatfile where an alpha2 can be put. Later on
we can worry about all the ways this can be updated.
Luis
Hi Luis,
> > I hesitate to try and specify an LSB-standard file anywhere for this,
> > not sure we need that. NM might want to store this value
> > per-connection, or might want to store the value system-wide, or
> > whatever. I don't really see the value in standardizing the location of
> > alpha2 config.
>
> The only reason why I was thinking of having a standard place for it
> is that there may be more than one device which can help update the
> country based on data it has (GPS, user, etc) and the fact that if we
> are going to set this somewhere perhaps some other things can make use
> of this as well?
don't go that way. It will cause to many problems. We can add an option
to the wpa_supplicant file if you really wanna store it (for the command
line guys). Leave the rest to NetworkManager.
Regards
Marcel