MWS:Rationale
From OpenSource
Contents |
[edit] A Website on a Mobile Personal Device is Different
[edit] Personal Content
A regular website can be personal but the content is largely explicitly created and has to be manually uploaded, because the website does not reside on a personal device. Contrary to that, a mobile phone is personal and both contains and collects personal data that implicitly and immediately are available.
Contact entries, logs of dialled and received calls, sent and received SMSs, taken pictures and video clips, people around you, places visited, etc. are all data that easily can be used for (semi)automatically creating a mobile home page. If you wanted to reach the similar kind of personal level on a regular web site you would have to continuously upload data. It would be possible, but at some point it becomes easier to simply share the data from the location where it is already stored.
This can be taken further so that, for instance, the CSS of a returned page could depend upon the mode of the phone - general, silent, outdoors, etc. That is, simply by browsing to someone's mobile homepage you would effectively know whether it is better to call, to send an instant message or to send an SMS.
[edit] Interactive Content
Currently the content a website returns depends largely on the input parameters of the request and sometimes on the identity of the one browsing. The content may be dynamically generated but there is typically no explicit human participation. When the website is personal and resides on a device that is carried along for most of the time, the situation changes, as the owner of the phone can become explicitly involved.
An example of this is the See what I see demo included with the software.
<picture to be added>
On the mobsite of someone there is a link that when clicked on causes the phone to beep and display a dialog asking Take Picture?. If the owner of the phone notices the request and feels like sharing his current moment, he points the camera at something in his surrounding and presses Yes, at which point a picture is taken, converted into a JPG and returned to the one browsing.
The interesting aspect of this example is not so much the demo itself, but the fact that the content did not exist before it was asked for, it was explicitly generated on the spot, it is tied to the place and moment, and it will not exist on the mobsite after it has been returned.
[edit] Context Dependent Content
With traditional websites the geographical location of the web server lacks meaning since it never changes and thus has no impact on the returned content. With a mobsite this is no longer the case, as the returned content may depend not only of the geographical location but on all surrounding context.
The mobsite hopping concept demo illustrates this aspect.
<picture to be added>
When the link is clicked on, the terminal does a Bluetooth device discovery. That is, all devices - including mobile phones - that are equipped with Bluetooth (and have it turned on) will be found. The Apache module doing that discovery will then create an HTML page containing those BDAs (Bluetooth Device Address) as comments.
When the page goes through the gateway on its way to the browser, the gateway translates all known BDAs into the equivalent URLs. Known BDAs are such the gateway have been told about and that is precisely what you do when you on Raccoon invoke Options -> Properties -> Enable Hopping.
The end-result is that the one browsing will be presented with a list of mobsites that are in the physical proximity of the first. Effectively this means that mobsites are linked by proximity; they are related because they happen to be in the same place. This is a totally new way for linking websites.
There is no reason to restrict this to mobsites only. This could be used for linking a Bluetooth beacon with any website thus creating regular websites that are reachable from any mobsite that happens to be in a particular geographical location.
It's worth noting that the surrounding mobsites are only found via the first one, but the access does not go via it. That is, even if the first mobsite leaves the location, the found mobsite is still accessible.
[edit] A Mobile Phone With a Web Server is Different
[edit] Web UI
Even though the user interfaces of mobile phones are quite user friendly, they are still rather constrained compared with the possibilities offered by the big screens and proper keyboards of regular PCs. Considering that many users of mobile phones have access to PCs for a significant fraction of the day, at work and at home, it is a restriction that also in that context the only UI available for a mobile phone is the native one.
If a web interface is created for the core applications of a mobile phone, it would mean that whenever you have access to a PC — any PC, not necessarily your own — with Internet connectivity you would be able to access the functionality of your phone using a proper keyboard and a big display. Reading and answering SMSs could take place from within a regular Internet browser and you could even arrange for an RSS feed for received messages. It could even turn out that some users would more frequently use the web interface than the native UI of the phone.
A web interface to an application on a mobile phone could obviously also be used remotely. Every mobile phone user is likely to have forgotten his phone at home at some time or another. With a mobile web server on the phone it is easy to browse to it remotely and check, for instance, whether someone has called or sent an SMS, and even answer SMSs.
[edit] Web Services
With a web server on a mobile phone it is straightforward to provide a web service interface to all core functionality of the phone. That opens up a whole range of new possibilities.
It could easily be arranged so that a part of a regular website is fetched from the mobile, when the mobile is online. This could be utilized, for instance, for showing your location on map by combining location information fetched from the mobile + Google maps.
Currently, if you want to share your calendar information with collegues or friends you must in practice have a centralized server that contains the calendar information and then work against that. When every phone has a URL and there is a web service interface to calendar, it becomes straightforward to create a peer-2-peer based distributed calendar application without any centralized server.
[edit] HTTP Connectivity is an Enabler
Currently the means for communicating with the phone are basically defined by standards, phone manufacturers and operators. In practice, you can call a phone or send it an SMS or MMS message.
Granted, there are, for instance, implementations of instant messaging and push-to-talk, but common to these is that they are dependent upon a server somewhere else and in order to use the functionality you need to have the appropriate client installed.
With a generic HTTP connectivity to the phone anybody can create new messaging concepts without a-priori standardization or other agreements. For instance, one of the included concept demos is a web application that allows you to send a message to the phone from a regular web browser. The message is either shown directly on the screen as an instant message or placed in the inbox of the phone along with the “real” SMSs and MMSs.
From a cost perspective this is also quite interesting. Provided you already have 2.5G/3G access — for instance, for browsing the web — functionality similar to SMS can be provided essentially for free as the amount of data in a textual message is negligible compared to the amount of data transferred during a regular browsing session.
