One concern I have is that the higher-level side can afford to do some processing that the low-level side can't, because the high-level side will be initialized as a one-time cost in zygote. Sure, the faster the better, but there are limits to how much should be done (i.e. I don't know whether we'd really want the configuration files to be ready-to-use mmap-able position-independent structures, though it'd certainly be an interesting exercise).
JBQ On Wed, Jan 21, 2009 at 1:59 PM, Brian Swetland <[email protected]> wrote: > > One point I think worth considering is "how do we configure parts of the > system that aren't in java" and it'd be cool if our solution could > handle both the lower and higher level side of system configuration. I > do agree that lookup-by-string has a lot of headaches and understand the > concerns there. > > [Jean-Baptiste Queru <[email protected]>] >> I thought that one of the goals I was aiming for was specifically to >> not store everything as a string (because if we do we might as well >> make SystemProperties public), given that the we assume that many >> values will be booleans. >> >> In fact there's an interesting optimization for booleans: if we decide >> by convention that a boolean that's not set is not distinguishable >> from false, the set of booleans that are set to true can be stored in >> a hashset instead of having a hashmap. Same thing for integers >> defaulting to zero. >> >> I'm afraid that at this point this is turning into a larger project >> that I have time for, though, as I was supposed to start working on >> something else yesterday already, and I think that I'll just revert >> the original change (and we'll manage with SdkSetup until someone has >> time to revisit). >> >> Anyway, do we prefer it as individual members, like in >> http://review.source.android.com/8415 or with functions like in >> http://review.source.android.com/8451 ? >> >> JBQ >> >> On Wed, Jan 21, 2009 at 1:39 PM, Dianne Hackborn <[email protected]> wrote: >> > I'd really like to see a change that is a more "real" implementation of the >> > API. All we are doing right now is rewriting an existing system property, >> > so we are missing half of the view of what this will look like -- where >> > these Config values are stored and how they are retrieved. >> > >> > Personally I would lean towards putting the values in an XML file, which >> > Config parses in its static initializer (which will happen one time in >> > Zygote). Then a single method on Config to retrieve a value. This would >> > unfortunately mean that the only thing you can get back is a String, not a >> > typed value, but if the intention is for this to hold a fairly arbitrary >> > set >> > of configuration params (including ones for specific apps??) then it seems >> > to me we would be going down this path anyway. >> > >> > On Tue, Jan 20, 2009 at 7:48 PM, Jean-Baptiste Queru <[email protected]> >> > wrote: >> >> >> >> There are definitely tradeoffs in both variants. I wanted to put quick >> >> implementations of both options together, so that we'd have something >> >> concrete to discuss. I'll prepare the other variant (function-based) >> >> tomorrow morning, as it'll take a tiny bit more time if I want the >> >> implementation to look like something that'd end up in production. >> >> >> >> JBQ >> >> >> >> On Tue, Jan 20, 2009 at 7:15 PM, Joe Onorato <[email protected]> wrote: >> >> > I missed Dave's message in this thread. The problem with putting >> >> > constants >> >> > into Config.java is that it forces us to have one file with all possible >> >> > configuration values in it, which I think is a huge mistake. >> >> > >> >> > This mechanism needs to work for built-in apps, many of which won't be >> >> > open >> >> > sourced, as well as the system. I really don't want to pollute the >> >> > platform >> >> > with all constants for all possible apps. >> >> > >> >> > -joe >> >> > >> >> > >> >> > >> >> > >> >> > On Tue, Jan 20, 2009 at 4:49 PM, Jean-Baptiste Queru <[email protected]> >> >> > wrote: >> >> >> >> >> >> I've uploaded a proposed implementation with the following changes: >> >> >> http://review.source.android.com/8415 >> >> >> http://review.source.android.com/8256 >> >> >> http://review.source.android.com/8416 >> >> >> http://review.source.android.com/8257 >> >> >> >> >> >> Please don't pay too much attention to the fact that the parameter is >> >> >> backed by a system property, that's an implementation detail at this >> >> >> point. I'm mostly interested in knowing whether this approach is >> >> >> sustainable in the future. >> >> >> >> >> >> Thanks, >> >> >> JBQ >> >> >> >> >> >> On Fri, Jan 16, 2009 at 4:30 PM, Jean-Baptiste Queru <[email protected]> >> >> >> wrote: >> >> >> > Agreed. The explicitly goal here is to avoid the use of an additional >> >> >> > system property (well, undo it, or at least hide it behind an API >> >> >> > that >> >> >> > we'll be able to re-implement some other way). >> >> >> > >> >> >> > JBQ >> >> >> > >> >> >> > On Fri, Jan 16, 2009 at 4:18 PM, Brian Swetland <[email protected]> >> >> >> > wrote: >> >> >> >> >> >> >> >> As a side-note I'd like to try to reduce usage of the underlying >> >> >> >> system >> >> >> >> properties -- they're becoming a dumping ground for all kinds of >> >> >> >> random >> >> >> >> stuff, and they were not really intended as an open-ended registry >> >> >> >> of >> >> >> >> every possible thing we might think to dump in there.... >> >> >> >> >> >> >> >> [Dave Bort <[email protected]>] >> >> >> >>> The major benefit of using static final fields that I see is that >> >> >> >>> it >> >> >> >>> becomes very obvious who is using a given flag (e.g., >> >> >> >>> "provisioned"), >> >> >> >>> we can track the existence of that flag using our existing API >> >> >> >>> checking tools, and the build breaks if a flag is removed but there >> >> >> >>> are users of it. >> >> >> >>> >> >> >> >>> A dictionary-style interface, on the other hand, provides no >> >> >> >>> possibility for static checking; there's no way to tell whether or >> >> >> >>> not >> >> >> >>> anyone is using a particular flag. This is the main reason we're >> >> >> >>> trying to kill the uses of the SystemProperties API. >> >> >> >>> >> >> >> >>> --dbort >> >> >> >>> >> >> >> >>> On Fri, Jan 16, 2009 at 3:58 PM, Jean-Baptiste Queru >> >> >> >>> <[email protected]> >> >> >> >>> wrote: >> >> >> >>> > As a follow-up to the thread about the "provisioned" bit, I'd >> >> >> >>> > like >> >> >> >>> > to >> >> >> >>> > look at the way some build-time-configurable aspects are exposed >> >> >> >>> > to >> >> >> >>> > applications. >> >> >> >>> > >> >> >> >>> > Right now, we're exposing android.os.Build ("Information about >> >> >> >>> > the >> >> >> >>> > current build, extracted from system properties."). It contains a >> >> >> >>> > dozen of fields (mostly strings) that contain information about >> >> >> >>> > the >> >> >> >>> > source code that was used, the build combo, and who built it, >> >> >> >>> > where, >> >> >> >>> > and when, i.e. what we often refer to as "the build". >> >> >> >>> > >> >> >> >>> > Next to that, we also have android.util.Config ("Build >> >> >> >>> > configuration. >> >> >> >>> > The constants in this class vary depending on [the] build."). It >> >> >> >>> > contains a handful of booleans, which were meant to be set >> >> >> >>> > according >> >> >> >>> > to the build configuration (e.g. DEBUG, PROFILE, LOGV). Given the >> >> >> >>> > way >> >> >> >>> > we now check API differences for compatibility breaks, we can't >> >> >> >>> > actually change those values without introducing what our >> >> >> >>> > api-checking >> >> >> >>> > tool considers an API breakage. >> >> >> >>> > >> >> >> >>> > I'd like to introduce a mechanism to allow the build-time side to >> >> >> >>> > pass >> >> >> >>> > parameters that can be checked at run-time at the SDK API level, >> >> >> >>> > for >> >> >> >>> > parameters like the "requires_provisioning" bit. >> >> >> >>> > >> >> >> >>> > Requirements: >> >> >> >>> > -Values must be read-only when seen from applications. >> >> >> >>> > -Must not involve any API change when the parameters change. >> >> >> >>> > -Must allow to document each possible value using the usual >> >> >> >>> > mechanism. >> >> >> >>> > -Must not involve build-time-generated (or build-dependent) >> >> >> >>> > source >> >> >> >>> > files written in the java programming language. >> >> >> >>> > -Performance and footprint are both important. >> >> >> >>> > -Must support at least booleans, integers (int and/or long?) and >> >> >> >>> > strings. >> >> >> >>> > >> >> >> >>> > I'm thinking that Config is a more appropriate location than >> >> >> >>> > Build >> >> >> >>> > for >> >> >> >>> > those parameters. >> >> >> >>> > >> >> >> >>> > One approach is to do something similar to Build: grab each >> >> >> >>> > parameter >> >> >> >>> > at init time (i.e. in a static final) from whichever location is >> >> >> >>> > appropriate (SystemProperties or any other place). >> >> >> >>> > >> >> >> >>> > Another approach is to not directly expose individual fields, but >> >> >> >>> > instead to expose functions that take string keys and return the >> >> >> >>> > values: e.g. boolean getBoolean(String key), int getInt(String >> >> >> >>> > key), >> >> >> >>> > and expose static final constant strings for the keys. >> >> >> >>> > >> >> >> >>> > The former feels like it'd be lighter-weight in terms of memory >> >> >> >>> > and >> >> >> >>> > CPU. The latter feels a lot more automated (so that we could just >> >> >> >>> > stick the values in a data file and parse that). >> >> >> >>> > >> >> >> >>> > What's the preferred option? >> >> >> >>> > >> >> >> >>> > Thanks, >> >> >> >>> > JBQ >> >> >> >>> > >> >> >> >>> > -- >> >> >> >>> > Jean-Baptiste M. "JBQ" Queru >> >> >> >>> > Android Engineer, Google. >> >> >> >>> > >> >> >> >> >> >> >> > >> >> >> > >> >> >> > >> >> >> > -- >> >> >> > Jean-Baptiste M. "JBQ" Queru >> >> >> > Android Engineer, Google. >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Jean-Baptiste M. "JBQ" Queru >> >> >> Android Engineer, Google. >> >> > >> >> > >> >> >> >> >> >> >> >> -- >> >> Jean-Baptiste M. "JBQ" Queru >> >> Android Engineer, Google. >> > >> > >> > >> > -- >> > Dianne Hackborn >> > Android framework engineer >> > [email protected] >> > >> > Note: please don't send private questions to me, as I don't have time to >> > provide private support. All such questions should be posted on public >> > forums, where I and others can see and answer them. >> > >> > >> >> >> >> -- >> Jean-Baptiste M. "JBQ" Queru >> Android Engineer, Google. > -- Jean-Baptiste M. "JBQ" Queru Android Engineer, Google. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-framework?hl=en -~----------~----~----~----~------~----~------~--~---
