Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Are We Abusing Settings API?
33 views
Skip to first unread message
Gene Lian
May 22, 2013, 12:05:30 PM5/22/13
to dev-w...@lists.mozilla.org, Hsin-Yi Tsai, Mounir Lamouri, Jonas Sicking, Justin Lebar
This is inspired by Justin's thought and I think it's worth addressing and discussing. We believe we're abusing the Settings API for some settings due to the following reasons:
1. Settings API is a privileged API, which means it cannot be exposed to the normal web content. For example, the |time.timezone| setting could be one of the overuse-case because the non-privileged apps might also want to set the time zone and receive the time zone changed event whenever the system time zone or DST info is updated.
2. It's not very clear to me what the main scope of the Settings API is. Should it be everything related to the system settings? Or only the setting entries in the Settings App? Or any values we like to synchronize among apps (processes)?
3. If we have a better purpose-specific API to use, should we put that in the Settings API? For example, recently we're discussing about where to put the *default SIM info* (i.e. service ID) because we're hoping to support the Multi-SIM features and the system might need to know a default SIM to make calls or do messaging... etc. Since we've already had Telephony API to make calls, should we extend that API to set/get the default SIM? Or create another new entry again in the Settings API and hook everything up to that setting?
4. As a Gecko developer, I cannot see a very explicit list of the current setting entries in the codes. They are being created, written, listened and scattered around everywhere. Do we have a more formal place or document to manage all of them?
Any inputs are highly welcomed. Thanks!
Gene
1. Settings API is a privileged API, which means it cannot be exposed to the normal web content. For example, the |time.timezone| setting could be one of the overuse-case because the non-privileged apps might also want to set the time zone and receive the time zone changed event whenever the system time zone or DST info is updated.
2. It's not very clear to me what the main scope of the Settings API is. Should it be everything related to the system settings? Or only the setting entries in the Settings App? Or any values we like to synchronize among apps (processes)?
3. If we have a better purpose-specific API to use, should we put that in the Settings API? For example, recently we're discussing about where to put the *default SIM info* (i.e. service ID) because we're hoping to support the Multi-SIM features and the system might need to know a default SIM to make calls or do messaging... etc. Since we've already had Telephony API to make calls, should we extend that API to set/get the default SIM? Or create another new entry again in the Settings API and hook everything up to that setting?
4. As a Gecko developer, I cannot see a very explicit list of the current setting entries in the codes. They are being created, written, listened and scattered around everywhere. Do we have a more formal place or document to manage all of them?
Any inputs are highly welcomed. Thanks!
Gene
Gene Lian
May 23, 2013, 4:08:18 AM5/23/13
to dev-w...@lists.mozilla.org, Hsin-Yi Tsai, Mounir Lamouri, Jonas Sicking, Justin Lebar
One more issue needs to clarify for the usage standard of Settings API (pleas see the in-line).
5. In our current codes, all the processes are allowed to modify the settings values through the Settings API, which means the Gecko end can also modify the settings and the Gaia end will get settings changed events, or vice versa. Is that really what we want? Some Gaia folks complain their settings are magically changed but no apps are triggering that, because it's actually changed by Gecko. It's currently happening in the RIL, wifi, system time and lots of system settings.
>
>
> Any inputs are highly welcomed. Thanks!
>
> Gene
> _______________________________________________
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
>
>
>
> Any inputs are highly welcomed. Thanks!
>
> Gene
> dev-webapi mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webapi
>
Tim Chien
May 23, 2013, 5:14:27 AM5/23/13
to Gene Lian, Justin Lebar, dev-w...@lists.mozilla.org, Mounir Lamouri, Jonas Sicking, Hsin-Yi Tsai
My 2¢:
1) timezone is actually exposed to the web content a long time ago
through |(new Date()).getTimezoneOffset()|. Whether or not that means
every date object could persist it's own timezone information (rather
than the system timezone info) is beyond my knowledge. However, I am
sure that Gene could find another example of a piece of information in
settings database that is necessary to expose to general web content.
We will just have to propose new properties and new Web APIs for them.
People do need to actively track them though, which is something b2g
project failed to do under our schedule pressure.
2) for me, the sole purpose of Settings API is "to store persistent
user preferences that is accessible across the entire OS stack", and
that's it. The "OS stack" currently means "Gaia System + Gaia
privileged apps + Gecko" in our implementation, but we have not yet
addressed race condition and dependency careful enough (see below).
That should be an engineering goal for our next versions.
3) 4) I think we should stop using Settings API entries as an way to
enable or disable a piece of hardware feature, e.g. wifi, mobile data,
or telephony. Yes, that contracts what I proposals originally, and I
was wrong. The main problem with that is a Boolean entry cannot
accurately tell the hardware state. Wifi could be enabled, disabled,
but it could also be initialing, or uninitialing, and the
initialization/uninitialization could fail. A setting entry and it's
changed event is not the best way to expose the state to the user
interface, and Settings app suffers significant pain on that. This
should be addressed too.
--
Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox
OS, Mozilla Corp. (Taiwan)
1) timezone is actually exposed to the web content a long time ago
through |(new Date()).getTimezoneOffset()|. Whether or not that means
every date object could persist it's own timezone information (rather
than the system timezone info) is beyond my knowledge. However, I am
sure that Gene could find another example of a piece of information in
settings database that is necessary to expose to general web content.
We will just have to propose new properties and new Web APIs for them.
People do need to actively track them though, which is something b2g
project failed to do under our schedule pressure.
2) for me, the sole purpose of Settings API is "to store persistent
user preferences that is accessible across the entire OS stack", and
that's it. The "OS stack" currently means "Gaia System + Gaia
privileged apps + Gecko" in our implementation, but we have not yet
addressed race condition and dependency careful enough (see below).
That should be an engineering goal for our next versions.
3) 4) I think we should stop using Settings API entries as an way to
enable or disable a piece of hardware feature, e.g. wifi, mobile data,
or telephony. Yes, that contracts what I proposals originally, and I
was wrong. The main problem with that is a Boolean entry cannot
accurately tell the hardware state. Wifi could be enabled, disabled,
but it could also be initialing, or uninitialing, and the
initialization/uninitialization could fail. A setting entry and it's
changed event is not the best way to expose the state to the user
interface, and Settings app suffers significant pain on that. This
should be addressed too.
Tim Guan-tin Chien, Engineering Manager and Front-end Lead, Firefox
OS, Mozilla Corp. (Taiwan)
Justin Lebar
May 23, 2013, 9:31:23 AM5/23/13
to Tim Chien, dev-w...@lists.mozilla.org, Jonas Sicking, Mounir Lamouri, Hsin-Yi Tsai, Gene Lian
> 1) timezone is actually exposed to the web content a long time ago
> through |(new Date()).getTimezoneOffset()|.
Yes, except you can't use this to get the current timezone offset
> through |(new Date()).getTimezoneOffset()|.
without DST, and you can't use this to get a notification when the
timezone setting changes. We currently expose this information using
the settings API, but I think we should do something different.
Mounir Lamouri
May 23, 2013, 9:36:12 AM5/23/13
to Gene Lian, dev-w...@lists.mozilla.org, Justin Lebar, Jonas Sicking, Hsin-Yi Tsai
On 23/05/13 09:08, Gene Lian wrote:
>> 1. Settings API is a privileged API, which means it cannot be exposed
>> to the normal web content. For example, the |time.timezone| setting
>> could be one of the overuse-case because the non-privileged apps
>> might also want to set the time zone and receive the time zone
>> changed event whenever the system time zone or DST info is updated.
IMO, the Settings API should have finer permissions, depending on the
>> 1. Settings API is a privileged API, which means it cannot be exposed
>> to the normal web content. For example, the |time.timezone| setting
>> could be one of the overuse-case because the non-privileged apps
>> might also want to set the time zone and receive the time zone
>> changed event whenever the system time zone or DST info is updated.
setting you want to access and what you want to do. Reading some stuff
could be more open than others and writing could be even more restricted.
>> 2. It's not very clear to me what the main scope of the Settings API
>> is. Should it be everything related to the system settings? Or only
>> the setting entries in the Settings App? Or any values we like to
>> synchronize among apps (processes)?
did. Are we expecting an RSS app to store in the Settings API its
settings? I think we don't. However, I do not think it should be limited
to the Settings App but if something is used in the Settings API and
isn't used in the Settings App, we should at least think why it is in
the Settings API and why not in the Settings App.
Regarding values we want to synchronise between applications, I believe
it would depend on the value and I would refer to what I said above: Is
that a setting we want to show in the Settings App? If not, why? If we
use this as a convenient way for our developers to create a channel
between two apps, this is clearly wrong.
>> 3. If we have a better purpose-specific API to use, should we put
>> that in the Settings API? For example, recently we're discussing
>> about where to put the *default SIM info* (i.e. service ID) because
>> we're hoping to support the Multi-SIM features and the system might
>> need to know a default SIM to make calls or do messaging... etc.
>> Since we've already had Telephony API to make calls, should we
>> extend that API to set/get the default SIM? Or create another new
>> entry again in the Settings API and hook everything up to that
>> setting?
settings because they might reflect user input and could be used by any
other application in the system. For example, the preferred SIM card,
and probably some other settings.
>> 4. As a Gecko developer, I cannot see a very explicit list of the
>> current setting entries in the codes. They are being created,
>> written, listened and scattered around everywhere. Do we have a more
>> formal place or document to manage all of them?
depends if we expect third party applications to create new settings? I
would tend to say that this shouldn't happen and ideally we should know
which settings are out there which means that we should be able to
reject any setting creation that isn't expected.
> 5. In our current codes, all the processes are allowed to modify the settings values through the Settings API, which means the Gecko end can also modify the settings and the Gaia end will get settings changed events, or vice versa. Is that really what we want? Some Gaia folks complain their settings are magically changed but no apps are triggering that, because it's actually changed by Gecko. It's currently happening in the RIL, wifi, system time and lots of system settings.
Applications that expect to be the only one to change a setting have a bug.
Thank you for bringing this issue Gene.
Cheers,
--
Mounir
Mounir Lamouri
May 23, 2013, 10:23:03 AM5/23/13
to dev-w...@lists.mozilla.org
On 23/05/13 14:31, Justin Lebar wrote:
>> 1) timezone is actually exposed to the web content a long time ago
>> through |(new Date()).getTimezoneOffset()|.
>
> Yes, except you can't use this to get the current timezone offset
> without DST
I believe this is a bug in JS Dates.
>> 1) timezone is actually exposed to the web content a long time ago
>> through |(new Date()).getTimezoneOffset()|.
>
> Yes, except you can't use this to get the current timezone offset
> without DST
> and you can't use this to get a notification when the
> timezone setting changes.
for time or timezone changes but I'm not sure what's the use case for
knowing about a timezone change but ignoring other kind of time changes.
(Goes without saying that the timechange shouldn't be fired every
minute/second but when the time actually changed for "non-natural"
reasons like user input or an app setting the time to another value.)
--
Mounir
Justin Lebar
May 23, 2013, 10:36:23 AM5/23/13
to Mounir Lamouri, dev-w...@lists.mozilla.org
>>> 1) timezone is actually exposed to the web content a long time ago
>>> through |(new Date()).getTimezoneOffset()|.
>>
>> Yes, except you can't use this to get the current timezone offset
>> without DST
>
> I believe this is a bug in JS Dates.
Agreed. With this fixed, plus the 'timechange' event, we wouldn't
>>> through |(new Date()).getTimezoneOffset()|.
>>
>> Yes, except you can't use this to get the current timezone offset
>> without DST
>
> I believe this is a bug in JS Dates.
need to use the settings API for this (at least, for reading this
value; I don't really care how we write it).
Gregor Wagner
May 23, 2013, 2:21:22 PM5/23/13
to Mounir Lamouri, dev-w...@lists.mozilla.org, Justin Lebar, Hsin-Yi Tsai, Jonas Sicking, Gene Lian
On May 23, 2013, at 6:36 AM, Mounir Lamouri <mou...@lamouri.fr> wrote:
> On 23/05/13 09:08, Gene Lian wrote:
>>> 1. Settings API is a privileged API, which means it cannot be exposed
>>> to the normal web content. For example, the |time.timezone| setting
>>> could be one of the overuse-case because the non-privileged apps
>>> might also want to set the time zone and receive the time zone
>>> changed event whenever the system time zone or DST info is updated.
>
> IMO, the Settings API should have finer permissions, depending on the
> setting you want to access and what you want to do. Reading some stuff
> could be more open than others and writing could be even more restricted.
but someone has to come up with a good model. Mounir do you want to start working
on the spec?
>
>>> 2. It's not very clear to me what the main scope of the Settings API
>>> is. Should it be everything related to the system settings? Or only
>>> the setting entries in the Settings App? Or any values we like to
>>> synchronize among apps (processes)?
>
> This is something we had a hard time to define and I'm not sure we ever
> did. Are we expecting an RSS app to store in the Settings API its
> settings? I think we don't. However, I do not think it should be limited
> to the Settings App but if something is used in the Settings API and
> isn't used in the Settings App, we should at least think why it is in
> the Settings API and why not in the Settings App.
> Regarding values we want to synchronise between applications, I believe
> it would depend on the value and I would refer to what I said above: Is
> that a setting we want to show in the Settings App? If not, why? If we
> use this as a convenient way for our developers to create a channel
> between two apps, this is clearly wrong.
The intention was "System Settings" and apps are not allowed
to add their own settings.
>
>>> 4. As a Gecko developer, I cannot see a very explicit list of the
>>> current setting entries in the codes. They are being created,
>>> written, listened and scattered around everywhere. Do we have a more
>>> formal place or document to manage all of them?
>
> I wonder if having a whitelist of setting could solve that problem? It
> depends if we expect third party applications to create new settings? I
> would tend to say that this shouldn't happen and ideally we should know
> which settings are out there which means that we should be able to
> reject any setting creation that isn't expected.
be known before hand and have to be listed in the settings.py file.
I didn't check it for a few weeks now but we shouldn't have settings that are not in
this file.
>
>> 5. In our current codes, all the processes are allowed to modify the settings values through the Settings API, which means the Gecko end can also modify the settings and the Gaia end will get settings changed events, or vice versa. Is that really what we want? Some Gaia folks complain their settings are magically changed but no apps are triggering that, because it's actually changed by Gecko. It's currently happening in the RIL, wifi, system time and lots of system settings.
>
> I do not see why Gecko modifying the setting is a bad thing.
> Applications that expect to be the only one to change a setting have a bug.
Also thanks from me for bringing this up.
Feel free to file a bug on those items you want to get fixed.
Thanks,
-Gregor
Reuben Morais
May 23, 2013, 5:39:31 PM5/23/13
to dev-w...@lists.mozilla.org
On May 23, 2013, at 2:38 PM, Reuben Morais <reuben...@gmail.com> wrote:
> so the index created for contains searches
Sorry, I meant the key range created for contains searches.
-- reuben
> so the index created for contains searches
Sorry, I meant the key range created for contains searches.
-- reuben
Reuben Morais
May 23, 2013, 5:38:20 PM5/23/13
to dev-w...@lists.mozilla.org
On May 22, 2013, at 5:23 AM, Ben Kelly <bke...@mozilla.com> wrote:
> On May 22, 2013, at 3:59 AM, JOSE MANUEL CANTERA FONSECA <jm...@tid.es> wrote:
>> My understanding was that 'contains' search for the target string in any
>> position and not only at the starting position. Thus, I think we need both
>> 'startsWith' and 'contains' filters
>
> I agree and that is what you would expect from the name "contains". The wiki is non-specific:
>
> https://developer.mozilla.org/en-US/docs/WebAPI/Contacts
>
> Unfortunately, it currently does implement startsWith functionality and we have apps, mms for example, relying on that behavior.
>
> From what I understand there are technical issues which make "contains" complicated to implement right now. Gregor can you speak to that?
The problem, as far as I know, is that IndexedDB doesn't have full text search, so in order to implement contains where it was needed (telephone numbers), we add substrings of the value to the index. For example, the number "12345" will be saved in the multiEntry index as ["12345", "2345", "345", "45", "5"]. We don't do this for any other properties, so the index created for contains searches (filterValue <= value <= (filterValue + "\uFFFF"), where "<" is a lexicographical comparision) is effectively a startsWith.
> If we want to provide both "contains" and "startsWith", what is the best path? Rename the current filterOp to "startsWith" and write a bug to fix "contains"?
We need to add full text search to IndexedDB. I believe Jonas has talked about the complexities of implementing this in the list before.
-- reuben
> On May 22, 2013, at 3:59 AM, JOSE MANUEL CANTERA FONSECA <jm...@tid.es> wrote:
>> My understanding was that 'contains' search for the target string in any
>> position and not only at the starting position. Thus, I think we need both
>> 'startsWith' and 'contains' filters
>
> I agree and that is what you would expect from the name "contains". The wiki is non-specific:
>
> https://developer.mozilla.org/en-US/docs/WebAPI/Contacts
>
> Unfortunately, it currently does implement startsWith functionality and we have apps, mms for example, relying on that behavior.
>
> From what I understand there are technical issues which make "contains" complicated to implement right now. Gregor can you speak to that?
The problem, as far as I know, is that IndexedDB doesn't have full text search, so in order to implement contains where it was needed (telephone numbers), we add substrings of the value to the index. For example, the number "12345" will be saved in the multiEntry index as ["12345", "2345", "345", "45", "5"]. We don't do this for any other properties, so the index created for contains searches (filterValue <= value <= (filterValue + "\uFFFF"), where "<" is a lexicographical comparision) is effectively a startsWith.
> If we want to provide both "contains" and "startsWith", what is the best path? Rename the current filterOp to "startsWith" and write a bug to fix "contains"?
We need to add full text search to IndexedDB. I believe Jonas has talked about the complexities of implementing this in the list before.
-- reuben
Gervase Markham
May 24, 2013, 5:08:04 AM5/24/13
to Justin Lebar, Tim Chien, Gene Lian, dev-w...@lists.mozilla.org, Mounir Lamouri, Jonas Sicking, Hsin-Yi Tsai
On 23/05/13 14:31, Justin Lebar wrote:
>> 1) timezone is actually exposed to the web content a long time ago
>> through |(new Date()).getTimezoneOffset()|.
>
> Yes, except you can't use this to get the current timezone offset
> without DST, and you can't use this to get a notification when the
> timezone setting changes. We currently expose this information using
> the settings API, but I think we should do something different.
+1 for the standard JS timezone API being broken.
>> through |(new Date()).getTimezoneOffset()|.
>
> Yes, except you can't use this to get the current timezone offset
> without DST, and you can't use this to get a notification when the
> timezone setting changes. We currently expose this information using
> the settings API, but I think we should do something different.
What would be most awesome would be an API for getting the Olsen TZ
identifier for the user's machine. Of course, in some areas, this also
does rough geolocation... but perhaps it's not any more accurate than
what people could already do using IP addresses.
Gerv
Gervase Markham
May 24, 2013, 5:08:04 AM5/24/13
to Justin Lebar, Tim Chien, Gene Lian, dev-w...@lists.mozilla.org, Mounir Lamouri, Jonas Sicking, Hsin-Yi Tsai
On 23/05/13 14:31, Justin Lebar wrote:
>> 1) timezone is actually exposed to the web content a long time ago
>> through |(new Date()).getTimezoneOffset()|.
>
> Yes, except you can't use this to get the current timezone offset
> without DST, and you can't use this to get a notification when the
> timezone setting changes. We currently expose this information using
> the settings API, but I think we should do something different.
>> through |(new Date()).getTimezoneOffset()|.
>
> Yes, except you can't use this to get the current timezone offset
> without DST, and you can't use this to get a notification when the
> timezone setting changes. We currently expose this information using
> the settings API, but I think we should do something different.
Gervase Markham
May 24, 2013, 5:08:04 AM5/24/13
to Justin Lebar, Tim Chien, Gene Lian, dev-w...@lists.mozilla.org, Mounir Lamouri, Jonas Sicking, Hsin-Yi Tsai
On 23/05/13 14:31, Justin Lebar wrote:
>> 1) timezone is actually exposed to the web content a long time ago
>> through |(new Date()).getTimezoneOffset()|.
>
> Yes, except you can't use this to get the current timezone offset
> without DST, and you can't use this to get a notification when the
> timezone setting changes. We currently expose this information using
> the settings API, but I think we should do something different.
>> through |(new Date()).getTimezoneOffset()|.
>
> Yes, except you can't use this to get the current timezone offset
> without DST, and you can't use this to get a notification when the
> timezone setting changes. We currently expose this information using
> the settings API, but I think we should do something different.
Andreas Gal
May 24, 2013, 10:30:28 AM5/24/13
to Gervase Markham, Justin Lebar, dev-w...@lists.mozilla.org, Gene Lian, Mounir Lamouri, Tim Chien, Hsin-Yi Tsai, Jonas Sicking
I filed a couple bugs and patches to replace the current manual
configuration with automatic timezone detection based on the SIM and
network identifiers as well as GPS (and wifi is AGPS is present). I
also filed a bug for NTP support in addition to NITZ. With those bugs
fixed I think all we need is a way in settings to override the
timezone default. Otherwise the user shouldn't have to deal with this
any more and the need to expose this via an API will be lessened I
believe.
Andreas
Sent from Mobile.
On May 24, 2013, at 2:09, Gervase Markham <ge...@mozilla.org> wrote:
> On 23/05/13 14:31, Justin Lebar wrote:
configuration with automatic timezone detection based on the SIM and
network identifiers as well as GPS (and wifi is AGPS is present). I
also filed a bug for NTP support in addition to NITZ. With those bugs
fixed I think all we need is a way in settings to override the
timezone default. Otherwise the user shouldn't have to deal with this
any more and the need to expose this via an API will be lessened I
believe.
Andreas
Sent from Mobile.
On May 24, 2013, at 2:09, Gervase Markham <ge...@mozilla.org> wrote:
> On 23/05/13 14:31, Justin Lebar wrote:
>>> 1) timezone is actually exposed to the web content a long time ago
>>> through |(new Date()).getTimezoneOffset()|.
>>
>> Yes, except you can't use this to get the current timezone offset
>> without DST, and you can't use this to get a notification when the
>> timezone setting changes. We currently expose this information using
>> the settings API, but I think we should do something different.
>
>>> through |(new Date()).getTimezoneOffset()|.
>>
>> Yes, except you can't use this to get the current timezone offset
>> without DST, and you can't use this to get a notification when the
>> timezone setting changes. We currently expose this information using
>> the settings API, but I think we should do something different.
>
> +1 for the standard JS timezone API being broken.
>
> What would be most awesome would be an API for getting the Olsen TZ
> identifier for the user's machine. Of course, in some areas, this also
> does rough geolocation... but perhaps it's not any more accurate than
> what people could already do using IP addresses.
>
> Gerv
>
>
>
> What would be most awesome would be an API for getting the Olsen TZ
> identifier for the user's machine. Of course, in some areas, this also
> does rough geolocation... but perhaps it's not any more accurate than
> what people could already do using IP addresses.
>
> Gerv
>
>
Ben Kelly
May 24, 2013, 6:04:46 PM5/24/13
to Gregor Wagner, dev-w...@lists.mozilla.org, Reuben Morais
On May 24, 2013, at 12:16 PM, Gregor Wagner <gwa...@mozilla.com> wrote:
> In short: indexedDB doesn't support full text search and trying to work around this has multiple drawbacks. Insertion time can be >1sec, the DB gets huge and consequently the lookup becomes slower as well. When I wanted to rename 'contains' it in December I was told that this is not blocking and I can't land it and afterwards I lost track of it :(
> I think we should introduce 'startsWith' I don't know what we should do with 'contains'.
I went ahead and made a patch to introduce "startsWith":
https://bugzilla.mozilla.org/show_bug.cgi?id=874462#c2
I didn't do anything with "contains" other than add an XXX comment for now. Seems like it could be handled as a separate bug or deprecated with a log warning if we don't think we'll ever fix it.
Thoughts?
Thanks.
Ben
Tantek Çelik
May 24, 2013, 6:50:29 PM5/24/13
to Ben Kelly, dev-w...@lists.mozilla.org, Gregor Wagner, Reuben Morais
In addition I've added "startsWith" and dropped "contains" from the ContactsAPI
https://wiki.mozilla.org/WebAPI/ContactsAPI
No need to hold onto "contains" *in the spec* for compat reasons. Will
leave implementation backcompat up to others to decide accordingly.
Thanks,
Tantek
Gene Lian
May 27, 2013, 5:31:10 AM5/27/13
to Mounir Lamouri, dev-w...@lists.mozilla.org
----- Original Message -----
> From: "Mounir Lamouri" <mou...@lamouri.fr>
> To: dev-w...@lists.mozilla.org
> Sent: Thursday, May 23, 2013 10:23:03 PM
> Subject: Re: Are We Abusing Settings API?
>
> On 23/05/13 14:31, Justin Lebar wrote:
> >> 1) timezone is actually exposed to the web content a long time ago
> >> through |(new Date()).getTimezoneOffset()|.
> >
> > Yes, except you can't use this to get the current timezone offset
> > without DST
>
> I believe this is a bug in JS Dates.
The current .getTimezoneOffset() returns the timezone offset *including DST*. We used to hope to expose another .getDSTOffset() (please see Bug 861812), which is going to return the DST offset info (something like 1H or 0.5H... etc). Are you saying .getTimezoneOffset() should return the pure ordinary timezone without DST? Anyway, we can discuss about how to properly expose the DST info at Bug 861812, since we all agreed the timezone should be one of first things to be removed from the settings entries.
>
> I believe this is a bug in JS Dates.
Gene
Mounir Lamouri
May 23, 2013, 9:33:49 AM5/23/13
to Gene Lian, dev-w...@lists.mozilla.org, Justin Lebar, Jonas Sicking, Hsin-Yi Tsai
On 23/05/13 09:08, Gene Lian wrote:
>> 1. Settings API is a privileged API, which means it cannot be exposed
>> to the normal web content. For example, the |time.timezone| setting
>> could be one of the overuse-case because the non-privileged apps
>> might also want to set the time zone and receive the time zone
>> changed event whenever the system time zone or DST info is updated.
IMO, the Settings API should have finer permissions, depending on the
setting you want to access and what you want to do. Reading some stuff
could be more open than others and writing could be even more restricted.
>> 1. Settings API is a privileged API, which means it cannot be exposed
>> to the normal web content. For example, the |time.timezone| setting
>> could be one of the overuse-case because the non-privileged apps
>> might also want to set the time zone and receive the time zone
>> changed event whenever the system time zone or DST info is updated.
IMO, the Settings API should have finer permissions, depending on the
setting you want to access and what you want to do. Reading some stuff
could be more open than others and writing could be even more restricted.
>> 2. It's not very clear to me what the main scope of the Settings API
>> is. Should it be everything related to the system settings? Or only
>> the setting entries in the Settings App? Or any values we like to
>> synchronize among apps (processes)?
This is something we had a hard time to define and I'm not sure we ever
did. Are we expecting an RSS app to store in the Settings API its
settings? I think we don't. However, I do not think it should be limited
to the Settings App but if something is used in the Settings API and
isn't used in the Settings App, we should at least think why it is in
the Settings API and why not in the Settings App.
Regarding values we want to synchronise between applications, I believe
it would depend on the value and I would refer to what I said above: Is
that a setting we want to show in the Settings App? If not, why? If we
use this as a convenient way for our developers to create a channel
between two apps, this is clearly wrong.
>> is. Should it be everything related to the system settings? Or only
>> the setting entries in the Settings App? Or any values we like to
>> synchronize among apps (processes)?
This is something we had a hard time to define and I'm not sure we ever
did. Are we expecting an RSS app to store in the Settings API its
settings? I think we don't. However, I do not think it should be limited
to the Settings App but if something is used in the Settings API and
isn't used in the Settings App, we should at least think why it is in
the Settings API and why not in the Settings App.
Regarding values we want to synchronise between applications, I believe
it would depend on the value and I would refer to what I said above: Is
that a setting we want to show in the Settings App? If not, why? If we
use this as a convenient way for our developers to create a channel
between two apps, this is clearly wrong.
>> 3. If we have a better purpose-specific API to use, should we put
>> that in the Settings API? For example, recently we're discussing
>> about where to put the *default SIM info* (i.e. service ID) because
>> we're hoping to support the Multi-SIM features and the system might
>> need to know a default SIM to make calls or do messaging... etc.
>> Since we've already had Telephony API to make calls, should we
>> extend that API to set/get the default SIM? Or create another new
>> entry again in the Settings API and hook everything up to that
>> setting?
Regarding Multi-SIM, I believe that some information should be saved as
settings because they might reflect user input and could be used by any
other application in the system. For example, the preferred SIM card,
and probably some other settings.
>> that in the Settings API? For example, recently we're discussing
>> about where to put the *default SIM info* (i.e. service ID) because
>> we're hoping to support the Multi-SIM features and the system might
>> need to know a default SIM to make calls or do messaging... etc.
>> Since we've already had Telephony API to make calls, should we
>> extend that API to set/get the default SIM? Or create another new
>> entry again in the Settings API and hook everything up to that
>> setting?
Regarding Multi-SIM, I believe that some information should be saved as
settings because they might reflect user input and could be used by any
other application in the system. For example, the preferred SIM card,
>> 4. As a Gecko developer, I cannot see a very explicit list of the
>> current setting entries in the codes. They are being created,
>> written, listened and scattered around everywhere. Do we have a more
>> formal place or document to manage all of them?
I wonder if having a whitelist of setting could solve that problem? It
depends if we expect third party applications to create new settings? I
would tend to say that this shouldn't happen and ideally we should know
which settings are out there which means that we should be able to
reject any setting creation that isn't expected.
> 5. In our current codes, all the processes are allowed to modify the settings values through the Settings API, which means the Gecko end can also modify the settings and the Gaia end will get settings changed events, or vice versa. Is that really what we want? Some Gaia folks complain their settings are magically changed but no apps are triggering that, because it's actually changed by Gecko. It's currently happening in the RIL, wifi, system time and lots of system settings.
I do not see why Gecko modifying the setting is a bad thing.
Applications that expect to be the only one to change a setting have a bug.
I do not see why Gecko modifying the setting is a bad thing.
Applications that expect to be the only one to change a setting have a bug.
Jonas Sicking
May 28, 2013, 11:30:23 PM5/28/13
to Gregor Wagner, dev-webapi, Reuben Morais
On May 24, 2013 9:17 AM, "Gregor Wagner" <gwa...@mozilla.com> wrote:
>
>
> On May 23, 2013, at 2:38 PM, Reuben Morais <reuben...@gmail.com>
>
>
> On May 23, 2013, at 2:38 PM, Reuben Morais <reuben...@gmail.com>
> In short: indexedDB doesn't support full text search and trying to work
around this has multiple drawbacks. Insertion time can be >1sec, the DB
gets huge and consequently the lookup becomes slower as well. When I wanted
to rename 'contains' it in December I was told that this is not blocking
and I can't land it and afterwards I lost track of it :(
> I think we should introduce 'startsWith' I don't know what we should do
with 'contains'.
Full text indexing is *hard*. See description here for a subset of the
around this has multiple drawbacks. Insertion time can be >1sec, the DB
gets huge and consequently the lookup becomes slower as well. When I wanted
to rename 'contains' it in December I was told that this is not blocking
and I can't land it and afterwards I lost track of it :(
> I think we should introduce 'startsWith' I don't know what we should do
with 'contains'.
problems that needs to be solved.
https://docs.google.com/a/chromium.org/document/d/1sAk00RsxZHFgyKomKq_n01rHbvsghS8RkQjulBZ3mpI
Doing it inside of indexedDB is no easier than doing it inside the
contacted API. Probably harder.
What we need here is somewhat different though. We need substring matching.
The way databases generally handle that is through full table scans I think.
There are obviously performance issues with that, but it might be OK if we
are able to do the scanning asynchronously while keeping the UI responsive.
We can also do tricks like whenever the user presses a new key and append a
character, filter the results retrieve so far and continue scanning where
you left off.
/ Jonas
JOSE MANUEL CANTERA FONSECA
May 29, 2013, 2:58:40 AM5/29/13
to Jonas Sicking, Gregor Wagner, dev-webapi, Reuben Morais
El 29/05/13 05:30, "Jonas Sicking" <jo...@sicking.cc> escribió:
>.
>
>We can also do tricks like whenever the user presses a new key and append
>a
>character, filter the results retrieve so far and continue scanning where
>you left off.
That strategy was put in place in the Contacts App search functionality.
>/ Jonas
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>.
>
>We can also do tricks like whenever the user presses a new key and append
>a
>character, filter the results retrieve so far and continue scanning where
>you left off.
>/ Jonas
>_______________________________________________
>dev-webapi mailing list
>dev-w...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-webapi
>
________________________________
>dev-webapi mailing list
>dev-w...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-webapi
>
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
Andrew Sutherland
May 29, 2013, 3:54:58 PM5/29/13
to dev-w...@lists.mozilla.org
On 05/28/2013 08:30 PM, Jonas Sicking wrote:
> What we need here is somewhat different though. We need substring matching.
> The way databases generally handle that is through full table scans I think.
Well, that's what happens if you do a naive LIKE query in SQL. You
> What we need here is somewhat different though. We need substring matching.
> The way databases generally handle that is through full table scans I think.
could and ideally should do fancier things like use tri-grams
(https://github.com/jonasfj/trilite) or the current contacts manual
suffix permutation generation if every query is going to search the
complete data-set.
In Thunderbird for our "gloda" autocomplete contact searching, we relied
on the fact that we would rank our returned results by popularity and at
startup would just build a suffix tree for the user's 200 most popular
contacts, falling back to an asynchronous LIKE scan in the background
(https://mxr.mozilla.org/comm-central/source/mailnews/db/gloda/modules/suffixtree.js).
Andrew
Jonas Sicking
May 29, 2013, 5:09:11 PM5/29/13
to Andrew Sutherland, dev-webapi
On Wed, May 29, 2013 at 12:54 PM, Andrew Sutherland
<asuth...@asutherland.org> wrote:
> On 05/28/2013 08:30 PM, Jonas Sicking wrote:
>>
>> What we need here is somewhat different though. We need substring
>> matching.
>> The way databases generally handle that is through full table scans I
>> think.
>
> Well, that's what happens if you do a naive LIKE query in SQL.
Yup. And the current Contacts API lets you do this. Simply do a getAll
<asuth...@asutherland.org> wrote:
> On 05/28/2013 08:30 PM, Jonas Sicking wrote:
>>
>> What we need here is somewhat different though. We need substring
>> matching.
>> The way databases generally handle that is through full table scans I
>> think.
>
> Well, that's what happens if you do a naive LIKE query in SQL.
and then filter the results yourself.
> You could
> and ideally should do fancier things like use tri-grams
> (https://github.com/jonasfj/trilite)
> or the current contacts manual suffix
> permutation generation if every query is going to search the complete
> data-set.
> In Thunderbird for our "gloda" autocomplete contact searching, we relied on
> the fact that we would rank our returned results by popularity and at
> startup would just build a suffix tree for the user's 200 most popular
> contacts, falling back to an asynchronous LIKE scan in the background
> (https://mxr.mozilla.org/comm-central/source/mailnews/db/gloda/modules/suffixtree.js).
sorting by popularity, since we have no such concept, I don't know how
we'd build it into the API itself. But stuff like this is why I think
it's good to allow applications to store the data in whatever format
they want, such that they can do optimizations like this.
/ Jonas
Ben Kelly
May 30, 2013, 10:17:55 AM5/30/13
to Jonas Sicking, dev-webapi, Gregor Wagner, Reuben Morais
On May 28, 2013, at 11:30 PM, Jonas Sicking <jo...@sicking.cc> wrote:
> Full text indexing is *hard*. See description here for a subset of the
> problems that needs to be solved.
>
> https://docs.google.com/a/chromium.org/document/d/1sAk00RsxZHFgyKomKq_n01rHbvsghS8RkQjulBZ3mpI
>
> Doing it inside of indexedDB is no easier than doing it inside the
> contacted API. Probably harder.
- Full text searching
- Locale based sorting
It also appears that these features are at least somewhat supported in sqlite:
- SELECT WHERE key LIKE '%value%'
- ICU sqlite collation extension [1]
Is there a particular requirement to use IndexedDB for ContactsAPI? Would it be completely crazy to consider going straight to mozStorage instead since the feature set might be a better match?
Obviously any change like that would be a huge undertaking, so its perhaps a silly question at this point. Just thought it might be worth asking since we seem to be running into these feature mis-matches lately.
Thanks!
Ben
[1]: http://stackoverflow.com/questions/611459/how-to-sort-text-in-sqlite3-with-specified-locale
0 new messages