Because we can: MySQL talks with Johan Wikman, Father of MySQL on Symbian/S60. (part 2 of 3)
By Henrik Ingo on Oct 27, 2008
Q: But, we digress... so let me instead ask you the question everyone asks me when they hear about Apache and MySQL on a mobile phone: Why on earth would anyone want to do THAT?
Because we can:)
No seriously, there are good reasons. If we assume that it makes sense to run a web server on your mobile (see further down for reasons for that) and the web-server you use is Apache, then it's quite obvious that you also want to provide both PHP and MySQL. After all, some 40% of all web-sites in the world are powered by (L)AMP, so if you provide the same environment on the mobile, you have hundreds of thousands of developers who are familiar with the stack.
But, in my mind, there are also compelling reasons to have a proper database on the mobile. Currently, the way applications store their data varies a lot; many even use crude binary files. This means that there in many cases is no way to manipulate the application data, without detailed knowledge about the structure of the data or with the cooperation of the application.
Think how different it would be if all applications stored their data in a DBMS. Making backups would be trivial, as you could just interact directly with the DBMS, without having to know anything about the applications storing their data there. And the only thing an application would have to do in order to be included in the backup, would be to store its data in the DBMS.
Q: Clearly you have no idea how weird backup setups people use on MySQL too! Well, I guess for an environment like a mobile phone it would be relatively trivial, yes. Being able to see and modify your data with SQL is a cool idea, I have to admit!
And since my hammer is a web server on a mobile phone, the use of a DBMS would also make it trivial to expose the core data of the phone via a REST API that could be generated on the fly. Again, the only thing an application would have to do in order to publish its data would be to store its data in the DBMS.
Q: Hmmm... This reminds me, I should ask about security. I mean, how do people react to the great news that their photos, SMS and calendar could be automatically available on the Internet?
That's really a good question. The simple answer is that all security mechanisms available on regular websites are just as applicable on mobile ones. If you are certain that others cannot access, for instance, your Hotmail or Amazon account, then you should also be certain that you can prevent others from accessing your SMSs on your mobile website.
However, in practice it is more complex than that. Firstly, it seems that quite a few have a very personal relationship with their mobile phone. The mere thought that someone might be poking around in it, is scary. So, the security mechanisms must be such that not only is the data safe, but people must also be really certain of it. Secondly, while regular websites are managed by professionals or semi-professionals, mobile websites will typically not be. That is, the security arrangement must be such that a non-professional can understand it and thus be able to make informed decisions.
One thing I am certain of, is that a straightforward mobile website specific account/password arrangement will not do. The situation becomes totally unmanageable if you need a specific account for each mobile website you intend to access and where you should have a distinct password on each. That would also turn the phone owner into a regular administrator that must manage accounts and "answer support calls" when someone has forgotten his password. Some single sign-on mechanism is needed, where the bulk of the account management is moved away from the mobile website itself. The phone owner should at most have to decide, for instance, which ones of his contacts are allowed to see his gallery.
I also think that it is important that the phone owner can put the same amount on trust into a "message", regardless of how it has reached his phone. For instance, if you get an SMS from a certain number you implicitly assume it really is sent by the owner of that number. Now, if, for instance, an instant message, delivered over HTTP, is displayed on the screen of your phone and you are told it is from your contact John, you should be able to trust that information as much as if you would have gotten that message as an SMS from John.
Q: Going back to the specialities of Symbian and embedded programming, isn't it contrary to the whole idea of saving battery and sleeping as much as possible, if you suddenly start to run servers on your phone?
Well, sending and receiving SMSs consumes energy as well, as does making a phone call. So it's a question of utility - is the functionality you get, worth the energy it consumes?
The primary problem is that with most other energy consuming activities on the mobile, the user is in control. If the battery is low, you can choose not to surf the web in order to be able to make a phone call later. If you have a server, especially one that is accessible from the Internet, on the mobile, in principle you are no longer in control. There can be activity of which you are not even aware.
And that's a significant difference between stationary and mobile web servers. If you have a regular website, as long as you are not slashdotted, you don't really care who visits it. In the mobile case, the situation is different as all access costs, if not in monetary terms then in terms of energy consumption. With the advent of flat-fee operator agreements the monetary issue is going away, but the energy issue is not. And even if you have access control on your site preventing access by anyone but the ones explicitly allowed, the mere delivery of the rejected request consumes energy.
Now, this is only a problem if direct access to the mobile is possible. In most operator networks it's not and in order be able to reach the mobile from the Internet, the access must go through our transparent gateway. And that, of course, can and indeed does perform access control on behalf of the mobile. That is, an unauthorized browser cannot cause any cost to you.
And that's actually an interesting aspect of the whole thing. You want gateway based access control, not necessarily in order to protect the data, but in order to control who can cause cost to you. That is, if you are at home, connected over WLAN and with the phone connected to a charger, the need for that kind of access control disappears. So, not only may the content be context dependent, as pointer out further down, but the access control may have to be as well.
Q: So maybe Drizzle could be interesting to you, if it becomes a leaner version of MySQL? I remember Symbian is all-Unicode too, so they would fit well together.
I really don't know much about Drizzle, so I can't say anything specific. In principle the leanness is quite attractive, but then again, the mobile phones of today really have quite a lot of memory and other resources. The high-end Nokia phones today have 128MB of RAM and if you compare the mobiles from a few years ago to the mobiles of today and use that for extrapolating where the mobiles will be a few years from now, it is not unrealistic to assume that they will have gigabytes of RAM and hundreds of gigabytes of storage. I suppose that's a lot more than what the servers had that were used for running many MySQL servers just a few years ago:)
Q: I know this but it is still hard to grasp... So if we plug in the phone to a charger, so we have electricity and can disregard thinking about battery all the time, you're saying my Nokia Communicator is more powerful than the servers I was administering in the 90's?
We all know that comparing raw CPU speed does not tell you that much, but I'll throw in some numbers nonetheless. For instance, the N95, which no longer is top of the line, has an ARM11 that, according to ARM's website, delivers up to 740 Dhrystone. I googled around and according to one site, the 450 Mhz Intel Pentium II, which was introduced in the fall of 1998, delivered 813 Dhrystone. So that's roughly where we are in terms of CPU power.
And as for memory... In the early nineties I worked on a HP/UX workstation that had 256MBs of memory. In those days, that was considered an almost obscene amount of memory. All recent Nokia smartphones have 128MBs of RAM.