MWS:FAQ
From OpenSource
[edit] General
[edit] What is a mobsite?
Mobsite stands for mobile website. We think a mobile website is quite different from a regular website, so having a specific term for the former makes it easier to talk about mobile and regular websites.
[edit] Aren't the processing power and network bandwidth of a mobsite always going to be lower and the cost (monetary and in terms of battery consumption) and network latency always higher than that of a website?
If the requirement is to be able to share large amounts of changing data to a large number of people then, yes, those concerns are very valid and a mobsite would probably be a bad choise. However, although a web-cache at the gateway decreases the difference between a mobsite and a website, the intention is not to replace websites with mobsites. There are a number of factors that clearly differentiates mobsites from websites and it is better to concentrate on those:
- Interactive
- With mobsites, the "administrator" is always nearby and can even participate in the content generation. The included demo application that allows the one browsing to ask the owner of the mobsite to take a picture, illustrates this aspect.
- Context Dependent
- With regular websites the physical location of the server computer lacks meaning since it never changes and it has no impact on the returned content. With mobsites the situation is quite different as the location and surrounding context changes constantly and can have an impact on the returned content. For instance, the current system has the capability of linking mobsites by proximity - the mobsites are related and reachable from each other since they happen to be geographically close by.
- Personal
- The mobsite resides on a personal device that contains a lot of personal data that easily can be used semi-automatically creating an always up-to-date homepage or blog.
- Novel
- HTTP access to a mobile phone enables functionality that up until now simply has not been possible. For instance, it would be quite straightforward to create a Web UI to all core applications on the phone. That would not only allow you to use a big screen and keyboard for accssing the functionality of your phone whenever you are next to a PC, but also to do that remotely, which is something everybody who has ever forgotten their phone at home would appreciate.
Furthermore, we anticipate, but may be wrong of course, that a mobsite - due to its very personal nature - is likely to primarily be accessed by people you know. That is, the number of people accessing it is likely to remain fairly low. In some cases - for instance, if it is only used for accessing the core functionality of the phone - there may be only one person accessing it ever - you yourself.
[edit] Wouldn't it be easier to just upload content to a website where it can be available any time at no cost?
Yes, if your mobsite really is a regular website that just happens to reside on a mobile phone. But if you utilize the properties that differentiates a mobsite from a website, it would be exceedingly hard to do so and it would save you nothing.
In general, it is better not to think web server that happens to be on a mobile device but instead personal context-rich mobile device with HTTP access to it. Technically they say the same thing, but the latter alternative describes much better what this is all about.
[edit] What about the cost - who pays?
The short answer is that the one who owns the phone (SIM-card) pays. The slightly longer answer is that it depends a great deal on the usage whether the presence of a mobsite will have a significant impact on the cost. For instance, if you share data which is non-cacheable and big, then surely it will at some point be noticeable in your phone bill. However, if you already have 2.5/3G-data, for browsing the web, then textual messages can be delivered to your phone over HTTP essentially for free since the amount of data is so small.
[edit] Occasionally there is no connectivity and at times I turn off my device; doesn't that make my mobsite inaccessible?
Yes, but this is again an example of the fact that a mobsite is not a website that just happens to reside on a mobile device. With mobsites the assumption that a website will be available 24/7 simply no longer holds.
When someone's phone is turned off, you can not call him or her either, but you may hear a personal voice message and be able to leave a voicemail. Similar solutions will be needed for mobsites. When going offline you may leave an out-of-site message that is shown by the gateway whenever someone tries to browse to your mobsite. The one browsing could be allowed to leave a message at the gateway that is delivered to the mobsite when it comes online again, or ask to be notified when the mobsite comes online.
[edit] Won't a web server on my phone drain my phone's battery?
It depends. There are two kinds of battery consumption that need to be considered; the battery consumption when you are online but your mobsite is not being accessed and the battery consumption when your mobsite is being accessed. The former consumption is in general not an issue. When your mobsite is online but not accessed there is still a, so called, keepalive traffic ongoing (see the Keepalive interval entry further down), but in most cellular network it is so infrequent that it in practice does not affect the battery consumption.
When your mobsite is accessed, it does affect the battery lifetime. But so does browsing the web and talking with someone. So the real question is whether the functionality provided by a mobsite outweighs the cost in terms of increased battery consumption? Sharing large amounts of data to a large number of people from a mobsite will not be feasible, but that is not the purpose of a mobsite anyway. For that purpose a regular website is a better alternative.
[edit] What about privacy? I don't want unauthorized access to my personal data (contacts, messages, calendar).
Having a web server on a personal device does not imply that you have to publish everything to everybody. Currently the means for controlling who can access what are rather limited, but there is no reason in principle why it could not be made fine-grained.
[edit] Connectivity
[edit] So how does my phone get a URL?
We have a gateway running on the Internet. By configuring DNS it is arranged so that the lookup a browser makes for the URL of a particular mobsite, is resolved to the IP address of the gateway computer. When the browser subsequently sends an HTTP request to the gateway, it is relayed to a so-called connector on the mobile device where it is delivered to the web server. To all parties concerned - the person browsing, the browser, the web server on the mobile device and to the person who owns that mobile device - it seems as if there would be a direct connection from the browser to the mobile web server.
[edit] Isn't the gateway based connectivity solution simply a kludge for working around current network limitations?
That is what we thought when we started the project, but have now come to realize that the gateway is an essential part that you probably would want to have even if it were possible to access a mobile phone directly from the Internet.
The reason is that the nature of mobsites is such that it is benefitial with an intermediary that can assist in mundane tasks, such as access control, and that can provide for a pleasant browsing experience when the mobsite is offline.
[edit] Phone Software
[edit] There are all sorts of settings behind [Options] -> [Settings]. What do they mean?
See Phone Software.
[edit] What are those blinkenlichts shown in the [Connector] tab?
- State
- Shows what state the connector is in: Offline - there is no connection between the connector and the gateway, Connecting - a control connection is being created to the gateway, Handshaking - handshaking is going on between the connector and the gateway, Online - a control connection existis between the connector and the gateway, and Orphaned - a control connection existed between the connector and the gateway but the connection was broken and is now being re-established. The number of times the connection has been re-created - because the connection was broken or because no keepalive message was received within the limits - is shown in the parenthesis after the state.
- Keepalive
- Shows the current keepliave interval and max latency and whether the values are being discovered, have been settled or are fixed.
- Keptalive
- Shows the minimum, average, maximum and last keepalive interval.
- Ticks
- How many keepalive messages have been received during the lifetime of the current control connection and using the current keepalive settings.
- Channels
- The first number shows the total number of created data connections and the second the current number of data connections.
- Recd recs
- The number of received (from the gateway) HTTP requests, the number of packets they were received in, and the total number of bytes.
- Sent recs
- The number of sent (from the connector to Apache running on the phone) HTTP requests, the number of packets they were sent in, and the total number of bytes. When things have settled (there's no browsing going on) these numbers should be identical to those in Recd recs.
- Recd reps
- The number of received (from Apache running on the phone) HTTP responses, the number of packets they were received in, and the total number of bytes.
- Sent reps
- The number of sent (from the connector to the gateway) HTTP responses, the number of packets they were sent in, and the total number of bytes. When things have settled (there's no browsing going on) these numbers should be identical to those in Recd reps.
[edit] Apache httpd has modules for access control. Are they applicable?
Yes, the access control mechanisms provided by Apache httpd are all applicable also on a mobsite. However, not all of them can be used because they depend upon components that are not yet available on S60.
[edit] Apache httpd has modules for access control. Are they sufficient?
In principle no and that primarily for two reasons.
Firstly, in order for the access control to be applied by the web server on the mobile device, the HTTP request must be delivered to the device and that already implies cost - both monetary and in terms of battery consumption. So, in order to prevent an unauthorized user from causing any cost, the access control has to be performed before the request is transferred over the cellular connection. That is, it must be performed at the gateway. In practice this may not be that big an issue as flat rates are becoming more common and mobsites, intended for a small audience, are not that appealing as targets for malicious users. However, we are reasearching how the responsibility for the access control could transparently be shared between the web server on the mobile device and the gateway.
Secondly, due to the very nature of mobsites, whether or not someone should be granted access may no longer be merely a function of the identity of the one accessing and the resource he is trying to access. The owner of a mobsite may want to restrict access to, for instance, nearby other mobsites, depending on where he is, with whom he is and, perhaps even, what mood he is in. In order to do that the interactive nature of mobsites need to be taken into the picture - that is, the mobsite owner perhaps must be asked whether to allow someone access to something.
[edit] Gateway
[edit] Do I need to setup a gateway of my own?
No, our intention is to provide the gateway service for the foreseeable future.
[edit] What kind of hardware do I need to be able to run a gateway?
Any regular PC running Windows (equipped with Cygwin) or Linux. Our gateway runs on a computer with a fixed IP address, but it may be possible to make it work with dynamic DNS as well, although we have never tried that.
[edit] How many users can the gateway support?
We actually do not know the breaking point for a fact but estimate that the number of concurrent online users is over 100 and is likely to be less than 1000. The number of accounts can be much larger than that. This version should be stable enough, for instance, for university trials.
[edit] Open Source
[edit] How are you going to develop this further?
The software is used internally for experimentation purposes and is also being actively developed.
Our plan is to eventually get the Symbian port of Apache httpd included as an integral part of the general Apache httpd distribution. We will continue to develop the connectivity solution in an open source fashion and, for instance, introduce mechanisms that provide for end-2-end security.
We hope this software will inspire people to explore the possibilities enabled by general HTTP access to a mobile phone, and to share what they create. We will setup a site for sharing python scripts and Apache modules.
