Yeah, the part about the mmap-able structure was tongue-in-cheek, and I agree it's probably not worth anybody's time.
I'm gonna pull the plug on this. What started as an idea to move a single line of code from one project to another is turning into a monster that's growing exponentially, and I can't afford to spend the time that it would take to satisfy everyone. We can revisit it when someone has time for it. JBQ On Wed, Jan 21, 2009 at 2:28 PM, Joe Onorato <[email protected]> wrote: > 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. > > -- 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 -~----------~----~----~----~------~----~------~--~---
