Disclose This

When one of my children was learning to speak and to control the world around her, we told her that some behavior was a good idea. (I don’t remember what the behavior was.) She declared, “I do not like this good idea!”

As a software developers, I have ideas all the time, and I think some of them are good and would help people. I don’t want some corporation preventing others from using those ideas simply because they don’t like for others to do so. What would happen to software patents and business process patents if there was prior art in the blogosphere? We now live in a time where every utterance is available to others, and I’d like some good to come of that. So here are a bunch of ideas that I might like myself and everyone else to be able use in the future.

Six years ago I gave my view that patents do have a place in society in that they give a monopoly for a limited time, in exchange for the public disclosure of an idea that society would not have had access to otherwise. In my view, if the idea is already disclosed and available to all, society has no interest in enforcing the artificial scarcity of a patent and should not do so. Here I’m putting the idea into practice. I don’t know if such disclosure has any legal weight, but I’d like to think that it will someday help someone demonstrate that the ideas are both already public and also obvious to one of ordinary skill in the art.

I don’t know whether everyone should disclose such stuff. Certainly, one shouldn’t disclose things that someone is paying you to develop in private. But for things that you don’t deal with every day, can you imagine having some huge corporation’s lawyer arguing that your blog doesn’t count as an example of obviousness because you have some sort of extraordinary skill? Fun!

For example, here’s how this initial set of ideas came about. I’m not a performance expert — I’m ordinary — but I once found myself talking to a mobile OS performance team. My impression from the recruiter and screeners was that they were looking for creative people of all disciplines, so I prepared some ideas and discussed them with the hiring manager outside of NDA. It turns out they were actually looking for people to debug specific problems that arose rather than creating new big-win stuff, which was less interesting to me. But my time wasn’t wasted, as we at least have a blog from it! Here they are…

1. Give users feedback when an application is using battery-sucking resources such as the radio or GPS. This gives users the opportunity to avoid apps or some of their own behaviors that suck performance. For some things, feedback might be unconditional, such as a symbol in the status bar. In other cases, it might be more intrusive but occur only in contexts in which the resource really hurts you. For example, you don’t care about bandwidth when you’re on WiFi. I wrote up an end-to-end form of this in my Digital Clutch of 2007.
2. The rate of expensive behaviors can be dynamically controlled by a closed-loop control system, just like on mechanical systems. Soon I’ll publish here a draft that I had written a few years ago on using PID controllers to match Webcam frame rate and animation rate to changing CPU and bandwidth priorities.
3. Overlay networks can dramatically improve network efficiency when it carries traffic from multiple applications. I described the effects within Teleplace here, but the same can be achieved across multiple mobile operating system applications when the http stream utilities go through a hosted content distribution network such as used by Amazon Silk or Opera. One might also provide a socket library for this as well. This helps more when there is real multi-tasking, which not every mobile OS really gets right, so this can further differentiate systems. In addition, there are opportunities for additional revenue streams for usage data, fast-laning paid apps (ugh!), and selling 1-port appliances to corporations in order to speed up mobile use of a company’s internal apps.
4. Hi-level APIs for lazy update can dramatically improve radio usage, development time, and user satisfaction for feed-reader type apps. While the preceding overlay network improvement can be implemented entirely on the system-library side (i.e., without API changes), an additional API can make it much easier for app developers to create very efficient and uniform versions of those kinds of applications that periodically get an update of social media, RSS or other kinds of feeds. Most of these should try to cache information so that there is some continuity for the user if the app has been terminated since the previous use. (The user might terminate the app, and some mobile operating systems will also terminate apps.) The app should display information from it’s local cache instantly so that the user never has to wait even a second before displaying something, while the app should then asynchronously update the data periodically and upon request. Old data should be removed from cache. While not rocket science, a lot of apps don’t do this very well, and the “CoreData” facilities for caching such data are a bit more general than is needed and therefore harder to use well. I’ve seen a lot of bugs that could be avoided if the OS provided a better API. But here’s the real win: the periodic updates can be done much more efficiently if done by an operating system service rather than by each individual app. Here’s why… While early cell phone radios needed power pretty much only while they were being used, 3G and later need to stay “hot” for a time after the transmission ends. If each app makes its own update requests, they pretty much have no choice but to make the polling requests whenever the heck they want to. This results in a lot of useless powered-up time after each short update. However, if one or more apps are due for polling, an operating system API could arrange to update many app caches at the same time, for perhaps zero additional radio cost. By combining this with the preceding overlay network technique, requests can even be pipelined to a combined OS-provided Content Distribution Network data-center, so the updates for several apps might even fit in fewer network frames. In addition, apps might specify update preferences that the operating could use to dynamically arrange for efficient polling, perhaps using a Fibonacci timetable to accumulate stuff, or a closed-loop controller as described above.
5. An API for split apps can allow very smart update processing to happen in the data center instead of on the app, allowing for CPU efficiencies and also for more uniform access from multiple devices. This is kind of like a special case of Kindle Silk. Consider, for example, how the email app is implemented in webOS. An operating system mail-transport system fetches provider-specific mail from different servers, and puts the results in a uniform object database on the mobile device. The email app gets notified of the database change, and gets the new mail messages from that. The email app only ever interacts with the database and never actually talks to the various mail servers. This is just like the preceding hi-level API for lazy update. However, on webOS the transport side is an operating-system provided utility that runs on the mobile device; it could instead have been written more generally in a way that would run in the webOS cloud data center. Apps could be submitted to a mobile app store in two parts: one that runs on the device and the other that runs in an exoscale data center on-demand.
6. Mobile APIs should avoid blocking network operations. This can allow the operating system to schedule work more efficiently, including not only network operations, but also CPU usage. While the above require either no changes to apps or making additional APIs available, some existing mobile APIs are really inviting trouble and should be changed. One example of a good way to handle this is from the open-source node.js project. In node, programmers are supposed to write everything in a non-blocking, asynchronous style, and this results in great computational efficiency and throughput for some kinds of applications. (Node never does busy waiting or poling, but instead goes idle, allowing the OS to do other things or even shut down.) Blocking versions are often still provided, but it is easy to detect and warn about such usage. Which brings me to…
7. Mobile programming tools can warn you about questionable practices. If you look at videos or slide shows for the performance sessions of various mobile OS development conferences, you hear about avoiding things like compositing or being careful about where cachable images are used. Such things are statically detectable and should be linted away.
8. When programmers don’t get things right, even after being warned, produce a development tool to automate the task. For example, scroll cells should avoid having to compose hierarchical graphics at run time. A tool could automated decompositing.