I would prefer that we not use xml for two reasons. First, I think the build system is going to want to concatenate multiple file fragments together into one file. Right now, build.prop is made from a bunch of echo xxx=yyy >> build.prop statements. I'd like to be able to reuse the code in the build system that gathers the list of which properties to define. XML makes this a little more difficult. Second, this won't be encoded in binary xml in a resource. I don't want to do jumbo xml parsing on the device. I could give on this, but I'm kinda with Brian.
As to the typing, how about something simple like bool com.android.internal.requires_something = true; int android.phone.something = 42; string com.google.maps.whatever = "xxx\u5038"; It doesn't have to be java, or allow expressions, or anything like that, but this syntax is pretty easy to parse. Using the java-style names gets us the namespace collision protection that we're using everywhere, even though it does waste a little bit of space. If we wanted to make it an mmap-able structure, that'd be cool, but I'm not conviced *that* would be worth the engineering work. -joe On Wed, Jan 21, 2009 at 2:08 PM, Jean-Baptiste Queru <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
