![CHAPTER 2. THE INTERNET AND MOBILE DEVICES 5
services with your mobile? Unfortunately it is easier said than done. Many websites
we like to use are very difficult to navigate or almost completely inaccessible with our
mobiles and other handheld devices. This problem is caused by a number of reasons
including the mobile browsers, the available bandwidth, and the technology used on
websites.
2.2 Specialized content
When an Internet connection was introduced to mobile phones it was obvious that
normal Hypertext Markup Language (HTML) webpages were not suitable for these
devices. Phones have many constraints compared to desktop computers which makes
processing of the page content quite demanding. Mobile devices have less powerful
CPUs, less memory, smaller displays, very limited input devices and restrictions on
power consumption. Also, the mobile network offers, in most cases, less bandwidth
and more latency than a normal modem or broadband connection on a computer.
To solve the problem Nokia, Ericsson, Phone.com (then Unwired Planet) and Mo-
torola founded the WAP Forum1
. Its goal was to develop a common format for Inter-
net transfers to mobile phones. Since then more companies have joined WAP Forum
so that it now has more than 200 members.
WAP and WML
The major results of the WAP Forum’s work are Wireless Application Protocol (WAP)
and Wireless Markup Language (WML) [40]. WML is an Extended Markup Lan-
guage (XML) application and it is used to create webpages that can be delivered to a
mobile device using WAP. A WAP browser on the phone can then render the WML
document to the small screen of the device. The set of tags that WML offers is very
limited due to the various constraints caused by the mobile environment.
WAP services are usually easy and relatively fast to use with a mobile device but there
is also a downside. WAP content always needs to be specifically designed for mobile
devices, which results in two problems: availability and cost.
1
WAP Forum no longer exists as an independent organization but is now part of the Open Mobile
Alliance http://www.openmobilealliance.org/](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-11-320.jpg)
![CHAPTER 2. THE INTERNET AND MOBILE DEVICES 7
HTML standards. All these things have lead to many poorly written HTML pages.
After all, how can web authors know their markup is wrong if the browser shows
the page correctly anyway. This makes writing new browsers and keeping the old
ones up to date increasingly difficult as one needs to be prepared for many different
non-standard HTML markups.
Another reason demanding development in HTML is the emerging of numerous new
devices accessing Internet. These devices include mobile phones, PDAs, televisions,
etc. which do not have the capacity of a desktop browser to parse and render the
incorrect HTML. Their memory and processing capacity are so limited that parsing
malformed HTML can be very resource consuming and even impossible with the
simpler devices.
For these reasons the World Wide Web Consortium5
(W3C) started to work on a new
version of HTML that would be based on XML. The result, XHMTL 1.0 (Extens-
ible HTML), was published in January 2000 [44]. XHTML 1.0 is a reformulation
of HTML 4 in XML 1.0. This means that while syntactically XHTML is an XML
application, its semantics are defined by HTML 4. The W3C recommendation lists
twelve differences between HTML 4 and XHTML, including the following:
¤
XHTML is case sensitive. Element and attribute names must be in lower case.
¤
All elements must be properly nested,
i.e. <p><em>text</em></p> instead of <p><em>text</p></em>.
¤
All elements, including empty elements, must have a closing tag.
¤
Attribute values must always be quoted.
These are just the most important ones. The whole list and more detailed explanations
can be read from the recommendation ([44], section 4).
XHTML Basic
As explained above, parsing HTML on a mobile device is very resource consuming.
XHTML makes it a lot easier by removing many ambiguities and clarifying the syn-
tax. XHTML Basic, published in December 2000, is the second recommendation in
5
http://www.w3c.org/](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-13-320.jpg)
![CHAPTER 2. THE INTERNET AND MOBILE DEVICES 8
the W3C’s series of XHTML specifications and it takes XHTML yet one step closer
to the requirements of web clients with limited capabilities.
The specification describes itself with the following: "The XHTML Basic document
type includes the minimal set of modules required to be an XHTML host language
document type and in addition it includes images, forms, basic tables, and object
support. It is designed for Web clients that do not support the full set of XHTML
features; for example Web clients such as mobile phones, PDAs, pagers, and set-top
boxes. The document type is rich enough for content authoring." [43]
XHTML Basic combined with Cascade Style Sheets (CSS) [2] allows the web author
to create versatile pages with the added benefit that they look good not only on a com-
puter screen but also work well when accessed with a mobile device. This becomes
very important if the site is meant for use with both desktop browsers and mobile user
agents, as there is no need to create two different versions of the page.
2.4 Layout
Page layout is one of the major problems with many websites when accessing them
with a mobile user agent that has a small screen. It is very difficult for the users to
read a page when they need to scroll in every direction to see the whole page.
Tables
One big reason behind the problems with layout is the use of tables. Tables are usually
slow to render, especially if they are nested, as the whole table definition must be read
before it can be properly presented. This prevents incremental rendering, which is
inconvenient for the user. This is a major usability concern that should be noted by
everyone making websites for general Internet users. When tables are used for the
purpose they are meant for – to present tabular data – they are not a problem but when
tables are used to do the page layout it means trouble. In addition to usability, one big
concern is the mixing of presentational markup with content.
For the sake of different user agents (e.g. screen readers for the blind, mobile devices)
and maintainability, web designers should use semantic markup. Semantic markup
means making a clear difference between the content and the presentation. The](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-14-320.jpg)
![CHAPTER 2. THE INTERNET AND MOBILE DEVICES 9
markup, (X)HTML, describes the content – what it is and what is its role in the doc-
ument. The presentation, how the data should be displayed to the user, is explained
with CSS. Separating presentation from content makes it easier to maintain and up-
date the site as changes in the outlook can be made in one or just a few files instead
of editing tens or hundreds of them individually.
Partial Solutions
Semantic markup with media dependent CSS offers an easy way to alter the layout
based on the user agent. One can define several different style sheets for one document
by using the media attribute of the HTML link element. The media attribute has
many possible values including screen, print, handheld, and all. Unfortunately not all
mobile browsers support the media attribute.
For mobile users there is some help available even when the site’s design does not
acknowledge them in any way. There are several browsers for mobile phones and
PDAs that try to render the page so that it fits on the small screen of the device and is
still readable.
Opera software’s solution is a technology called Small Screen Rendering (SSR) [34].
Its main concern is to avoid horizontal scrolling and this is achieved by using several
different techniques. If the layout uses columns and they are too wide to fit on the
screen side by side, they are merged into one in the document order (the order in
which the elements appear in the page source code). Big images do not work well on
the small screen so they are either scaled down or removed altogether. Background
images are not shown and SSR also adjusts the fonts so that only three different sizes
are used in order to improve readability. Based on our experiences and given the wide
variety of different webpages, SSR works quite well while still not being the ideal
solution to access the Internet with mobile devices.
There are many other similar approaches to solve the problem. For example Access6
has an embedded browser for mobiles called NetFront. It uses its own Smart-Fit
technology to adapt pages on a small screen.
6
http://www.access-us-inc.com/](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-15-320.jpg)
![CHAPTER 2. THE INTERNET AND MOBILE DEVICES 10
2.5 Images and Bandwidth
Images on webpages can be a real annoyance for the mobile user. The issue is the
size of the images, in terms of both pixels and bytes. An image that looks good on
the desktop browser does not fit on the small screen of a mobile device and forces the
user to scroll in every direction. Also, as previously mentioned, the mobile bandwidth
is very limited and downloading of a single image, let alone several images, takes a
long time.
What makes the problem worse is the fact that the first solution that comes into mind,
turning off image downloads, is not always feasible. Sometimes images are used for
important functions on webpages such as navigation buttons or menu items. Without
those images the whole page is useless, but with the useful images can come many
unwanted and unnecessary graphics. This slows the download speeds to an unbearable
level or just makes reading the page very hard on a small screen.
Mobile networks currently offer very limited bandwidth compared to that of the broad-
band or even the modem Internet connection of a desktop PC. This causes page
downloads to the mobile browser to be slow, which is quite inconvenient for the user.
Again, webpages designed specifically for mobile users usually download fast, but
these pages represent only a tiny portion of the potentially interesting pages available
on the whole Internet. Many mobile operators and other companies offer services de-
signed to help users to improve their mobile browsing experience by compressing and
caching data. Examples of such services include Sonera’s Nettinopeutin and Mobile
Accelerator from Opera Software.
The Finnish mobile operator Sonera has a service called Nettinopeutin [39] (web
accelerator) that promises three to four times faster downloads on average. Net-
tinopeutin works by reducing the image quality, blocking GIF-animations and com-
pressing all the data. This service does not require any program to be installed on the
device and is free for Sonera GPRS customers.
Opera Software, who are best known for their web browser, have a Mobile Accelerator
service [33]. It reduces the size of webpages by approximately 50-70% by optimizing
code, compressing data, and removing unnecessary content. Mobile Accelerator is a
commercial service, prices start from 6.90 euros for three months.](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-16-320.jpg)
![CHAPTER 3. MOBILE FRIENDLY FEATURES 12
devices is becoming too big to be ignored by web service designers. Furthermore, all
the time new people are becoming aware of the possibilities that mobile devices offer,
and therefore the number of potential users is increasing with a rapid rate. Unfortu-
nately, there are not many websites that support mobile devices in a way we would
like them to.
Mobile phones travel with their owners, so wherever they go their phones will follow.
This is one very essential reason why mobile friendliness is needed. With mobile
friendly features it is easier for users to keep track of their daily events, for example by
writing them down to a weblog or uploading images taken with their camera phones to
an online gallery. These and many other similar services already exist in the Internet
but the problem is that only a tiny fraction of them provide a mobile friendly user
interface.
3.2 Recognizing Mobile Devices
In order to enable mobile friendly features we must first be able to determine when a
mobile device is present, i.e. when the device requesting a webpage from our server is
a mobile device. One way to do this is to use device’s user agent string as an identifier.
The user agent string is a string of text containing information about the device, such
as operating system, platform, used browser, and localization. Also, other details
can be inserted into the user agent string. Some mobile devices may even include
their display dimensions in pixels. Table 3.1 lists some user agent strings of different
mobile and desktop browsers. Most user agent strings in the table were acquired from
the Internet [35][45] and others by manually checking them with mobile phones.
Knowing just the user agent string is obviously not enough to activate mobile friendly
features. Display dimensions is another important step on our way towards mobile
friendly web services. We need to know the display dimensions of those mobile
devices that we want to support on our website. There are a few ways to find out
display dimensions of different devices. If dimensions are not included in the user
agent string, which seems to be the case most of the time, they can usually be found
from the device manufacturer’s homepage. When we have both the user agent string
and the display dimensions of a mobile device we will need to map them together.
This can be done best by using a tabular data structure where user agent strings are
keys to the corresponding display dimensions.](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-18-320.jpg)
![CHAPTER 3. MOBILE FRIENDLY FEATURES 13
Table 3.1: User agent strings of various devices.
Device Browser User Agent String
Nokia 3650 phone’s Nokia3650/1.0 SymbianOS/6.1 Series60/1.2
browser Profile/MIDP-1.0 Configuration/CLDC-1.0
Nokia 7610 phone’s Nokia7610/2.0 (4.0421.4) SymbianOS/7.0s Series60/2.1
browser Profile/MIDP-2.0 Configuration/CLDC-1.0
Nokia 7700 Opera Mozilla/4.0 (compatible; MSIE 5.0;
Symbian OS; Series 90) Opera 6.0 [en]
Sony Ericsson T610 phone’s SonyEricssonT610/R201 Profile/MIDP-1.0
browser Configuration/CLDC-1.0
Sony Ericsson P900 phone’s SonyEricssonP900/R101 Profile/MIDP-2.0
browser Configuration/CLDC-1.0
Pocket PC PocketIE Mozilla/4.0 (compatible; MSIE 4.01;
Windows CE; PPC; 240x320)
PC w/Linux Opera Mozilla/4.0 (compatible; MSIE 6.0;
X11; Linux i686) Opera 7.23 [en]
PC w/Windows XP Mozilla Mozilla/5.0 (Windows; U; Windows NT 5.1;
Firefox rv:1.7.3) Gecko/20041001 Firefox/0.10.1
The user agent string holds a lot of information and therefore we do not need to
use the whole string as a key. Instead, we could use regular expressions to rep-
resent the user agent strings. Regular expressions are special text strings for de-
scribing search patterns. Plenty of information on regular expressions is available
on the Internet1
. A Regular expression could cover only the part of a user agent
string that is needed to uniquely identify a device. For example, a regular expression
“.*?Nokia3650.*?” matches only with user agent strings containing the string
“Nokia3650”. Furthermore, if we look at user agent strings in Table 3.1, we see a pat-
tern emerging, at least, when Nokia’s Series 60 phones (Nokia 3650 and Nokia 7610)
are considered. For example, the regular expression string “.*?Series ?60.*?”
matches to all Nokia’s Series 60 mobile phones This is a good way to reduce the
number of needed regular expressions. All Nokia’s Series 60 phones can be grouped
together because they all have the same display dimensions (176 pixels wide and 208
pixels tall screen). Instead of using individual identifiers for all Series 60 phones we
are able to use just one identifier for the whole group. It is possible to use even more
general identifiers, such as the operating system and browser. These “default” iden-
tifiers should only be used as a fall-back, i.e. if some device’s identifier is not on the
list, we can take a guess based on its operating system. For example many Series 60
mobile phones use Symbian OS and therefore a suitable fall-back regular expression
string for them would be “.*?Symbian ?OS.*?”.
1
http://www.regular-expressions.info/](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-19-320.jpg)
![Chapter 4
Open Source Software
What is open source? Many people seem to think it is just a free access to software
products. While it is true that open source means a free access to software’s source
code, there is also a more complex side to it, i.e. what are the limitations and respons-
ibilities when using and distributing open source software? How open source software
can be distributed, is determined by a license attached to the software by its original
developers. There exist various open source licenses which all have to fill completely
the criteria of the Open Source Definition (OSD) [30]. Besides the matters described
above, this chapter also takes a look at open source software development and some
successful open source projects.
4.1 The Open Source Definition
Working in software development and using source code of a another program written
by someone else is something that brings up legal issues about immaterial rights, such
as who owns the source code and how the code or the modified version of it should be
distributed. It is good to know your rights when it comes to dealing with source code
that is not yours.
Proprietary software, shareware, freeware, free software, public domain, copyleft, and
open source are terms that one eventually runs into in open source software develop-
ment. In order to understand what open source means precisely, it is necessary to
know the meanings of these terms. In the following a short explanation on each of the
terms is given [13].](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-26-320.jpg)
![CHAPTER 4. OPEN SOURCE SOFTWARE 22
Lesser General Public License (LGPL, section 4.2) allows source code licensed under
it to be used in products that are not open source. The open source definition, released
by Open Source Initiative (OSI), is a list of criteria which a license has to fulfill in
order to be an open source license. The ten most important parts of the open source
definition will be explained in the following [30].
Free Redistribution. The first requirement of the definition concerns one of the most
important characteristics of open source. The clause says that open source software
must be redistributed freely, which means the license can not restrict selling or giving
away the modified software nor require any royalties or other fees for it. However,
this does not say that you can not charge for example for your customer support or
printed documentation of the software.
Source Code. The second clause is about the software’s source code. It requires
that the source code must be obtainable for free, e.g. preferably downloadable via the
Internet. Furthermore, the distributed code must not be deliberately obfuscated.
Derived Works. The third clause demands that the license must allow modifications
and derived works, and must allow them to be distributed under the same license that is
used with the original software. This clause, together with the second one, guarantees
access to the software’s source code and allows it to be modified. Therefore it is
possible that open source software can be developed by anyone.
Integrity of The Author’s Source Code. The next part deals with the integrity of the
author’s source code. It says that the license may restrict source code from being
distributed in a modified form. However, it must allow distribution of patch files.
This gives users a possibility to know who is responsible for the software they are
using.
No Discrimination Against Persons, Groups nor Fields of Endeavor. The fifth and
sixth clauses require that the license must not discriminate against any persons or
groups nor the place where it is used. These clauses guarantee that open source soft-
ware can be used by anyone in any group and in any business branch.
License Features. The last four clauses are all concerning features of the license. The
first one is about distributing the license. It says the rights attached to software must
also apply to all whom the software is redistributed to. The next one says the license
must not be specific to a product. By demanding this, the clause closes one class of li-
cense traps which are ways of questionably making open source software proprietary.
The third one requires that the license does not restrict other software. It means that](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-28-320.jpg)
![CHAPTER 4. OPEN SOURCE SOFTWARE 23
the license can not place any restrictions on any software that is distributed along with
the licensed software. The last clause says the license must be technology-neutral,
meaning that non of the license’s clauses may be based on individual technology or
style of interface.
As we can see the open source definition is quite complex and demands a lot from a
license. When designing a license that aims to be open source valid, one needs to be
very exact when writing the conditions and it is probably not a bad idea to have some
legal advice on as well. Each piece of software that is open source should have an
individual license attached to it to guarantee that the software remains open source.
Fortunately most open source licenses have been created as templates, where the user
can just fill in the software name and the copyright owner to have a valid open source
license for the software. This way programmers can use ready-made licenses and
do not have to waste time in creating one of their own from scratch. Programmers
can can pick up a license suitable for their software product for example from the
Open Source Initiative’s website1
that lists all the licenses OSI have approved as open
source licenses.
4.2 Popular Open Source Licenses
In this section we will describe the features of some of the most popular open source
licenses. We start with GPL and LGPL and then move on to BSD, MIT, and Artistic
License. All of these licenses protect the software with a copyright. To make a license
to be an open source license, copyright holders add copyleft to it, which means they
grant permission to copy, distribute and modify the software if certain conditions are
met.
GPL – GNU General Public License – was released by Free Software Foundation in
1989, and is today the most popular license used in open source projects. About 69%
of all 33,931 projects at Freshmeat.net and around 70% of all 53,345 Open Source
Initiative (OSI) approved projects at SourceForge.net use GPL [31][32]. The license
says that anyone may copy and distribute verbatim copies of the source code as long
as copyright notices and disclaimers are included unchanged. A fee may be charged
for physical distribution of copies or if one decides to offer warranty. The software
may be modified and then redistributed by anyone if the modified files are marked
1
http://www.opensource.org/licenses/](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-29-320.jpg)
![CHAPTER 4. OPEN SOURCE SOFTWARE 24
with the name and date modified. Also, the modified program, or the program the
modification is part of, must be licensed as a whole under GPL. The software, or a
work based on it, may be distributed and copied in object code or executable as long as
the complete corresponding source code is included in the distribution. A reasonable
fee can be charged based on the physical reproduction cost of the code. [29]
LGPL – GNU Lesser General Public License – was also released by Free Software
Foundation in 1991. It is the second most popular open source license at Fresh-
meat.net with 7.5% share, and at SourceForge.net with a share of 11% [31][32]. This
license is mainly intended for libraries. Like GPL it allows anyone to copy and dis-
tribute verbatim copies of the source code under the license. Also, a reasonable fee
may be charged for physically distributing copies or if one decides to offer warranty.
The library or any part of it may be modified. If the result itself is a library and
modified files are marked with the modifier’s name and date, the modification may
be copied and redistributed. It is possible to change the license type of a modified
library from LGPL to the ordinary GPL by simply replacing all notices referring to
LGPL with those of GPL. The library may be copied and distributed in object code or
executable form, provided the complete corresponding source code is also included.
Programs using LGPL libraries do not fall under LGPL as long as the programs are
only compiled or linked with the library, and therefore do not contain any portions of
the library. [29]
BSD License - Berkeley Source Distribution License was released by the University
of California, Berkeley, in 1998. The BSD License is almost as popular as LGPL.
At Freshmeat.net it is used in 5.6% and at SourceForge.net in 7.2% of all projects
[31][32]. This license’s clauses are easy to understand and there are just a few of them.
First it says that anyone can redistribute and use the source or binary forms, with or
without modifications as long as the license’s clauses are not broken. Clauses define
that copyright notice and disclaimer must be included with the redistributed software.
Furthermore, neither the copyright owner’s name nor the names of the software’s
contributors may be used to promote the product without written permissions from
original authors. Features of the MIT License, released by Massachusetts Institute of
Technology, and the BSD License are equal without the final no-promotion clause of
the BSD-license. [29]
Artistic License is the last example. It was released by Perl in 1987 but despite of the
releaser’s name, it is today widely used in various other projects as well. About 1.8%
of projects at Freshmeat.net and around 2.1% of OSI approved projects at Source-
Forge.net use this license to copyright their software [31][32]. The first clause says](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-30-320.jpg)
![CHAPTER 4. OPEN SOURCE SOFTWARE 25
that anyone may distribute verbatim copies of the original, unmodified, version as
long as they include copyright notices and disclaimers with the distribution. Anyone
may use patches derived from the copyright owner and the software is still considered
as original and unmodified. Anyone may modify the software provided they make a
notice of the changes they have made at the beginning of each modified file and, of
course, make the modified software freely available. It is also possible to use a modi-
fied version of the software within organizations or rename the whole software so the
names do not conflict with the original. Anyone may distribute binary or source form
as long as they provide the whole package, i.e. the original version must be included
with modified versions. Reasonable fees may be charged by anyone for physically
distributing the package or if they choose to support the package. Fees on the pack-
age itself may not be charged, though. Scripts and libraries supplied as input to or
produced as output from the package do not fall under the copyright of Artistic Li-
cense. C and Perl subroutines linked to this package and supplied by the distributer
of this package are not considered as part of the package. The name of the copyright
owner may not be used to promote products derived from software under this license
without written permission from the original authors. [29]
Choosing the right license for your own open source software may be difficult, but
it is something that has to be done. Also, when you take an open source software
package and modify it to suit your needs, you will need to know what are the rights
and responsibilities defined by the software’s license. Table 4.1 summarizes important
features of licenses that have been discussed in this section including GPL, LGPL,
BSD, MIT, and Artistic License. Some other popular licenses, such as QPL (Qt Public
License), MPL (Mozilla Public License), IBM Public License, and Apache Software
License are presented as well. Though it is easy to see from the table what are each
licenses’ features, one should still always get to know the original license thoroughly.
Working with a license whose conditions are not familiar may lead into trouble. The
following will explain the meaning of each column in the Table 4.1 [5].
Possible to link with proprietary software. For example, according to the terms of
GPL, if you mix code published under GPL to your software, you must distribute
your software under GPL. It does not matter whether your software already is open
source or whether it is proprietary, from there on it is open source under GPL. This
kind of licensing is not beneficial for commercial software and because of it, other
licenses have been created which do not include this requirement.
If software is published, modified source code must be redistributed. A free software
license requires always that if any modifications have been made to the source code,](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-31-320.jpg)
![CHAPTER 4. OPEN SOURCE SOFTWARE 26
Table 4.1: Features of popular OS licenses. Slightly modified from [5].
Possible to If software Modifications Can GPL
link with is published, can be prohibit compatible
proprietary modified source forked to commercial
software code must be proprietary sale
redistributed
GPL no yes no yes yes
LGPL yes yes no yes yes
BSD yes no yes no yes
MIT yes no yes no yes
Artistic License yes no yes yes yes
QPL no yes no yes no
MPL yes yes yes no no
IBM Public License yes no yes no no
Apache Software License yes no yes no no
it must be redistributed. Open source licenses have provided some relaxation for this
requirement by not demanding the redistribution of modified source if certain condi-
tions are met. For example, open source software can be modified, but the modified
source does not need to be redistributed if the software is kept private or within an
organization, i.e. the software is not published.
Modifications can be forked to proprietary. This is another major difference between
open source and free software. Most free software products are copylefted and by that
they disallow the possibility to turn them to proprietary. Open source, however, leaves
it for licenses to decide whether to allow forking or not. If it is allowed, the software
can be modified and made proprietary.
Can prohibit commercial sale. This option is important for companies who plan to
release both commercial and non-commercial versions of their software. If the license
does not prevent commercial sale, the copyright owner can release a commercial ver-
sion of the program in addition to the open source version. The license prevents
subsequent developers from commercially distributing the open source version of the
software.
GPL compatible. If any code is mixed with code that is licensed under GPL, the
result will be all GPL as the GPL demands. When a license announces that it is GPL
compatible, it means that the software under the license can be relicensed to GPL. In
other words, source code that is not published under a GPL compatible license can
not be joined with GPL licensed source code.](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-32-320.jpg)
![CHAPTER 4. OPEN SOURCE SOFTWARE 27
4.3 OSS Projects
Open source software is free and anyone can obtain their own copy of the source
code with no charge (except the almost non-existent cost of an Internet connection).
Open source projects can be found best by visiting some web services hosting these
projects. Probably the most known ones of these are SourceForge2
and Freshmeat3
,
which were already mentioned in section 4.2. Together they host over 115,000 open
source projects with over 1,100,000 registered users [32][31]. Besides SourceForge
and Freshmeat, there are other similar services including BerliOS Developer4
with
just over 1,500 projects, and Open Source Directory5
with about 700 open source
projects [28][1].
While most open source projects remain unknown to the general public, there are
some that really have made their way through and some of them are even making
money. Some of the well known open source projects include Apache, Linux, and
MySQL. Apache is a web server software that started to gain much reputation during
1995 and by the end of the first quarter of 1996, its market had closed up the gap
with Microsoft’s web server. From there on Apache has been the leading web server
software and it has gained a market share of 67.2% (Figure 4.1) [25].
Linux is probably the best known open source project. It is an operating system
that was released by Linus Torvalds in 1991. Since then many programmers have
made their own contributions for Linux development. Gradually Linux has gained
reputation as a good and stable operating system and has become more and more
used amongst academic society and Internet service providers [13]. The most popular
open source database is MySQL. Its market share is still far from its commercial rivals
Oracle, IBM and Microsoft databases but it is still used by some big companies [7].
Just to mention a few, MySQL is used by Yahoo!, Google, Cisco, Sabre Holdings, HP,
and NASA [24].
2
http://sourceforge.net/
3
http://freshmeat.net/
4
http://developer.berlios.de/
5
http://osdir.com/](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-33-320.jpg)
![CHAPTER 4. OPEN SOURCE SOFTWARE 28
Figure 4.1: Market share development of web servers.
4.4 Development of OSS
Open source software can be developed using varying development models but even-
tually they all can be categorized to be either the cathedral model or the bazaar model.
The names cathedral and bazaar come from Eric S. Raymond’s essay on open source
software engineering methods. Raymond talks about his observations on the Linux
kernel development and his experiences on managing an open source project [36].
Before Linux, which uses the bazaar model, the cathedral was the prevailing model.
According to Eric S. Raymond’s essay, he thinks that Linus Torvalds is the inventor
of the bazaar model.
One notable difference between the bazaar and the cathedral model is how often the
software is released. Cathedral projects believe that releasing source code early, be-
fore it is tested properly and seen to be quite stable, is a bad policy because early
versions most likely contain more than just a few bugs and it would wear out the pa-
tience of users. Operating quite opposite to the cathedral model, the bazaar model
endorses releasing early and releasing often. The advantage of this style compared
to the cathedral model is that projects get feedback about bugs also from the users
instead of just getting it from the developer team. In his essay Raymond defines the
“Linus’s law” which says that “Given enough eyeballs, all bugs are shallow”. It means
that when the source code is publicly available, like it is in the bazaar model, there are](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-34-320.jpg)
![CHAPTER 4. OPEN SOURCE SOFTWARE 29
more people testing the software and therefore bugs will be discovered and reported
considerably faster than in the cathedral model. [36]
What if there are not enough “eyeballs” available, will the bugs be discovered any-
way? This kind of situation can occur when a community around an open source
project has not grown much. This may reduce the quality of source code because
bugs and errors are detected with a much lower rate than what it would be with larger
communities. Therefore, it can be said that the quality of open source software is
not necessarily any better than it is with proprietary software. Eventually the quality
of source code depends on used person hours which can be much greater with large
communities than with proprietary software or small open source projects. [36][12]
Today, partly because of being inspired by Raymond’s essay and the fact that the
bazaar model actually works, most open source projects that used to use the cathedral
model now use the bazaar model. Also, the majority of newly launched open source
projects have adopted the bazaar model. For a contrast, the typical development model
for proprietary software projects would be, without an exception, the cathedral model.
Naturally, most of the time these projects do not publish the source with the release
of their proprietary software. [36]
Open source is open for all and therefore anyone can pick up a project for example
from SourceForge.net and start working on their own modifications. This naturally
leads to a situation where popular open source projects are being developed all over
the world by different individuals who have never even met each other. As arranging
meetings would be difficult and expensive, most open source projects use the Internet
as a medium to discuss and inform others about the changes concerning the project.
The informing can be done using a simple bulletin board website that is dedicated
for the project. The projects that need more interaction between developers, need a
more sophisticated method of communication. These methods include newsgroups,
mailing lists, communities, and forums. Communities and forums are pretty much
the same and one of them can usually be found from the project’s website. They are
meant to be a place for the project related discussion where people can comment on
entries submitted by others, inform about bugs, ask installing or usage instructions,
etc. Communities and forums seem to be used mainly by larger projects with many
developers and users, while newsgroups and mailing lists seem to be used by smaller
projects.
Open source projects are started mainly by one person or a small group of people.
Mostly their common interest is to create something they would need. Initially this](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-35-320.jpg)
![CHAPTER 5. CASE STUDY: GALLERY 32
development and new features are added all the time but at the same time a new
version, Gallery 2, is being developed. Gallery 2 is a complete rewrite of the program
with a new extensible and modular architecture along with some new features. We
will discuss more about the differences later in this chapter. The development of
Gallery 2 has been going on for about two years now and the first public release, 2.0
Alpha, was made on July 18, 2004.
5.2 Programming Languages
Both Gallery 1 and Gallery 2 are programmed in PHP. Gallery 2 also uses a PHP based
Smarty template system to separate the user interface and the logic of the program.
As all data in Gallery 2 is stored in a database, SQL is needed to query the data.
5.2.1 PHP
PHP2
is a very popular general-purpose scripting language that is especially useful
for web development [15]. The name of the language is a recursive acronym for PHP:
Hypertext Preprocessor. PHP can be used on its own (command line scripting) or it
can be embedded in HTML pages (server-side scripting). Figures 5.1 and 5.2 illustrate
the differences between these two methods of using PHP with a familiar Hello World
program. Both examples are fully functional PHP programs and their outputs are
exactly the same.
While PHP alone is enough for command line scripting, server-side scripting requires
a web server. PHP can work with the web server in two ways: as a server module or
CGI (Common Gateway Interface) processor. PHP has a direct module interface for
many popular web servers such as Apache and Microsoft IIS (Internet Information
Server).
One of the most important features of PHP is that it supports a wide range of data-
bases. This allows easy creation of dynamic webpages. The supported databases
include dBase, IBM DB2, Ingres, mSQL, MySQL, Oracle, PostgreSQL, and many
more. PHP also supports ODBC (Open Database Connectivity), an open standard
database access method to connect to different databases without a database specific
client software.
2
http://www.php.net/](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-38-320.jpg)
![CHAPTER 5. CASE STUDY: GALLERY 33
1 textbferer
2 <?php
3 $hello = ’Hello World!’; $
4 echo "<html>n<head><title>Hello</title></head>n";
5 echo "<body>n$hellon</body>n</html>";
6 ?>
Figure 5.1: Hello World example, pure PHP code.
1 <html>
2 <head><title>Hello</title></head>
3 <body>
4 <?php
5 $hello = ’Hello World!’;
6 echo $hello;
7 ?>
8 </body>
9 </html>
Figure 5.2: Hello World example, embedded PHP code.
5.2.2 Smarty
Gallery 2 makes extensive use of a Smarty templating engine. Smarty [27] is a PHP
based templating system that is designed to make it easy for web developers and
website designers to separate the layout and the look of a page from the site’s logic.
Figure 5.3 shows a simple Smarty template and Figure 5.4 illustrates how the template
is used in a program.
Using templates has many benefits over the traditional method of printing the HTML
in the application code. The first advantage is that it makes the programmers’ task
easier as they do not need to worry about the presentation layer and the code is easier
to read as well when all the HTML is somewhere else. Secondly, the designers can
modify the layout and presentation without making any changes to the application
code. Actually, the designers do not even need to know PHP.
The third benefit is the close relationship that templates have with the actual page
output. Compared to mixing the application code with the HTML markup, the page
layout is a lot easier to design with a template as it closely resembles the final out-
put. Other advantages Smarty offers include a built-in debugging console and easy
extensions through plug-ins.
The first time a template is used Smarty compiles it into PHP code thus saving the
time used to parse the template on every consecutive request. The page output can
cached too, saving even more time. Even just parts of single page can be cached.](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-39-320.jpg)
![CHAPTER 5. CASE STUDY: GALLERY 36
Data Storage
All user data (usernames, passwords, email addresses etc.) and the images are stored
in an installation specific directory. Under that directory, albums have their own sub-
directories where all images and sub-albums belonging to that album are kept.
In the user data directory there is a file called albumdb.dat that contains the name of
each top level album. Under each album directory there are the files album.dat and
photos.dat. These files hold all the album details and photo properties respectively.
Each of these .dat files is a serialized version of a PHP object. In essence a serial-
ized object is a string representation of the object’s value and it can be easily stored
anywhere.
5.3.2 Gallery 2
As new features were added to Gallery 1 it grew bigger and more complex and difficult
to maintain and develop because of the lack of proper architecture. At that point the
developers decided to write everything again from scratch but this time plan it ahead
and create a solid, modular and extensible architecture for Gallery. The result of this
work is Gallery 2.
MVC Pattern
Gallery 2 uses several design patterns and coding methodologies to make the system
easier to implement and understand [23]. The main design pattern is the Model-View-
Controller (MVC) pattern. MVC pattern’s basic principle is to separate data from the
logic and display.
Model or data in Gallery 2 is a relational database where all the information is stored.
Currently Gallery 2 supports MySQL, PostgreSQL, and Oracle databases but sup-
port for different databases can be added relatively easy. Data is then processed by
controllers and finally presented to the user through a view i.e. the user interface.
Figure 5.5 clearly shows how the data is only accessed through the Gallery Core
API (Application Programming Interface), the modules do all the processing, and in
addition to the theme CSS files, all output to the browser goes through the main.php
file.](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-42-320.jpg)
![CHAPTER 5. CASE STUDY: GALLERY 37
Figure 5.5: The top level architecture of Gallery 2. The diagram is slightly modified from [22].
Gallery 2 Is Modular
All functionality in Gallery 2 is implemented using modules. The core module provides
the framework and some basic functionality like creating users, creating albums and
viewing images. All other functionality, such as search, commenting, and slide show,
which are not essential, are provided as separate modules. The administrators of the
Gallery installations can install and then activate or deactivate any combination of
modules they wish.](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-43-320.jpg)
![CHAPTER 5. CASE STUDY: GALLERY 42
5.5.1 User Agent Recognition
The first task on making Gallery 1 (or any other system, for that matter) mobile
friendly was to recognize the mobile user agents. This is done based on the user
agent string as reported by the user’s web browser and the list of known mobile phone
user agent strings.
In PHP the user agent string is available in the $_SERVER[’HTTP_USER_AGENT’]
global variable. Our list of known user agent strings is stored in the mobile_term-
inal.php file as shown in Figure 5.8. The keys in the $screenSizes array are
regular expressions that match different user agent strings and the values are screen
dimensions of a respective phone model. The keys are defined in the order where
the most specific ones come first and the most general key comes last. The order of
the keys is meaningful as array items in PHP are internally stored in the order they
are assigned. For example, both Series 60 and Series 90 phones use the Symbian
operating system and this information is in their user agent string. If we had the key
’/.*?Symbian.*?/’ first in the array it would match both models, which is not
what we want since their display sizes are different.
The function screenSize() in Figure 5.9 shows how we use the $screensizes
array. This function is defined in the same mobile_terminal.php file as the array. It
takes the user agent string as an optional parameter with an empty string as the default
value for it. In lines 5–14 we check if we are in the “force mode”. The force mode
means that Gallery does not actually read the user agent string but the decision is made
based on other information. Forcing is meant for testing and demonstration purposes
and it will be better described later in this section.
If the user agent string is not given as a parameter to the screenSize() function,
we get it from a server variable in lines 17–19. When we have the current user agent
1 global $screensizes;
2 // Phones that use the Series 60 platform, e.g. Nokia 3650 and 6600.
3 $screensizes[’/.*?Series ?60.*?/’] = array(’width’ => 176, ’height’ => 208);
4 // Phones that use the Series 90 platform, e.g. Nokia 7700.
5 $screensizes[’/.*?Series ?90.*?/’] = array(’width’ => 640, ’height’ => 320);
6
7 // The generic mobile phone using Symbian OS.
8 $screensizes[’/.*?Symbian.*?/’] = array(’width’ => 176, ’height’ => 208);
9
10 // this is for forcing & test cases
11 $default_screensizes[’series60’] = array("width" => 176,"height" => 208);
Figure 5.8: Mobile user agent strings in mobile_terminal.php file.](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-48-320.jpg)
![CHAPTER 5. CASE STUDY: GALLERY 43
1 function screenSize($useragent = ’’) {
2 global $screensizes, $default_screensizes;
3
4 // are we in force mode?
5 if (isset($_SESSION[’force’])) {
6 switch($_SESSION[’force’]) {
7 case ’mobile’:
8 return $default_screensizes[’series60’];
9 case ’desktop’:
10 return null;
11 default:
12 return null;
13 }
14 }
15
16 // if user agent is not specified, use the current from server
17 if ($useragent == ’’) {
18 $useragent = $_SERVER[’HTTP_USER_AGENT’];
19 }
20
21 // check if the user agent string matches any screen size key
22 foreach (array_keys($screensizes) as $key) {
23 if (preg_match($key, $useragent)) {
24 return $screensizes[$key];
25 }
26 }
27 return null;
28 }
Figure 5.9: Function screenSize() returns the user agent’s screen size.
string we can compare it to the known user agent strings. In lines 22–26 we step
through the $screensizes array starting from the beginning and compare each of
the keys with the user agent string. If a match is found we return the respective screen
dimension value.
Finally, in Figure 5.10, we define a function isMobileUser() that returns true
if the user agent is a known mobile device and false otherwise. This function too, is
defined in the mobile_terminal.php file. It takes an optional $useragent parameter
with default value of empty string. To determine the situation isMobileUser()
calls the screenSize() function. If the return value of that function call is not
null then we know that in the list of mobile terminals’ display sizes there is a defin-
ition for our current user agent, and therefore it is a mobile device.
1 function isMobileUser($useragent = ’’) {
2 if (screenSize($useragent) !== null) {
3 return true;
4 }
5 return false;
6 }
Figure 5.10: Function isMobileUser() recognizes mobile user agents.](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-49-320.jpg)
![CHAPTER 5. CASE STUDY: GALLERY 44
The Force Mode
To make testing and demonstrating the mobile friendly Gallery 1 easier we added a
possibility to force Gallery into a certain mode (mobile or desktop) from the browser.
On the Gallery main page we add the following line:
Terminal selection (current: automatic desktop): [automatic | mobile | desktop]
where mobile and desktop are links to force the Gallery into the respective mode. The
line is created by a command “include(’force.php’);”, which we added into
the albums.php file. This file is responsible for displaying the Gallery main page. The
contents of force.php are shown in Figure 5.11.
First, in lines 3–12, we check if we are in the forced or automatic mode and print the
appropriate information about the current status to the screen. Then, in lines 15, 20,
and 25, we check which exact mode (forced mobile, forced desktop, or automatic) we
are in and prepare the links accordingly. Finally, in line 31, we print the links to the
screen.
1 <?php
2 echo ’<div style="font-size: 8pt;"> Terminal selection (current:’;
3 if (isset($_SESSION[’force’])) {
4 echo ’forced ’;
5 } else {
6 echo ’automatic ’;
7 if (isMobileUser()) {
8 echo ’mobile): ’;
9 } else {
10 echo ’desktop): ’;
11 }
12 }
13
14 $link = ’<a href="setforce.php?force=’;
15 if ($_SESSION[’force’] == ’mobile’) {
16 echo ’mobile): ’;
17 $auto = $link . ’off" title="Automatic mode">automatic</a>’;
18 $mob = ’mobile’;
19 $desk = $link . ’desktop" alt="Desktop mode">desktop</a>’;
20 } else if ($_SESSION[’force’] == ’desktop’) {
21 echo ’desktop): ’;
22 $auto = $link . ’off" title="Automatic mode">automatic</a>’;
23 $mob = $link . ’mobile" title="Mobile mode">mobile</a>’;
24 $desk = ’desktop’;
25 } else {
26 $auto = ’automatic’;
27 $mob = $link . ’mobile" title="Mobile mode">mobile</a>’;
28 $desk = $link . ’desktop" alt="Desktop mode">desktop</a>’;
29 }
30
31 echo ’[’ . $auto . ’ | ’ . $mob . ’ | ’ . $desk . ’]’;
32 echo ’</div>’;
33 ?>
Figure 5.11: force.php script creates a browsing mode selection link.](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-50-320.jpg)
![CHAPTER 5. CASE STUDY: GALLERY 45
1 <?php
2 session_start();
3 if (isset($_GET[’force’])) {
4 switch($_GET[’force’]) {
5 case ’mobile’:
6 $_SESSION[’force’] = ’mobile’;
7 break;
8 case ’desktop’:
9 $_SESSION[’force’] = ’desktop’;
10 break;
11 default:
12 unset($_SESSION[’force’]);
13 break;
14 }
15 }
16
17 header(’Location: ’ . $_SERVER[’HTTP_REFERER’]);
18 ?>
Figure 5.12: setforce.php script saves the browsing mode information in the session.
The setforce.php script that gets called when the user selects a force link is shown in
Figure 5.12. The code simply checks if the force variable is set in the request and
then updates the session information accordingly. In line 17 the script instructs the
user’s browser to load the original page again.
5.5.2 Layout
If you narrow down your browser’s window, you will notice that Gallery’s main page
adjusts the layout accordingly. However, there is a limit to that. When the window is
narrower than the combined width of the album icon and the album title, the page does
not scale down anymore and some of it is left outside the screen. When accessing the
page with a Series 60 mobile phone, we see that the page is approximately twice as
wide as the phone’s display. Browsing an album with a mobile browser is even worse
as the number of picture columns does not change even if the screen gets narrower.
This is a direct consequence of the table based layout. We wanted to modify Gallery
so that the layout would scale properly even to the small 176 x 208 display of Series
60 phones.
Gallery Main Page
We started with the Gallery main page that is created by the albums.php file. The first
problem was that the album’s highlight image (albums first picture) and album’s title](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-51-320.jpg)
![CHAPTER 5. CASE STUDY: GALLERY 48
Figure 5.14: Gallery’s layout for album view.
1 $rows = $gallery->album->fields["rows"];
2 $cols = $gallery->album->fields["cols"];
3
4 if (isMobileUser()) {
5 $ss = screenSize();
6 $tot = $rows*$cols;
7 $cols = min(floor($ss[’width’] / 100), 3);
8 $rows = floor($tot/$cols);
9 }
Figure 5.15: Adjust the number of picture columns in album view.
One more thing that we needed to change was the commenting feature. People who
view the pictures can leave their comments about the images if they want. The prob-
lem is that the input field is too wide, 30 characters, to fit on the small display. We
changed the code in the add_comment.php file so that whenever we have a mobile
user agent the width of the comment text box is 10 characters instead of the normal
30 characters. The commenters can also give their name or email with the comment.
There is a text box for the name and the description “Name or email:” is in front of
it. Text and description are in their own table cells which forces them onto the same
row. We changed this so that in the case of a mobile user agent the text box and the
description are in the same cell. This makes it possible for the text box to be wrapped
to the next line thus fitting on a small display.](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-54-320.jpg)
![CHAPTER 5. CASE STUDY: GALLERY 50
1 function adjustThumbDimensions($thumbsize, $maxwidth = 80) {
2 if (!is_array($thumbsize) || !array_key_exists(’width’, $thumbsize)
3 || !array_key_exists(’width’, $thumbsize)) {
4 return false;
5 }
6
7 if ($thumbsize[’width’] > $maxwidth) {
8 $delta = $thumbsize[’width’] / $thumbsize[’height’];
9 $thumbsize[’width’] = $maxwidth;
10 $thumbsize[’height’] = $maxwidth / $delta;
11 }
12
13 return $thumbsize;
14 }
15
16 function adjustAlbumThumbDimensions($thumbsize) {
17 return adjustThumbDimensions($thumbsize, 80);
18 }
19
20 function adjustThumbSize($size, $maxsize = 80) {
21 if (($size > $maxsize) || ($size == 0)) {
22 return $maxsize;
23 }
24
25 return $size;
26 }
Figure 5.16: Helper functions in util.php to adjust the image sizes.
maximum value and calculate the new height keeping the same proportions (lines 8-
10). The function adjustAlbumThumbDimensions() is basically just a short-
cut for adjustThumbDimensions(). In some places Gallery only uses one size
parameter (width) for images and in those cases we use the adjustThumbSize()
function.
The main page of Gallery is printed in the albums.php file. When each of the album
highlight (or thumbnail) images is prepared for output we check if it needs adjusting.
This is done by adding the code shown in Figure 5.17. We use the same code also
in view_album.php except that we call the adjustThumbDimensions() func-
tion instead. Below every image Gallery writes the name of the file and a view
count. These are printed in a table that is of the same width as the image. Gal-
lery gets this value from the $gallery->album->fields[’thumb_size’]
variable. Whenever we have a mobile user agent we replace that with a call to the
adjustThumbSize() function. Finally we modified the getThumbnailTag()
function in classes/AlbumItem.php so that it calls the adjustThumbSize() func-
tion when a mobile device is accessing Gallery.](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-56-320.jpg)
![CHAPTER 5. CASE STUDY: GALLERY 51
1 if (isMobileUser()) {
2 $dimensions = adjustAlbumThumbDimensions(array(’width’=>$iWidth,
3 ’height’=>$iHeight));
4 $iWidth = floor($dimensions[’width’]);
5 $iHeight = floor($dimensions[’height’]);
6 $scaleTo = $iWidth;
7 }
Figure 5.17: Adjusting the dimensions of an album thumbnail image.
5.5.4 Image Upload Module
Some of Nokia’s mobile phone models, such as 3650 and 6600, have a built-in Image
Uploader. This allows phone owners to upload pictures straight from their phone to
any server that supports the Image Upload protocol. One of the goals of our project
was to implement the support for this service in the Gallery software. We did this for
both Gallery 1 and Gallery 2 and this section describes how it was done on the latter.
Image Upload Server API
The protocol specification, Image Upload Server API version 1.1, "describes an in-
terface that is used to upload images from a terminal to Remote Storage (RS). The
goal is to provide a set of calls that can be used in upcoming imaging phones, are easy
to implement at both the phone and server end, and are futureproof, in that the same
protocol will be useful for a long period of time." [11]
Before using the service a phone owner needs to store the RS’s address in the Image
Uploader’s settings. The username and password can also be saved or typed manually
at every upload. The user selects an image he or she wants to upload and starts the
uploader on the phone. The phone will then connect to the address provided in the
settings and send the username and password with the request. The server responds
with a list of the services it provides.
The client on the phone can now ask for a directory listing or decide to create a new
album. Finally, after the upload directory is chosen or created, the image is uploaded
to the server. At any point the server can return an error code if the authentication
fails, there is a name conflict, or for any other possible server side error. The user will
be notified of the error and he or she can try to upload again.](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-57-320.jpg)
![CHAPTER 5. CASE STUDY: GALLERY 55
1 GalleryCoreApi::requireOnce(
2 dirname(__FILE__) . ’/classes/ImageUploadHelper.class’);
3
4 class DirectoryListingController extends GalleryController {
5 function handleRequest($form) {
6 $results[’delegate’] = array(’view’ => ’nokiaupload:DirectoryListing’);
7 $results[’status’] = ImageUploadHelper::getDirectoryListing();
8 $results[’error’] = array();
9
10 return array(GalleryStatus::success(), $results);
11 }
12 }
13
14
15 class DirectoryListingView extends GalleryView {
16 function isImmediate() {
17 return true;
18 }
19
20 function renderImmediate($status, $error) {
21 global $gallery;
22
23 $reply = array($status[’success’] . "rn");
24
25 if ($status[’success’] == NOKIAUPLOAD_ERR_NOERR) {
26 $dirNum = count($status[’albums’]);
27 $reply[] = $dirNum . "rn";
28 $reply[] = "3rn"; // Lines per directory (id, parent id and name).
29 foreach ($status[’albums’] as $album) {
30 $reply[] = ’DId=’ . $album[’id’] . "rn";
31 $reply[] = ’PId=’ . $album[’parentid’] . "rn";
32 $reply[] = ’DirName=’. $album[’name’] . "rn";
33 }
34 } else {
35 $reply[] = "Couldn’t fetch directory list.rn";
36 }
37
38 $reply = implode(’’, $reply);
39 header(’Content-Length: ’ . strlen($reply));
40 print $reply;
41
42 return GalleryStatus::success();
43 }
44 }
Figure 5.20: Image Uploader’s Directory Listing controller and view in DirectoryListing.inc file. The
code is fully functional but details irrelevant for this example have been left out.
The getDirectoryListing() function fetches all IDs of the albums where the
current user has permission to add data items i.e. pictures (line 12 in Figure 5.21).
After checking that there were no errors we load the albums in line 19. Then, in lines
24-35, we go through all the albums and fetch the ID, name, and parent’s ID for each
album. The function returns the album information along with the success code to the
controller. This is the status that is then passed on to the view.
The DirectoryListingView class in Figure 5.20 defines two functions. The isImmediate()
function always returns true. This tells Gallery that no templates are used but this](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-61-320.jpg)
![CHAPTER 5. CASE STUDY: GALLERY 56
1 define(’NOKIAUPLOAD_PROTOCOLVERSION’, ’1.00’);
2 define(’NOKIAUPLOAD_ERR_NOERR’, ’0’);
3 define(’NOKIAUPLOAD_ERR_DIRLIST’, ’2’);
4
5 function getDirectoryListing() {
6 global $gallery;
7
8 /* Change the status to no error only if everything succeeds. */
9 $status[’success’] = NOKIAUPLOAD_ERR_DIRLIST;
10
11 /* Get all album ids where we have addDataItem permission. */
12 list($ret, $albumIds) = GalleryCoreApi::fetchAllItemIds(
13 ’GalleryAlbumItem’, ’core.addDataItem’);
14 if ($ret->isError() || count($albumIds) < 1) {
15 return $status;
16 }
17
18 /* Load albums and get their names. */
19 list($ret, $albums) = GalleryCoreApi::loadEntitiesById($albumIds);
20 if ($ret->isError()) {
21 return $status;
22 }
23
24 foreach ($albums as $album) {
25 $id = $album->getId();
26 $parentId = $album->getParentId();
27 $name = $album->getTitle();
28 if (empty($name)) {
29 /* If album doesn’t have a name set use the file system name. */
30 $name = $album->getPathComponent();
31 }
32 $name = GalleryUtilities::htmlEntityDecode($name);
33 $albumData[] =
34 array(’id’ => $id, ’parentid’ => $parentId, ’name’ => $name);
35 }
36
37 $status[’albums’] = $albumData;
38 $status[’success’] = NOKIAUPLOAD_ERR_NOERR;
39 return $status;
40 }
Figure 5.21: Funtion getDirectoryListing() in ImageUploadHelper.class. The code is fully
functional but details irrelevant for this example have been left out.
module renders all output itself. Then Gallery calls the renderImmediate()
function and passes status as a parameter. In lines 25-36 the album information
is extracted from the status array and formatted for printing according to the fol-
lowing model:
errorcode<newline>
NumberOfDirectories<newline>
LinesPerDirectory<newline>
DId=Id<newline>
PId=PId<newline>
DirName=Name<newline>](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-62-320.jpg)
![Chapter 6
Case Study: LiveJournal
One goal of our project was to add mobile friendly features to an existing open source
web logging, also known shorter as blogging, service. LiveJournal (LJ) was chosen
amongst several available blogging services based on its popularity. The beginning
of this chapter concentrates in explaining what LiveJournal is, how it works and how
it is being developed using communities as a channel of information. Later on we
will introduce the reader with the programming languages behind LiveJournal before
finally going into the solutions needed while implementing mobile friendly features
on LiveJournal.
6.1 Overview
Today blogging is a popular way to preserve your memories and daily events. It is
pretty much the same as keeping a common diary or journal but it is done over the
Internet. Blogging also provides a possibility to have joint diaries with your friends
and a control over who can view certain entries in your journal.
LiveJournal is one of the most popular blogging service providers today [38]. It has
a wide user base totaling over three million bloggers where about half of them are
from the United States. At the moment over one million of all those users are active
which means they have updated their blogs during last 30 days. For LiveJournal this
means that their servers receive approximately 250 journal updates per minute [19].
For this, and the 2.8 million requests per hour and other tasks, LiveJournal has about](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-65-320.jpg)
![CHAPTER 6. CASE STUDY: LIVEJOURNAL 60
80 computers running the whole system 24 hours a day, seven days a week (i.e. 24-7)
[10]. Other popular blogging services include e.g. Blogger, xanga and tBLOG.
LiveJournal offers two types of accounts for new users. A more favoured one is the
Free Account which is, as the name says, free. The other one, named Paid Account,
offers more features in return for the money paid for it. There also exists an account
called Early Adopter for users registered before September 14, 2000 and a Perman-
ent Account for LiveJournal staff. Everyone who is 13 years or older can create an
account for themselves and start blogging. [17]
Once an account has been created users can start to update their journals, upload some
user pictures, generate a personal profile and define which other LiveJournal users are
their friends. Users are given a possibility to find other bloggers by searching for them
based on interests. It has been made possible for users to change the appearance of the
pages, modify the looks of own journal and choose a preferred mood icon set to use
with journal entries. Journal access can be defined as either public, private or friends
only. Any combination of these is possible because the security level is defined one
by one for each entry. If the security level is set to public everybody can view your
journal entries. On the private level you are the only one allowed to view your entries.
The friends only setting lets just those people who you have defined as your friends
to read your journal.
Once users have made some entries to their journals, other people, who have the
right to view those journals or actually the entries in them, can post comments on the
entries. Besides journals, users can create communities for common causes. All users
interested in a specific topic, which a community has been created for, can make posts
to it. In the case of the community being closed, users can not make posts to it before
they have been accepted as members of the community by one of its maintainers.
Furthermore, some communities have moderators who may reject member and non-
member postings if they are not relevant for the community. [16]
The features described above come with the Free Account. The Paid Account provides
several more features. It gives users an access to a directory search that allows them
to find other users based on location, journal update time, user’s age and some other
options. A few other features provided include an increased number of allowed user
pictures, the possibility to embed polls into journal entries, a LiveJournal email ad-
dress and text messaging to other LiveJournal users. [16]
LiveJournal is an open source web based application. Because the source code is open
it means that anyone can get it for free and set up their own LiveJournal web server.](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-66-320.jpg)
![CHAPTER 6. CASE STUDY: LIVEJOURNAL 61
For the development and source code repository there is livejournal.org which is the
“non-profit” wing of livejournal.com [21]. livejournal.org offers the latest version of
the source code straight from the CVS (Concurrent Version System) repository or as
a downloadable package including an older, but without fail, stable version of the
source code.
6.2 Architecture
LiveJournal uses Apache’s version 1.3.x with version 1.x of mod_perl to run the
service. For registered users’ information, journal entries, etc. LiveJournal uses a
MySQL database. The software and functionality behind LiveJournal can be divided
into three sections: basic pages, journal pages and a number of CGI scripts and Perl
modules.
The first one is, as we call it, basic pages which are webpages like login, logout,
update journal, edit friends, edit personal info and to-do. This section contains the
functionality which handles the user interface, both the look of it and any inputs initi-
ated by users. The majority of these pages are created using Better Markup Language
(BML, section 6.4.2).
The second section contains journal pages, which differ from basic pages because
they are created using Style System 2 (S2, section 6.4.3) instead of BML and they all
concern the actual journal. As for basic pages, this section handles user inputs and the
look of the interface for journal pages.
The third and final section consist of CGI scripts, written in Perl (section 6.4.1), and
some Perl modules which both are used by basic pages and journal pages to help in
creating their content, identifying users, updating journals, handling inputs, etc.
6.3 Developers & Communities
According to livejournal.com there is currently a core group of eight people devel-
oping LiveJournal [18]. Besides these guys there are about fifty hackers who make
contributions for LiveJournal by sending in patches [20]. When LiveJournal is con-
sidered, hacker is a word used to describe those programmers who do their own modi-
fications to the software.](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-67-320.jpg)
![CHAPTER 6. CASE STUDY: LIVEJOURNAL 62
One written rule for LiveJournal hackers is to talk about the changes they are about
to embark on or just did at LiveJuornal’s lj_dev community to avoid duplicate work
[21]. And what would be a greater place to discuss about development than using
LiveJournal’s own community feature for it? Not only hackers but also other re-
gistered LiveJournal users can post to and comment on this community as long as
their messages continue to be appropriate.
lj_dev is not the only community that is related to the development process of Live-
Journal. suggestions is a community where registered LiveJournal users can make
suggestions about what would be a cool new feature or what should be changed from
the current version in order to make LiveJournal even better. Another community that
is closely tied up to the development process is lj_test. This community is a place
for the developers and hackers to announce and discuss recent code changes to the
LiveJournal Test Server1
. [17]
There are also many more communities which are somehow connected to the devel-
opment process of LiveJournal. lj_sysdoc and lj_userdoc are communities where a
conversation about the documentation project is kept up by the developers. Common
topics could be the use of XML in documentation, contents of guides and FAQ, and
errors on documentation. Again it is possible for regular LiveJournal users to tell
their opinion about documentation by issuing comments. lj_support is a community
for LiveJournal volunteers to discuss the possible ways to help people to use the site.
It is not, though, a place for regular users to ask questions about how to use the site.
Other LiveJournal related communities exist also but they are not so important from
our project’s, nor LiveJournal development’s, point of view. [17]
6.4 Programming Languages
LiveJournal has been mainly built using three different programming and markup lan-
guages. These languages are Perl, BML and S2. What each language’s purpose is in
LiveJournal and what kind of languages they are will be described in the following
subsections. Besides the obvious use of HTML, some JavaScript is also used to help
out the design and functionality of the user interface. For database querying Live-
Journal uses SQL (section 5.2.3).
1
http://test.livejournal.org/](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-68-320.jpg)
![CHAPTER 6. CASE STUDY: LIVEJOURNAL 63
6.4.1 Perl
First we take a look at Perl which definitely is the only well-known one of these
three languages. The word “Perl” is not really an acronym but it has become one,
well actually a backronym, because people have invented meaning for its each letter
afterwards. Anyway, Perl is short for “Practical Extraction and Report Language” but
it has also been referred to as “Pathologically Eclectic Rubbish Lister”. Both have
been endorsed by Larry Wall, the developer of Perl, so there is no point in arguing
which one is correct. One of Perl’s mottos goes “There’s more than one way to do
it” and with our experience of Perl we could say it is absolutely true. LiveJournal
uses Perl e.g. for database operations and for help on generating the user interface.
[37][41][3]
Originally Perl was developed by one man, Larry Wall, and it was released in 1987
when he also decided to make the compiler and the source code free for everyone.
Ever since Perl has been publicly available and until nowadays it has been distrib-
uted under GNU General Public License and Artistic License. From its release date
Perl has gained a huge number of fans and some of them have even made their own
contributions for Perl by developing it further. This is mostly shown in the number
of optional Perl modules. There are hundreds of modules freely available at CPAN2
(Comprehensive Perl Archive Network). [4]
Perl is designed to have good and strong text processing abilities. This is one reason
why the language has become popular amongst programmers writing CGI scripts. Be-
sides web programming and text processing, Perl is widely used in graphical interface
programming, database access and system utilities. Perl is an interpretive language
and its interpreter is written in C. This is no surprise when you consider the fact that
Perl derives from C. Amongst many other tools and languages Perl also has herit-
age from sed and awk. Like most other modern programming languages Perl also
has object oriented features. However, the difference between regular Perl and object
oriented Perl is not that big as it is between C and C++. [3][4]
6.4.2 BML - Better Markup Language
The motto for BML is [9]: BML - “Because smart webmasters are lazy webmas-
ters.. . ”. The following paragraphs will describe some characteristics of this lan-
2
http://www.cpan.org](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-69-320.jpg)
![CHAPTER 6. CASE STUDY: LIVEJOURNAL 64
guage and also, in parallel, try to reveal if the motto is true or not. BML was mostly
developed by Brad Fitzpatrick, Brad Whitaker and Matt Wilson. It was designed to
help to make a consistent looking website and alleviate their maintenance, and also
because HTML code looks ugly [9]. BML is a server-side markup language which
means, in practice, that BML files are converted to HTML on the server before send-
ing them to the client. Actually, a BML file is an HTML file with some BML blocks
in it. A block is just another name for a macro, so BML can also be called as a simple
macro language. Blocks consists of chunks of HTML and possibly other BML blocks.
[8][9]
BML blocks can take parameters, which allows programmers to use blocks as tem-
plates. Because of the fact that BML blocks are executed on the server it is also
possible to write blocks that are not just static but dynamic. Within the BML system
there are a few core blocks that are predefined, waiting for programmers to use them.
One of these blocks and presumably the most useful is the main core block called
_CODE. This block allows execution of Perl code within the BML file. Perl code is
also executed on the server and the result must be either BML, which is then converted
to HTML, or HTML. [8]
The main purpose of BML is to help in creating and maintaining a consistent look
throughout a website. It allows users to define a header style, for example, and
whenever the style is used it produces the same kind of headers. If users should
want to change the style of their header, all they have to do is to make the change to
one place. This is the reason why BML is used in LiveJournal, to help in making a
similar look over the pages (excluding the user customizable journal pages). [8]
6.4.3 S2 - Style System 2
S2 is a programming language that gives users and programmers full control over the
appearance of their content. In other words it helps programmers and users to cus-
tomize the look of their layouts. Also, simple games like Tic Tac Toe have been im-
plemented by just using S2. The language was developed mostly by Brad Fitzpatrick
and Martin Atkins. It was developed for the journal pages of LiveJournal and for a
photo-hosting service called FotoBuilder but it could also be used in various other
projects as well. The language’s syntax mainly resembles Perl, C++ and Java. S2 is
actually a second, yet completely different and rewritten, version of the LiveJournal
original template engine which is now referred to as Style System 1 (S1). S1 is still](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-70-320.jpg)
![CHAPTER 6. CASE STUDY: LIVEJOURNAL 65
used in LiveJournal along with the new style system S2 because not all users have
updated their journals to S2. [42][6]
S2 is an object oriented programming language which therefore allows declaration of
classes with member functions and variables along with normal variables and func-
tions. S2 source code is compiled into Perl and executed on the server during requests.
Some S2 functions have been specified as built-in functions and are written in Perl.
These functions form an environment which is called the S2 subsystem. S2 introduces
a new feature to programming languages called properties, which are not specific to
object or class but to a layer. Properties can be strings, integers, hex color codes,
etc. S2 includes six layers: core, i18nc (i18n is short for internationalization because
there are 18 letters between ’i’ and ’n’; letter ’c’ stands for core), layout, i18n, theme
and user (Figure 6.1). Each layer has a specific meaning and some of them inherit
functions, variables and properties from other layers. [42][6]
All S2 layers have a different purpose and they are listed on the following list [42]:
¤
core is the root layer. It gives default implementation to all classes and member
functions specific to the whole website.
¤
i18nc is core’s internationalization layer. The core itself is in one language and
every i18nc layer adds one new language to it. This can be done by overrid-
ing the textual string properties in the core simply by just translating them to
another language.
¤
layout specifies one particular layout. In other words it describes how the pages
should look like. layout is a subclass of core and as in other object oriented
languages, in S2 new member functions and variables can be added while in-
troducing new properties and overriding old member functions and variables.
¤
i18n is a subclass of layout. Like i18nc is to core, i18n is to layout. In other
words every i18n file adds one new language to the layout layer.
¤
theme is also a subclass of layout. Its meaning is to provide a set of suggested
values for layout’s properties. It is mainly used to provide color themes but also
other properties can be overridden.
¤
The user layer also inherits layout’s functionality. It is meant to store user’s
preferences.](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-71-320.jpg)
![CHAPTER 6. CASE STUDY: LIVEJOURNAL 66
usertheme i18n
i18nc layout
core
Figure 6.1: Hierarchy of S2 layers.
S2 also offers a method for documentation within the source code. After every func-
tion, variable, property and header of class there is the possibility to enter a small
chunk of text to describe its meaning or functionality. From these pieces of text a
short documentation can be generated automatically. Another feature S2 provides is
a web user interface which allows users to easily change the values of their layout’s
properties. [42]
6.5 Mobile Friendly Features
Amongst the huge number of LiveJournal users there are also users who own mobile
devices and would like to use the service also with these devices. That was the prob-
lem we started to work on, how to get the site’s content suitable also for devices with
a smaller display. This section describes how the mobile devices are recognized with
the use of a user agent string, how layout issues were solved, what kind of problems
we encountered during the process, and what were the results on implementing the
mobile friendly version of LiveJournal.
6.5.1 User Agent Recognition
The first thing on our way towards a mobile friendly LiveJournal is to determine
whether a device requesting a webpage is a mobile device or a regular desktop com-
puter. Next we needed to find out a suitable place to do this. Because LiveJournal is](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-72-320.jpg)
![CHAPTER 6. CASE STUDY: LIVEJOURNAL 67
1 my $user_screen_size = undef;
2 $useragent = CGI::user_agent();
3 foreach $key (@screensizekeys) {
4 if($useragent =~ $key) {
5 $user_screen_size = $screensizes{$key};
6 last;
7 }
8 }
9 return $user_screen_size;
Figure 6.2: Finding device’s display dimensions based on the user agent string.
divided in two sections, basic pages and journal pages, we actually need to find two
different places to detect devices. For basic pages this place would be the beginning
of each page i.e. each BML file and for journal pages it would in the file S2.pm in
the function make_journal(), where it is decided which kind of journal will be
shown.
The actual recognition of mobile devices is done in mobile.pl by function isMobi-
leUser() which then calls function screenSize(). First the user agent string
of a device is acquired by using function user_agent() from the Perl’s CGI mod-
ule. (Figure 6.2). Next we compare the acquired user agent string against known
mobile device identifiers which are located in a table called @screensizekeys. If
a matching identifier is found during the search process, we stop searching and return
the corresponding screen size. On the other hand, if none is found, the device in ques-
tion is either an undefined mobile device or a regular desktop computer and we return
undefined value. [14]
@screensizekeys is a table structure which has regular expressions as values.
These regular expressions work as keys to a hash called %screensizes which
holds the actual width and height values of devices’ display dimensions (Figure 6.3).
The regular expressions either match to individual devices, a group of devices (e.g. all
Series 60 mobile phones) or to some more general identifier like an operating system
or a web browser. [14]
The order of the @screensizekeys table is crucial. First needs to come individual
identifiers (Figure 6.3, line 1), then more general identifiers like device groups (lines
2-3) and finally “global” identifiers like operating systems (line 4). If the table would
not be arranged in correct order, e.g. some device could be matched by its unique
identifier and it could also be matched by its operating system. Because one regular
expression may be matched only with one dimension value, it is not guaranteed that
the more general identifiers will give the right dimensions for devices, i.e. identifiers](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-73-320.jpg)
![CHAPTER 6. CASE STUDY: LIVEJOURNAL 68
1 my @screensizekeys = (".*?IndividualDevice.*?",
2 ".*?Series ?60.*?",
3 ".*?Series ?90.*?",
4 ".*?Symbian ?OS.*?");
5 my %screensizes;
6 $screensizes{".*?IndividualDevice.*?"} =
7 {"width" => 240, "height" => 180};
8 $screensizes{".*?Series ?60.*?"} =
9 {"width" => 176, "height" => 208};
10 $screensizes{".*?Series ?90.*?"} =
11 {"width" => 640, "height" => 320};
12 $screensizes{".*?Symbian ?OS.*?"} =
13 {"width" => 176, "height" => 208};
Figure 6.3: Table and hash for known mobile device identifiers.
like operating system and web browser are used more as a fall-back, a guess, if no
individual identifiers for devices are found. The order of the %screensizes hash
is not so important because Perl randomizes hashes anyway for better performance.
The only reason keeping it in the same order with @screensizekeys table is that
it is easier to maintain. [14]
Adding new devices has been made easy. First you have to know the user agent string
of the device you are adding, e.g. lets add device with user agent string Mozilla/4.51
(compatible; Opera 3.62; IndividualDevice; 240x180). In this particular case a suit-
able regular expression for the user agent string would be “.*?IndividualDevice.*?”.
Because the identifier in question is individual it should be placed at the beginning of
the table, before device groups and “global” identifiers. Lines needed to be added are
shown in italic font in Figure 6.3.
The recognition of mobile devices is done differently on basic and journal pages.
On basic pages it is done at the beginning of each page so that a suitable layout for
the page can be chosen. For journal pages the recognition is done when creating an
individual journal page. More of where the recognition is done will be described in
sections 6.5.2 and 6.5.3 along with how the correct layout is chosen based on the
information gained from the user agent string.
6.5.2 Layout for Basic Pages
LiveJournal has two types of layouts. One is called scheme, and it creates the general
look for all basic pages using BML. The other ones are called layouts which generate
the look for individual journals using S2, one layout per one journal (This is explained](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-74-320.jpg)
![Bibliography
[1] BerliOS Developer. Fostering Open Source Development.
www: http://developer.berlios.de/. Accessed: 2004.
[2] Bos, Bert et al. CSS2 - Cascading Style Sheets, level 2 Specification.
www: http://www.w3c.org/TR/CSS21/. Accessed: October 2004.
[3] Christiansen, Tom & Torkington, Nathan. perlfaq1 - General Questions About
Perl. PerlDoc. May 1999.
www: http://www.perldoc.com/perl5.6/pod/perlfaq1.html. Accessed: June 2004.
[4] CMP Media LLC. What is Perl. The Perl Journal.
www: http://www.tpj.com/whatisperl.html. Accessed: June 2004.
[5] Copyright Website LLC. Open Source Licensing.
www: http://www.benedict.com/Digital//OSLicense.aspx. Accessed: October 2004.
[6] Danga Interactive. S2 Manual. 2003.
www: http://www.livejournal.com/doc/s2. Accessed: June 2004.
[7] Deshpande, Prabhakar. Oracle tops database market with 40% share. The Eco-
nomic Times. June 2004.
www: http://economictimes.indiatimes.com/articleshow/744324.cms. Accessed: June
2004.
[8] Fitzpatrick, Brad. The Better Markup Language. 2002.
www: http://www.livejournal.com/doc/server/bml.index.html. Accessed: June 2004.
[9] Fitzpatrick, Brad. BML - Better Markup Language.
www: http://bradfitz.com/bml. Accessed: June 2004.](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-90-320.jpg)
![BIBLIOGRAPHY 85
[10] Fitzpatrick, Brad. Copy of lj_maintenance post..... LiveJournal: lj_backend.
May 2004.
www: http://www.livejournal.com/community/lj_backend/3659.html. Accessed: June
2004.
[11] Forum Nokia. Image Upload Server API Version 1.1. February 2003.
www: http://www.forum.nokia.com/documents. Accessed: October 2004.
[12] Heliö, Jaana. Requirements Engineering When Collaborating With Open Source
Projects. Master’s Thesis, Tampere University of Technology. July 2004.
[13] Johnson, Kim. A Descriptive Process Model for Open-Source Software Devel-
opment. Master’s Thesis, The University of Calgary. June 2001.
www: http://sern.ucalgary.ca/students/theses/KimJohnson/thesis.htm. Accessed:
July 2004.
[14] Kumpu, Niko & Poutanen, Ilkka & Rannikko, Jerome. Providing Mobile
Friendly Web Services -Implementing Mobile LiveJournal-. May 2004.
www: http://mummola.cs.tut.fi/files/livejournal/. Accessed: June 2004.
[15] Lerdorf, Rasmus & Tatroe, Kevin. Programming PHP. O’Reilly & Associates,
Inc. March 2002. First edition.
[16] LiveJournal. Features by Account Type.
www: http://www.livejournal.com/site/accounts.bml. Accessed: June 2004.
[17] LiveJournal. LiveJournal.com.
www: http://www.livejournal.com/. Accessed: June 2004.
[18] LiveJournal. Senior Staff.
www: http://www.livejournal.com/press/staff.bml. Accessed: June 2004.
[19] LiveJournal. Statistics.
www: http://www.livejournal.com/stats.bml. Accessed: June 2004.
[20] livejournal.org. Hackers.
www: http://goathack.livejournal.org/hackers.cgi. Accessed: June 2004.
[21] livejournal.org. LiveJournal.org.
www: http://www.livejournal.org/. Accessed: June 2004.](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-91-320.jpg)
![BIBLIOGRAPHY 86
[22] Mediratta, Bharat. The high level architecture diagram of Gallery 2.. February
2004.
www: http://gallery.menalto.com/modules.php?op=modload&name=gallery&file=
index&include=albums.php. Accessed: November 2004. The architecture diagram is in
Miscellaneous album.
[23] Mediratta, Bharat et al. Gallery 2.x Developer’s Guide.
www: http://gallery.menalto.com/. Accessed: October 2004.
[24] MySQL AB. The World’s Most Popular Open Source Database.
www: http://www.mysql.com/. Accessed: July 2004.
[25] Netcraft Ltd. June 2004 Web Server Survey. June 2004.
www: http://news.netcraft.com/archives/2004/06/06/june_2004_web_server_survey.
html. Accessed: July 2004.
[26] Nokia. Forum Nokia - Developers Resources.
www: http://www.forum.nokia.com/. Accessed: September 2004.
[27] Ohrt, Monte & Zmievski, Andrei & Mohr, Messju. Smarty template engine
homepage.
www: http://smarty.php.net/. Accessed: September 2004.
[28] Open Source Directory - OSDir.com. Stable, Open Source Apps.
www: http://osdir.com. Accessed: July 2004.
[29] Open Source Initiative (OSI). The Approved Licenses.
www: http://www.opensource.org/licenses/. Accessed: July 2004.
[30] Open Source Initiative (OSI). The Open Source Definition.
www: http://www.opensource.org/docs/definition.php. Accessed: July 2004.
[31] Open Source Technology Group (OSTG). License Breakdown.
www: http://freshmeat.net/stats/. Accessed: July 2004.
[32] Open Source Technology Group (OSTG). OSI Approved Licenses.
www: http://sourceforge.net/softwaremap/trove_list.php?form_cat=14. Accessed:
July 2004.
[33] Opera. Opera Mobile Accelerator.
www: http://www.opera.com/products/smartphone/accelerator/. Accessed: October
2004.](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-92-320.jpg)
![BIBLIOGRAPHY 87
[34] Opera. Opera’s Small-Screen Rendering.
www: http://www.opera.com/products/smartphone/smallscreen/. Accessed: October
2004.
[35] PGTS Pty. Ltd.. List of User Agent Strings. May 2004.
www: http://www.pgts.com.au/pgtsj/pgtsj0208c.html. Accessed: July 2004.
[36] Raymond, Eric S. The Cathedral and The Bazaar. May 1997.
www: http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/. Ac-
cessed: July 2004.
[37] Schwartz, Randal L. & Christiansen, Tom. Learning Perl. O’Reilly & Associ-
ates, Inc. July 1997. Second edition.
[38] Shor, Nathan. Entertainment: Blog this!. La Voz Online. January 2004.
www: http://www.lavozdeanza.com/vnews/display.v/ART/2004/01/26/4015b75fb498b/.
Accessed: June 2004.
[39] Sonera. Sonera Nettinopeutin - mobile browsing accelerator.
www: http://www.sonera.fi/matkapuhelin/nettinopeutin/. Accessed: October 2004.
[40] WAP Forum. WAP Forum Specifications.
www: http://www.wapforum.org/what/technical.htm. Accessed: October 2004.
[41] Webopedia. Perl. March 2004.
www: http://www.webopedia.com/TERM/P/Perl.html. Accessed: June 2004.
[42] Wikipedia. S2 programming language.
www: http://www.free-definition.com/S2-programming-language.html. Accessed: June
2004.
[43] W3C HTML Working Group. XHTML Basic.
www: http://www.w3.org/TR/xhtml-basic/. Accessed: October 2004.
[44] W3C HTML Working Group. XHTML 1.0 The Extensible HyperText Markup
Language.
www: http://www.w3.org/TR/xhtml1/. Accessed: October 2004.
[45] ZyTrax, Inc. Mobile Browser ID (User-Agent) Strings. July 2004.
www: http://www.zytrax.com/tech/web/mobile_ids.html. Accessed: October 2004.](https://image.slidesharecdn.com/ec3e11de-3520-4bd1-849a-2d7b495fa7d4-160426183103/85/Mobile-Friendly-Web-Services-Thesis-93-320.jpg)
Mobile Friendly Web Services - Thesis
- 1. TAMPERE UNIVERSITY OF TECHNOLOGY Department of Information Technology NIKO KUMPU & JEROME RANNIKKO MOBILE FRIENDLY WEB SERVICES Master of Science Thesis Topic accepted in the department council meeting on 18 ¢¡ August 2004. Examiners: Prof. Ilkka Haikala (TUT) Lic.Tech. Jari Mononen (Nokia)
- 2. Acknowledgements This thesis has been done as part of a research project at Tampere University of Tech- nology and was funded by Nokia. We would like to thank Professor Ilkka Haikala for his guidance and support during the writing of this thesis. We would also like to thank Jari Mononen from Nokia for his feedback and comments regarding our work. Special thanks go to the third member of our project team, Ilkka Poutanen, for his significant contribution to the Gallery case study. Our gratitude also goes to Kathryn Williams for proofreading our thesis. Finally, we would like to thank everybody who has in some way helped us during the writing of this thesis. Tampere, 24 £¡ November 2004 Niko Kumpu Jerome Rannikko mobile: +358 40 7573 205 mobile: +358 41 5020 789 email: [email protected] email: jerome.rannikko@iki.fi
- 3. iii TAMPERE UNIVERSITY OF TECHNOLOGY Department of Information Technology Institute of Software Systems KUMPU, NIKO and RANNIKKO, JEROME: Mobile Friendly Web Services Master of Science Thesis, 87 pages Examiners: Prof. Ilkka Haikala (TUT) and Lic.Tech. Jari Mononen (Nokia) Funding: Nokia December 2004 Keywords: Internet, mobile friendliness, open source Most new mobile phones and PDAs include a possibility to access the Internet with the device’s own or a third-party XHTML browser. However, small displays and slow Internet connections are a problem. These complicate browsing and especially pages containing images download slowly. A mobile friendly web service offers the users of mobile devices the same service than for the desktop computer users, but in a form that is suitable for mobile user agents. In practise this means recognizing the mobile devices, scaling down the images, and altering the page layout, so that they fit on the narrow screen of a mobile device. In this thesis the concept of mobile friendliness is defined and modifying existing software to become mobile friendly is studied in practise. Two programs, Gallery and LiveJournal, are used as examples. Gallery is a popular web server based photo gallery software programmed in PHP. LiveJournal is written in Perl and provides over one million of its users with the possibility to publish an online diary. Both programs are distributed under the GPL open source license, which means that their source code is publicly available and can be freely modified. Modifications necessary for mobile friendliness were made in both Gallery and Live- Journal. The programs were modified so that they recognize mobile devices and present the content in a form suitable for them. In addition, support for the Image Uploader functionality found in some Nokia mobile phone models was implemented for Gallery. The modified programs were made available on the homepage of this project and the Image Uploader support was included in the official Gallery release.
- 4. iv TAMPEREEN TEKNILLINEN YLIOPISTO Tietotekniikan osasto Ohjelmistotekniikka KUMPU, NIKO ja RANNIKKO, JEROME: Mobiiliystävälliset www-palvelut Diplomityö, 87 sivua Tarkastajat: prof. Ilkka Haikala (TTY) ja tekn.lis. Jari Mononen (Nokia) Rahoittaja: Nokia Joulukuu 2004 Avainsanat: Internet, mobiiliystävällisyys, avoin lähdekoodi Useimmat uudet matkapuhelimet ja PDA-laitteet sisältävät mahdollisuuden käyttää Internetiä joko laitteiden omilla tai kolmannen osapuolen XHTML-selaimilla. Ongel- mia aiheuttavat kuitenkin laitteiden pienet näytöt ja hitaat Internet-yhteydet. Näistä johtuen selaaminen on vaivalloista ja varsinkin kuvia sisältävien sivujen lataaminen hidasta. Mobiiliystävällinen www-palvelu tarjoaa sekä mobiililaitteen että tietoko- neen käyttäjälle saman palvelun. Mobiileille päätelaitteille palvelun sisältö esitetään niille sopivassa muodossa. Käytännössä tämä tarkoittaa mobiililaitteiden tunnistamis- ta sekä kuvien pienentämistä ja sivujen rakenteen muuttamista siten, että ne mahtuvat mobiililaitteen kapealle näytölle. Tässä diplomityössä määritellään mobiiliystävällisyyden käsite ja tutkitaan käytän- nössä valmiiden ohjelmistojen muokkaamista mobiiliystävällisiksi. Esimerkkeinä käy- tetään Gallery ja LiveJournal -ohjelmistoja. Gallery on suosittu PHP-kielellä ohjel- moitu www-palvelimella toimiva valokuvagalleria. LiveJournal on Perl-kielellä kir- joitettu ohjelmisto, joka tarjoaa yli miljoonalle käyttäjälleen mahdollisuuden julkais- ta päiväkirjaa Internetissä. Molemmat ohjelmistot on julkaistu avoimen lähdekoodin GPL-lisenssillä, minkä johdosta niiden lähdekoodit ovat julkisesti saatavilla ja va- paasti muokattavissa. Esimerkkiohjelmistoihin toteutettiin mobiiliystävällisyyden vaatimat muutokset. Oh- jelmia muokattiin niin, että ne tunnistavat mobiililaitteet ja muokkaavat sisällön niille sopivaan muotoon. Lisäksi Galleryyn toteutettiin tuki joissakin Nokian matkapuhelin- malleissa olevalle Image Uploader -toiminnolle. Muokatut ohjelmistot laitettiin saa- taville projektin kotisivulle ja Image Uploader -tuki saatiin osaksi Galleryn virallista jakeluversiota.
- 5. Contents 1 Introduction 1 2 The Internet and Mobile Devices 4 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Specialized content . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 XHTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.4 Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.5 Images and Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . 10 3 Mobile Friendly Features 11 3.1 Mobile Friendliness Is Needed . . . . . . . . . . . . . . . . . . . . . 11 3.2 Recognizing Mobile Devices . . . . . . . . . . . . . . . . . . . . . . 12 3.3 Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.4 Images and Bandwidth . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.5 Mobile Friendly Web Services . . . . . . . . . . . . . . . . . . . . . 18 4 Open Source Software 20 4.1 The Open Source Definition . . . . . . . . . . . . . . . . . . . . . . 20 4.2 Popular Open Source Licenses . . . . . . . . . . . . . . . . . . . . . 23 4.3 OSS Projects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 4.4 Development of OSS . . . . . . . . . . . . . . . . . . . . . . . . . . 28 5 Case Study: Gallery 31 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.2 Programming Languages . . . . . . . . . . . . . . . . . . . . . . . . 32 5.2.1 PHP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 5.2.2 Smarty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.2.3 SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.3 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 5.3.1 Gallery 1.x . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5.3.2 Gallery 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
- 6. CONTENTS vi 5.4 Community . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 5.5 Mobile Friendly Features . . . . . . . . . . . . . . . . . . . . . . . . 41 5.5.1 User Agent Recognition . . . . . . . . . . . . . . . . . . . . 42 5.5.2 Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 5.5.3 Images . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 5.5.4 Image Upload Module . . . . . . . . . . . . . . . . . . . . . 51 5.6 Summary of Gallery Experiences . . . . . . . . . . . . . . . . . . . . 57 6 Case Study: LiveJournal 59 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 6.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 6.3 Developers & Communities . . . . . . . . . . . . . . . . . . . . . . . 61 6.4 Programming Languages . . . . . . . . . . . . . . . . . . . . . . . . 62 6.4.1 Perl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 6.4.2 BML - Better Markup Language . . . . . . . . . . . . . . . . 63 6.4.3 S2 - Style System 2 . . . . . . . . . . . . . . . . . . . . . . . 64 6.5 Mobile Friendly Features . . . . . . . . . . . . . . . . . . . . . . . . 66 6.5.1 User Agent Recognition . . . . . . . . . . . . . . . . . . . . 66 6.5.2 Layout for Basic Pages . . . . . . . . . . . . . . . . . . . . . 68 6.5.3 Layout for Journal Pages . . . . . . . . . . . . . . . . . . . . 74 6.6 Summary of LiveJournal Experiences . . . . . . . . . . . . . . . . . 78 7 Conclusions 81
- 7. Chapter 1 Introduction The Internet today is an essential source of both information and entertainment for many people. Every day we use it for various purposes such as to check the weather forecast, to see what is on television in the evening, to book a holiday, or just send an email to a friend or a colleague. The Internet also has an increasing importance within our work places, both as an information resource and as a communication channel. An increasing number of people have a mobile phone or a PDA (Personal Digital Assistant) with an Internet connection and a browser. The combination of the Internet and a mobile device has great potential, and immediately suggests several possible use scenarios: sending email wherever you want to, getting driving instructions to your mobile device while on the road, reading timetables, or checking the latest additions to the family’s picture gallery on your way to work. All this and more could be done with your mobile phone or a PDA away from you desktop computer. These visions are examples of a mobile friendly Internet as we would like to see it. By mobile friendly we mean that the users have essentially the same user experience of a website whether they are using a desktop browser or a mobile browser to access the resource. From a wider perspective mobile friendliness can also mean having a totally different way of implementing a web service or part of it. For example, an image gallery could provide an email address instead of a web form for mobile users to upload their images. Unfortunately, there are some major problems between the current situation and the mobile friendly Internet we envision. These problems range from the websites them- selves through to the mobile networks and the mobile devices.
- 8. CHAPTER 1. INTRODUCTION 2 The first major problem is the combination of the small screens on mobile devices and the layouts of many webpages. Most layouts are designed for the big screens of desktop computers without considering the restrictions of mobile user agents. When browsing these sites with a mobile device, the pages usually need to be scrolled both horizontally and vertically, which makes the use of the site difficult and inconvenient for the user. Another issue is the images on webpages. Most of the time images are far too wide and tall to fit on the small screen of a mobile device. This again forces the user to scroll the page in both dimensions to view the whole picture. If the visible dimensions of an image are large, this implies that the file size will also be large. Considering the limited bandwidth of mobile networks, big image files make page downloads slow. One option for mobile browsers is not to download images on webpages at all. This does enable the device to render the page faster but it might also make the page hard to understand, for example if the images are navigational links. Some browsers auto- matically scale the images to fit on the screen but this takes even more time and uses more processing power. In order to provide mobile friendly web services we first need to be able to recognize mobile user agents. This can be done based on the user agent string that the browser sends with the request for a webpage. The user agent string usually consists of at least the browser’s name and version, operating system, language, and, in the case of mobile user agents, usually the device model and make. Based on this information we can usually know or at least make an educated guess as to the screen size of the device. The next step is to make the page suitable for the small screens. This involves scaling the images and altering the layout. When building our site using modern web stand- ards such as Extensible Hyper Text Markup Language (XHTML) and Cascading Style Sheets (CSS), achieving mobile friendliness may be easier than we think. XHTML has a strict syntax which makes it easy for mobile browsers to parse it. With CSS we can define different layouts and styles for mobile and desktop users. When we add to this image scaling and avoid using tables where possible, we are making our site quite accessible for mobile users without compromising our other visitors’ browsing experience. Using open source software allows us to experiment with our ideas and put them into practise in an existing system. Open source software means, essentially, that you have access to the program’s source code and the program is available for free. You can
- 9. CHAPTER 1. INTRODUCTION 3 modify the code and redistribute it if you wish. There are different licenses that have different restrictions on what you can do and how. One of the most popular licenses is GPL (GNU General Public License) which allows you to modify the code, use it as part of your own program and even sell it. However, GPL requires that if you sell your program you must supply the source code with it, and the source code also has to be available for free for anybody who is interested. In this thesis we will explain in detail what exactly is mobile friendliness and why the current Internet, for the most part, is not mobile friendly. Then we will use two open source projects, Gallery and LiveJournal, to demonstrate how existing software can be modified to achieve mobile friendliness. Gallery is a very popular web image gallery software and LiveJournal is a popular weblogging service with millions of users. We add to these software products functionality to recognize mobile user agents, and based on that, alter the layout and scale images. For the image gallery we will also build a support for Nokia’s Image Uploader, which enables phone owners to upload images directly from their camera phones straight to their Gallery account. Chapter 2 looks into the current situation regarding the browsing experience when using the Internet with a mobile device. In Chapter 3 we define mobile friendliness and some basic principles and view points that need to be considered when designing a mobile friendly website. This chapter also explains how open source is relevant to mobile friendliness. Chapter 4 is a short introduction to open source software, its different licenses and development models. Chapter 5 is a case study of an open source image gallery software called Gallery. Gallery was chosen for our case study because of the association between camera phones and web image gallery. We work with two versions of Gallery, Gallery 1 and Gallery 2, and in this chapter we describe their architecture, the differences between these versions, and how they work. An important part of this chapter is to show how we made Gallery mobile friendly and added the Nokia Image Uploader support to it. In Chapter 6 we present our other case study: LiveJournal weblogging software. Today weblogging, or blogging, is a popular way to preserve your memories and daily events. It is similar to keeping a diary or journal but it is done over the Internet. Obviously, being able to do this with your mobile phone or PDA would be a benefit. This chapter explains how we added mobile friendly features to LiveJournal. Chapter 7 summarizes our work in this thesis. In this chapter we also offer some conclusions and share the experiences we learned while working on this project.
- 10. Chapter 2 The Internet and Mobile Devices The Internet offers us many useful services that make our lives easier and that we use daily. Many people have mobile phones with an Internet connection, which in theory enables us to use these services whenever and wherever we like. In practise, it is often quite different. This chapter takes a closer look at the mobile browsing experience, the problems we encounter, the reasons behind them, and some of the solutions that are used to try to make things work better. 2.1 Overview Some of the most useful websites available to us on the Internet include bus and train timetables, news headlines, search engines, weather forecasts, and driving instruc- tions. We can also book tickets, buy books and DVDs, check out the movie showtime listings or television program, upload a picture to the family photo gallery or update personal online journals. We use most of these services daily with our computers both at work and at home. However, many of these services are of such a nature that we often find ourselves in need of that particular resource, e.g. a timetable, but are not at our computer. Or we would like to use the time we spend every day in a bus or a train commuting to work to read the news headlines or to book a theater ticket for the evening but are not able to so because we do not have our computer and an Internet connection. However, almost all of the new mobile phones are equipped with GPRS (General Packet Radio Service) and a web browser. So why not browse the web and use its
- 11. CHAPTER 2. THE INTERNET AND MOBILE DEVICES 5 services with your mobile? Unfortunately it is easier said than done. Many websites we like to use are very difficult to navigate or almost completely inaccessible with our mobiles and other handheld devices. This problem is caused by a number of reasons including the mobile browsers, the available bandwidth, and the technology used on websites. 2.2 Specialized content When an Internet connection was introduced to mobile phones it was obvious that normal Hypertext Markup Language (HTML) webpages were not suitable for these devices. Phones have many constraints compared to desktop computers which makes processing of the page content quite demanding. Mobile devices have less powerful CPUs, less memory, smaller displays, very limited input devices and restrictions on power consumption. Also, the mobile network offers, in most cases, less bandwidth and more latency than a normal modem or broadband connection on a computer. To solve the problem Nokia, Ericsson, Phone.com (then Unwired Planet) and Mo- torola founded the WAP Forum1 . Its goal was to develop a common format for Inter- net transfers to mobile phones. Since then more companies have joined WAP Forum so that it now has more than 200 members. WAP and WML The major results of the WAP Forum’s work are Wireless Application Protocol (WAP) and Wireless Markup Language (WML) [40]. WML is an Extended Markup Lan- guage (XML) application and it is used to create webpages that can be delivered to a mobile device using WAP. A WAP browser on the phone can then render the WML document to the small screen of the device. The set of tags that WML offers is very limited due to the various constraints caused by the mobile environment. WAP services are usually easy and relatively fast to use with a mobile device but there is also a downside. WAP content always needs to be specifically designed for mobile devices, which results in two problems: availability and cost. 1 WAP Forum no longer exists as an independent organization but is now part of the Open Mobile Alliance http://www.openmobilealliance.org/
- 12. CHAPTER 2. THE INTERNET AND MOBILE DEVICES 6 Let us first consider the problem of availability. Internet has millions and millions of homepages and other sites full of more or less useful information. The problem is that these pages are mostly HTML and therefore not accessible with a WAP browser. In many cases these sites are created and maintained by individuals who do it in their spare time. They do not usually have enough time or knowledge to develop a WML version of their pages as well as HTML, because that would in practise double the time and effort used to create the page. For this reason the content available for WAP users is only a marginal portion of the whole Internet. There have been some attempts to overcome this problem by translating HTML to WML. This is possible to accomplish on a single site where the page structure is well known but a general solution is a lot harder to achieve. This can be seen, for example, at Google’s WAP portal2 where they offer WML translation as part of their service. Certain kinds of page structures, such as simple news headline pages, seem to be relatively easy to automatically translate into WML. However, more complicated HTML sites translate into WML pages that are practically impossible to navigate. The second problem is cost. It is mostly the big organizations and commercial entities who have the resources to create a WAP version of their sites alongside the main HTML version. But using their resources to expand their service also means more costs for the company. Many times, unfortunately, they want to move that cost to their customers. One such example is Finland’s biggest news paper, Helsingin Sanomat, who charge a small fee for their WAP service3 although the same content in HTML is available for free. Of course not all companies work like this and for example the BBC offers a free WAP portal4 where mobile phone users can access news and some other services. 2.3 XHTML Web browsers are usually quite forgiving when it comes to following the HTML standards. If a tag is missing it does not cause a problem as long as the browser can deduce what is missing, or if there are unknown tags in the document (some browser vendors have their own extensions to HTML) the browser just ignores them. Also, browsers tolerate improperly nested elements although it is illegal according to the 2 http://wap.google.com/ 3 http://wap.hs.fi/ 4 http://www.bbc.co.uk/mobile/
- 13. CHAPTER 2. THE INTERNET AND MOBILE DEVICES 7 HTML standards. All these things have lead to many poorly written HTML pages. After all, how can web authors know their markup is wrong if the browser shows the page correctly anyway. This makes writing new browsers and keeping the old ones up to date increasingly difficult as one needs to be prepared for many different non-standard HTML markups. Another reason demanding development in HTML is the emerging of numerous new devices accessing Internet. These devices include mobile phones, PDAs, televisions, etc. which do not have the capacity of a desktop browser to parse and render the incorrect HTML. Their memory and processing capacity are so limited that parsing malformed HTML can be very resource consuming and even impossible with the simpler devices. For these reasons the World Wide Web Consortium5 (W3C) started to work on a new version of HTML that would be based on XML. The result, XHMTL 1.0 (Extens- ible HTML), was published in January 2000 [44]. XHTML 1.0 is a reformulation of HTML 4 in XML 1.0. This means that while syntactically XHTML is an XML application, its semantics are defined by HTML 4. The W3C recommendation lists twelve differences between HTML 4 and XHTML, including the following: ¤ XHTML is case sensitive. Element and attribute names must be in lower case. ¤ All elements must be properly nested, i.e. <p><em>text</em></p> instead of <p><em>text</p></em>. ¤ All elements, including empty elements, must have a closing tag. ¤ Attribute values must always be quoted. These are just the most important ones. The whole list and more detailed explanations can be read from the recommendation ([44], section 4). XHTML Basic As explained above, parsing HTML on a mobile device is very resource consuming. XHTML makes it a lot easier by removing many ambiguities and clarifying the syn- tax. XHTML Basic, published in December 2000, is the second recommendation in 5 http://www.w3c.org/
- 14. CHAPTER 2. THE INTERNET AND MOBILE DEVICES 8 the W3C’s series of XHTML specifications and it takes XHTML yet one step closer to the requirements of web clients with limited capabilities. The specification describes itself with the following: "The XHTML Basic document type includes the minimal set of modules required to be an XHTML host language document type and in addition it includes images, forms, basic tables, and object support. It is designed for Web clients that do not support the full set of XHTML features; for example Web clients such as mobile phones, PDAs, pagers, and set-top boxes. The document type is rich enough for content authoring." [43] XHTML Basic combined with Cascade Style Sheets (CSS) [2] allows the web author to create versatile pages with the added benefit that they look good not only on a com- puter screen but also work well when accessed with a mobile device. This becomes very important if the site is meant for use with both desktop browsers and mobile user agents, as there is no need to create two different versions of the page. 2.4 Layout Page layout is one of the major problems with many websites when accessing them with a mobile user agent that has a small screen. It is very difficult for the users to read a page when they need to scroll in every direction to see the whole page. Tables One big reason behind the problems with layout is the use of tables. Tables are usually slow to render, especially if they are nested, as the whole table definition must be read before it can be properly presented. This prevents incremental rendering, which is inconvenient for the user. This is a major usability concern that should be noted by everyone making websites for general Internet users. When tables are used for the purpose they are meant for – to present tabular data – they are not a problem but when tables are used to do the page layout it means trouble. In addition to usability, one big concern is the mixing of presentational markup with content. For the sake of different user agents (e.g. screen readers for the blind, mobile devices) and maintainability, web designers should use semantic markup. Semantic markup means making a clear difference between the content and the presentation. The
- 15. CHAPTER 2. THE INTERNET AND MOBILE DEVICES 9 markup, (X)HTML, describes the content – what it is and what is its role in the doc- ument. The presentation, how the data should be displayed to the user, is explained with CSS. Separating presentation from content makes it easier to maintain and up- date the site as changes in the outlook can be made in one or just a few files instead of editing tens or hundreds of them individually. Partial Solutions Semantic markup with media dependent CSS offers an easy way to alter the layout based on the user agent. One can define several different style sheets for one document by using the media attribute of the HTML link element. The media attribute has many possible values including screen, print, handheld, and all. Unfortunately not all mobile browsers support the media attribute. For mobile users there is some help available even when the site’s design does not acknowledge them in any way. There are several browsers for mobile phones and PDAs that try to render the page so that it fits on the small screen of the device and is still readable. Opera software’s solution is a technology called Small Screen Rendering (SSR) [34]. Its main concern is to avoid horizontal scrolling and this is achieved by using several different techniques. If the layout uses columns and they are too wide to fit on the screen side by side, they are merged into one in the document order (the order in which the elements appear in the page source code). Big images do not work well on the small screen so they are either scaled down or removed altogether. Background images are not shown and SSR also adjusts the fonts so that only three different sizes are used in order to improve readability. Based on our experiences and given the wide variety of different webpages, SSR works quite well while still not being the ideal solution to access the Internet with mobile devices. There are many other similar approaches to solve the problem. For example Access6 has an embedded browser for mobiles called NetFront. It uses its own Smart-Fit technology to adapt pages on a small screen. 6 http://www.access-us-inc.com/
- 16. CHAPTER 2. THE INTERNET AND MOBILE DEVICES 10 2.5 Images and Bandwidth Images on webpages can be a real annoyance for the mobile user. The issue is the size of the images, in terms of both pixels and bytes. An image that looks good on the desktop browser does not fit on the small screen of a mobile device and forces the user to scroll in every direction. Also, as previously mentioned, the mobile bandwidth is very limited and downloading of a single image, let alone several images, takes a long time. What makes the problem worse is the fact that the first solution that comes into mind, turning off image downloads, is not always feasible. Sometimes images are used for important functions on webpages such as navigation buttons or menu items. Without those images the whole page is useless, but with the useful images can come many unwanted and unnecessary graphics. This slows the download speeds to an unbearable level or just makes reading the page very hard on a small screen. Mobile networks currently offer very limited bandwidth compared to that of the broad- band or even the modem Internet connection of a desktop PC. This causes page downloads to the mobile browser to be slow, which is quite inconvenient for the user. Again, webpages designed specifically for mobile users usually download fast, but these pages represent only a tiny portion of the potentially interesting pages available on the whole Internet. Many mobile operators and other companies offer services de- signed to help users to improve their mobile browsing experience by compressing and caching data. Examples of such services include Sonera’s Nettinopeutin and Mobile Accelerator from Opera Software. The Finnish mobile operator Sonera has a service called Nettinopeutin [39] (web accelerator) that promises three to four times faster downloads on average. Net- tinopeutin works by reducing the image quality, blocking GIF-animations and com- pressing all the data. This service does not require any program to be installed on the device and is free for Sonera GPRS customers. Opera Software, who are best known for their web browser, have a Mobile Accelerator service [33]. It reduces the size of webpages by approximately 50-70% by optimizing code, compressing data, and removing unnecessary content. Mobile Accelerator is a commercial service, prices start from 6.90 euros for three months.
- 17. Chapter 3 Mobile Friendly Features The term mobile friendly will be used in the following chapters. It is derived from user friendly and it means how easy it is to use a webpage and how nice the browsing experience is for the user of a mobile browser. A website is mobile friendly when it provides the mobile users with the same service than the desktop users and offers an easy user interface. To offer mobile users a mobile friendly experience we need to take following things into consideration: device recognition, content scaling, and webpage structure modifications. In addition, to achieve a superb mobile browsing experience, new styles and layouts for mobile devices need to be implemented. 3.1 Mobile Friendliness Is Needed Mobile friendly features offer users a much better browsing experience than what it would be without these features. With mobile friendly features users do not have to scroll webpages in both horizontal and vertical directions. Scrolling in both directions would sooner or later become uncomfortable because users would get lost while trying to view the content from a small “window”. Mobile friendliness provides a way where only vertical scrolling is needed, which is the case also with regular desktop browsers, at least when the website is not poorly designed or implemented. Nowadays an increasing number of the released mobile devices have the capability to show XHTML content. In other words, mobile devices have a GPRS connection and either they have an XHTML browser or one can be downloaded and installed. There- fore, the group of potential people wanting to access web services with their mobile
- 18. CHAPTER 3. MOBILE FRIENDLY FEATURES 12 devices is becoming too big to be ignored by web service designers. Furthermore, all the time new people are becoming aware of the possibilities that mobile devices offer, and therefore the number of potential users is increasing with a rapid rate. Unfortu- nately, there are not many websites that support mobile devices in a way we would like them to. Mobile phones travel with their owners, so wherever they go their phones will follow. This is one very essential reason why mobile friendliness is needed. With mobile friendly features it is easier for users to keep track of their daily events, for example by writing them down to a weblog or uploading images taken with their camera phones to an online gallery. These and many other similar services already exist in the Internet but the problem is that only a tiny fraction of them provide a mobile friendly user interface. 3.2 Recognizing Mobile Devices In order to enable mobile friendly features we must first be able to determine when a mobile device is present, i.e. when the device requesting a webpage from our server is a mobile device. One way to do this is to use device’s user agent string as an identifier. The user agent string is a string of text containing information about the device, such as operating system, platform, used browser, and localization. Also, other details can be inserted into the user agent string. Some mobile devices may even include their display dimensions in pixels. Table 3.1 lists some user agent strings of different mobile and desktop browsers. Most user agent strings in the table were acquired from the Internet [35][45] and others by manually checking them with mobile phones. Knowing just the user agent string is obviously not enough to activate mobile friendly features. Display dimensions is another important step on our way towards mobile friendly web services. We need to know the display dimensions of those mobile devices that we want to support on our website. There are a few ways to find out display dimensions of different devices. If dimensions are not included in the user agent string, which seems to be the case most of the time, they can usually be found from the device manufacturer’s homepage. When we have both the user agent string and the display dimensions of a mobile device we will need to map them together. This can be done best by using a tabular data structure where user agent strings are keys to the corresponding display dimensions.
- 19. CHAPTER 3. MOBILE FRIENDLY FEATURES 13 Table 3.1: User agent strings of various devices. Device Browser User Agent String Nokia 3650 phone’s Nokia3650/1.0 SymbianOS/6.1 Series60/1.2 browser Profile/MIDP-1.0 Configuration/CLDC-1.0 Nokia 7610 phone’s Nokia7610/2.0 (4.0421.4) SymbianOS/7.0s Series60/2.1 browser Profile/MIDP-2.0 Configuration/CLDC-1.0 Nokia 7700 Opera Mozilla/4.0 (compatible; MSIE 5.0; Symbian OS; Series 90) Opera 6.0 [en] Sony Ericsson T610 phone’s SonyEricssonT610/R201 Profile/MIDP-1.0 browser Configuration/CLDC-1.0 Sony Ericsson P900 phone’s SonyEricssonP900/R101 Profile/MIDP-2.0 browser Configuration/CLDC-1.0 Pocket PC PocketIE Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; PPC; 240x320) PC w/Linux Opera Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux i686) Opera 7.23 [en] PC w/Windows XP Mozilla Mozilla/5.0 (Windows; U; Windows NT 5.1; Firefox rv:1.7.3) Gecko/20041001 Firefox/0.10.1 The user agent string holds a lot of information and therefore we do not need to use the whole string as a key. Instead, we could use regular expressions to rep- resent the user agent strings. Regular expressions are special text strings for de- scribing search patterns. Plenty of information on regular expressions is available on the Internet1 . A Regular expression could cover only the part of a user agent string that is needed to uniquely identify a device. For example, a regular expression “.*?Nokia3650.*?” matches only with user agent strings containing the string “Nokia3650”. Furthermore, if we look at user agent strings in Table 3.1, we see a pat- tern emerging, at least, when Nokia’s Series 60 phones (Nokia 3650 and Nokia 7610) are considered. For example, the regular expression string “.*?Series ?60.*?” matches to all Nokia’s Series 60 mobile phones This is a good way to reduce the number of needed regular expressions. All Nokia’s Series 60 phones can be grouped together because they all have the same display dimensions (176 pixels wide and 208 pixels tall screen). Instead of using individual identifiers for all Series 60 phones we are able to use just one identifier for the whole group. It is possible to use even more general identifiers, such as the operating system and browser. These “default” iden- tifiers should only be used as a fall-back, i.e. if some device’s identifier is not on the list, we can take a guess based on its operating system. For example many Series 60 mobile phones use Symbian OS and therefore a suitable fall-back regular expression string for them would be “.*?Symbian ?OS.*?”. 1 http://www.regular-expressions.info/
- 20. CHAPTER 3. MOBILE FRIENDLY FEATURES 14 At this point we have individual, group and “global” identifiers for different devices. These identifiers should be placed in a table structure in an order where first comes the individual identifiers and then the more general identifiers. This is necessary (if the table is searched from beginning to end without any wiser algorithms) because in the case of a “global” identifier coming first, it would likely match with a huge number of devices. Furthermore, this would result in errors because not all devices, e.g. devices using Symbian OS, have the same display dimensions. Another reason for keeping the identifiers in a strict order is that groups may have exceptions, i.e. not all devices belonging to a certain group necessarily have the same display dimensions, and therefore the group identifiers must not come before the individual identifiers. Based on the ideas given above the actual process of identifying a mobile device and sending suitable content back to it would be something like the following (Figure 3.1 illustrates the process): Figure 3.1: Adjusting content based on recognized devices.
- 21. CHAPTER 3. MOBILE FRIENDLY FEATURES 15 1. The device requests a webpage from the server. 2. The server finds out device’s user agent string. 3. The server tries to match the user agent string against known identifiers. 4. The server chooses suitable layout to use based on the results from the user agent string matching. 5. The server sends the webpage to the device. 3.3 Layout Usually the basic layout structure of a webpage is a narrow pane on the left edge of the page for menu items, and the rest of the screen is occupied by the actual con- tent. Sometimes there may also be another narrow pane on the right edge of the page containing possibly more menu items, a poll, links, site related news, etc. Figure 3.2 shows a typical layout with three panes. It is a screenshot from an open source CMS (Content Management System) software called Mambo Open Source. To show this kind of pages on mobile devices it is necessary to divide the page into two or three sections. The main content forms one section and the panes on the sides of the page form the other, one or two, sections depending on the situation. In cases where only Figure 3.2: Front page of Mambo and its three-column layout.
- 22. CHAPTER 3. MOBILE FRIENDLY FEATURES 16 one section besides the main content is desired, left and right panes can be tiled one above another to form that one section. Mobile devices come with varying sized displays. Table 3.2 lists dimensions of multiple devices measured in pixels. As can be seen from the table, the smallest devices have a very small screen compared for example to a regular desktop monitor. Nokia’s Series 60 mobile phones have only 176 pixels wide display, which is just about a quarter from the standard VGA resolution (Video Graphic Array resolution is 640x480 pixels). Due to the variable display sizes, the designed layout must be flexible in a way that it can smartly fill the available area given to it regardless of the display width. Some mobile browsers have built-in functionality (e.g. Opera’s Small Screen Render- ing) that tries to alter the structure of a webpage so that it would fit to the display and still be legible. We could say this is “filling the available area somewhat smartly and automatically”. This might be something that most website designers would want to avoid, because it can possibly destroy the designed look of their site. Therefore, web- site designers should take mobile devices into consideration when designing a layout for a website. One layout should be designed for mobile devices and one for desktop browsers, or if possible, one very flexible layout to cover them both. What does the phrase “to smartly fill the available area” really mean and how could it be done? This is one of the main questions of this project. In short, it means that users can easily view a good looking webpage in their browsers and only need to scroll the page in the vertical direction. This is what users are used to do with their desktop browsers. Rarely do they have to scroll horizontally and even then it is probably because of the inferior design of a website. Table 3.2: Display dimensions of multiple devices. Device Display Dimension (pixels) Sony Ericsson T610 128x160 Samsung SGH-P510 128x160 Samsung SGH-Z105 176x192 Nokia 3650 176x208 Nokia 7610 176x208 Sony Ericsson P900 208x320 HP iPAQ h2215 Pocket PC 240x320 Toshiba Pocket PC e800 240x320 Nokia 7700 640x320 Desktop Computer e.g. 1600x1200
- 23. CHAPTER 3. MOBILE FRIENDLY FEATURES 17 The basic idea in optimizing the screen usage is that first everything has to be squeezed into a small space and when the display size increases, the content and the elements are adjusted accordingly. Some elements, like headers and text paragraphs, are com- pressed and expanded automatically by the browser to the extent possible. Some other components, however, need the programmer’s attention. These include broad text fields and areas with fixed size, buttons with long texts, tables with multiple columns, big images, etc. One possibility is to construct these components with the principle “one size fits for all”. With this approach we should follow the limitations set by the narrowest display. Another possibility is to make the components dynamic in a way that their width changes in accordance with the width of the present device’s display. Tables may cause some trouble that should be resolved by modifying their structure or by removing them completely and using CSS instead. If the removal and CSS are not an option, probably the best thing would be to move adjacent table cells to con- secutive rows. That will cut down enough the space the table is taking, but it also may reduce the legibility of the table at the same time. To maintain the legibility it would be beneficial to insert some kind of a separator between groups that consist of cells belonging logically together. 3.4 Images and Bandwidth Images are a major usability concern when dealing with mobile devices. Usually the pictures are far too big to fit on the small screen of a mobile phone or a PDA. Also, as mobile networks offer very limited bandwidth, a webpage containing images downloads considerably slower than the same page without the images. There are, however, some ways to deal with this problem. The easiest and most obvious solution is not to download any images at all. This cer- tainly solves the problem with bandwidth but considering the use of the page, espe- cially if the website uses images as navigational links, it may not be the best solution. (This is not a very good design practise and you should avoid it if at all possible. Even more so, if you intend your pages for mobile audiences as well.) Other image hand- ling option utilized by mobile browsers is to download only selected images. This option is not very useful though as usually there is no way for the user to know what size the image is or what is its importance considering the information on the page. Some browsers, such as Opera, offer a third choice: automatic image scaling to make the images fit on the screen. If we think the usability of this solution from the layout
- 24. CHAPTER 3. MOBILE FRIENDLY FEATURES 18 point of view only it seems rather good. However, there is still the issue with band- width. The full image needs to be downloaded before scaling can be done. And then there is a new concern: the scaling takes time and reduces the battery life of the mo- bile device. So, we see that although scaling images on the mobile is a step towards a better user experience it is still far from truly being called mobile friendly. For a website to be mobile friendly we require, that considering the restrictions on mo- bile devices, the mobile user experience is as close as possible to the user experience offered by a desktop browser. With current mobile devices and their capacities, mobile friendliness in the case of im- age and bandwidth issues, can only be achieved through server-side solutions. Some of the options available to the mobile users were mentioned in section 2.5. The prob- lem with all those solutions is that they are either mobile network operator specific, they cost, or they might require extra software to be installed on the mobile device. True mobile friendliness must be implemented within the website itself. Compared to a third party “mobile friendlifying” service, the in-house solution has the added benefit of knowing the structure and semantics of the site so more intelligent choices can be made in making the page mobile friendly. When the site detects a mobile user agent, images must be scaled down to a proper size according to the user’s display size. Images can be scaled on the fly or different sized versions can be stored on a server. Alternatively, if images are not essential, they can be left out altogether. In Chapters 5 and 6 we show how this can be added to existing systems. Implementing a mobile friendly web service is even easier if mobile users are taken into account right from the start of the design process. The numbers of Internet enabled mobile device owners are growing rapidly. We be- lieve that it is in the interest of (commercial) web services to make their sites mobile friendly. This should be done without any extra charges for the mobile users or re- quiring them to use some third party “mobile proxy” service. 3.5 Mobile Friendly Web Services Now that we have defined the solutions for the problems presented in Chapter 2, we need to test them in practise. We want to know whether it is possible to recognize mobile devices and based on that scale the web site content automatically and alter the layout to be suitable for mobile devices. We could start off by writing our own
- 25. CHAPTER 3. MOBILE FRIENDLY FEATURES 19 software from scratch and design a very sophisticated support for mobile devices into it. Another way, that we decided was the best approach for us, is to use some popular open source programs and integrate mobile friendly features into them. This way we will save the time in actually implementing the whole functionality of the software. After some research we decided to use Gallery and LiveJournal. When choosing the web services one important criteria was their popularity. Another criteria was that once completed, would these software products add value to the use of mobile phones, i.e. what good would they offer to the mobile users. Gallery (over 100,000 installs) is a photo hosting service and a mobile friendly version would naturally be a valuable service for camera phone owners because you can upload pictures you have taken straight from your mobile to the web service. LiveJournal (over million active users) is a blogging service and the possibility to update one’s journal or diary from anywhere at any time using a mobile device would be a benefit for the user. Both of these services would be good examples on how to increase the value of us- ing mobile devices, if we succeed in modifying them to be mobile friendly. Also, because open source is considered, we will not be completely satisfied even though we do get these mobile friendly features implemented, unless we are able to get the modifications to be part of the official distribution packages of these programs. Chapters 5 and 6 describe how Gallery and LiveJournal, respectively, were made mo- bile friendly. Both Gallery and LiveJournal are open source software and therefore the next chapter gives an introduction to open source. The chapter can be skipped if the open source concept already is familiar.
- 26. Chapter 4 Open Source Software What is open source? Many people seem to think it is just a free access to software products. While it is true that open source means a free access to software’s source code, there is also a more complex side to it, i.e. what are the limitations and respons- ibilities when using and distributing open source software? How open source software can be distributed, is determined by a license attached to the software by its original developers. There exist various open source licenses which all have to fill completely the criteria of the Open Source Definition (OSD) [30]. Besides the matters described above, this chapter also takes a look at open source software development and some successful open source projects. 4.1 The Open Source Definition Working in software development and using source code of a another program written by someone else is something that brings up legal issues about immaterial rights, such as who owns the source code and how the code or the modified version of it should be distributed. It is good to know your rights when it comes to dealing with source code that is not yours. Proprietary software, shareware, freeware, free software, public domain, copyleft, and open source are terms that one eventually runs into in open source software develop- ment. In order to understand what open source means precisely, it is necessary to know the meanings of these terms. In the following a short explanation on each of the terms is given [13].
- 27. CHAPTER 4. OPEN SOURCE SOFTWARE 21 Proprietary software is copyrighted. No source code is provided with the release nor by other means leaving the customer with no possibility to modify the software. The only people with an access to the source code are the ones working with the project in the corporation who owns the copyright. This is the traditional way for commercial projects to release their software. After the release of a shareware software it is available to anyone with no initial cost. However, if anyone decides to continue to use the software after its free trial period has expired, a reasonable price for a license has to be paid. Shareware software can be redistributed to other users while the license is not passed along with it. There also exists a shareware derivative software type called crippleware. It is released with some of its functionality pruned. When someone decides to pay the license for it, he gets access also to the originally deactivated functionality. The source code is not usually released with this type of software. Freeware is equal to shareware without the exception that users do not have to pay for the license at any point. Freeware gets easily mixed with free software even though they are two different cases. Free software licensing aims to guarantee access to the source code. Therefore it is not the same as freeware. It gives the rights for everyone to use, modify and redistribute the software in any way they choose. However, distributors are also obligated to give the same access to the modified source code and the license must remain unchanged. Free software is often confused with public domain. Software released in the public domain has no restrictions because nobody owns a copyright to it. To be more specific, there is no copyright. This means that anyone can use, modify and redistribute the software in anyway one chooses. Furthermore, it is even possible to charge for the original software without any obligations to give the source code for free. Copyleft was originally Richard Stallman’s idea to address the problems releasing a software in public domain, which makes the software lose its copyright. Copyleft does not remove software’s copyright but instead it adds specific distribution terms. Alto- gether it says that copylefted software may be used, modified and redistributed, with or without changes, as long as the distribution terms follow the software unchanged. Open source goes alongside with free software. They both want to ensure that the source code remains free and available to everyone, but open source can be considered to be more commercial-friendly. For example, an open source license called GNU
- 28. CHAPTER 4. OPEN SOURCE SOFTWARE 22 Lesser General Public License (LGPL, section 4.2) allows source code licensed under it to be used in products that are not open source. The open source definition, released by Open Source Initiative (OSI), is a list of criteria which a license has to fulfill in order to be an open source license. The ten most important parts of the open source definition will be explained in the following [30]. Free Redistribution. The first requirement of the definition concerns one of the most important characteristics of open source. The clause says that open source software must be redistributed freely, which means the license can not restrict selling or giving away the modified software nor require any royalties or other fees for it. However, this does not say that you can not charge for example for your customer support or printed documentation of the software. Source Code. The second clause is about the software’s source code. It requires that the source code must be obtainable for free, e.g. preferably downloadable via the Internet. Furthermore, the distributed code must not be deliberately obfuscated. Derived Works. The third clause demands that the license must allow modifications and derived works, and must allow them to be distributed under the same license that is used with the original software. This clause, together with the second one, guarantees access to the software’s source code and allows it to be modified. Therefore it is possible that open source software can be developed by anyone. Integrity of The Author’s Source Code. The next part deals with the integrity of the author’s source code. It says that the license may restrict source code from being distributed in a modified form. However, it must allow distribution of patch files. This gives users a possibility to know who is responsible for the software they are using. No Discrimination Against Persons, Groups nor Fields of Endeavor. The fifth and sixth clauses require that the license must not discriminate against any persons or groups nor the place where it is used. These clauses guarantee that open source soft- ware can be used by anyone in any group and in any business branch. License Features. The last four clauses are all concerning features of the license. The first one is about distributing the license. It says the rights attached to software must also apply to all whom the software is redistributed to. The next one says the license must not be specific to a product. By demanding this, the clause closes one class of li- cense traps which are ways of questionably making open source software proprietary. The third one requires that the license does not restrict other software. It means that
- 29. CHAPTER 4. OPEN SOURCE SOFTWARE 23 the license can not place any restrictions on any software that is distributed along with the licensed software. The last clause says the license must be technology-neutral, meaning that non of the license’s clauses may be based on individual technology or style of interface. As we can see the open source definition is quite complex and demands a lot from a license. When designing a license that aims to be open source valid, one needs to be very exact when writing the conditions and it is probably not a bad idea to have some legal advice on as well. Each piece of software that is open source should have an individual license attached to it to guarantee that the software remains open source. Fortunately most open source licenses have been created as templates, where the user can just fill in the software name and the copyright owner to have a valid open source license for the software. This way programmers can use ready-made licenses and do not have to waste time in creating one of their own from scratch. Programmers can can pick up a license suitable for their software product for example from the Open Source Initiative’s website1 that lists all the licenses OSI have approved as open source licenses. 4.2 Popular Open Source Licenses In this section we will describe the features of some of the most popular open source licenses. We start with GPL and LGPL and then move on to BSD, MIT, and Artistic License. All of these licenses protect the software with a copyright. To make a license to be an open source license, copyright holders add copyleft to it, which means they grant permission to copy, distribute and modify the software if certain conditions are met. GPL – GNU General Public License – was released by Free Software Foundation in 1989, and is today the most popular license used in open source projects. About 69% of all 33,931 projects at Freshmeat.net and around 70% of all 53,345 Open Source Initiative (OSI) approved projects at SourceForge.net use GPL [31][32]. The license says that anyone may copy and distribute verbatim copies of the source code as long as copyright notices and disclaimers are included unchanged. A fee may be charged for physical distribution of copies or if one decides to offer warranty. The software may be modified and then redistributed by anyone if the modified files are marked 1 http://www.opensource.org/licenses/
- 30. CHAPTER 4. OPEN SOURCE SOFTWARE 24 with the name and date modified. Also, the modified program, or the program the modification is part of, must be licensed as a whole under GPL. The software, or a work based on it, may be distributed and copied in object code or executable as long as the complete corresponding source code is included in the distribution. A reasonable fee can be charged based on the physical reproduction cost of the code. [29] LGPL – GNU Lesser General Public License – was also released by Free Software Foundation in 1991. It is the second most popular open source license at Fresh- meat.net with 7.5% share, and at SourceForge.net with a share of 11% [31][32]. This license is mainly intended for libraries. Like GPL it allows anyone to copy and dis- tribute verbatim copies of the source code under the license. Also, a reasonable fee may be charged for physically distributing copies or if one decides to offer warranty. The library or any part of it may be modified. If the result itself is a library and modified files are marked with the modifier’s name and date, the modification may be copied and redistributed. It is possible to change the license type of a modified library from LGPL to the ordinary GPL by simply replacing all notices referring to LGPL with those of GPL. The library may be copied and distributed in object code or executable form, provided the complete corresponding source code is also included. Programs using LGPL libraries do not fall under LGPL as long as the programs are only compiled or linked with the library, and therefore do not contain any portions of the library. [29] BSD License - Berkeley Source Distribution License was released by the University of California, Berkeley, in 1998. The BSD License is almost as popular as LGPL. At Freshmeat.net it is used in 5.6% and at SourceForge.net in 7.2% of all projects [31][32]. This license’s clauses are easy to understand and there are just a few of them. First it says that anyone can redistribute and use the source or binary forms, with or without modifications as long as the license’s clauses are not broken. Clauses define that copyright notice and disclaimer must be included with the redistributed software. Furthermore, neither the copyright owner’s name nor the names of the software’s contributors may be used to promote the product without written permissions from original authors. Features of the MIT License, released by Massachusetts Institute of Technology, and the BSD License are equal without the final no-promotion clause of the BSD-license. [29] Artistic License is the last example. It was released by Perl in 1987 but despite of the releaser’s name, it is today widely used in various other projects as well. About 1.8% of projects at Freshmeat.net and around 2.1% of OSI approved projects at Source- Forge.net use this license to copyright their software [31][32]. The first clause says
- 31. CHAPTER 4. OPEN SOURCE SOFTWARE 25 that anyone may distribute verbatim copies of the original, unmodified, version as long as they include copyright notices and disclaimers with the distribution. Anyone may use patches derived from the copyright owner and the software is still considered as original and unmodified. Anyone may modify the software provided they make a notice of the changes they have made at the beginning of each modified file and, of course, make the modified software freely available. It is also possible to use a modi- fied version of the software within organizations or rename the whole software so the names do not conflict with the original. Anyone may distribute binary or source form as long as they provide the whole package, i.e. the original version must be included with modified versions. Reasonable fees may be charged by anyone for physically distributing the package or if they choose to support the package. Fees on the pack- age itself may not be charged, though. Scripts and libraries supplied as input to or produced as output from the package do not fall under the copyright of Artistic Li- cense. C and Perl subroutines linked to this package and supplied by the distributer of this package are not considered as part of the package. The name of the copyright owner may not be used to promote products derived from software under this license without written permission from the original authors. [29] Choosing the right license for your own open source software may be difficult, but it is something that has to be done. Also, when you take an open source software package and modify it to suit your needs, you will need to know what are the rights and responsibilities defined by the software’s license. Table 4.1 summarizes important features of licenses that have been discussed in this section including GPL, LGPL, BSD, MIT, and Artistic License. Some other popular licenses, such as QPL (Qt Public License), MPL (Mozilla Public License), IBM Public License, and Apache Software License are presented as well. Though it is easy to see from the table what are each licenses’ features, one should still always get to know the original license thoroughly. Working with a license whose conditions are not familiar may lead into trouble. The following will explain the meaning of each column in the Table 4.1 [5]. Possible to link with proprietary software. For example, according to the terms of GPL, if you mix code published under GPL to your software, you must distribute your software under GPL. It does not matter whether your software already is open source or whether it is proprietary, from there on it is open source under GPL. This kind of licensing is not beneficial for commercial software and because of it, other licenses have been created which do not include this requirement. If software is published, modified source code must be redistributed. A free software license requires always that if any modifications have been made to the source code,
- 32. CHAPTER 4. OPEN SOURCE SOFTWARE 26 Table 4.1: Features of popular OS licenses. Slightly modified from [5]. Possible to If software Modifications Can GPL link with is published, can be prohibit compatible proprietary modified source forked to commercial software code must be proprietary sale redistributed GPL no yes no yes yes LGPL yes yes no yes yes BSD yes no yes no yes MIT yes no yes no yes Artistic License yes no yes yes yes QPL no yes no yes no MPL yes yes yes no no IBM Public License yes no yes no no Apache Software License yes no yes no no it must be redistributed. Open source licenses have provided some relaxation for this requirement by not demanding the redistribution of modified source if certain condi- tions are met. For example, open source software can be modified, but the modified source does not need to be redistributed if the software is kept private or within an organization, i.e. the software is not published. Modifications can be forked to proprietary. This is another major difference between open source and free software. Most free software products are copylefted and by that they disallow the possibility to turn them to proprietary. Open source, however, leaves it for licenses to decide whether to allow forking or not. If it is allowed, the software can be modified and made proprietary. Can prohibit commercial sale. This option is important for companies who plan to release both commercial and non-commercial versions of their software. If the license does not prevent commercial sale, the copyright owner can release a commercial ver- sion of the program in addition to the open source version. The license prevents subsequent developers from commercially distributing the open source version of the software. GPL compatible. If any code is mixed with code that is licensed under GPL, the result will be all GPL as the GPL demands. When a license announces that it is GPL compatible, it means that the software under the license can be relicensed to GPL. In other words, source code that is not published under a GPL compatible license can not be joined with GPL licensed source code.
- 33. CHAPTER 4. OPEN SOURCE SOFTWARE 27 4.3 OSS Projects Open source software is free and anyone can obtain their own copy of the source code with no charge (except the almost non-existent cost of an Internet connection). Open source projects can be found best by visiting some web services hosting these projects. Probably the most known ones of these are SourceForge2 and Freshmeat3 , which were already mentioned in section 4.2. Together they host over 115,000 open source projects with over 1,100,000 registered users [32][31]. Besides SourceForge and Freshmeat, there are other similar services including BerliOS Developer4 with just over 1,500 projects, and Open Source Directory5 with about 700 open source projects [28][1]. While most open source projects remain unknown to the general public, there are some that really have made their way through and some of them are even making money. Some of the well known open source projects include Apache, Linux, and MySQL. Apache is a web server software that started to gain much reputation during 1995 and by the end of the first quarter of 1996, its market had closed up the gap with Microsoft’s web server. From there on Apache has been the leading web server software and it has gained a market share of 67.2% (Figure 4.1) [25]. Linux is probably the best known open source project. It is an operating system that was released by Linus Torvalds in 1991. Since then many programmers have made their own contributions for Linux development. Gradually Linux has gained reputation as a good and stable operating system and has become more and more used amongst academic society and Internet service providers [13]. The most popular open source database is MySQL. Its market share is still far from its commercial rivals Oracle, IBM and Microsoft databases but it is still used by some big companies [7]. Just to mention a few, MySQL is used by Yahoo!, Google, Cisco, Sabre Holdings, HP, and NASA [24]. 2 http://sourceforge.net/ 3 http://freshmeat.net/ 4 http://developer.berlios.de/ 5 http://osdir.com/
- 34. CHAPTER 4. OPEN SOURCE SOFTWARE 28 Figure 4.1: Market share development of web servers. 4.4 Development of OSS Open source software can be developed using varying development models but even- tually they all can be categorized to be either the cathedral model or the bazaar model. The names cathedral and bazaar come from Eric S. Raymond’s essay on open source software engineering methods. Raymond talks about his observations on the Linux kernel development and his experiences on managing an open source project [36]. Before Linux, which uses the bazaar model, the cathedral was the prevailing model. According to Eric S. Raymond’s essay, he thinks that Linus Torvalds is the inventor of the bazaar model. One notable difference between the bazaar and the cathedral model is how often the software is released. Cathedral projects believe that releasing source code early, be- fore it is tested properly and seen to be quite stable, is a bad policy because early versions most likely contain more than just a few bugs and it would wear out the pa- tience of users. Operating quite opposite to the cathedral model, the bazaar model endorses releasing early and releasing often. The advantage of this style compared to the cathedral model is that projects get feedback about bugs also from the users instead of just getting it from the developer team. In his essay Raymond defines the “Linus’s law” which says that “Given enough eyeballs, all bugs are shallow”. It means that when the source code is publicly available, like it is in the bazaar model, there are
- 35. CHAPTER 4. OPEN SOURCE SOFTWARE 29 more people testing the software and therefore bugs will be discovered and reported considerably faster than in the cathedral model. [36] What if there are not enough “eyeballs” available, will the bugs be discovered any- way? This kind of situation can occur when a community around an open source project has not grown much. This may reduce the quality of source code because bugs and errors are detected with a much lower rate than what it would be with larger communities. Therefore, it can be said that the quality of open source software is not necessarily any better than it is with proprietary software. Eventually the quality of source code depends on used person hours which can be much greater with large communities than with proprietary software or small open source projects. [36][12] Today, partly because of being inspired by Raymond’s essay and the fact that the bazaar model actually works, most open source projects that used to use the cathedral model now use the bazaar model. Also, the majority of newly launched open source projects have adopted the bazaar model. For a contrast, the typical development model for proprietary software projects would be, without an exception, the cathedral model. Naturally, most of the time these projects do not publish the source with the release of their proprietary software. [36] Open source is open for all and therefore anyone can pick up a project for example from SourceForge.net and start working on their own modifications. This naturally leads to a situation where popular open source projects are being developed all over the world by different individuals who have never even met each other. As arranging meetings would be difficult and expensive, most open source projects use the Internet as a medium to discuss and inform others about the changes concerning the project. The informing can be done using a simple bulletin board website that is dedicated for the project. The projects that need more interaction between developers, need a more sophisticated method of communication. These methods include newsgroups, mailing lists, communities, and forums. Communities and forums are pretty much the same and one of them can usually be found from the project’s website. They are meant to be a place for the project related discussion where people can comment on entries submitted by others, inform about bugs, ask installing or usage instructions, etc. Communities and forums seem to be used mainly by larger projects with many developers and users, while newsgroups and mailing lists seem to be used by smaller projects. Open source projects are started mainly by one person or a small group of people. Mostly their common interest is to create something they would need. Initially this
- 36. CHAPTER 4. OPEN SOURCE SOFTWARE 30 core group of people, or one person from it, becomes the maintainer of the project. When a project grows larger it is the maintainer’s job to decide which patches, sent by other developers, get accepted to the software and which ones do not. When the project maintainer loses his interest over the project or has a lack of time, his final duty is to appoint a successor. The successor is usually nominated amongst those who have made significant contributions for the project and of course is willing to accept the responsibility.
- 37. Chapter 5 Case Study: Gallery We chose Gallery as one of our research subjects because of its popularity and for its obvious value to the camera enabled mobile phone users. Also, Gallery has active developer and user communities around it who are continuously making Gallery a better product. This made Gallery an even more attractive option as one of our aims was to see how we could make the ideas of mobile friendliness better known and applied in open source software projects. We started working with Gallery 1 and soon expanded to Gallery 2 that was still in its beta phase at the time. At the time of writing this, Gallery 2 Alpha 2 has just been published. 5.1 Overview Gallery’s homepage1 describes the program as follows: “Gallery is a web based soft- ware product that lets you manage your photos on your own website. You must have your own website with PHP support in order to install and use it. With Gallery you can easily create and maintain albums of photos via an intuitive interface. Photo management includes automatic thumbnail creation, image resizing, rotation, order- ing, captioning, searching and more.” The administrator of a Gallery installation can create multiple user accounts with different permissions on a per album basis. The Gallery project was started in June 2000 by its main developer Bharat Mediratta. The current version (as of 2004-08) is 1.4.4 and Gallery has a big user base with over 100 000 installs, according to their own statistics. Gallery 1.x is still under active 1 http://gallery.menalto.com/
- 38. CHAPTER 5. CASE STUDY: GALLERY 32 development and new features are added all the time but at the same time a new version, Gallery 2, is being developed. Gallery 2 is a complete rewrite of the program with a new extensible and modular architecture along with some new features. We will discuss more about the differences later in this chapter. The development of Gallery 2 has been going on for about two years now and the first public release, 2.0 Alpha, was made on July 18, 2004. 5.2 Programming Languages Both Gallery 1 and Gallery 2 are programmed in PHP. Gallery 2 also uses a PHP based Smarty template system to separate the user interface and the logic of the program. As all data in Gallery 2 is stored in a database, SQL is needed to query the data. 5.2.1 PHP PHP2 is a very popular general-purpose scripting language that is especially useful for web development [15]. The name of the language is a recursive acronym for PHP: Hypertext Preprocessor. PHP can be used on its own (command line scripting) or it can be embedded in HTML pages (server-side scripting). Figures 5.1 and 5.2 illustrate the differences between these two methods of using PHP with a familiar Hello World program. Both examples are fully functional PHP programs and their outputs are exactly the same. While PHP alone is enough for command line scripting, server-side scripting requires a web server. PHP can work with the web server in two ways: as a server module or CGI (Common Gateway Interface) processor. PHP has a direct module interface for many popular web servers such as Apache and Microsoft IIS (Internet Information Server). One of the most important features of PHP is that it supports a wide range of data- bases. This allows easy creation of dynamic webpages. The supported databases include dBase, IBM DB2, Ingres, mSQL, MySQL, Oracle, PostgreSQL, and many more. PHP also supports ODBC (Open Database Connectivity), an open standard database access method to connect to different databases without a database specific client software. 2 http://www.php.net/
- 39. CHAPTER 5. CASE STUDY: GALLERY 33 1 textbferer 2 <?php 3 $hello = ’Hello World!’; $ 4 echo "<html>n<head><title>Hello</title></head>n"; 5 echo "<body>n$hellon</body>n</html>"; 6 ?> Figure 5.1: Hello World example, pure PHP code. 1 <html> 2 <head><title>Hello</title></head> 3 <body> 4 <?php 5 $hello = ’Hello World!’; 6 echo $hello; 7 ?> 8 </body> 9 </html> Figure 5.2: Hello World example, embedded PHP code. 5.2.2 Smarty Gallery 2 makes extensive use of a Smarty templating engine. Smarty [27] is a PHP based templating system that is designed to make it easy for web developers and website designers to separate the layout and the look of a page from the site’s logic. Figure 5.3 shows a simple Smarty template and Figure 5.4 illustrates how the template is used in a program. Using templates has many benefits over the traditional method of printing the HTML in the application code. The first advantage is that it makes the programmers’ task easier as they do not need to worry about the presentation layer and the code is easier to read as well when all the HTML is somewhere else. Secondly, the designers can modify the layout and presentation without making any changes to the application code. Actually, the designers do not even need to know PHP. The third benefit is the close relationship that templates have with the actual page output. Compared to mixing the application code with the HTML markup, the page layout is a lot easier to design with a template as it closely resembles the final out- put. Other advantages Smarty offers include a built-in debugging console and easy extensions through plug-ins. The first time a template is used Smarty compiles it into PHP code thus saving the time used to parse the template on every consecutive request. The page output can cached too, saving even more time. Even just parts of single page can be cached.
- 40. CHAPTER 5. CASE STUDY: GALLERY 34 1 <html> 2 <head><title>Message</title></head> 3 <body> My message today is: {$message} </body> 4 </html> Figure 5.3: simple.tpl - a simple Smarty template. 1 <?php 2 include ’Smarty.class.php’; 3 $smarty = new Smarty; 4 $smarty->assign(’message’, ’Hello world!’); 5 $smarty->display(’simple.tpl’); 6 ?> Figure 5.4: A simple program using the Smarty template. 5.2.3 SQL Structured Query Language (SQL) is a computer language for accessing and manipu- lating relational databases. It is an ANSI3 /ISO4 standard and is supported by virtually all major databases. For more information and examples see W3 Schools’ online SQL manual5 . Gallery 2 module developers do not need to write any SQL queries themselves as the Gallery framework does it for them. This will be covered in more detail in section 5.3.2. Gallery 1 does not use a database and therefore SQL is not needed there either. 5.3 Architecture We wanted to make mobile friendly modifications or modules to both Gallery 1 and Gallery 2 so it was necessary to get to know the structure of both of the programs. When we started our project Gallery 2 was still under heavy development and chan- ging often so we begun our work with Gallery 1.4. Later when Gallery 2 had reached a more stable condition we started working with that also. In this section we will outline the structure or architecture of both of the Gallery versions. 3 http://www.ansi.org/ 4 http://www.iso.org/ 5 http://www.w3schools.com/sql/
- 41. CHAPTER 5. CASE STUDY: GALLERY 35 5.3.1 Gallery 1.x Gallery 1 grew out of the need to have an easy way to publish online pictures taken with a digital camera. In the beginning it was just a small script for sharing photos with a few people. New features were added one by one as they were needed. As a direct result of this the program lacks of any real architecture. Functionality The functionality of Gallery 1 consists of small scripts such as login.php, search.php, view_album.php, and add_photos.php. Each of the scripts implements one logical function in the gallery. For example, login.php implements the process of prompting the user for the username and password, checking their validity, and logging the user into Gallery. albums.php is the file that takes care of rendering the HTML for the Gallery’s main page whenever a user browses there. The first thing all the scripts do before their own functionality is to initialize the Gal- lery. All work that is needed to set up the Gallery is done in the init.php file. This loads the utility functions in util.php, the proper file system functions depending on the platform (Unix or Windows), and the current installations configuration inform- ation in config.php. During the initialization the different classes such as Album and User get loaded as well as the session information and the language settings. Layout and Themes One of the main problems with Gallery 1 is that the layout is not clearly separated from the program logic. All the different functions render most of their HTML code themselves. The rest of the layout code is in the html, html_wrap, and layout direct- ories. The navigation images and other symbols are in the images directory and the default style files are in the css directory. Users can create their own themes of skins. Skins are CSS files that override the default values and attached image files. They are all located in subdirectories under the skins directory. Gallery 1 comes with about twenty different skins of which the installation’s administrator can choose the one she likes or create a new one herself.
- 42. CHAPTER 5. CASE STUDY: GALLERY 36 Data Storage All user data (usernames, passwords, email addresses etc.) and the images are stored in an installation specific directory. Under that directory, albums have their own sub- directories where all images and sub-albums belonging to that album are kept. In the user data directory there is a file called albumdb.dat that contains the name of each top level album. Under each album directory there are the files album.dat and photos.dat. These files hold all the album details and photo properties respectively. Each of these .dat files is a serialized version of a PHP object. In essence a serial- ized object is a string representation of the object’s value and it can be easily stored anywhere. 5.3.2 Gallery 2 As new features were added to Gallery 1 it grew bigger and more complex and difficult to maintain and develop because of the lack of proper architecture. At that point the developers decided to write everything again from scratch but this time plan it ahead and create a solid, modular and extensible architecture for Gallery. The result of this work is Gallery 2. MVC Pattern Gallery 2 uses several design patterns and coding methodologies to make the system easier to implement and understand [23]. The main design pattern is the Model-View- Controller (MVC) pattern. MVC pattern’s basic principle is to separate data from the logic and display. Model or data in Gallery 2 is a relational database where all the information is stored. Currently Gallery 2 supports MySQL, PostgreSQL, and Oracle databases but sup- port for different databases can be added relatively easy. Data is then processed by controllers and finally presented to the user through a view i.e. the user interface. Figure 5.5 clearly shows how the data is only accessed through the Gallery Core API (Application Programming Interface), the modules do all the processing, and in addition to the theme CSS files, all output to the browser goes through the main.php file.
- 43. CHAPTER 5. CASE STUDY: GALLERY 37 Figure 5.5: The top level architecture of Gallery 2. The diagram is slightly modified from [22]. Gallery 2 Is Modular All functionality in Gallery 2 is implemented using modules. The core module provides the framework and some basic functionality like creating users, creating albums and viewing images. All other functionality, such as search, commenting, and slide show, which are not essential, are provided as separate modules. The administrators of the Gallery installations can install and then activate or deactivate any combination of modules they wish.
- 44. CHAPTER 5. CASE STUDY: GALLERY 38 The only mandatory thing for a module to have is a file called module.in that should define a class extending the GalleryModule class. This class contains all the necessary functionality to install and initialize the module so that the services provided by the module can be used. Gallery framework provides two classes called GalleryView and GalleryController. The various modules of Gallery 2 must extend (implement) these classes in order to process user input and render HTML to the browser. Other Design Principles Other patterns or methodologies that Gallery 2 uses are templates, redirect-on-post, locking, and code generation, among others. The reason behind many of these prin- ciples is to protect the data integrity. Another motivation is the easier maintenance and updating of the code base. Templates are used to help separate the logic from the user interface. Specifically Gallery uses the Smarty template engine that was described in section 5.2.2. It is a powerful templating system that allows modifications to the existing pages and the designing of new templates without needing to change the application code. The template designer does not even need to know any PHP. Redirect-on-post means that every time an operation is used that changes the data model (e.g. an album is renamed or a picture is deleted), the user is redirected to a new page, providing the operation was successful. This ensures that possible reloading of the page does not have any unwanted effects. In cases like viewing an image where the the model does not change the redirect is not used. Locking is also used to ensure that the data does not get corrupted. Before any changes are made to an item, a lock must be acquired for that particular item and in some cases for its parent items as well. This guarantees that only one operation at a time can be performed on any object thus securing the data integrity. Code Generation A good example of striving towards easier maintenance and a more robust product is the code generation. All Gallery entities such as users, albums, and images have XML code embedded in their class definition comments marked with special tags. Figure 5.6 shows a partial class definition as an example.
- 45. CHAPTER 5. CASE STUDY: GALLERY 39 1 /* Abstract base class for all objects in the Gallery composite tree. 2 * 3 * @g2 <class-name>GalleryItem</class-name> 4 * @g2 <parent-class-name>GalleryFileSystemEntity</parent-class-name> 5 * @g2 <schema> 6 * @g2 <schema-major>1</schema-major> 7 * @g2 <schema-minor>0</schema-minor> 8 * @g2 </schema> 9 * @g2 <requires-id/> 10 */ 11 class GalleryItem_core extends GalleryFileSystemEntity { 12 /* Can this item contain children? 13 * @g2 <member> 14 * @g2 <member-name>canContainChildren</member-name> 15 * @g2 <member-type>BOOLEAN</member-type> 16 * @g2 </member> 17 * @var int $_canContainChildren 18 * @access private 19 */ 20 var $_canContainChildren; Figure 5.6: Class definition with @g2 special comments. The comment lines with @g2 tags are then stripped from the file and we get the XML code shown in Figure 5.7. When this XML code is wrapped inside a <class> tag and a document type declaration (DTD) is added, we have a well-formed XML doc- ument. Together with the actual class definition the XML code can now be used to generate an interface class with all the necessary get and set methods. In addition, Gallery automatically generates the database definitions and access scripts so that the developers do not need to write a single SQL command themselves. The XML code can also be used to generate UML diagrams. 1 <class-name>GalleryItem</class-name> 2 <parent-class-name>GalleryFileSystemEntity</parent-class-name> 3 <schema> 4 <schema-major>1</schema-major> 5 <schema-minor>0</schema-minor> 6 </schema> 7 <requires-id/> 8 <member> 9 <member-name>canContainChildren</member-name> 10 <member-type>BOOLEAN</member-type> 11 </member> Figure 5.7: XML stripped from the class definition code.
- 46. CHAPTER 5. CASE STUDY: GALLERY 40 A Sample Workflow We use the following URL to demonstrate how Gallery 2 works. http://example.com/g2/main.php?g2_view=core:ShowItem&g2_itemId=8 Parameter g2_view tells Gallery that it must show a view specified by the value of this parameter. The value, core:ShowItem, means that the intended view is located in the ShowItemView class in core module. Gallery then loads the view and passes the rest of the parameters to it. g2_itemId is, clearly enough, the id number of the item the user is requesting to see. In this case it would be an album. The view loads the album and renders it on the screen based on the album’s settings. Another important parameter that could be used is g2_controller. This tells Gallery which controller to use to process the user input. Controllers are used every time when the model is updated (data is added, removed, or modified). 5.4 Community Gallery has a very active community of developers and users around it. The com- munication takes place in the discussion forums, the developer mailing list (gallery- [email protected]), and the IRC channel (#gallery). The Gallery website6 gathers all these resources, plus some more, together in one place. Developers Gallery project’s Source Forge page7 lists 28 developers, some working with Gallery 1 and some with Gallery 2. The development team has many other responsibilities in addition to writing the code. Some of them manage the project, some do testing, some user support, while others write documentation and moderate the discussion forums. Members of the core development team seem to be very committed to the project, contributing at least 5-10 hours a week each to work with Gallery. This commitment can be seen by the fast development and quick replies in the discussion forums when users ask questions or comment the product. 6 http://gallery.menalto.com/ 7 http://sourceforge.net/projects/gallery/
- 47. CHAPTER 5. CASE STUDY: GALLERY 41 Discussion Forums The discussion forums are an integral part of the Gallery user community. In the forums users can ask questions, report problems, and give feedback. There are (in September 2004) over 20 000 registered users who have sent almost 100 000 messages to the forums. There are forums for many different subjects. Some are for Gallery 1 and some for Gallery 2. Within just these groups there is a variety of subjects, such as Installation and Configuration Help, Customizing Gallery, Suggestions and Feedback, G2 Gen- eral Development, and G2 User Interface. In addition to these, there are forums for discussion on embedding Gallery into other applications and translating Gallery to other languages and much more. Gallery Website Gallery’s homepage offers a lot of useful information and resources for Gallery users and developers as well as for anyone interested to know more about Gallery. From the homepage you can read the latest news about Gallery, get to know all its features, and read the installation instructions. All the documentation for both users and developers is available on the site. There is also the possibility to submit bug reports and feature requests. One interesting option is to buy installation service or other support. Money from this goes to the website hosting costs. 5.5 Mobile Friendly Features We wanted to modify Gallery so that it would look good on the small screen of a mobile phone or some other device. This meant changing the layout and scaling images. In order to be able to achieve these goals we first needed to implement a way of recognizing mobile user agents. In addition to these features we also added support for the Image Uploader included in some Nokia mobile phone models (e.g. 3650 and 6600). All modifications were done on Gallery 1.4.3-pl2 and the Image Uploader was also implemented as a Gallery 2 module.
- 48. CHAPTER 5. CASE STUDY: GALLERY 42 5.5.1 User Agent Recognition The first task on making Gallery 1 (or any other system, for that matter) mobile friendly was to recognize the mobile user agents. This is done based on the user agent string as reported by the user’s web browser and the list of known mobile phone user agent strings. In PHP the user agent string is available in the $_SERVER[’HTTP_USER_AGENT’] global variable. Our list of known user agent strings is stored in the mobile_term- inal.php file as shown in Figure 5.8. The keys in the $screenSizes array are regular expressions that match different user agent strings and the values are screen dimensions of a respective phone model. The keys are defined in the order where the most specific ones come first and the most general key comes last. The order of the keys is meaningful as array items in PHP are internally stored in the order they are assigned. For example, both Series 60 and Series 90 phones use the Symbian operating system and this information is in their user agent string. If we had the key ’/.*?Symbian.*?/’ first in the array it would match both models, which is not what we want since their display sizes are different. The function screenSize() in Figure 5.9 shows how we use the $screensizes array. This function is defined in the same mobile_terminal.php file as the array. It takes the user agent string as an optional parameter with an empty string as the default value for it. In lines 5–14 we check if we are in the “force mode”. The force mode means that Gallery does not actually read the user agent string but the decision is made based on other information. Forcing is meant for testing and demonstration purposes and it will be better described later in this section. If the user agent string is not given as a parameter to the screenSize() function, we get it from a server variable in lines 17–19. When we have the current user agent 1 global $screensizes; 2 // Phones that use the Series 60 platform, e.g. Nokia 3650 and 6600. 3 $screensizes[’/.*?Series ?60.*?/’] = array(’width’ => 176, ’height’ => 208); 4 // Phones that use the Series 90 platform, e.g. Nokia 7700. 5 $screensizes[’/.*?Series ?90.*?/’] = array(’width’ => 640, ’height’ => 320); 6 7 // The generic mobile phone using Symbian OS. 8 $screensizes[’/.*?Symbian.*?/’] = array(’width’ => 176, ’height’ => 208); 9 10 // this is for forcing & test cases 11 $default_screensizes[’series60’] = array("width" => 176,"height" => 208); Figure 5.8: Mobile user agent strings in mobile_terminal.php file.
- 49. CHAPTER 5. CASE STUDY: GALLERY 43 1 function screenSize($useragent = ’’) { 2 global $screensizes, $default_screensizes; 3 4 // are we in force mode? 5 if (isset($_SESSION[’force’])) { 6 switch($_SESSION[’force’]) { 7 case ’mobile’: 8 return $default_screensizes[’series60’]; 9 case ’desktop’: 10 return null; 11 default: 12 return null; 13 } 14 } 15 16 // if user agent is not specified, use the current from server 17 if ($useragent == ’’) { 18 $useragent = $_SERVER[’HTTP_USER_AGENT’]; 19 } 20 21 // check if the user agent string matches any screen size key 22 foreach (array_keys($screensizes) as $key) { 23 if (preg_match($key, $useragent)) { 24 return $screensizes[$key]; 25 } 26 } 27 return null; 28 } Figure 5.9: Function screenSize() returns the user agent’s screen size. string we can compare it to the known user agent strings. In lines 22–26 we step through the $screensizes array starting from the beginning and compare each of the keys with the user agent string. If a match is found we return the respective screen dimension value. Finally, in Figure 5.10, we define a function isMobileUser() that returns true if the user agent is a known mobile device and false otherwise. This function too, is defined in the mobile_terminal.php file. It takes an optional $useragent parameter with default value of empty string. To determine the situation isMobileUser() calls the screenSize() function. If the return value of that function call is not null then we know that in the list of mobile terminals’ display sizes there is a defin- ition for our current user agent, and therefore it is a mobile device. 1 function isMobileUser($useragent = ’’) { 2 if (screenSize($useragent) !== null) { 3 return true; 4 } 5 return false; 6 } Figure 5.10: Function isMobileUser() recognizes mobile user agents.
- 50. CHAPTER 5. CASE STUDY: GALLERY 44 The Force Mode To make testing and demonstrating the mobile friendly Gallery 1 easier we added a possibility to force Gallery into a certain mode (mobile or desktop) from the browser. On the Gallery main page we add the following line: Terminal selection (current: automatic desktop): [automatic | mobile | desktop] where mobile and desktop are links to force the Gallery into the respective mode. The line is created by a command “include(’force.php’);”, which we added into the albums.php file. This file is responsible for displaying the Gallery main page. The contents of force.php are shown in Figure 5.11. First, in lines 3–12, we check if we are in the forced or automatic mode and print the appropriate information about the current status to the screen. Then, in lines 15, 20, and 25, we check which exact mode (forced mobile, forced desktop, or automatic) we are in and prepare the links accordingly. Finally, in line 31, we print the links to the screen. 1 <?php 2 echo ’<div style="font-size: 8pt;"> Terminal selection (current:’; 3 if (isset($_SESSION[’force’])) { 4 echo ’forced ’; 5 } else { 6 echo ’automatic ’; 7 if (isMobileUser()) { 8 echo ’mobile): ’; 9 } else { 10 echo ’desktop): ’; 11 } 12 } 13 14 $link = ’<a href="setforce.php?force=’; 15 if ($_SESSION[’force’] == ’mobile’) { 16 echo ’mobile): ’; 17 $auto = $link . ’off" title="Automatic mode">automatic</a>’; 18 $mob = ’mobile’; 19 $desk = $link . ’desktop" alt="Desktop mode">desktop</a>’; 20 } else if ($_SESSION[’force’] == ’desktop’) { 21 echo ’desktop): ’; 22 $auto = $link . ’off" title="Automatic mode">automatic</a>’; 23 $mob = $link . ’mobile" title="Mobile mode">mobile</a>’; 24 $desk = ’desktop’; 25 } else { 26 $auto = ’automatic’; 27 $mob = $link . ’mobile" title="Mobile mode">mobile</a>’; 28 $desk = $link . ’desktop" alt="Desktop mode">desktop</a>’; 29 } 30 31 echo ’[’ . $auto . ’ | ’ . $mob . ’ | ’ . $desk . ’]’; 32 echo ’</div>’; 33 ?> Figure 5.11: force.php script creates a browsing mode selection link.
- 51. CHAPTER 5. CASE STUDY: GALLERY 45 1 <?php 2 session_start(); 3 if (isset($_GET[’force’])) { 4 switch($_GET[’force’]) { 5 case ’mobile’: 6 $_SESSION[’force’] = ’mobile’; 7 break; 8 case ’desktop’: 9 $_SESSION[’force’] = ’desktop’; 10 break; 11 default: 12 unset($_SESSION[’force’]); 13 break; 14 } 15 } 16 17 header(’Location: ’ . $_SERVER[’HTTP_REFERER’]); 18 ?> Figure 5.12: setforce.php script saves the browsing mode information in the session. The setforce.php script that gets called when the user selects a force link is shown in Figure 5.12. The code simply checks if the force variable is set in the request and then updates the session information accordingly. In line 17 the script instructs the user’s browser to load the original page again. 5.5.2 Layout If you narrow down your browser’s window, you will notice that Gallery’s main page adjusts the layout accordingly. However, there is a limit to that. When the window is narrower than the combined width of the album icon and the album title, the page does not scale down anymore and some of it is left outside the screen. When accessing the page with a Series 60 mobile phone, we see that the page is approximately twice as wide as the phone’s display. Browsing an album with a mobile browser is even worse as the number of picture columns does not change even if the screen gets narrower. This is a direct consequence of the table based layout. We wanted to modify Gallery so that the layout would scale properly even to the small 176 x 208 display of Series 60 phones. Gallery Main Page We started with the Gallery main page that is created by the albums.php file. The first problem was that the album’s highlight image (albums first picture) and album’s title
- 52. CHAPTER 5. CASE STUDY: GALLERY 46 and other data were on the same row, as can be seen in the Figure 5.13(a). The layout of the main page is done using a table: the album highlight image is in one cell and the album description is in another cell on the same table row. We added a line of code between these two cells that separates them to their own rows: <?php if (isMobileUser()) { ?> </tr><tr> <?php } ?> This is a really simple modification but it has a big impact on the mobile browser. Another problem with the main page was that the album title was in a cell with a nowrap attribute. Due to this, long titles did not fit on the narrow display. This was fixed with the following small modification that simply does not print the nowrap attribute if the user agent is a mobile device. <td <?=isMobileUser() ? ” : ’nowrap’?> class="title"> We also changed some of the align attribute values from left and right to center, which makes the page look better on a small screen. (a) Desktop (b) Mobile Figure 5.13: Gallery in two different layouts: mobile and desktop.
- 53. CHAPTER 5. CASE STUDY: GALLERY 47 The _getStyleSheetLink() in the util.php file chooses the style sheet for a page. It looks for a file called standalone_style.css. If the file does not exist then the function looks for a standalone_style.css.default file. We modified the function so that it first tries to find a standalone_style_mobile.css file. The mobile style sheet changes the background and link colors and link decoration. It also defines zero margins for the body element. One common component for all the Gallery pages is the “admin box”. The admin box is the box on the top of the page below title. It has one cell for text, for example “3 albums, 18 images”, and commands such as login, slideshow, and photo properties. The text was in one cell and the commands were in another cell, both cells in the same row. This was not good for the mobile device as all that information does not fit on the display. Admin box is defined in the layout/adminbox.inc file. Between the text and command cells we added the same code we already used in the main page to separate the two cells into their own rows. The result of all these modifications can be seen in Figure 5.13(b). Album and Photo View The Figure 5.14 shows the default layout of an album page in Gallery 1. The number of columns and rows can be set independently per album. On the narrow display of a mobile device there seldom is space for more than one or two columns of pictures. Figure 5.15 shows how we adjust the number of columns for mobile devices based on their screen sizes. Lines 1–2 are original Gallery code. In case of a mobile user we first find out the user’s screen size in line 5 (see Figure 5.9). In line 6 we calculate the number of pictures per page with the original settings, as we want to keep it approximately the same. We reserve 100 pixels for each mobile version of an image (see section 5.5.3) and based on that we calculate the new number of columns. Then, in line 8, we adjust the number of rows accordingly. The navigation links above and below the image in a photo view (view_photo.php file) were also a problem. They are in a fixed width table structure, which is too wide for a mobile device. We changed this by editing the navphoto.inc file. Now, when a mobile device is accessing the photo view, the navigation links are in a <div> element instead of a table. Individual links (first, next, etc.) are inside <span> elements. This makes it possible to spread the links over more than one row, to make them fit on the small screen.
- 54. CHAPTER 5. CASE STUDY: GALLERY 48 Figure 5.14: Gallery’s layout for album view. 1 $rows = $gallery->album->fields["rows"]; 2 $cols = $gallery->album->fields["cols"]; 3 4 if (isMobileUser()) { 5 $ss = screenSize(); 6 $tot = $rows*$cols; 7 $cols = min(floor($ss[’width’] / 100), 3); 8 $rows = floor($tot/$cols); 9 } Figure 5.15: Adjust the number of picture columns in album view. One more thing that we needed to change was the commenting feature. People who view the pictures can leave their comments about the images if they want. The prob- lem is that the input field is too wide, 30 characters, to fit on the small display. We changed the code in the add_comment.php file so that whenever we have a mobile user agent the width of the comment text box is 10 characters instead of the normal 30 characters. The commenters can also give their name or email with the comment. There is a text box for the name and the description “Name or email:” is in front of it. Text and description are in their own table cells which forces them onto the same row. We changed this so that in the case of a mobile user agent the text box and the description are in the same cell. This makes it possible for the text box to be wrapped to the next line thus fitting on a small display.
- 55. CHAPTER 5. CASE STUDY: GALLERY 49 5.5.3 Images Normally the pictures in Gallery are too big to fit on the small screen of the mobile device and therefore we need to adjust their sizes. There are two places where the image resizing could be done: either when the image is originally uploaded to Gallery or on the fly when the image is viewed with a mobile device. We chose to do it at the upload time. Although the upload process takes a bit longer when we do the resize at the same time, we save time when the user is viewing the pictures and therefore offer a better user experience. Adding Images to Gallery When images are added to an album its save() method (in file classes/Album.php) is called. This is where we create the mobile versions of the images. When a picture.jpg is added to Gallery, normally two other versions are created for it: the thumbnail ver- sion picture.thumb.jpg and the intermediate size version picture.sized.jpg. We added code to the save() method that creates two more versions: picture.mobile.jpg and picture.thumb.mobile.jpg. These are compressed from the original file by defining their widths to be 150 and 80 pixels respectively. We also needed to change the classes/Image.php so that it would recognize the mobile versions of images. The getTag() method returns the <img> tag that points to the image. This tag is used in many places throughout the Gallery. We changed the function so that it looks for the mobile version of the image and uses that when we have a mobile user agent. Viewing Images When users are viewing the images Gallery generates a frame around each image unless the administrator has chosen no frame. The size of the frame depends on the size of the image. When we have a mobile user agent we use the mobile versions of the images and therefore need different size frame as well. To alter the size of the frame we wrote three helper functions. They are shown in Figure 5.16. The function adjustThumbDimensions() takes the dimensions of the thumbnail image as a parameter plus an optional maximum width parameter. If the thumbnail image is wider than the maximum value (line 7), we set the width to the
- 56. CHAPTER 5. CASE STUDY: GALLERY 50 1 function adjustThumbDimensions($thumbsize, $maxwidth = 80) { 2 if (!is_array($thumbsize) || !array_key_exists(’width’, $thumbsize) 3 || !array_key_exists(’width’, $thumbsize)) { 4 return false; 5 } 6 7 if ($thumbsize[’width’] > $maxwidth) { 8 $delta = $thumbsize[’width’] / $thumbsize[’height’]; 9 $thumbsize[’width’] = $maxwidth; 10 $thumbsize[’height’] = $maxwidth / $delta; 11 } 12 13 return $thumbsize; 14 } 15 16 function adjustAlbumThumbDimensions($thumbsize) { 17 return adjustThumbDimensions($thumbsize, 80); 18 } 19 20 function adjustThumbSize($size, $maxsize = 80) { 21 if (($size > $maxsize) || ($size == 0)) { 22 return $maxsize; 23 } 24 25 return $size; 26 } Figure 5.16: Helper functions in util.php to adjust the image sizes. maximum value and calculate the new height keeping the same proportions (lines 8- 10). The function adjustAlbumThumbDimensions() is basically just a short- cut for adjustThumbDimensions(). In some places Gallery only uses one size parameter (width) for images and in those cases we use the adjustThumbSize() function. The main page of Gallery is printed in the albums.php file. When each of the album highlight (or thumbnail) images is prepared for output we check if it needs adjusting. This is done by adding the code shown in Figure 5.17. We use the same code also in view_album.php except that we call the adjustThumbDimensions() func- tion instead. Below every image Gallery writes the name of the file and a view count. These are printed in a table that is of the same width as the image. Gal- lery gets this value from the $gallery->album->fields[’thumb_size’] variable. Whenever we have a mobile user agent we replace that with a call to the adjustThumbSize() function. Finally we modified the getThumbnailTag() function in classes/AlbumItem.php so that it calls the adjustThumbSize() func- tion when a mobile device is accessing Gallery.
- 57. CHAPTER 5. CASE STUDY: GALLERY 51 1 if (isMobileUser()) { 2 $dimensions = adjustAlbumThumbDimensions(array(’width’=>$iWidth, 3 ’height’=>$iHeight)); 4 $iWidth = floor($dimensions[’width’]); 5 $iHeight = floor($dimensions[’height’]); 6 $scaleTo = $iWidth; 7 } Figure 5.17: Adjusting the dimensions of an album thumbnail image. 5.5.4 Image Upload Module Some of Nokia’s mobile phone models, such as 3650 and 6600, have a built-in Image Uploader. This allows phone owners to upload pictures straight from their phone to any server that supports the Image Upload protocol. One of the goals of our project was to implement the support for this service in the Gallery software. We did this for both Gallery 1 and Gallery 2 and this section describes how it was done on the latter. Image Upload Server API The protocol specification, Image Upload Server API version 1.1, "describes an in- terface that is used to upload images from a terminal to Remote Storage (RS). The goal is to provide a set of calls that can be used in upcoming imaging phones, are easy to implement at both the phone and server end, and are futureproof, in that the same protocol will be useful for a long period of time." [11] Before using the service a phone owner needs to store the RS’s address in the Image Uploader’s settings. The username and password can also be saved or typed manually at every upload. The user selects an image he or she wants to upload and starts the uploader on the phone. The phone will then connect to the address provided in the settings and send the username and password with the request. The server responds with a list of the services it provides. The client on the phone can now ask for a directory listing or decide to create a new album. Finally, after the upload directory is chosen or created, the image is uploaded to the server. At any point the server can return an error code if the authentication fails, there is a name conflict, or for any other possible server side error. The user will be notified of the error and he or she can try to upload again.
- 58. CHAPTER 5. CASE STUDY: GALLERY 52 The API specification defines the following interface (the numbers in brackets refer to sections in the specification). For minimum functionality, those marked with * must be implemented. ¤ Login* (5.2) Attempts to log user into RS. ¤ Remote Storage Capabilities* (5.3) Retrieves a list of URLs that correspond to the services the RS in question provides. ¤ Create New Directory* (5.4) Creates a new directory. ¤ Upload* (5.5) Uploads a file from the device into RS. ¤ Retrieve Directory Listing* (5.6) Fetches a list of user’s directories from RS. ¤ Retrieve Album Contents Listing (5.7) Retrieves the listing of files from wanted directory. ¤ Retrieve Single Item (5.8) Downloads an item from RS. ¤ Delete Directory (5.9) Deletes a directory and its contents from RS. ¤ Delete Item (5.10) Deletes a single item from RS. Our module implements only the minimum functionality, as this is sufficient for the mobile phone’s Image Uploader to work. From Figure 5.18 it is easy to see which files and classes implement each of the above functions. module.inc Gallery 2 has a modular architecture (see section 5.3.2), which allows the extension of functionality by just adding new modules. Using examples from the existing modules we started to create our own module. The only mandatory component of a module is a module.inc file. It must define a class that extends the GalleryModule class. Our module defines a class called NokiaUp- loadModule and it overrides some of its parent’s member functions. These functions and a short description of what they do are presented in the following list.
- 59. CHAPTER 5. CASE STUDY: GALLERY 53 ¤ NokiaUploadModule() is the constructor and it sets the id, name, version number, and the description of the module. ¤ install() updates the version number if the module has changed. ¤ needsConfiguration() checks if all the necessary parameters are set in the database. If they are, it returns false, meaning no configuration is needed. Otherwise it returns true. ¤ getConfigurationView() returns the name of the configuration view, in this case nokiaupload:Configure. The module.inc really is just the installer for the module. The real functionality is implemented in several other files. Initially, when we created the module, it had the structure shown in Figure 5.18. However, after we offered it to be included in the official Gallery 2 code base and it got accepted, the Gallery development team made some changes to it. The Gallery team added the configuration view (Config.inc) and the whole test direct- ory with all the unit tests. They also streamlined the module’s structure by combin- ing all helper classes in the ImageUploadApi.class file and renaming it to ImageUp- loadHelper.class. Constant definitions in constants.inc were moved there, also. Log- File.class was removed and the code was changed to use Gallery’s debug() function instead. Figure 5.19 shows the current structure after all these changes (some details are left out). 1 |_ DirectoryListing.inc 2 |_ Login.inc 3 |_ NewDirectory.inc 4 |_ README 5 |_ RemoteStorageCapabilities.inc 6 |_ Upload.inc 7 |_ constants.inc 8 |_ module.inc 9 +-classes/ 10 |_ ImageUploadApi.class 11 |_ LogFile.class 12 +-helpers/ 13 |_ DirectoryListingHelper.class 14 |_ LoginHelper.class 15 |_ NewDirectoryHelper.class 16 |_ RemoteStorageCapabilitiesHelper.class 17 _ UploadHelper.class Figure 5.18: Original structure of the Image Uploader module.
- 60. CHAPTER 5. CASE STUDY: GALLERY 54 1 |_ Configure.inc 2 |_ DirectoryListing.inc 3 |_ Login.inc 4 |_ NewDirectory.inc 5 |_ README 6 |_ RemoteStorageCapabilities.inc 7 |_ Upload.inc 8 |_ constants.inc 9 |_ module.inc 10 +-classes/ 11 | _ ImageUploadHelper.class 12 +-templates/ 13 | _ Configure.tpl 14 +-test/ 15 +-phpunit/ 16 |_ NokiaUploadConfigureControllerTest.class 17 |_ NokiaUploadDirectoryListingControllerTest.class 18 |_ NokiaUploadLoginControllerTest.class 19 |_ NokiaUploadNewDirectoryControllerTest.class 20 _ NokiaUploadUploadControllerTest.class Figure 5.19: The current structure of the Image Uploader module. The Module Functionality We take, as an example, the Image Upload API’s Retrieve Directory Listing com- mand to show how the module works. When a phone owner uses the Image Up- loader to upload images to Gallery 2, the phone first connects to Gallery and logs in. Then it asks the remote storage capabilties list where it chooses the Retrieve Directory Listing command. In our module’s case the command’s address is some- thing like http://server.com/gallery2/main.php?g2_controller= nokiaupload:DirectoryListing When Gallery receives this request it knows to look for the DirectoryListing.inc file (see Figure 5.20) in the modules/nokiaupload directory. Gallery reads the file and tries to load the DirectoryListingController class. If this succeeds, then Gallery calls the handleRequest() method of the class. This method returns an array con- taining three keys: delegate, status, and error. delegate tells Gallery which view to delegate the controller results to. In this case it is DirectoryListingView (also in Figure 5.20) in the nokiaupload module. status and error values are passed to the view. The status information is the directory listing returned from the getDirectoryListing() function (see Figure 5.21). error is meant for de- livering error messages from the controller to the template files to be displayed to the user. The upload module does not have a user interface so the error information is left empty.
- 61. CHAPTER 5. CASE STUDY: GALLERY 55 1 GalleryCoreApi::requireOnce( 2 dirname(__FILE__) . ’/classes/ImageUploadHelper.class’); 3 4 class DirectoryListingController extends GalleryController { 5 function handleRequest($form) { 6 $results[’delegate’] = array(’view’ => ’nokiaupload:DirectoryListing’); 7 $results[’status’] = ImageUploadHelper::getDirectoryListing(); 8 $results[’error’] = array(); 9 10 return array(GalleryStatus::success(), $results); 11 } 12 } 13 14 15 class DirectoryListingView extends GalleryView { 16 function isImmediate() { 17 return true; 18 } 19 20 function renderImmediate($status, $error) { 21 global $gallery; 22 23 $reply = array($status[’success’] . "rn"); 24 25 if ($status[’success’] == NOKIAUPLOAD_ERR_NOERR) { 26 $dirNum = count($status[’albums’]); 27 $reply[] = $dirNum . "rn"; 28 $reply[] = "3rn"; // Lines per directory (id, parent id and name). 29 foreach ($status[’albums’] as $album) { 30 $reply[] = ’DId=’ . $album[’id’] . "rn"; 31 $reply[] = ’PId=’ . $album[’parentid’] . "rn"; 32 $reply[] = ’DirName=’. $album[’name’] . "rn"; 33 } 34 } else { 35 $reply[] = "Couldn’t fetch directory list.rn"; 36 } 37 38 $reply = implode(’’, $reply); 39 header(’Content-Length: ’ . strlen($reply)); 40 print $reply; 41 42 return GalleryStatus::success(); 43 } 44 } Figure 5.20: Image Uploader’s Directory Listing controller and view in DirectoryListing.inc file. The code is fully functional but details irrelevant for this example have been left out. The getDirectoryListing() function fetches all IDs of the albums where the current user has permission to add data items i.e. pictures (line 12 in Figure 5.21). After checking that there were no errors we load the albums in line 19. Then, in lines 24-35, we go through all the albums and fetch the ID, name, and parent’s ID for each album. The function returns the album information along with the success code to the controller. This is the status that is then passed on to the view. The DirectoryListingView class in Figure 5.20 defines two functions. The isImmediate() function always returns true. This tells Gallery that no templates are used but this
- 62. CHAPTER 5. CASE STUDY: GALLERY 56 1 define(’NOKIAUPLOAD_PROTOCOLVERSION’, ’1.00’); 2 define(’NOKIAUPLOAD_ERR_NOERR’, ’0’); 3 define(’NOKIAUPLOAD_ERR_DIRLIST’, ’2’); 4 5 function getDirectoryListing() { 6 global $gallery; 7 8 /* Change the status to no error only if everything succeeds. */ 9 $status[’success’] = NOKIAUPLOAD_ERR_DIRLIST; 10 11 /* Get all album ids where we have addDataItem permission. */ 12 list($ret, $albumIds) = GalleryCoreApi::fetchAllItemIds( 13 ’GalleryAlbumItem’, ’core.addDataItem’); 14 if ($ret->isError() || count($albumIds) < 1) { 15 return $status; 16 } 17 18 /* Load albums and get their names. */ 19 list($ret, $albums) = GalleryCoreApi::loadEntitiesById($albumIds); 20 if ($ret->isError()) { 21 return $status; 22 } 23 24 foreach ($albums as $album) { 25 $id = $album->getId(); 26 $parentId = $album->getParentId(); 27 $name = $album->getTitle(); 28 if (empty($name)) { 29 /* If album doesn’t have a name set use the file system name. */ 30 $name = $album->getPathComponent(); 31 } 32 $name = GalleryUtilities::htmlEntityDecode($name); 33 $albumData[] = 34 array(’id’ => $id, ’parentid’ => $parentId, ’name’ => $name); 35 } 36 37 $status[’albums’] = $albumData; 38 $status[’success’] = NOKIAUPLOAD_ERR_NOERR; 39 return $status; 40 } Figure 5.21: Funtion getDirectoryListing() in ImageUploadHelper.class. The code is fully functional but details irrelevant for this example have been left out. module renders all output itself. Then Gallery calls the renderImmediate() function and passes status as a parameter. In lines 25-36 the album information is extracted from the status array and formatted for printing according to the fol- lowing model: errorcode<newline> NumberOfDirectories<newline> LinesPerDirectory<newline> DId=Id<newline> PId=PId<newline> DirName=Name<newline>
- 63. CHAPTER 5. CASE STUDY: GALLERY 57 5.6 Summary of Gallery Experiences Our project had two goals for our work on Gallery software. Firstly, we wanted to try out and demonstrate our ideas about mobile friendliness, and how to modify existing systems, even large ones, to adapt to the needs of mobile user agents. Gallery was chosen as one of our targets because of its great potential for mobile users and the popularity of the software. Secondly, we were interested to see how the ideas of mobile friendliness could be promoted in the open source software communities. Gallery 1 has many active developers and tens of thousands of users. Gallery has been developed for over three years and it has many useful features. However, as the devel- opment has been very incremental and without a clear plan from the start, Gallery has grown into quite a complex program. For that reason, the Gallery development team decided that a complete rewrite of the software was needed. After about two years of development, the first release, Gallery 2 Alpha, was made in July 2004. Gallery 2 has a modular extensible architecture and uses a database to store all the data. Most of our modifications were done in Gallery 1.4.3 but we also created an Image Upload module for Gallery 2. The first step on the way towards a mobile friendly Gallery was to make it aware of the mobile users. This was done by collecting a small database of user agent strings that identify the different types of mobile devices and their respective display sizes. The data was then made available to Gallery through two functions: isMobileUser() and screenSize(). The former returns true if the user agent string belongs to a known mobile device and latter returns the screen size of the mobile device. Next we could start to modify the user interface to a more suitable version for the mobile devices and their small screens. This meant making modifications to the lay- out and scaling images to smaller sizes whenever Gallery detects a mobile user agent. The layout modifications were mainly concerned with altering the tabular layout struc- ture, so that images and other items could easily be tiled in one or two columns were needed. This frees the user from horizontal scrolling of the pages which makes brows- ing much more convenient. Image handling was modified so that when users add new images to Gallery, mobile versions of these images are automatically created. Mo- bile thumbnail pictures are 80 pixels wide and fullsize pictures are 150 pixels. The original images, if they are bigger than that, are never sent to the mobile browser. We also added a small script that enabled us to test the mobile friendly Gallery with a desktop browser. The script adds a link to the Gallery’s main page where the user
- 64. CHAPTER 5. CASE STUDY: GALLERY 58 can force Gallery into the mobile or normal desktop mode. This makes it easy to demonstrate the modifications and their impact in both desktop and mobile browsers. The module we created for Gallery 2 implements the Image Upload Server API defined by Nokia. The module allows mobile phones that support the Image Up- load protocol to connect to Gallery and users can upload pictures straight from their phones to their Gallery account. Image uploader enabled mobile phones include the Nokia 3650 and 6600 models. We published the Image Upload module in the Gallery 2 discussion forum and offered it to be included in Gallery. The developers accepted the module and since Gallery 2 Alpha 2 it has been a part of Gallery. The Gallery team made some changes to the code to make it better fit in the Gallerys module system and coding standards. They also added test cases and a configuration view but for the most parts the code remained the same. Already, when not yet included in Gallery the module was available for downloading on our own server and some 20 people have downloaded it so far. One of them said: “This was really the module I was waiting for, although I didn’t know that three days ago. I never knew my nokia 6600 had an image uploader. This module makes things much easier than transfering through email.” The Upload module was our most notable contribution in making mobile friendliness better known in the Gallery development community. We had some discussion about mobile friendliness in the discussion forums but at least so far they have not produced any visible effect. Some of Gallery’s main developers seemed interested in the idea of mobile friendliness but their priority is to first get Gallery 2.0 ready and published. After that there is time to think through the mobile friendly concept and see how it can be best applied to Gallery. Our mobile friendly Gallery 1.4.3 is available on our website8 and has been advertised in Gallery discussion forums but has not resulted in any contacts from the Gallery developers. 8 http://mummola.cs.tut.fi/
- 65. Chapter 6 Case Study: LiveJournal One goal of our project was to add mobile friendly features to an existing open source web logging, also known shorter as blogging, service. LiveJournal (LJ) was chosen amongst several available blogging services based on its popularity. The beginning of this chapter concentrates in explaining what LiveJournal is, how it works and how it is being developed using communities as a channel of information. Later on we will introduce the reader with the programming languages behind LiveJournal before finally going into the solutions needed while implementing mobile friendly features on LiveJournal. 6.1 Overview Today blogging is a popular way to preserve your memories and daily events. It is pretty much the same as keeping a common diary or journal but it is done over the Internet. Blogging also provides a possibility to have joint diaries with your friends and a control over who can view certain entries in your journal. LiveJournal is one of the most popular blogging service providers today [38]. It has a wide user base totaling over three million bloggers where about half of them are from the United States. At the moment over one million of all those users are active which means they have updated their blogs during last 30 days. For LiveJournal this means that their servers receive approximately 250 journal updates per minute [19]. For this, and the 2.8 million requests per hour and other tasks, LiveJournal has about
- 66. CHAPTER 6. CASE STUDY: LIVEJOURNAL 60 80 computers running the whole system 24 hours a day, seven days a week (i.e. 24-7) [10]. Other popular blogging services include e.g. Blogger, xanga and tBLOG. LiveJournal offers two types of accounts for new users. A more favoured one is the Free Account which is, as the name says, free. The other one, named Paid Account, offers more features in return for the money paid for it. There also exists an account called Early Adopter for users registered before September 14, 2000 and a Perman- ent Account for LiveJournal staff. Everyone who is 13 years or older can create an account for themselves and start blogging. [17] Once an account has been created users can start to update their journals, upload some user pictures, generate a personal profile and define which other LiveJournal users are their friends. Users are given a possibility to find other bloggers by searching for them based on interests. It has been made possible for users to change the appearance of the pages, modify the looks of own journal and choose a preferred mood icon set to use with journal entries. Journal access can be defined as either public, private or friends only. Any combination of these is possible because the security level is defined one by one for each entry. If the security level is set to public everybody can view your journal entries. On the private level you are the only one allowed to view your entries. The friends only setting lets just those people who you have defined as your friends to read your journal. Once users have made some entries to their journals, other people, who have the right to view those journals or actually the entries in them, can post comments on the entries. Besides journals, users can create communities for common causes. All users interested in a specific topic, which a community has been created for, can make posts to it. In the case of the community being closed, users can not make posts to it before they have been accepted as members of the community by one of its maintainers. Furthermore, some communities have moderators who may reject member and non- member postings if they are not relevant for the community. [16] The features described above come with the Free Account. The Paid Account provides several more features. It gives users an access to a directory search that allows them to find other users based on location, journal update time, user’s age and some other options. A few other features provided include an increased number of allowed user pictures, the possibility to embed polls into journal entries, a LiveJournal email ad- dress and text messaging to other LiveJournal users. [16] LiveJournal is an open source web based application. Because the source code is open it means that anyone can get it for free and set up their own LiveJournal web server.
- 67. CHAPTER 6. CASE STUDY: LIVEJOURNAL 61 For the development and source code repository there is livejournal.org which is the “non-profit” wing of livejournal.com [21]. livejournal.org offers the latest version of the source code straight from the CVS (Concurrent Version System) repository or as a downloadable package including an older, but without fail, stable version of the source code. 6.2 Architecture LiveJournal uses Apache’s version 1.3.x with version 1.x of mod_perl to run the service. For registered users’ information, journal entries, etc. LiveJournal uses a MySQL database. The software and functionality behind LiveJournal can be divided into three sections: basic pages, journal pages and a number of CGI scripts and Perl modules. The first one is, as we call it, basic pages which are webpages like login, logout, update journal, edit friends, edit personal info and to-do. This section contains the functionality which handles the user interface, both the look of it and any inputs initi- ated by users. The majority of these pages are created using Better Markup Language (BML, section 6.4.2). The second section contains journal pages, which differ from basic pages because they are created using Style System 2 (S2, section 6.4.3) instead of BML and they all concern the actual journal. As for basic pages, this section handles user inputs and the look of the interface for journal pages. The third and final section consist of CGI scripts, written in Perl (section 6.4.1), and some Perl modules which both are used by basic pages and journal pages to help in creating their content, identifying users, updating journals, handling inputs, etc. 6.3 Developers & Communities According to livejournal.com there is currently a core group of eight people devel- oping LiveJournal [18]. Besides these guys there are about fifty hackers who make contributions for LiveJournal by sending in patches [20]. When LiveJournal is con- sidered, hacker is a word used to describe those programmers who do their own modi- fications to the software.
- 68. CHAPTER 6. CASE STUDY: LIVEJOURNAL 62 One written rule for LiveJournal hackers is to talk about the changes they are about to embark on or just did at LiveJuornal’s lj_dev community to avoid duplicate work [21]. And what would be a greater place to discuss about development than using LiveJournal’s own community feature for it? Not only hackers but also other re- gistered LiveJournal users can post to and comment on this community as long as their messages continue to be appropriate. lj_dev is not the only community that is related to the development process of Live- Journal. suggestions is a community where registered LiveJournal users can make suggestions about what would be a cool new feature or what should be changed from the current version in order to make LiveJournal even better. Another community that is closely tied up to the development process is lj_test. This community is a place for the developers and hackers to announce and discuss recent code changes to the LiveJournal Test Server1 . [17] There are also many more communities which are somehow connected to the devel- opment process of LiveJournal. lj_sysdoc and lj_userdoc are communities where a conversation about the documentation project is kept up by the developers. Common topics could be the use of XML in documentation, contents of guides and FAQ, and errors on documentation. Again it is possible for regular LiveJournal users to tell their opinion about documentation by issuing comments. lj_support is a community for LiveJournal volunteers to discuss the possible ways to help people to use the site. It is not, though, a place for regular users to ask questions about how to use the site. Other LiveJournal related communities exist also but they are not so important from our project’s, nor LiveJournal development’s, point of view. [17] 6.4 Programming Languages LiveJournal has been mainly built using three different programming and markup lan- guages. These languages are Perl, BML and S2. What each language’s purpose is in LiveJournal and what kind of languages they are will be described in the following subsections. Besides the obvious use of HTML, some JavaScript is also used to help out the design and functionality of the user interface. For database querying Live- Journal uses SQL (section 5.2.3). 1 http://test.livejournal.org/
- 69. CHAPTER 6. CASE STUDY: LIVEJOURNAL 63 6.4.1 Perl First we take a look at Perl which definitely is the only well-known one of these three languages. The word “Perl” is not really an acronym but it has become one, well actually a backronym, because people have invented meaning for its each letter afterwards. Anyway, Perl is short for “Practical Extraction and Report Language” but it has also been referred to as “Pathologically Eclectic Rubbish Lister”. Both have been endorsed by Larry Wall, the developer of Perl, so there is no point in arguing which one is correct. One of Perl’s mottos goes “There’s more than one way to do it” and with our experience of Perl we could say it is absolutely true. LiveJournal uses Perl e.g. for database operations and for help on generating the user interface. [37][41][3] Originally Perl was developed by one man, Larry Wall, and it was released in 1987 when he also decided to make the compiler and the source code free for everyone. Ever since Perl has been publicly available and until nowadays it has been distrib- uted under GNU General Public License and Artistic License. From its release date Perl has gained a huge number of fans and some of them have even made their own contributions for Perl by developing it further. This is mostly shown in the number of optional Perl modules. There are hundreds of modules freely available at CPAN2 (Comprehensive Perl Archive Network). [4] Perl is designed to have good and strong text processing abilities. This is one reason why the language has become popular amongst programmers writing CGI scripts. Be- sides web programming and text processing, Perl is widely used in graphical interface programming, database access and system utilities. Perl is an interpretive language and its interpreter is written in C. This is no surprise when you consider the fact that Perl derives from C. Amongst many other tools and languages Perl also has herit- age from sed and awk. Like most other modern programming languages Perl also has object oriented features. However, the difference between regular Perl and object oriented Perl is not that big as it is between C and C++. [3][4] 6.4.2 BML - Better Markup Language The motto for BML is [9]: BML - “Because smart webmasters are lazy webmas- ters.. . ”. The following paragraphs will describe some characteristics of this lan- 2 http://www.cpan.org
- 70. CHAPTER 6. CASE STUDY: LIVEJOURNAL 64 guage and also, in parallel, try to reveal if the motto is true or not. BML was mostly developed by Brad Fitzpatrick, Brad Whitaker and Matt Wilson. It was designed to help to make a consistent looking website and alleviate their maintenance, and also because HTML code looks ugly [9]. BML is a server-side markup language which means, in practice, that BML files are converted to HTML on the server before send- ing them to the client. Actually, a BML file is an HTML file with some BML blocks in it. A block is just another name for a macro, so BML can also be called as a simple macro language. Blocks consists of chunks of HTML and possibly other BML blocks. [8][9] BML blocks can take parameters, which allows programmers to use blocks as tem- plates. Because of the fact that BML blocks are executed on the server it is also possible to write blocks that are not just static but dynamic. Within the BML system there are a few core blocks that are predefined, waiting for programmers to use them. One of these blocks and presumably the most useful is the main core block called _CODE. This block allows execution of Perl code within the BML file. Perl code is also executed on the server and the result must be either BML, which is then converted to HTML, or HTML. [8] The main purpose of BML is to help in creating and maintaining a consistent look throughout a website. It allows users to define a header style, for example, and whenever the style is used it produces the same kind of headers. If users should want to change the style of their header, all they have to do is to make the change to one place. This is the reason why BML is used in LiveJournal, to help in making a similar look over the pages (excluding the user customizable journal pages). [8] 6.4.3 S2 - Style System 2 S2 is a programming language that gives users and programmers full control over the appearance of their content. In other words it helps programmers and users to cus- tomize the look of their layouts. Also, simple games like Tic Tac Toe have been im- plemented by just using S2. The language was developed mostly by Brad Fitzpatrick and Martin Atkins. It was developed for the journal pages of LiveJournal and for a photo-hosting service called FotoBuilder but it could also be used in various other projects as well. The language’s syntax mainly resembles Perl, C++ and Java. S2 is actually a second, yet completely different and rewritten, version of the LiveJournal original template engine which is now referred to as Style System 1 (S1). S1 is still
- 71. CHAPTER 6. CASE STUDY: LIVEJOURNAL 65 used in LiveJournal along with the new style system S2 because not all users have updated their journals to S2. [42][6] S2 is an object oriented programming language which therefore allows declaration of classes with member functions and variables along with normal variables and func- tions. S2 source code is compiled into Perl and executed on the server during requests. Some S2 functions have been specified as built-in functions and are written in Perl. These functions form an environment which is called the S2 subsystem. S2 introduces a new feature to programming languages called properties, which are not specific to object or class but to a layer. Properties can be strings, integers, hex color codes, etc. S2 includes six layers: core, i18nc (i18n is short for internationalization because there are 18 letters between ’i’ and ’n’; letter ’c’ stands for core), layout, i18n, theme and user (Figure 6.1). Each layer has a specific meaning and some of them inherit functions, variables and properties from other layers. [42][6] All S2 layers have a different purpose and they are listed on the following list [42]: ¤ core is the root layer. It gives default implementation to all classes and member functions specific to the whole website. ¤ i18nc is core’s internationalization layer. The core itself is in one language and every i18nc layer adds one new language to it. This can be done by overrid- ing the textual string properties in the core simply by just translating them to another language. ¤ layout specifies one particular layout. In other words it describes how the pages should look like. layout is a subclass of core and as in other object oriented languages, in S2 new member functions and variables can be added while in- troducing new properties and overriding old member functions and variables. ¤ i18n is a subclass of layout. Like i18nc is to core, i18n is to layout. In other words every i18n file adds one new language to the layout layer. ¤ theme is also a subclass of layout. Its meaning is to provide a set of suggested values for layout’s properties. It is mainly used to provide color themes but also other properties can be overridden. ¤ The user layer also inherits layout’s functionality. It is meant to store user’s preferences.
- 72. CHAPTER 6. CASE STUDY: LIVEJOURNAL 66 usertheme i18n i18nc layout core Figure 6.1: Hierarchy of S2 layers. S2 also offers a method for documentation within the source code. After every func- tion, variable, property and header of class there is the possibility to enter a small chunk of text to describe its meaning or functionality. From these pieces of text a short documentation can be generated automatically. Another feature S2 provides is a web user interface which allows users to easily change the values of their layout’s properties. [42] 6.5 Mobile Friendly Features Amongst the huge number of LiveJournal users there are also users who own mobile devices and would like to use the service also with these devices. That was the prob- lem we started to work on, how to get the site’s content suitable also for devices with a smaller display. This section describes how the mobile devices are recognized with the use of a user agent string, how layout issues were solved, what kind of problems we encountered during the process, and what were the results on implementing the mobile friendly version of LiveJournal. 6.5.1 User Agent Recognition The first thing on our way towards a mobile friendly LiveJournal is to determine whether a device requesting a webpage is a mobile device or a regular desktop com- puter. Next we needed to find out a suitable place to do this. Because LiveJournal is
- 73. CHAPTER 6. CASE STUDY: LIVEJOURNAL 67 1 my $user_screen_size = undef; 2 $useragent = CGI::user_agent(); 3 foreach $key (@screensizekeys) { 4 if($useragent =~ $key) { 5 $user_screen_size = $screensizes{$key}; 6 last; 7 } 8 } 9 return $user_screen_size; Figure 6.2: Finding device’s display dimensions based on the user agent string. divided in two sections, basic pages and journal pages, we actually need to find two different places to detect devices. For basic pages this place would be the beginning of each page i.e. each BML file and for journal pages it would in the file S2.pm in the function make_journal(), where it is decided which kind of journal will be shown. The actual recognition of mobile devices is done in mobile.pl by function isMobi- leUser() which then calls function screenSize(). First the user agent string of a device is acquired by using function user_agent() from the Perl’s CGI mod- ule. (Figure 6.2). Next we compare the acquired user agent string against known mobile device identifiers which are located in a table called @screensizekeys. If a matching identifier is found during the search process, we stop searching and return the corresponding screen size. On the other hand, if none is found, the device in ques- tion is either an undefined mobile device or a regular desktop computer and we return undefined value. [14] @screensizekeys is a table structure which has regular expressions as values. These regular expressions work as keys to a hash called %screensizes which holds the actual width and height values of devices’ display dimensions (Figure 6.3). The regular expressions either match to individual devices, a group of devices (e.g. all Series 60 mobile phones) or to some more general identifier like an operating system or a web browser. [14] The order of the @screensizekeys table is crucial. First needs to come individual identifiers (Figure 6.3, line 1), then more general identifiers like device groups (lines 2-3) and finally “global” identifiers like operating systems (line 4). If the table would not be arranged in correct order, e.g. some device could be matched by its unique identifier and it could also be matched by its operating system. Because one regular expression may be matched only with one dimension value, it is not guaranteed that the more general identifiers will give the right dimensions for devices, i.e. identifiers
- 74. CHAPTER 6. CASE STUDY: LIVEJOURNAL 68 1 my @screensizekeys = (".*?IndividualDevice.*?", 2 ".*?Series ?60.*?", 3 ".*?Series ?90.*?", 4 ".*?Symbian ?OS.*?"); 5 my %screensizes; 6 $screensizes{".*?IndividualDevice.*?"} = 7 {"width" => 240, "height" => 180}; 8 $screensizes{".*?Series ?60.*?"} = 9 {"width" => 176, "height" => 208}; 10 $screensizes{".*?Series ?90.*?"} = 11 {"width" => 640, "height" => 320}; 12 $screensizes{".*?Symbian ?OS.*?"} = 13 {"width" => 176, "height" => 208}; Figure 6.3: Table and hash for known mobile device identifiers. like operating system and web browser are used more as a fall-back, a guess, if no individual identifiers for devices are found. The order of the %screensizes hash is not so important because Perl randomizes hashes anyway for better performance. The only reason keeping it in the same order with @screensizekeys table is that it is easier to maintain. [14] Adding new devices has been made easy. First you have to know the user agent string of the device you are adding, e.g. lets add device with user agent string Mozilla/4.51 (compatible; Opera 3.62; IndividualDevice; 240x180). In this particular case a suit- able regular expression for the user agent string would be “.*?IndividualDevice.*?”. Because the identifier in question is individual it should be placed at the beginning of the table, before device groups and “global” identifiers. Lines needed to be added are shown in italic font in Figure 6.3. The recognition of mobile devices is done differently on basic and journal pages. On basic pages it is done at the beginning of each page so that a suitable layout for the page can be chosen. For journal pages the recognition is done when creating an individual journal page. More of where the recognition is done will be described in sections 6.5.2 and 6.5.3 along with how the correct layout is chosen based on the information gained from the user agent string. 6.5.2 Layout for Basic Pages LiveJournal has two types of layouts. One is called scheme, and it creates the general look for all basic pages using BML. The other ones are called layouts which generate the look for individual journals using S2, one layout per one journal (This is explained
- 75. CHAPTER 6. CASE STUDY: LIVEJOURNAL 69 1 <?_code 2 require "$ENV{’LJHOME’}/cgi-bin/mobile.pl"; 3 my $width = mobile::screenSize()->{’width’}; 4 $ret .= ’<DIV STYLE="width:’ . $width . 5 ’px; FONT-SIZE: 10pt;">’; 6 return $ret; 7 _code?> Figure 6.4: Setting width of a page using <div> tags. in more detail in subsection 6.5.3). The basic idea is that we have a regular desktop version and a mobile friendly version of every page and when the time comes we decide which version to show. Furthermore, because there are various sized displays amongst mobile devices, the mobile friendly version has been made to adapt its look depending on the width of the display. The general layout for basic pages is generated using schemes which use BML. A few schemes exist that come with the LiveJournal installation. One of these, named bluewhite.look, was made mobile friendly during our project. The scheme holds the information on what is the general look of a page. In the bluewhite.look scheme there is a menu bar on the left edge of the page and the remaining space is reserved for the content of single pages. There is also, on the top of the page, the title of the current page and a background image which fades from blue to white (this is where the name bluewhite.look comes from). Later on in this section we will illustrate the look of a basic BML page that is using bluewhite.look. In order to make the bluewhite.look scheme mobile friendly the menu bar is needed to be extracted from the rest of the content. This was simply done by copying the functionality to create the menu bar from the bluewhite.look scheme and adding it into a new scheme called mobilemenu.look. The content part of the bluewhite.look scheme was used to create another scheme called mobilepage.look, which generates the content of a single page when mobile mode is used. These two created schemes have only one common element, which is printing the title and the background image. Later on in this section we will illustrate the looks of basic BML pages that are using mobilepage.look and mobilemenu.look. One fundamental addition we made to the mobilepage.look scheme was how to control the width of the page (Figure 6.4). We ended up using <div> tags where the width is set using a style and width attribute (line 4). Correct width, i.e. the width of present device’s display, to be used is acquired using screenSize() from mobile.pl. Doing just this, unfortunately, is not enough to set all the content on every BML page to the
- 76. CHAPTER 6. CASE STUDY: LIVEJOURNAL 70 1 <?_code 2 require "$ENV{’LJHOME’}/cgi-bin/mobile.pl"; 3 mobile::set_scheme(); 4 return; 5 _code?> Figure 6.5: Scheme is set at the beginning of each BML file. correct width, e.g. LiveJournal uses a lot of HTML <table> structures which easily makes the content exceed the allowed width for mobile devices. We take a closer look at this problem later on in this section. At this point we had separate schemes for menu and content. Next we needed to implement a way for users to switch between these two schemes. A solution for this problem was to place two links, menu and page, below the title of the page, one that changes from menu to page and vice versa. Only one of these links is active at a time, i.e. if the user is viewing the menu only page link is active and vice versa. Also, when the user presses a link on the menu we need to change the scheme to mobilepage.look in order to avoid an awkward situation where the user would first press a link on the menu and then one has to press the page link to view the content. When any of these menu, page or link on the menu, is pressed it launches the setforce.pl script. The setforce.pl script can take three types of parameters but only one at a time is needed. Possible parameters are tab for switching between menu and page, site for the location to go to when a link on the menu is clicked and force for forcing between mobile and desktop modes. Forcing is not essential for the application to work properly and it is mainly used for debugging and demonstrating mobile mode on desktop browsers. setforce.pl reads the parameter given to it using Perl’s CGI module and creates two cookies based on the parameter, $scookie for scheme and $fcookie for forcing. Finally, at the end of the script force and scheme cookies are set and the user is redirected back to a suitable location. This location is the same page where the user was if the menu, page or forcing link was selected, or if the user clicked a link on the menu, one is redirected to the page requested. The force-cookie tells us whether we should be in automatic, mobile or desktop mode. Respectively, the scheme-cookie tells us whether we should use bluewhite.look, mo- bilepage.look or mobilemenu.look scheme. At the top of every basic page, or BML page, we added a BML code block whose task is to set the correct scheme before the page is sent to the client (Figure 6.5). First it includes functions from mobile.pl and then uses its function set_scheme() which sets the scheme. The code block
- 77. CHAPTER 6. CASE STUDY: LIVEJOURNAL 71 1 sub set_scheme { 2 my $scheme = cookie(’scheme’); 3 if($scheme && $scheme ne BML::get_scheme()) { 4 BML::set_scheme($scheme); 5 } 6 elsif(mobile::isMobileUser()) { 7 BML::set_scheme(’mobilepage’); 8 } 9 else { 10 BML::set_scheme(’bluewhite’); 11 } 12 return; 13 } Figure 6.6: Setting the scheme based on scheme-cookie’s value. was first attempted to be inserted to scheme files (i.e. to each *.look file) but for some reason this did not work properly, maybe because it ultimately did not have enough control over a BML file. The results for that approach were unwanted as sometimes a cached version of a page was loaded or a page was in the wrong mode, i.e. a mobile version was shown although we should have shown a desktop version. Function set_scheme() (Figure 6.6) reads the value of scheme-cookie which was set by the setforce.pl script whenever the user did an action where one requested the scheme to be changed. After reading the cookie, the value function sets the scheme using BML package’s set_scheme($scheme) function. In the case the scheme is not set, i.e. when a user enters the site for the first time or has removed the cookie, the else-if part is used and the correct scheme is set according to whether a mobile or a desktop user is present. At this point we are pretty far in modifying mobile friendly features to basic pages. Next we have to adjust the content of individual BML pages. The main problem in LiveJournal’s case is the abundant use of HTML <table> structures. It easily produces structures which are too wide for mobile devices with a small display (e.g. Series 60 mobile phones). A solution which resolves this problem is to alter the table structures so that their adjacent cells are shifted to consecutive rows when a mobile user is present. On the other hand, this creates a new problem but luckily only a minor one. Without good design the new modified table and its cells may become ambiguous in what they stand for. When everything is put to just one column you have to be sure that users can still tell the meaning of each table cell without having to trouble their minds too much. Next we will try to illustrate how a table structure is modified when going from a desktop version (Figure 6.7) to two different sized mobile versions (Figure 6.8). Note that
- 78. CHAPTER 6. CASE STUDY: LIVEJOURNAL 72 Figure 6.7: A basic BML page in the original desktop mode. the table cells in these pictures have been framed with black rectangles to clarify the situation. The horizontal line appearing in the smaller mobile version is not part of the original table but instead it tries to help the user to identify which table cells belong logically together. Along with the table problem, HTML components like text fields, text areas, select boxes and buttons with lengthy texts caused some difficulties. For text fields and text areas the resolution was quite simple. Depending on the situation, the width of these components were either set to be static or dynamic. In the case of dynamic, the width is determined by the width of a present mobile device’s display. In the case of static, we had to be sure the components would be perfect the way they are no matter how wide the present device’s display is. For too wide select boxes or buttons two types of solutions were applied. First the width of a component could be reduced by setting a smaller font for it. The other resolution for buttons was to make them narrower by using a different, shorter, button text. For select boxes the other solution was to use the same idea that was used with text fields and text areas: set the width to static or dynamic depending on the situation. Figure 6.9 includes a piece of code where a dynamic width is set for a component when the user is in mobile mode. In this case the width for the component is calculated using a linear function where a line intersects y-axis at 9. The slope is a quarter from
- 79. CHAPTER 6. CASE STUDY: LIVEJOURNAL 73 (a) 176 pixels (b) 376 pixels Figure 6.8: Two different width versions of the mobile layout. 1 require "$ENV{’LJHOME’}/cgi-bin/mobile.pl"; 2 #make long text boxes.. 3 if(mobile::isMobileUser()) { 4 my $width = 9 + int(mobile::screenSize()->{’width’} / 25); 5 #..shorter for mobile devices. 6 $opts->{’size’} = $width > 30 ? 30 : $width; 7 } Figure 6.9: Defining dynamic width for a component. 100 while x-axis is operating as display width. Furthermore, we wanted components no longer than 30 units wide, so we placed a delimiter for that (line 6). On a Series 60 phone the component would become 16 units wide because the result is eventually truncated. Mobile friendly schemes (mobilepage.look and mobilemenu.look) were designed to operate best between 176 and 640 pixels wide displays. For example, the menu bar will fit nicely to a 176 pixels wide display, and when the display size increases, the menu bar will adjust itself to multiple columns whenever there is enough space to do
- 80. CHAPTER 6. CASE STUDY: LIVEJOURNAL 74 (a) 176 pixels (b) 526 pixels Figure 6.10: Two different width mobile menus. that (Figure 6.10). Any displays smaller than 176 pixels are not guaranteed to work equally well because we did not have a device to test it with. For wider displays, i.e over 640 pixels, the schemes should operate quite smoothly but eventually, while the display width increases, one has to decide when the scheme should be switched back to the original scheme (bluewhite.look). It seems that 800 pixels would be the point to do that. 6.5.3 Layout for Journal Pages The look of a journal is determined by a layout. Various layouts exist that come with a LiveJournal installation. There are two types of layout, ones that are generated using S1 and ones that are generated using S2. Because S1 is the old style system and very toilsome to implement the kind of changes we wanted to do, we decided to leave it the way it is. Instead, the new style system, called S2, includes eight layouts and five of them were made mobile friendly during our project. In Figures 6.11 and 6.12 you can see how some of these layouts look like in their original form, in desktop mode. Next we will describe the modifications and additions we needed to do in order to achieve our goal, i.e. mobile friendly journals. The results
- 81. CHAPTER 6. CASE STUDY: LIVEJOURNAL 75 Figure 6.11: Generator layout in desktop mode. Figure 6.12: Penquin Elegant layout in desktop mode. are shown in Figure 6.13, which shows the mobile friendly versions of journals in Figures 6.11 and 6.12. Due to the fact that there are many S2 layouts to choose from, we decided to first start working on Generator layout, which was the best looking layout in our opinion. Later we made some other layouts mobile friendly as well. After some careful testing we came to the conclusion that it is not worth the effort to add mobile friendly features
- 82. CHAPTER 6. CASE STUDY: LIVEJOURNAL 76 (a) Generator (b) Penquin Elegant Figure 6.13: Mobile friendly versions of the journals in Figures 6.11 and 6.12. into an existing layout. Instead we decided it would be better to generate our com- pletely own mobile version of the layout. In the case of the Generator layout this was done by copying the code of the original layout and modifying it to suit the needs of mobile devices. We named this new layout simply as Generatormobile. Like in the basic pages where we set the width for pages, we also had to do it here. Our initial problem was how to get the width of a mobile device’s display to S2 layout. After a long while of searching we found a way to pass it as a property (properties
- 83. CHAPTER 6. CASE STUDY: LIVEJOURNAL 77 1 require "$ENV{’HOME’}/cgi-bin/mobile.pl"; 2 if(mobile::isMobileUser()) { 3 $ctx->S2::PROPS->{’screen_width’} = 4 mobile::screenSize()->{’width’}; 5 } Figure 6.14: Setting screen_width property for layout. 1 #first the screen_width property is declared 2 property int screen_width { 3 des = "tells how wide the screen is in pixels"; 4 } 5 ... 6 function Page::print() { 7 #later in print function screen_width is used 8 #to set box_width which controls journal’s width 9 if($*box_width > $*screen_width) { 10 $*box_width = $*screen_width; 11 } 12 ... 13 } Figure 6.15: Defining property for display width and using it to control journal’s width. were previously discussed in section 6.4.3) (Figure 6.14). First we needed to define this new property for the layout (Figure 6.15, lines 2-4) so that we were able to use it later e.g. when defining the width for the journal (line 10). Now we were able to set the perfect width for the journal but like in the case of basic pages it did not have the full control over the content and again some wide table structures, text fields, etc. were in our way. Fortunately we already had dealt with this problem before and the same solutions worked here as well. The next problem was how to show the mobile version of the layout when the user is in mobile mode. Without any modifications the desktop version of the journal would be shown always. This problem was solved by modifying module S2.pm, which is also known as LJ::S2 package, and its function s2_context. This function has a place where the selection between mobile and desktop versions can be made. Users have their preferred layout which is stored in a database. This information, or actually the layout’s ID, can be extracted from the %style hash while layout is operating as a key (Figure 6.16, lines 12-13). If the user is in mobile mode we need to change hash’s layout value. This is only done if it is possible, i.e. if the layout the user uses has been made mobile friendly (line 16). The actual change is made simply by searching a layout amongst all public layers which includes the name of the current layout and ends with a word “Mobile” (lines 18-28). Once the correct layout comes across the
- 84. CHAPTER 6. CASE STUDY: LIVEJOURNAL 78 1 sub s2_context 2 { 3 my $r = shift; 4 my $styleid = shift; 5 my $opts = shift; 6 my $dbr = LJ::get_db_reader(); 7 my %style = get_style($styleid); 8 require "$ENV{’LJHOME’}/cgi-bin/mobile.pl"; 9 if(mobile::isMobileUser()) { #only for mobile users 10 my $pub_layers = LJ::S2::get_public_layers(); 11 my $cur_layout_name = 12 $pub_layers->{$style{’layout’}}->{’name’}; 13 #check only mobile friendly layers: if ’ (m)’ at end 14 if($cur_layout_name =~ s/(.*) ¥ /$1/) { 15 #go through all layers 16 foreach my $id (keys %$pub_layers) { 17 #if numbers only, name ends with Mobile and 18 #it includes current layout’s name 19 if($id =~ /^+.$/ && 20 $pub_layers->{$id}->{’name’}=~/Mobile$/ && 21 $pub_layers->{$id}->{’name’}=~/$cur_layout_name/){ 22 #set layout to founded layout id 23 $style{’layout’} = $id; 24 last; 25 } 26 } 27 } 28 } 29 ... 30 } Figure 6.16: Changing to mobile friendly layout. layout’s ID is set to %style hash (line 25) which is later on used in generating the journal layout. After we had successfully finished with altering the Generator layout to a mobile friendly version, we used the same approach to make layouts Classic, Magazine, Pen- quin Elegant and Tabular Indent also mobile friendly. Without few minor problems, caused by different construct of the layouts, we succeeded in our task. 6.6 Summary of LiveJournal Experiences LiveJournal is a blogging software that we wanted to make some modifications to. These modifications included recognizing the devices that are using the site and ad- justing the layout accordingly, i.e. creating dynamically a layout that is the same width as the devices’ display. Perl, BML and S2, the languages behind LiveJournal, were new acquaintances to us and we got to know them well on our way to a mobile friendly
- 85. CHAPTER 6. CASE STUDY: LIVEJOURNAL 79 version of LiveJournal. Another goal for our project was to get our modification to be a part of the LiveJournal’s open source distribution package. The first part of this project, recognizing devices accessing the site, was pretty easy and straightforward to implement. Basically all we needed to do there was to acquire device’s user agent string and match it against all known identifiers. Identifiers on the other hand are keys to get devices’ display dimensions which then can be used in creating proper layouts for devices. The second part included the actual creating of mobile layouts for basic and journal pages. LiveJournal developers have used a lot of HTML tables in the layout design. This made it harder for us to create mobile layouts because it was difficult to fit these table structures to a small display. Also, we had to change the way some of the content was represented because here also the abundant use of HTML tables was present. Besides getting the layouts to function properly, we needed a way to “turn on” a mobile layout when a mobile device is present. We already had implemented func- tionality to recognize present devices and all we needed to add was a way to keep track which mode, mobile or desktop, should be used. For that we simply placed information in a cookie as to which mode should be on. Using cookies was not a problem because LiveJournal was already utilizing some other cookies as well. After we had finished all the modifications we wanted, or actually some time before that, it was time to inform some of the LiveJournal communities about the work we had done. So far interest from that direction has been, unfortunately, almost non- existent. Most people, i.e. LJ users, like the idea and have nothing against it but only a couple of LiveJournal developers have shown some more interest by saying they would want to view the code behind Mobile LiveJournal. Again, unfortunately, no word from those persons has been heard since. Even though our mobile friendly version of LiveJournal is a fully functional package, it did not seem to be enough. There might be several reasons why we were not able to inject our modification to be a part of LiveJournal’s open source distribution pack- age. One reason, which we think can be named as the most presumptive one, is that LiveJournal has also a commercial version of its software which is maintained by the same developers as is the open source version. During our project we were able to notice (by watching communities) that LiveJournal developers were more focused on the commercial version than the open source distribution. Also, the same developers are implementing a software called FotoBuilder which is a kind of a photo hosting service to be run along-side LiveJournal. There is a conclusion we can make from
- 86. CHAPTER 6. CASE STUDY: LIVEJOURNAL 80 this: the developers do not have enough time to work on the open source distribution. Therefore, they do not have the time nor resources to waste on reviewing our modific- ation of LiveJournal and whether it should be a part of the open source distribution, and maybe even a part of the commercial version. Despite the fact that we were not able to inject our code to the official open source distribution of LiveJournal, we distribute our mobile friendly version of LiveJournal on our web server3 and learned a great deal of valuable knowledge about mobile friendliness. That knowledge can be used in projects to come, not only by us but also all those people who happen to read this thesis. 3 http://mummola.cs.tut.fi
- 87. Chapter 7 Conclusions In this thesis we have defined the ‘term mobile friendliness’ and shown how the cur- rent Internet is not very mobile friendly. We have also discussed how some of the available Internet standards, such as XHTML and CSS, could be used to create mo- bile friendly web services. Open source software provided us an opportunity to test out our ideas with real life examples. We presented two case studies where we have modified programs to be mobile friendly and have described how the development communities reacted to the concept. First we described the problems that users of mobile devices encounter when trying to access the Internet with their device. Usually webpages download slowly and they are difficult to navigate because they require users to scroll pages both vertically and horizontally. These problems result from the limited capabilities, especially the dis- play size, of the mobile user agents, the limited mobile network bandwidth, and the technologies used on websites. One solution that has been offered is WAP. While be- ing a technically good concept, WAP requires a lot of extra work from the website’s owner. This limits the available WAP content on the Internet. We defined mobile friendly web service as a service that provides the mobile device users with the same, or as close as possible, user experience as when using the same service with a desktop browser. In practise this requires altering the layout and scaling images based on the user agent. We then outlined how the new Internet technologies XHTML and CSS could be used when creating new web services. New mobile devices that are equipped with an In- ternet connection, also usually have an XHTML browser. XHTML is a powerful and
- 88. CHAPTER 7. CONCLUSIONS 82 robust markup language for webpage design. When combined with media dependent CSS and a careful design, the same page can serve both mobile and desktop users. Open source software (OSS) is freely available for anyone to use and even modify. Commercial software does not, in most cases, allow this and therefore OSS provided us with an excellent possibility to test the concepts of mobile friendliness in practise. The two programs that we chose, Gallery and LiveJournal, are both distributed under the GPL, a popular open source license. Gallery is a picture gallery software and LiveJournal is a web logging system. These programs are widely used on the Internet and they both offered great potential to be useful services for mobile users. An important part of providing mobile friendly services is to recognize the mobile user agents. This was the first modification we did in both Gallery and LiveJournal. The mobile user recognition consists of two parts: a database of user agent strings and their respective display sizes, and an interface to that data. The interface has functions to tell whether a user agent is mobile or not and what its display size is. The user agent information is then used to modify the layout so that a mobile user does not need horizontal scrolling when using either Gallery or LiveJournal. In Gallery we modified the image handling so that mobile users get smaller versions of the images. The mobile versions are small enough to fit on the small display, and also use less bandwidth so the page downloads faster. When new images are uploaded to Gallery they are scaled to mobile versions in addition to the normal desktop thumbnail and intermediate sizes. This slows down the upload process but speeds up viewing the mobile version of the page. We also created a module for Gallery 2 that implements the Image Upload Server API defined by Nokia. Some Nokia mobile phone models, such as 3650 and 6600, in- clude an Image Uploader. With our module, users of these phones can upload pictures straight from their camera phones to an album in their Gallery account. We published the module in Gallery discussion forums and it was well received. With small modi- fications it was included in the Gallery code base and was distributed with the Gallery 2 Alpha 2 release. Part of our project was to promote the ideas of mobile friendliness in the developer communities of both Gallery and LiveJournal. They both have many active developers and a great number of users, but there are also differences. LiveJournal has a com- mercial version as well as the open source version, and it seems to occupy a lot of the developers time. We announced our mobile friendly LiveJournal in their discussion
- 89. CHAPTER 7. CONCLUSIONS 83 forums but got very little feedback. Only a few people were interested in seeing the code but nothing was heard from them later. Conversely, Gallery developers were very active in their forums to answer questions and comment on new ideas. We discussed about mobile friendliness in Gallery’s for- ums with some of the core Gallery development team members. The comments were positive and encouraging but did not lead to any actual changes in either Gallery 1 or Gallery 2, except the Upload module. The developers explained that their prior- ity was to get Gallery 2 ready for a final release before considering any non-critical modifications to the core functionality. We learned that modifying existing software to be mobile friendly is not very difficult. It requires effort, especially if the system is new to the programmer, but it is well worth it, considering the added value it provides to the expanding population of users with mobile devices. Also, based on our two case studies, it seems that when trying to promote new ideas in open source communities, at least two things have an efect on the outcome. Firstly, working code contribution is always better than even a very good idea. Secondly, even a good code contribution may not be enough if the community is not open to outside ideas.
- 90. Bibliography [1] BerliOS Developer. Fostering Open Source Development. www: http://developer.berlios.de/. Accessed: 2004. [2] Bos, Bert et al. CSS2 - Cascading Style Sheets, level 2 Specification. www: http://www.w3c.org/TR/CSS21/. Accessed: October 2004. [3] Christiansen, Tom & Torkington, Nathan. perlfaq1 - General Questions About Perl. PerlDoc. May 1999. www: http://www.perldoc.com/perl5.6/pod/perlfaq1.html. Accessed: June 2004. [4] CMP Media LLC. What is Perl. The Perl Journal. www: http://www.tpj.com/whatisperl.html. Accessed: June 2004. [5] Copyright Website LLC. Open Source Licensing. www: http://www.benedict.com/Digital//OSLicense.aspx. Accessed: October 2004. [6] Danga Interactive. S2 Manual. 2003. www: http://www.livejournal.com/doc/s2. Accessed: June 2004. [7] Deshpande, Prabhakar. Oracle tops database market with 40% share. The Eco- nomic Times. June 2004. www: http://economictimes.indiatimes.com/articleshow/744324.cms. Accessed: June 2004. [8] Fitzpatrick, Brad. The Better Markup Language. 2002. www: http://www.livejournal.com/doc/server/bml.index.html. Accessed: June 2004. [9] Fitzpatrick, Brad. BML - Better Markup Language. www: http://bradfitz.com/bml. Accessed: June 2004.
- 91. BIBLIOGRAPHY 85 [10] Fitzpatrick, Brad. Copy of lj_maintenance post..... LiveJournal: lj_backend. May 2004. www: http://www.livejournal.com/community/lj_backend/3659.html. Accessed: June 2004. [11] Forum Nokia. Image Upload Server API Version 1.1. February 2003. www: http://www.forum.nokia.com/documents. Accessed: October 2004. [12] Heliö, Jaana. Requirements Engineering When Collaborating With Open Source Projects. Master’s Thesis, Tampere University of Technology. July 2004. [13] Johnson, Kim. A Descriptive Process Model for Open-Source Software Devel- opment. Master’s Thesis, The University of Calgary. June 2001. www: http://sern.ucalgary.ca/students/theses/KimJohnson/thesis.htm. Accessed: July 2004. [14] Kumpu, Niko & Poutanen, Ilkka & Rannikko, Jerome. Providing Mobile Friendly Web Services -Implementing Mobile LiveJournal-. May 2004. www: http://mummola.cs.tut.fi/files/livejournal/. Accessed: June 2004. [15] Lerdorf, Rasmus & Tatroe, Kevin. Programming PHP. O’Reilly & Associates, Inc. March 2002. First edition. [16] LiveJournal. Features by Account Type. www: http://www.livejournal.com/site/accounts.bml. Accessed: June 2004. [17] LiveJournal. LiveJournal.com. www: http://www.livejournal.com/. Accessed: June 2004. [18] LiveJournal. Senior Staff. www: http://www.livejournal.com/press/staff.bml. Accessed: June 2004. [19] LiveJournal. Statistics. www: http://www.livejournal.com/stats.bml. Accessed: June 2004. [20] livejournal.org. Hackers. www: http://goathack.livejournal.org/hackers.cgi. Accessed: June 2004. [21] livejournal.org. LiveJournal.org. www: http://www.livejournal.org/. Accessed: June 2004.
- 92. BIBLIOGRAPHY 86 [22] Mediratta, Bharat. The high level architecture diagram of Gallery 2.. February 2004. www: http://gallery.menalto.com/modules.php?op=modload&name=gallery&file= index&include=albums.php. Accessed: November 2004. The architecture diagram is in Miscellaneous album. [23] Mediratta, Bharat et al. Gallery 2.x Developer’s Guide. www: http://gallery.menalto.com/. Accessed: October 2004. [24] MySQL AB. The World’s Most Popular Open Source Database. www: http://www.mysql.com/. Accessed: July 2004. [25] Netcraft Ltd. June 2004 Web Server Survey. June 2004. www: http://news.netcraft.com/archives/2004/06/06/june_2004_web_server_survey. html. Accessed: July 2004. [26] Nokia. Forum Nokia - Developers Resources. www: http://www.forum.nokia.com/. Accessed: September 2004. [27] Ohrt, Monte & Zmievski, Andrei & Mohr, Messju. Smarty template engine homepage. www: http://smarty.php.net/. Accessed: September 2004. [28] Open Source Directory - OSDir.com. Stable, Open Source Apps. www: http://osdir.com. Accessed: July 2004. [29] Open Source Initiative (OSI). The Approved Licenses. www: http://www.opensource.org/licenses/. Accessed: July 2004. [30] Open Source Initiative (OSI). The Open Source Definition. www: http://www.opensource.org/docs/definition.php. Accessed: July 2004. [31] Open Source Technology Group (OSTG). License Breakdown. www: http://freshmeat.net/stats/. Accessed: July 2004. [32] Open Source Technology Group (OSTG). OSI Approved Licenses. www: http://sourceforge.net/softwaremap/trove_list.php?form_cat=14. Accessed: July 2004. [33] Opera. Opera Mobile Accelerator. www: http://www.opera.com/products/smartphone/accelerator/. Accessed: October 2004.
- 93. BIBLIOGRAPHY 87 [34] Opera. Opera’s Small-Screen Rendering. www: http://www.opera.com/products/smartphone/smallscreen/. Accessed: October 2004. [35] PGTS Pty. Ltd.. List of User Agent Strings. May 2004. www: http://www.pgts.com.au/pgtsj/pgtsj0208c.html. Accessed: July 2004. [36] Raymond, Eric S. The Cathedral and The Bazaar. May 1997. www: http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/. Ac- cessed: July 2004. [37] Schwartz, Randal L. & Christiansen, Tom. Learning Perl. O’Reilly & Associ- ates, Inc. July 1997. Second edition. [38] Shor, Nathan. Entertainment: Blog this!. La Voz Online. January 2004. www: http://www.lavozdeanza.com/vnews/display.v/ART/2004/01/26/4015b75fb498b/. Accessed: June 2004. [39] Sonera. Sonera Nettinopeutin - mobile browsing accelerator. www: http://www.sonera.fi/matkapuhelin/nettinopeutin/. Accessed: October 2004. [40] WAP Forum. WAP Forum Specifications. www: http://www.wapforum.org/what/technical.htm. Accessed: October 2004. [41] Webopedia. Perl. March 2004. www: http://www.webopedia.com/TERM/P/Perl.html. Accessed: June 2004. [42] Wikipedia. S2 programming language. www: http://www.free-definition.com/S2-programming-language.html. Accessed: June 2004. [43] W3C HTML Working Group. XHTML Basic. www: http://www.w3.org/TR/xhtml-basic/. Accessed: October 2004. [44] W3C HTML Working Group. XHTML 1.0 The Extensible HyperText Markup Language. www: http://www.w3.org/TR/xhtml1/. Accessed: October 2004. [45] ZyTrax, Inc. Mobile Browser ID (User-Agent) Strings. July 2004. www: http://www.zytrax.com/tech/web/mobile_ids.html. Accessed: October 2004.