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…
- 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.
- 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.
- 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.
- 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.
- 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.
- 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…
- 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.
- 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.
Your signin already hates me and wants to kick me out, so you might be careful of this 62 year old retired nurse. Warnings come in miraculous ways. I must confess that I am writing you, because I am inclined to believe help comes from unusual places. Thus since I hardly knew one damned thing you were saying; I thought; “There is my help.” Two months ago I was ready to submit my book to a purgatory press; Create Space, but before I could hit submit, A blood clot somehow crashed through my heart and went in to both lungs; Thus I am now back in the world; novel published, looks great, is a story know one has written before, and I somehow wound up with 400 pages before it was over. My Dr. in San Francisco loved it so that he read it and said he could not put it down. He started out at Tuft’s university, then finished at UCSF. Dog Eared Books out in SF is giving it a try; I”M going to carry it a few more places. Problem: I cannot get around very well; I have a white space where my Left knee was; Delightful on X-Rays, but because of anticoagulants I live and breath, but I had to cancel the surgery.
My book is about a 3rd world place, the once agrarian mid-south Appalachian Mts and valleys where we survived. We were organic farmers and did not use food produced from much more than 12 miles from our homes. I explain that we were the Crackers, Hillbillies, Holy Rollers, and white trash mixed in with some black trash, worked, half beaten to death by adults; Often victims of incest as women, for women had no life other than to pull cotton sacks with babies. My book takes you there around mid-century, endeavors to give mercy to my cultural heritage, and embroiders my life in to both experienced and genuine history as I neared adulthood and got married in Washington, D.C..
I speak for those who cannot. My book makes you laugh, makes you cry, and endeavors to show that people like Alice Waters are frauds, and the southern dirt farmers,, not she and Jamie Oliver had the seal on organic farming long before those pompous folks entered the picture. The problem is that most of the folks left and went to the rust belt cities and changed from moonshine to the nasty and more horrible drugs that have destroyed all the autonomy we ever knew. I got lucky, some insist, wound married to a CSO player before I left Washington, and we wound up in Cincinnati.
Now that I have filled you in with my organ recital and the fact I am not very well, I need someone to help me market this book. You can see it on Amazon, “Pinkhoneysuckle,” Author, Barbara Everett Heintz. I hate going to meetings; People still make me anxious, but I have got a really good book, and I need someone with half a brain to review it. Fergus review happens circa Dec. 5th. Create Space turned out to be a most unpleasant experience. When I look at what they actually did; Every one should set up a publishing area in one corner room of their house, but I need marketing advice and help; Actually, I need an honest marketer to help me get this off the ground. I would be happy to send you a copy, and I believe you will find it to be on a higher level of writing than is usually seen in the self publishing market. From our home in SF flying back to our home here in Cinci to be with the grand children, I took note of every other person around me with their Ebook. We are about to have more trash on the market than God has angels, for it is the new deal. My Harvard Law 3rd son was the lawyer for Amazon to marry Kindle, so I have to be careful what I say.
Thank you for any suggestions which you may have. Is there known help to get this out there, and I mean it; It is so good even I have to gloat. I end with many thanks for whatever help you may give to me.
Barbara Everett Heintz
To deletecomment or not to delete. Aw, what the heck…