Location-Based Mashups for Nokia Internet Tablets

Institute of Parallel and Distributed Systems Universität Stuttgart Universitätsstraße 38 D–70569 Stuttgart

Diplomarbeit Nr. 2579

Location-based Mashups for Nokia Internet Tablets

Andreas Brodt

Course of Study: Software Engineering

Examiner: Prof. Dr.-Ing. habil. Bernhard Mitschang Supervisor: Dr. rer. nat. Daniela Nicklas

Commenced: February 5, 2007 Completed: August 7, 2007

CR-Classiﬁcation: H.2.5, H.5.1, H.5.4

Abstract

Location-based services have gained large impact in the last years. Also, meanwhile small and powerful end-user devices are present and available. At the same time, so-called mashup pages are spreading on the web. Mashups integrate content from existing sources into a new presentation. With the appearance of web-based map APIs, such as Google Maps, it has become easy to create mapping mashups, which present geographically annotated data on a map. Giving such a mapping mashup the possibility to utilize the user’s position would make the mashup location-aware and provide additional user value. This thesis explores how the user’s position can be integrated into a mashup. Different approaches to achieve this are examined. An architecture for a system enabling location-based mashups is developed. The architecture integrates the user’s position into mashups by extending the web browser. The Delivery Context Interfaces (DCI) are used as standardized interface for providing mashups with the user’s position. Mashups are created on the user’s device by a JavaScript client. Adaptation to the various data formats of the data sources is done by wrappers on the server side which convert the data into a uniform format. The architecture is implemented on a Nokia N800 Internet Tablet. An external Bluetooth GPS device is used for locating the user. Finally, an approach to integrate privacy aspects to the platform is presented.

3 4 Zusammenfassung

Ortsbezogene Dienste haben in den letzten Jahren stark an Bedeutung gewonnen. Außerdem sind kleine und leistungsfähige Endgeräte verfügbar geworden. Gleichzeitig verbeiten sich sogenannte Mashups im Web. Mashups kombinieren Inhalte verschiedener Quellen zu einer neuen Darstellung. Mit der Verfügbarkeit webbasierter Kartensysteme wie Google Maps ist es mit geringem Aufwand möglich, Kartenmashups zu bauen, die Daten, die mit geographischen Informationen versehen sind, auf einer Karte anzeigen. Würde man es solchen Kartenmashups ermöglichen, auf die Position des Benutzers zuzugreifen, würden die Mashups ortsbasiert, was den Nutzen der Mashups deutlich steigern würde. Die vorliegende Diplomarbeit untersucht, wie die Position des Benutzers in Mashups integriert werden kann. Hierzu werden verschiedene Ansätze untersucht. Es wird eine Architektur für ein System entwickelt, das ortsbasierte Mashups ermöglicht. Die Architektur integriert die Position des Bentzers in Mashups mit Hilfe einer Browsererweiterung. Die Delivery Context Interfaces (DCI) werden als standardisierte Schnittstelle benutzt, um die Position für Mashups verfügbar zu machen. Mashups werden auf dem Gerät des Benutzers in JavaScript erzeugt. Die unterschiedlichen Datenformate der Datenanbieder werden aber serverseitig von sog. Wrappern in ein einheitliches Format konvertiert. Die Architektur wird auf einem Nokia N800 Internet Tablet umgesetzt, dabei wird ein externes Bluetooth- GPS-Gerät benutzt, um den Benutzer zu lokalisieren. Schließlich wird ein Ansatz vorgestellt, wie die Privatsphäre des Benutzers geschützt werden kann.

5 6 CONTENTS

1 Introduction 9 1.1 Background ...... 9 1.2 Structure of this document ...... 11 1.3 Acknowledgements ...... 11

2 Related Work 13 2.1 Location-based mobile applications ...... 13 2.2 Mashups ...... 21 2.3 Generic mashup platforms ...... 25

3 Transferring the Position 31 3.1 Requirements ...... 31 3.2 Position data provider ...... 32 3.3 Local mashup ...... 34 3.4 Web browser extension ...... 34 3.5 Comparison ...... 38

4 Delivery Context Interfaces (DCI) 41 4.1 Introduction ...... 41 4.2 Description ...... 41 4.3 Evaluation ...... 42 4.4 An architecture using DCI ...... 43 4.5 Delivery Context Client Interfaces (DCCI) ...... 44

5 A System for location-based mashups 45 5.1 Requirements ...... 45 5.2 Architecture ...... 46 5.3 Data format ...... 51

6 Implementation 57 6.1 Technologies ...... 57 6.2 Implementing the TELAR mashup platform ...... 62 6.3 Performance ...... 66 6.4 Implementation results ...... 69

7 Privacy 71 7.1 Geopriv privacy model ...... 71 7.2 Applying the Geopriv privacy model ...... 72

8 Conclusion 75

A Sample HTML Pages 77 A.1 An HTML page using the DCI API ...... 77 A.2 An HTML page using the TELAR Mashup Platform ...... 79

7 CONTENTS

8 CHAPTER 1

INTRODUCTION

The most exciting phrase to hear in science, the one that heralds new discoveries, is not ‘Eureka!’ (I found it!) but ‘That’s funny...’ Isaac Asimov (1920 - 1992)

Location-based services have gained large impact in the last years. Also, meanwhile small and powerful end-user devices are present and available. At the same time, so-called mashup pages are spreading on the web. Mashups integrate content from existing sources into a new presentation. With the appearance of web-based map APIs, such as Google Maps, it has become easy to create mapping mashups, which present geographically annotated data on a map. Giving such a mapping mashup the possibility to utilize the user’s position would make the mashup location-aware and provide additional user value. This thesis explores how the user’s position can be facilitated for use in mashups. In addition, a system is developed, which enables location-based mashups on a Nokia Internet Tablet. As web-browsers use sandbox- techniques to achieve a strict separation between local data and server-based data, possible ways of integrating the current position (being totally local data) into server-based data are examined and evaluated. An architecture is developed which integrates data from various data providers into a mapping mashup and obtains the user’s position from a GPS device. The architecture is implemented on a Nokia N800 Internet Tablet using an external Bluetooth GPS device. This work is carried out in cooperation with Nokia Multimedia, Oulu, Finland.

1.1 Background

1.1.1 Mashups Mashups (also referred to as Web application hybrid) are one of many recent trends in Web technology being fuzzily summarized under the term “Web 2.0”. A mashup is a website or application that combines content from more than one source into an integrated experience [Wik05]. Most notably, a mashup web site draws upon content and functionality retrieved from data sources that lie outside of its organizational boundaries [Mer06]. What makes mashups particularly interesting is their ability to combine existing sources of information to new services which have the potential to be richer and more useful than the sum of their parts. The reason for the increasing number of mashups on the WWW is the fact that it has become easy to obtain raw content data from the web. Many websites have exposed some of their raw content data through an API making it considerably easier to extract and re-use the information compared to parsing the HTML-encoded presentation of the website. Moreover, it is not necessary to provide any own data at all. With a small amount of server-sided scripting, e. g., in a language like PHP, and/or some JavaScript code, a number of data sources can be “mashed” together providing a potentially powerful new service. A big push to the mashup trend was given by Google’s introduction of its Google Maps API, soon followed by similar products from Microsoft, Yahoo and AOL. These free map services make it possible to create and annotate a map with arbitrary items, as long as these items have some kind of location information. An often cited example of these mapping mashups, as categorized in [Mer06], is Chicago Crime, shown in ﬁgure 1.1.1. Chicago Crime shows crime reports from the Chicago Police Department on a Google Map, making it to some extent possible to estimate, how safe a certain area of Chicago is. Thus, new value is created by combining two existing services, neither of which were designed to provide.

9 CHAPTER 1. INTRODUCTION

Figure 1.1: Crime reports shown on a Google Map by www.chicagocrime.org (screenshot)

1.1.2 The Nokia Internet Tablet family

Heading for a new generation of computers following an “always on” and “always online” philosophy, Nokia has created its Internet Tablet family. The Nokia 770 and its successor, the Nokia N800 (see figure 1.2), are handheld devices small enough to be taken along all day. However, they offer a relatively big screen and a desktop class web browser, which makes it possible to use the Internet wherever there is a WLAN or a cellular network1. With the user constantly connected as part of a “mobile Internet experience” (as Nokia calls it), people will be able to use the web in new ways. As the user does not necessarily stay in a fixed position and definitely does not always access the Internet from the same position it is particularly interesting to integrate the current position into Internet services.

Figure 1.2: The Nokia N800 Internet Tablet (Source: Nokia)

1Connecting via cellular networks requires a mobile phone, which is accessed via Bluetooth.

10 1.2. STRUCTURE OF THIS DOCUMENT

1.2 Structure of this document

This document is structured as follows: Chapter two gives an overview of related work. A number of Location-based mobile applications is introduced and mashups are discussed in detail. Chapter three examines how the user’s position can be integrated into a mashup using various approaches. It is concluded that the Delivery Context Interfaces (DCI) serve the purposes of this thesis best, so that DCI is discussed in more detail in chapter four. Chapter ﬁve presents a system architecture of a platform enabling location-based mashups. Details about the implementation of the platform carried out in this thesis are provided in chapter six. Chapter seven discusses privacy aspects of the implemented system and chapter eight concludes the thesis.

1.3 Acknowledgements

I would like to thank the following persons (in alphabetical order). Without their help this thesis would not have been possible.

• my mother Renate Brodt for proof-reading • Harri Kiviahde for supervising and supporting my work • Prof. Dr. Mitschang for ﬁnding the topic interesting and accepting the thesis • Dr. Daniela Nicklas for encouraging me to do this thesis, getting the whole project started and supervising and supporting my work • Olli Pettay and Oleg Romashin for being very supportive Mozilla gurus • Josh Soref for being a very supportive Mozilla guru and for proof-reading • Sailesh Sathish for cooperating with the DCI implementation • Jari Tenhunen for supporting my work and uttering brilliant ideas • Päivi Tikkala for establishing the contact to Nokia Multimedia • Esko Törmäkangas for the interesting topic and for making this whole thesis possible in the ﬁrst place

11 CHAPTER 1. INTRODUCTION

12 CHAPTER 2

RELATED WORK

This thesis is related to two separate topics; location-based mobile services and applications on the one hand and web-applications and mashups on the other hand. Thus, this chapter deals with both topics; ﬁrst looking at location-based mobile applications and then discussing the mashup topic, which was introduced in section 1.1.1, in more detail.

2.1 Location-based mobile applications

Integrating context awareness in mobile systems is an integral part of ubiquitous and pervasive computing. This has been subject to intensive research since the early 1990s. The context is much more than location, but its other elements are still difﬁcult to identify or measure [Kaa03]. Many systems aiming at location-based services have been built in research environments. However, only now location-based systems start to emerge on the mainstream consumer market. This section introduces some existing location-based applications both from the research world and the consumer world. Table 2.1 summarizes the main features of the different approaches.

2.1.1 Active Badge location system

One of the first location-based applications was the Active Badge Location System [WHFG92] developed by Olivetti Research between 1989 and 1992. The system makes it possible to locate people in a building, who carry an “Active Badge” (see figure 2.1). The initial application of the system was built to enable a telephone receptionist to relay incoming calls to the phone closest to the receiver’s current position. The Active Badges send a unique ID via an infra-red signal every 15 seconds. The signals are picked up by a network of sensors installed in the building and collected by a central server. At first, the only communication with the carrier of a badge was an alarm mechanism to notify a person. Later it was considered to integrate more context information, so that people could state to not want to be interrupted, e. g., being in a meeting.

Figure 2.1: Active Badges of different device generations [ATT02]

13 CHAPTER 2. RELATED WORK

Applications using the Active Badge system connect to the central server and process the location data of the employees. These applications are not mobile nor do the badge carriers use them. The main beneﬁt of the system is delivered, e. g., to the telephone receptionists, while the employees beneﬁt by not missing incoming calls, being bothered more often on the other hand.

2.1.2 PARCTAB The ParcTab system is an approach for a general purpose mobile computing system developed at Xerox PARC in 1993 [SAG+93]. The ParcTab system is based on small PDA-like devices, the so-called ParcTabs, which are equipped with a touch-sensitive display and three buttons (see figure 2.2). The ParcTabs communicate with a central server via a cell-based infra-red network deployed throughout the building. The cell to which a user is currently connected allows the system to determine, in which room the user is currently staying. Thus, the infra-red network is used for positioning as well. Facing the very limited computing power of the ParcTabs, all user interaction is transmitted to the server, which handles the entire computing. The server can access files from the company network. The ParcTab system can thus be considered to have a three tier architecture consisting of the ParcTabs, the ParcTab server and the file servers of the company.

Figure 2.2: Xerox ParcTab computer [par]

There are a number of applications for the ParcTabs, making the ParcTabs usable as ofﬁce assistants. Some of the applications are location-based. For instance, the user’s position in the building can be shown on a ﬂoor-plan, information about the current room can be obtained (e. g., for use in a library), nearby resources such as printers can be located and virtual notes can be left for other users to be shown to them when they enter a certain room.

2.1.3 Cyberguide Cyberguide is a mobile context-aware tour guide that provides information to a tourist based on knowledge of position and orientation (see ﬁgure 2.3). It was developed at the Georgia Institute of Technology in 1996 [LKAA96] and focuses on creating a family of mobile context-aware systems rather than a single application. There was an indoor version and an outdoor version of the Cyberguide system. In order to achieve the ﬂexibility needed to build a family of systems, Cyberguide features a modular architecture, which consists of the following parts:

Information module. The information module encapsulates and stores information about certain points of interest (POIs), thus containing the knowledge of the tour guide. The data is kept locally, in one early version it was even hard-coded in the module’s implementation. It was considered for future work to make the information editable in order to achieve personalized data.

Position module. Like PARCTAB and Active Badge, Cyberguide uses infra-red positioning for the indoor version. However, the Cyberguide system clearly separates the position module from the communication module, unlike PARCTAB and Active Badge, which use the infra-red network for both communication and positioning

14 2.1. LOCATION-BASED MOBILE APPLICATIONS

Figure 2.3: The map view and the information view of the indoor Cyberguide system [LKAA96]

in a closely coupled way. This separation made it possible to switch to GPS positioning for the later outdoor version very easily.

Mapping module. The mapping module retrieves data from the position module and the information module and draws the user’s position and points of interest within sight on a map. The map data is stored locally on the device.

Communication module. Connectivity is provided through a wired Internet AppleTalk connection, which is only used for user feedback sheets. In [LKAA96] reading e-mail and fetching HTML pages are reported to be possible, but the lack of an appropriate wireless communication medium at the time is clearly stated, especially for providing the mapping and information modules with remote data.

2.1.4 GUIDE GUIDE is a tour guide system for visitors of Lancaster City, UK, developed at Lancaster University and installed in 1999 [DCMF99, CDM+00]. The project relies on a WaveLAN high-bandwidth wireless infrastructure to download information to the GUIDE end-systems, thus no data is stored locally. The cell information of the network is also used for positioning, i. e., there is no separation between positioning and communication as in Cyberguide. The Fujitsu TeamPad 7600 portable PC is used as terminal and a Java-based HTML browser as client. An example screenshot of GUIDE is shown in ﬁgure 2.4. As all information is retrieved over the network, the information can be dynamic. For example, Lancaster Castle is available for visitors only when the court located in the castle is not in session, which can change on an hourly basis. GUIDE also offers the possibility to create a user-tailored tour through the town, taking into account opening times of attractions, distances between attractions and the user’s personal interests. Throughout the tour, GUIDE is able to modify the tour dynamically, e. g., if the user stays longer at a certain attraction or if opening times change.

2.1.5 REAL REAL is a pedestrian navigation system designed at the University of Saarbrücken in 2000 [BKW02]. In contrast to the systems introduced above, REAL adapts to the user’s context not only based on the user’s location but also on the user’s speed, on the quality of the location information and the properties of the user’s mobile device (screen size, etc.). Taking into account that, e. g., a business man needs to get to the train station as fast as possible, whereas a tourist likes to see the most beautiful route, REAL attempts to generate a route which best fits the user’s needs. Moreover, a running person is unlikely to desire detailed information about the surroundings, while a person walking slowly might be interested. Thus, REAL displays environmental information depending on the user’s speed. More or less of the surrounding landmarks are shown, depending on how exact REAL believes to know about its position. E. g., if REAL is not confident to know about the user’s orientation, the walls of the corridor are displayed, so that the user can find his/her way, whereas otherwise only an arrow pointing to the right direction will suffice.

15 CHAPTER 2. RELATED WORK

Figure 2.4: Screenshot of GUIDE [GUI]

Figure 2.5: The outdoor version of the REAL system [BKW02]

16 2.1. LOCATION-BASED MOBILE APPLICATIONS

Another key feature of REAL is that it does not rely on one single positioning system but utilizes a number of sensors, which integrate smoothly (see ﬁgure 2.5). Outdoors, a GPS receiver is used, while indoor navigation is done with infra-red beacons. REAL stores no data locally on the device but retrieves all its information from a central server via WaveLAN or infra-red broadcasts (non-mobile clients such as smartboards connect via LAN). In the case of infra-red, the communication is unidirectional with the server not knowing the user’s position. Thus, data about all locations is broadcasted on all infra-red senders constantly.

2.1.6 Nexus The Nexus system [NGS+01] aims at providing a general framework for mobile and location-based computing and is developed at Universität Stuttgart since 1999. Rather than creating a speciﬁc location-based system having its own isolated data holding, as done by the systems mentioned above, Nexus focuses on integrating single systems into one open platform. This way, different systems can share their data and even communicate with each other. Thus, Nexus can be seen as a middleware connecting providers and consumers of spatial information. The vision of the Nexus project is an open infrastructure similar to the WWW, where everybody can publish spatial information and offer spatial services to the public. Nexus organqizes the data using an extendable data model, the Augmented World Model, which consists of a large class hierarchy. The architecture of the Nexus platform is shown in ﬁgure 2.6.

Application 1 Application 2 ... Application l Application layer

Area Service Nexus Node 1 ... Nexus Node m Federation layer Register

Context Context Context ... Context Service layer Server 1 Server 2 Server 3 Server n

Figure 2.6: The architecture of the Nexus platform (based on [NGS+01])

The Nexus platform integrates different data providers, so-called context servers, into the federation. A context server registers at the area service register supplying the area the server covers. In order to access the data of the context servers, a location-based application only queries the federation. The federation then decides, which context servers need to be queried in order to get the best possible result. The federation subsequently queries the context servers and combines the query results to a single set of data. Duplicates are removed and it is attempted to complete missing information. Finally, the set of combined data is returned to the application. In addition to real-world spatial data, Nexus also provides virtual data following the concept of an augmented world. So-called virtual information towers bind virtual information objects (e. g., web pages) to locations of the real world. For instance, the menu of a restaurant could be placed at a virtual information tower near the restaurant and people walking along could access it.

2.1.7 Nokia Mobile Search Nokia Mobile Search is a unified search application for mobile phones introduced in 2005. Mobile Search is able to search local data, including e-mails, text messages and calendar entries, as well as information from the Internet. For Internet-based data, Mobile Search integrates data from third party services. The data providers depend on the user’s country and language. In contrast to the Nexus platform, which integrates all data sources before transmitting a query result to the user, Mobile Search does the integration of the different data providers on the user’s device. Using the “local search” feature, the user can find and directly contact local services like restaurants and shops, as shown in figure 2.7.

17 CHAPTER 2. RELATED WORK

Figure 2.7: Nokia Mobile Search looking for “Pizza” in London

Apart from being able to select the data providers for the current country automatically (“media roaming”), Mobile Search is not location-based in its present state. As seen in ﬁgure 2.7, Mobile Search requires the user to enter the search location manually. However, as phones are increasingly appearing to be equipped with a GPS device, like the Nokia N95 introduced in 2007, it is only a matter of time that Mobile Search will use the GPS.

2.1.8 Maemo Mapper Maemo Mapper is a relatively simple application for browsing maps of the earth and runs on the Nokia Internet Tablets. In contrast to the systems introduced above, Maemo Mapper does not have a scientiﬁc background but was started as an open source project in 2005. The type of application is not new either, however Maemo Mapper is one of the most popular applications for the Nokia Internet Tablets and enjoys a large user base.

Figure 2.8: The Maemo Mapper application showing a satellite-based map

Maemo Mapper does not provide any map data by itself, but it supports downloading maps from different map providers on the Internet, including Google Maps. Maps of a certain area can be downloaded manually by supplying the respective coordinates and the desired zoom level. This is useful if the user intends to take the device along without continuous Internet access. However, maps can also be downloaded automatically on demand as the user browses a certain area. This causes a very ﬂuent and interactive user experience, as it seems like the whole map data

18 2.1. LOCATION-BASED MOBILE APPLICATIONS was stored locally. A screenshot of Maemo Mapper displaying a map from Microsoft Virtual Earth is shown in figure 2.8. While one can use Maemo Mapper to browse maps, the feature that makes it location-based is its ability to connect to a Bluetooth GPS device. This way, the current position can be marked in the map and the map can be navigated to the current position. It is possible to record tracks while moving and store them to a file. As tracks have a timestamp associated with every waypoint, the user’s movement history can be documented this way. Moreover, routes can be imported from GPX files and to a certain extent used as driving directions for navigation purposes. However, neither textual nor spoken driving directions are supported. As an additional feature Maemo Mapper supports points of interest (POIs). The POIs are stored locally and there is currently no possibility to download or share the POIs. So effectively the user has to create the database containing POIs himself and enter the points manually.

2.1.9 Navicore In cooperation with Nokia, Navicore Ltd. developed a commercial navigation software for the Nokia Internet Tablets in 2006. It can be purchased as a bundle including a Nokia LD-3W Bluetooth GPS module, a memory card to store map data, a car power charger and a car holder for the Internet Tablet. Although it is claimed that Navicore could be used, e. g., on a bike as well, the intention is to turn the Internet Tablet into a feature-complete car navigation device.

Figure 2.9: The Navicore application running on a Nokia N800 (screenshot)

As displayed in figure 2.9, Navicore usually operates in full-screen mode and does not look any different from other car navigation systems. Also the features provided by Navicore are roughly the same as specialized car navigation systems typically provide these days: Navicore gives both clear visual and spoken driving directions, in order not to draw off the driver’s attention. It is possible to store favourite places and addresses, so that they do not need to be entered repeatedly. A large database of POIs, like petrol stations, local attractions, etc., is included and current traffic information can be retrieved via the Internet. The map data is stored locally on the Internet Tablet’s removable memory card, thus in contrast to Maemo Mapper (in auto-download mode) no constant Internet access is required. The POIs are stored locally as well, a large data set is included in Navicore. It is not possible to define own POIs on the Internet Tablet, however a tool is available for editing the POI database on a desktop computer.

2.1.10 Helsinki public transport The public transport carrier in the city of Helsinki, HKL, established broadband connectivity to some of its vehicles as a test operation in 2007 [Leh07]. In order to provide WLAN Internet access for passengers, 26 buses and trams were equipped with a Flash-OFDM uplink and a WLAN access point. Moreover, each vehicle also bears a GPS receiver and transmits the current position to a central server. On top of this communication platform, which the

19 CHAPTER 2. RELATED WORK passengers can use for other purposes as well, an information system was built, which is capable of showing the next stops and available bus and tram connections at these stops, including the waiting time (see ﬁgure 2.10). The system is put into practice as a web application, which the users access with their private devices.

Figure 2.10: Public transport passenger information system [Leh07]

In addition to that, “Ajoneuvot kartalla”, a mapping mashup, was created combining a map from Google Maps with the position data of the vehicles. The Ajoneuvot kartalla retrieves the positions from the central server once per second using asynchronous HTTP requests, and updates the map accordingly. This way, one can actually see the vehicles moving in real-time on the web page, which is especially impressive when the map is set to display satellite images as shown in ﬁgure 2.1.10.

Figure 2.11: “HKL Ajoneuvot kartalla” showing busses and trams in real-time on a Google Map

Albeit in test operation, Ajoneuvot kartalla is publicly available on the Internet1. However naturally, it is more useful when accessed while on the go, as it graphically shows where the user is travelling as well as where connecting vehicles are. Also walking to a bus stop a user can ﬁnd out, whether the bus is late or whether it might be a good idea to run. In a sense, Ajoneuvot kartalla is the perfect application for devices like the Nokia Internet Tablets. The mashup web page is too big for a mobile phone’s screen and it is not very practical to walk with an open laptop, either. But with a connected device somewhere between phone and laptop a great user beneﬁt is created.

1http://research.wspgroup.fi/hklajoneuvot (accessed March 2007)

20 2.2. MASHUPS

2.1.11 Conclusion The popularity of applications like Maemo Mapper and car navigation systems like Navicore proves, that there is a wide interest in location-based mobile applications also outside the scientific world and that non-research systems are slowly appearing on the scene. Looking at the systems introduced in the sections above and summarized in table 2.1, some requirements for location-based mobile applications can be observed: Remote data. There is a clear advantage to keep the data remote. Cyberguide uses local data due to the lack of sufficient mobile connectivity at the time it was built. [LKAA96] however states that this is not the way it should be done. The GUIDE system is able to provide dynamic data and keep the information up to date, because all information is provided remotely. Data integration and sharing. [LKAA96] also mentions that much of the data provided by the Cyberguide system was to be found on the WWW as well. So the system could have benefited from integrating the WWW. Moreover, the fact that most of the systems introduced above use a central server is merely because the systems are limited to a certain area, such as a university campus in REAL. As stated in [HKL+99], a production system needs to be scalable for a huge number of users and information. Also the large amount of information required to make a location-based mobile application useful will have to be provided by several parties. A system like the Nexus platform or Mobile Search will have to integrate the data. Several ways of positioning. As long as there is no unified way of positioning, a location-based mobile system will have to make use of several positioning systems and smoothly integrate them in order to work always. With the exceptions of REAL, which does exactly do this, and GUIDE, which does not locate the user very accurately, all other systems introduced here work only either indoors or outdoors. This aspect is not considered throughout this thesis, which will use GPS for positioning, although it would be theoretically possible to locate a Nokia Internet Tablet, e. g., based on the current WLAN access point as well. It is however the author’s own experience that the user value is clearly reduced when the GPS receiver has to be placed near a window or will not work indoors at all.

System Task Positioning Data Notable Active Badge telephone relay IR (remote) locating people PARCTAB ofﬁce assistant IR remote general purpose Cyberguide visitor guide IR or GPS local modular architecture GUIDE tourist guide cell-based remote dynamic data REAL pedestrian navigation IR and GPS remote wide use of context Nexus platform generic remote data integration Mobile Search general search GSM network remote and local data providers Maemo Mapper map browsing GPS or none remote and local Internet Tablet Navicore (car) navigation GPS local Internet Tablet HKL Ajoneuvot public transport information GPS remote mashup

Table 2.1: Summary of the location-based applications introduced above

2.2 Mashups

As introduced in section 1.1.1, mashups are a hallmark of second generation of Web applications informally known as Web 2.0 [Mer06]. This section ﬁrst introduces the term Web 2.0. Then, it is explained how mashups are built and an overview is given of the technologies used for building mashups.

2.2.1 Web 2.0 The term “Web 2.0”, introduced by Tim O’Reilly in [O’R05], is arguable for a number of reasons and has been discussed intensively. Failing to give an airtight deﬁnition of the term, Tim O’Reilly merely refers to recent trends in the WWW and provides examples such as wikis, blogging, syndication and pages like Wikipedia2 and Flickr3.

2http://www.wikipedia.org (accessed July 23, 2007) 3http://www.flickr.com (accessed July 23, 2007)

21 CHAPTER 2. RELATED WORK

Attempting to extract the quintessence from the hyped buzzword “Web 2.0” [Tre06] identiﬁes those recent trends to be interactivity, social networking, tagging and “some aspects of Web services”. These are discussed in more detail in the following sections.

Interactivity By the term “interactivity” [Tre06] means what Tim O’Reilly calls “Rich User Experiences”. Both mainly refer to AJAX, which stands for “Asynchronous JavaScript and XML” (see section 2.2.3). Being another hype by itself, AJAX allows web pages to “feel” much more like a desktop application than a static HTML page does. The most famous example these days is Google Maps4. Very much like in Google Earth, a desktop application for browsing maps and satellite pictures of the earth, the user can interact with the Google Maps application, by zooming and dragging around the map to show a certain position. This is a signiﬁcant improvement in usability compared to static map pages which use hyperlinks to navigate through the map requiring a page reload for each user interaction. Using AJAX, Google Maps is able to load additional data in the background without having to rebuild the entire page.

Social networking Social networking means constructing a graph of people being related by friendship, family, business, common interest and the like. Using a service such as Friendster5, LinkedIn6, facebook7 or the German Studiverzeichnis8 it is not only possible to keep track of former schoolmates. But for example when looking for a job at a certain company, social networking might enable to ﬁnd a friend who has a friend whose wife works for that company. Not at all being a technology, Tim O’Reilly hardly mentions social networking. However, social networking is a type of application that essentially depends on its users. This matches well what Tim O’Reilly calls “Users Add Value” in his list of Web 2.0 design patterns, although he rather refers to wikis and blogs.

Tagging Tagging is a very simple technique to categorize arbitrary items. Users associate keywords, tags, which are in fact nothing but bare text strings, with those items to create lists of related items. Examples include the photo publishing website Flickr, where users can tag their own and other people’s images, and the bookmarking service del.icio.us9, where users keep and tag URLs. The categories supported by most blog software and wikis can also be considered tagging. By tagging all kinds of items on the Internet, the users create searchable databases which can be used for information retrieval. By associating metadata to objects, tagging is an extremely lightweight effort to achieve what the Semantic Web is heading for (see section 2.2.3). The sheer simplicity of the tags introduces a number of serious ﬂaws like ambiguity of tags and even problems with case sensitivity. Tags are personal and with the absence of ontologies and even standards of any kind, tagging does not provide any possibility for machine reasoning or consistent indexing. But with semantic web technologies like ontologies, RDF and OWL being far beyond the horizon of the average user, tagging is a concept simple enough to be understood and actually used.

Some aspects of web services Nowadays, there’s a lot of talk about Web 2.0, web mashups, AJAX, etc., which in my mind are all facets of the same phenomenon: that information and presentation are being separated in ways that allow for novel forms of reuse. [Kuw05]

What [Kuw05] describes is essentially what web services are about. Quoting Tim O’Reilly’s list of Web 2.0 design patterns, Web 2.0 applications are built of a network of cooperating data services. Therefore, a Web 2.0 application should offer web services interfaces and content syndication, and re-use the data services of others. This describes the trend of many websites providing open APIs for the public to use (often within certain licence constraints).

4http://maps.google.com (accessed July 23, 2007) 5http://www.friendster.com (accessed July 23, 2007) 6http://www.linkedin.com (accessed July 23, 2007) 7http://www.facebook.com (accessed July 23, 2007) 8http://www.studivz.net (accessed July 23, 2007) 9http://del.icio.us (accessed July 23, 2007)

22 2.2. MASHUPS

To some extent, an AJAX program can be considered a client of web services, because it uses the web to fetch additional XML data. This also and especially applies to mashups, even to those mashups which do not use AJAX but server-sided scripting.

Criticism What is most criticised about the term “Web 2.0” is that it lacks a deﬁnition. Indeed so many contrary descriptions of “Web 2.0” exist, that it is even claimed it was nothing but a marketing buzzword without any meaning. Moreover, the name indicates a concrete product with a version number, as if Web 2.0 was a replacement of “Web 1.0”. As the “old” WWW has obviously not been replaced, the question could be, whether there are at least any signiﬁcant technical innovations. However, this is not the case, as most aspects of Web 2.0 are older than the term. The ideas of AJAX and related technologies exist since 1998, when Microsoft equipped Internet Explorer 4.0 with the “remote scripting component”. Social Networking has been possible to some extent before, for instance with instant message services like ICQ. Besides, the basic idea of the WWW was collaboration when it was created in 1989. Web Services and open APIs are much older, too. Amazon.com, for instance, opened its API to the public in 2002. So it is obvious that Web 2.0 does not come up with new technology but utilizes the “Web 1.0”. What might be new is that these technologies are used more widely and more consequently than before. [Gra05] expresses this by stating that Web 2.0 means “using the web the way it’s meant to be used”.

2.2.2 General mashup architecture The general architecture of a mashup comprises three logically and physically disjoint components, as illustrated in ﬁgure 2.12.

Data Provider

HTTP

Web Browser HTTP Mashup Site HTTP Data Provider

HTTP

HTTP Data Provider

Figure 2.12: General architecture of a mashup

The data is accessed from third party data providers, which expose their data through web-protocols such as REST, Web Services (SOAP) and RSS/Atom (all described below) and might not even know about the mashup. In case a data provider does not expose any data in such an easily machine-readable way, it is possible, though cumbersome, to parse the data provider’s HTML pages and extract the desired information from there. This technique is called screen scraping. The mashup is created on the mashup site. This is where the mashup is hosted and the mashup logic resides. However, it is not necessarily where the mashup logic is executed. Mashups can be built like conventional web applications using server-sided dynamic content generation technologies such as Java servlets, CGI, PHP, ASP, etc. In this case the mashup site assembles the different data sources into one integrated web page and serves it to the client’s web browser. Another way of creating a mashup is to combine the data only in the client’s browser. This is indicated by the dashed line in figure 2.12. In that case the mashup site serves a web page containing JavaScript code to the client. The JavaScript program is executed by the browser and fetches and integrates the data from the data providers. For fetching the data, usually the XMLHttpRequest JavaScript object is used (see section 2.2.3), which may only connect to the same server from which the web page was downloaded. Thus, either the data providers need to be on the same host as the mashup site, which in a way compromises the mashup architecture, or advanced hacks, such as hidden elements, are required.23 CHAPTER 2. RELATED WORKIn case of a mapping mashup, as introduced in section 1.1.1, one of the data providers is a map service like Google Maps. These map services are usually used in the JavaScript way, i. e., the mashup site includes JavaScript code from the server of the map service into the HTML code of the mashup.2.2.3 Technological building blocks AJAX AJAX, which is short for “Asynchronous JavaScript and XML”, means using JavaScript, XML, the document object model API of the web browser, HTML and CSS together in order to load and present content asynchronously on an HTML page. Thus AJAX is not a technology by itself, but a pattern of using several technologies together. The goal is to create a smooth and cohesive user experience. This is achieved by loading the HTML page once and further exchanging only small amounts of data between the server and the user’s web browser—rather than reloading the whole HTML page over and over on every user interaction. Whereas user interaction in a conventional web application is handled with HTML links and forms, causing a page reload, an AJAX-based web application calls JavaScript code on user interaction. If additional data is required for fulfilling the user’s needs, the data is fetched from the web server using the XMLHttpRequest JavaScript object, which loads the data in the background asynchronously. The data is often encoded in an XML-based format, but other formats like JSON are equally possible. On completion of the data transfer, the JavaScript code modifies the document of the browser using the document model API (DOM). An often-cited example for a web page which benefits from AJAX is Google Maps, as explained in section 2.2.1. Loading required map images in the background gives Google Maps a huge gain in usability. Another nice example is the HKL Ajoneuvot mashup introduced in section 2.1.10. In addition to using Google Maps, the mashup fetches the positions of busses and trams once per second from the central server using the XMLHttpRequest object and updates the positions of the vehicles on the map accordingly. With the HTML page refreshing itself periodically, a similar effect would have been possible without AJAX too, but considering the reload times of all images (despite caching) the user experience would not be nearly as smooth as the AJAX implementation.SOAP and REST Both SOAP and REST are platform neutral mechanisms for communicating with remote services [Mer06]. As part of the service-oriented architecture (SOA) paradigm, clients can use SOAP and REST to interact with remote services. They do not need to know any details about the underlying platform, because interaction with a service is solely based on messages. Many data providers offer an API based on SOAP or REST, in order to make the data easily accessible.SOAP is a fundamental technology of the Web Services paradigm. SOAP messages are serialized into XML documents in order make them platform independent. SOAP APIs for Web Services are described by WSDL documents, which define interaction with the service, i. e., what operations the service offers, the accepted message format and how to address the service. Typically, SOAP messages are transported via HTTP.REST stands for “Representational State Transfer” [Fie00] and is a much simpler approach for communicating with remote services. In REST-based services, every data object is identified by a URI. The data objects are retrieved, updated, created and deleted using the HTTP request methods GET, POST, PUT and DELETE, respectively. As an example, a REST-based photo management site could expose a (possibly XML-encoded) list of a user’s photos via the URI http://www.photosite.com/user123/photos/ and a single image could be accessible via http://www.photosite.com/user123/photos/photo123. Sending the HTTP request DELETE /user123/photos/photo123 to the webserver at www.photosite.com would consequently delete the picture. However in practice, many APIs claiming to be “RESTful” include a method name in the URIs rather than fully using HTTP request methods. The API offered by the bookmarks sharing site del.icio.us, for instance, lets an appropriately authenticated user delete a bookmark by sending an HTTP GET request containing the URI of the bookmark as a parameter: https://api.del.icio.us/v1/posts/delete?uri=<bookmark URI>RSS and Atom RSS and Atom are both XML-based web feed formats to publish frequently updated digital content (RSS is actually a family of such formats as several incompatible versions exist). A data provider can publish a web feed for its data.24 2.3. GENERIC MASHUP PLATFORMSThen a client can then check the web feed for new data regularly and react to it, without having to check the actual data for changes over and over. Web feeds are widely used by news services and blogs but have also been adopted for changelogs of CVS commits and even radio programs. For mashups aggregating such data (especially news and blogs) web feeds are very useful, as they provide a machine-readable representation of the data, augmented with metadata such as the publication date.Screen scraping Screen scraping is the process to parse and analyse content automatically that was originally written for human consumption in order to obtain data structures that can be used and manipulated programmatically. Screen scraping is used by some mashups in order to obtain data from a data provider which does not offer the data in any other way. Screen scraping is not very robust; as soon as the data provider changes the design, i. e., the presentation of the data, the screen scraping code is unlikely to remain functional. Besides, it is cumbersome and expensive to implement, as the data provider’s website needs to be reverse engineered and a specific parser needs to be written for every website. But in some cases screen scraping is the only way to obtain data as it can be applied to every (HTML-based) website.RDF The inelegant aspects of screen scraping are directly traceable to the fact that content created for human consumption is not suitable for machine consumption. The Semantic Web [BLHL01], which envisions the existing WWW being augmented with machine-readable metadata, has come up with a family of specifications collectively known as the Resource Description Framework (RDF). With RDF, relationships between data objects can be described in subject-predicate-object triples (“subject s has relationship r with object o”). Combining a data model with a graph of such relationships, ontologies can be created, which are hierarchical structure of knowledge that can be searched and formally reasoned about. Whereas currently the Semantic Web is not widely present in the WWW, RDF data has been adopted by a number of domains including social networking and syndication. Earlier versions of RSS (described above) were based on RDF.2.3 Generic mashup platforms2.3.1 Yahoo! Pipes Yahoo! Pipes10 is a web application for building mashups that aggregate Web feeds and other services. Heavily using AJAX, Yahoo! Pipes offers a rich user interface, with which a mashup can be created extremely easily using drag and drop. A pipe is a series of components which are connected in a pipe-and-filter way, similar to a Unix pipe. The data model of Yahoo! Pipes is based on RSS items. RSS items are fetched by one or more source components and processed by other components of the pipe until they reach the “pipe output” component. Having created a pipe, the user stores it on Yahoo!’s server, exposing the pipe to the public. Running the pipe lists all resulting RSS items on a web page and the output of the pipe is also accessible in various machine readable formats like RSS and JSON. A pipe is entirely executed on the server, i. e., despite the extreme use of AJAX while creating a pipe, running a pipe is done in the way of a traditional web application. Figure 2.13 shows a simple Yahoo! pipe which fetches the RSS feed from the German news service www. tagesschau.de using a “fetch” source component. A user input field asks the user for the number of news items to show and a “truncate” component restricts the RSS items accordingly. Afterwards a “babelfish” component translates the German news items into English using AltaVista’s Babelfish translation service11. The output of the babelfish component reaches the “pipe output” component and is presented as the result of the pipe. In its current state Yahoo! Pipes is not suitable for creating arbitrary mashups as it is restricted to RSS feed items, which the pipe components modify and augment. For example it would not be possible to build a mashup like Chicago Crime (see section 1.1.1) as the Chicago Police Department does not offer an RSS feed containing the crime reports. In addition to that, the output of Yahoo! Pipes is also an RSS feed, i. e., functionality like putting the crime reports on a map must me implemented in yet another hard-coded mashup, which utilizes the pipe as a content provider.10http://pipes.yahoo.com (accessed July 23, 2007) 11http://babelfish.altavista.com/ (accessed July 23, 2007)25 CHAPTER 2. RELATED WORKFigure 2.13: Structure and result of a Yahoo! pipe translating German news to English (screenshots)2.3.2 Piggy Bank Piggy Bank [HMK05] is an extension to the Firefox web browser that extracts information from existing web pages and stores it in RDF format. Piggy Bank was developed at the Massachusetts Institute of Technology in 2005 and is freely available. The motivation behind Piggy Bank is to promote Semantic Web technologies (namely RDF) by integrating a user-friendly Semantic Web tool into an existing and widely used web browser. With very few mouse clicks Piggy Bank lets the user extract RDF data from web pages, save the data locally and upload it to a so-called semantic bank in order to share it with others. Piggy Bank uses a local web server offering a web application which lets the user work with the RDF data stored locally. As the data is separated from its representation, a unified view of the data is possible, regardless of its origin. The data can be categorized using tags, the data can be searched and sorted by different criteria (see figure 2.14) and viewed in different ways. If the data contains location information, the data can be displayed on a Google map, if temporal information is found, it can be shown on a time line. If a web page links to RDF data, that data is simply retrieved. Otherwise, Piggy Bank uses screen scraping in order to extract information from a web page. Screen scrapers for different web pages can be written and installed into Piggy Bank. As Piggy Bank operates as a browser extension, the screen scrapers can access the document object model (DOM) tree of the web browser. By examining the DOM tree rather than parsing the code of the web page, screen scraping also works for web pages which make heavy use of JavaScript. Besides, screen scrapers are more robust to design changes of the web page this way. Although Piggy Bank is called a “mashup platform” on its website, the intension behind Piggy Bank is similar but not exactly the same as the one behind mashups. A mashup integrates many sources of data into one new presentation for the user, whereas Piggy Bank integrates many sources of data into one database. Based on this database, the user himself can create new presentations. However, the presentation features offered by Piggy Bank are currently not very elaborate.2.3.3 Mash-o-Matic Mash-o-Matic [MMD06] is a tool to create mapping mashups from all kinds of source documents in formats including HTML, Microsoft Word and PDF. It was developed at Portland State University in 2006. Mash-o-Matic uses a concept called superimposed information in order to superimpose metadata on unstructured source documents, thus creating a structured database. This structured database is queried in order to generate an output document understood by Mash-o-Matic. Processing the output document Mash-o-Matic automatically creates a mashup displaying a number of markers on a map and a caption. Figure 2.15 shows a mashup of Portland State University campus created by Mash-o-Matic. The structured database is made up by a number of items, which can be recursively structured into groups. An item can be connected to a mark, which is a reference to a fragment in a source document. The mark abstraction is defined and implemented in the Superimposed Pluggable Architecture for Contexts and Excepts (SPARCE)26 2.3. GENERIC MASHUP PLATFORMSFigure 2.14: Piggy Bank browsing and searching the saved RDF data [HMK05]Figure 2.15: A mashup of Portland State University campus created by Mash-o-Matic [Por06]27 CHAPTER 2. RELATED WORK[MMDB04], a middleware for managing superimposed information. One way to create such marks, i. e., to import source data, is to select a fragment of a source document with the mouse. Technically this is done using plugins to the applications handling the source documents, such as Microsoft Internet Explorer, Microsoft Word, and Adobe Acrobat. However, marks can be created programmatically as well by using the SPARCE API. This way, screen scrapers can be written to create marks or data might even be imported from the API of a data provider. hM asp u� ilT t e t enerC ll oomee vZ1 dk* anmar..0 LT pe y kM arer ame*TN pe y..10 dd ress di tA oornaesC cronm yBA conase lkBI oc f no IFigure 2.16: The data model used by Mash-o-Matic (based on [MMD06])In order to create a mashup with Mash-o-Matic, information from the structured database is queried and transformed into the data model used by Mash-o-Matic (see figure 2.16). This is done using a query engine for SPARCE and an XSLT style sheet. During this step also street addresses are mapped to coordinates using a third-party geocoding service. The result is an XML document defining one Mash-Up entity, which contains a number of marker entities. A marker will be placed on the map at its coordinates and represents one or more landmarks. A landmark is, e. g., a building and will be displayed in the caption of the mashup. From this point on, everything happens automatically. Mash-o-Matic uses AJAX to obtain and process the XML document created from the structured database. A map from Google Maps or Yahoo! Maps is created, the markers are placed on the map according to the XML document and the landmarks are displayed in the caption. The landmarks contain links, which pop up an info window at the corresponding marker. Mash-o-Matic is similar to Piggy Bank in the way that information from different sources is integrated in a database with a defined structure. Piggy Bank has a much more universal structure using RDF. Mash-o-Matic on the other hand (by building on SPARCE) focuses on supporting many source data formats. In contrast to Piggy Bank, Mash-o-Matic really supports creating a mashup web page from the database rather than just offering functionality to search and browse it.2.3.4 Kapow Mashup Platform The Kapow Mashup Platform [Kap05] is a commercial product by Kapow Technologies12 aimed at information integration. A key feature of the Kapow Mashup Platform is to create adapters for different data sources. Whereas it is possible to obtain data from web services or SQL databases, the most interesting feature is the ability to extract data from web pages. So-called robots, in fact screen scrapers, can be created in a graphical development environment which the developer has to install on his computer. Using a graphical programming language the developer can click together the single steps the robot will perform in order to extract data from a web site. These steps can include complex navigation through the web site, authentication and management of cookies and sessions, entering information into HTML forms, conditional execution based on content and executing JavaScript. A simple robot is shown in figure 2.17. In addition to defining the robot, the developer also has to define a data model, which is a set of input and output variables. The output variables can be obtained from the robot via SOAP and REST in several data formats such as XML, JSON, HTML and comma-separated values (CSV). Code generation for Java and .NET and portal platforms including IBM WebSpere and BEA Weblogic is supported as well.12http://www.kapowtech.com (accessed July 23, 2007)28 2.3. GENERIC MASHUP PLATFORMSFigure 2.17: A simple Kapow robot for performing a Google search [Kap05]Information retrieval from several sources and formats is thus made a lot easier using the Kapow Mashup Platform. The actual mashup application, however, still remains to be done by the developer.2.3.5 IBM QEDWiki QEDWiki is an AJAX application for creating mashups and situational applications developed by IBM. QEDWiki provides a canvas in the web browser, on which content from different sources can be combined using drag and drop. The content is displayed by widgets. Widgets have properties that can be bound to other widgets or data. For instance, a list widget might be bound to an SQL database to show employee addresses in a list, as shown in figure 2.18. Then, a Google Maps widget might be bound to the address list to show the employees’ addresses on a map. Another widget could be bound to the phone number column in the address list and add the functionality to send an SMS message to each number. A weather report widget could be bound to the Google Maps widget in order to show the weather forecast for a particular place. The resulting application is both created and used via the web browser and resides on a server. Functionality is included for editing, commenting and multi-user collaboration.Figure 2.18: IBM QEDWiki [Nic07]QEDWiki goes beyond the idea of a mashup, which displays data from different sources in a new presentation. QEDWiki does not only combine data, but also provides functionality for creating situational applications [Eva06]. The idea behind this is that people with domain expertise (e. g., sales managers) can create applications that fit their current needs on their own in a very short time and without any programming skills. As requirements change, the application is modified by the users. This way, the IT department does not need to keep up with the constantly changing user requirements. In this development model, the job of the IT department is to provide the widgets as solid and universally combinable building blocks.29 CHAPTER 2. RELATED WORK30 CHAPTER 3TRANSFERRINGTHE POSITIONThe central challenge for achieving location-based mashups is to transfer the local position of the user to the mashup. Mashups are accessed through the web browser and web browsers strictly separate remote data from local data. For obvious security reasons, web browsers keep remote data isolated inside a sandbox. However, the position retrieved from a GPS receiver is local data, thus web pages—being remote data—normally cannot access it. This chapter discusses possible approaches to address this challenge. First, the requirements in the context of this work are given in section 3.1. Based on these requirements, the thesis identifies three fundamental approaches to transfer the position data to a web page and thus create location-based mashups: a position data provider, a local mashup and a web browser extension. The approaches are based on the general mashup architecture introduced in section 2.2.2 and are subsequently discussed in detail. Finally, the most promising approaches are compared in section 3.5.3.1 Requirements3.1.1 Hardware This thesis is carried out on a Nokia N800 Internet Tablet. So, naturally, all approaches discussed in this chapter have to be implementable on a N800. However, the results of the thesis are not required to be compatible with the Nokia 770 Internet Tablet, the predecessor of the N800. It is a requirement that positioning is done using GPS. As the N800 does not have a built-in GPS receiver, an external GPS device is used, which is connected to the N800 via Bluetooth. During this thesis a Nokia LD-3W GPS receiver was used. Other GPS receivers were not tested.3.1.2 GPS access It is a requirement that the GPS device is accessed using the Maemo location framework, i. e., the framework for GPS access included in the software platform of the Nokia N800. While it is technically possible to establish a serial Bluetooth connection to the GPS device and read raw data from the GPS, this approach has a number of disadvantages. First of all, only one program can use such a Bluetooth connection to the GPS device at a time. The GPS device supports only one connection and a single connection cannot be shared by several programs. Thus, accessing the GPS device directly would lock other programs out. In addition to that, the raw data would have to be parsed manually to extract the location information, which introduces extra effort, possible errors, and compatibility issues. The Maemo location framework avoids these problems by providing an API for both managing the Bluetooth connection to the GPS device and accessing the location information in an easy way. At its core, the Maemo location framework uses gpsd, the <a href="/tags/Linux/" rel="tag">Linux</a> GPS daemon. Gpsd reads and parses the data received over the Bluetooth connection and is accessible via TCP on a local port. A client API for easy access to gpsd is provided. The Maemo location framework is explained in more detail in section 6.1.1. The API of the Maemo location framework is only available in the C programming language. Thus, this requirement effectively means that at some point C code needs to be used.3.1.3 Access through the web browser The definition of a mashup by [Wik05] introduced in section 1.1.1 states that a mashup is a website or an application. However, this thesis is restricted to mashups which are websites. Thus, it is a requirement that the mashups are31 CHAPTER 3. TRANSFERRING THE POSITION accessed through a web browser on the Internet Tablet. At the time of writing, the standard browser for the Internet Tablets is a commercial third-party product by Opera Software ASA. However, an open source browser based on Mozilla is under development inside Nokia. So all approaches discussed in this chapter must work with at least one of the two.3.1.4 User-centric system The emphasis of the system shall clearly be on the direct value for the person using an Internet Tablet and a GPS, rather than on the value for a remote system tracking the positions of all such persons. The architecture of the system shall be targeted towards user-initiated device centric applications rather than empowering the server side. This aspect has parallels to the control plane vs. user plane discussions in the context of location-based systems for mobile phone networks [Spi05]. Although this requirement is to some extend a “soft” requirement, it expresses preferences over the approaches.3.2 Position data providerA mashup fetches and combines data from different sources. By consistently applying the general mashup architecture, one (or more) position data providers can be introduced, which provide position data for use in the mashup. An existing example of this approach is WhereAmI.At1, a mapping mashup showing the user’s position on a Google map, pictures of the surrounding area from Flickr, and a link to the first Google search result on the name of the place. The data provider used for positioning is Hostip.info2, which attempts to determine the user’s position from the user’s IP address. While this means of positioning is not effective at all, the architectural principle behind WhereAmI.At is a promising approach which can be used for GPS positioning as well. Two ways to do this can be distinguished: The third party position data provider and the local data provider.3.2.1 Third party position data provider As it is the case with Hostip.info, the position data provider can be a third party service in the Internet. As illustrated in figure 3.1, mashups query the position data provider in order to obtain the user’s position. For the position data to be fresh, the user’s device has to upload the current position to the position data provider very frequently. This job can be done using a small native program, which constantly runs on the user’s device in the background.Data ProviderDeviceWeb Browser Mashup Site Data ProviderPosition GPS Client Data ProviderPosition uploadFigure 3.1: Mashup architecture using a third party position data provider. (For simplicity, the browser’s possibility to access data providers directly is not shown.)The approach of the third party position data provider has a number of advantages. First, it bears a clean architecture with separate components for separate concerns. Like all other data providers, the position data provider is a service with a defined interface, which can be re-used for many purposes. In addition to a system offering the1http://www.whereami.at/ (accessed July 23, 2007) 2http://www.hostip.info/ (accessed July 23, 2007)32 3.2. POSITION DATA PROVIDER user information concerning the current position, other applications like a map containing the positions of all the user’s friends are easily possible. Secondly, it is no problem if the user’s position is queried very frequently, as the position data provider is decoupled from the user’s device. Moreover, as more than one user’s position is available from the position data provider, this architecture is ideal for applications involving more than one user. This might be the map of all friends mentioned above or a tracker of a transport company’s trucks, for instance. However, in a way, this violates the requirement of a user-centric system mentioned in section 3.1.4. Thirdly, the last position that was sent to the position data provider is always available from there, even if the user loses the GPS fix (e. g., when inside a building) or goes offline. This adds extra robustness to systems utilizing this architecture. Finally, it is easily possible to create a history of the user’s movements if the position data provider stores more than only the last uploaded position, which can, e. g., be used to record driving routes, sports activities and the like. The most obvious downside of the third party data provider is that it lacks privacy. While this architecture enables a number of interesting applications it is unlikely that in a production system many users want the whole Internet to know their positions or even movement profiles based on the position history. So a trustworthy access control system is an absolute must-have. Besides, the user must thoroughly trust the third party data provider. A further disadvantage is that a server is required in the first place. In a production system this means that some organization is needed to run that server. While this might turn into a promising business model, it also means that a system built using the architecture of the third party position data provider cannot simply be deployed as a small add-on to the Internet Tablet. Another aspect is that in this push architecture, frequent updates to the position data provider are required to make the system useful. This way, network traffic is generated constantly, even if the position data is not being used. As the user might not always have WLAN connectivity, it can get quite costly to stay permanently connected via the mobile phone (at least at the time of writing).3.2.2 Local position data provider An alternative to the third party position data provider is to run the position data provider on the user’s device, as illustrated in figure 3.2. In the architecture of the local position data provider the program that accesses the GPS device and the position data provider are identical. It is a small program which offers position data via a certain, well-defined interface as a service running on the user’s device.Data ProviderDeviceWeb Browser Mashup Site Data ProviderPosition Data ProviderFigure 3.2: Mashup architecture using a local position data providerAt its core, this is what gpsd does. So basically all that is needed to create location-based mashups using a local position data provider is to start up the Maemo location framework and write a mashup page which opens a socket to the Internet Tablet on the gpsd port. Moreover, it is not hard to generate a user message or even ask the user for permission whenever a remote client attempts to connect to a local data provider such as gpsd. In addition to that, no unnecessary network traffic is generated as opposed to the push architecture of the third-party position data provider. The local position data provider apparently solves some of the issues of the third party position data provider, as it is no longer required to upload the user’s position to a possibly untrusted third-party server. However, in practice this approach is unlikely to work. The biggest problem is that it is virtually impossible for an arbitrary web server to open a socket to the Internet Tablet at all. The Internet Tablet is likely to be behind a masquerading firewall, have a local IP address or may even be connected via a mobile phone. So the approach does not even generally work in the first place.33 CHAPTER 3. TRANSFERRING THE POSITIONThe second big issue is that the mashup must know the IP address of the Internet Tablet and the port on which the local position data provider is running. Thus, once again the problem of bringing local data to the mashup is introduced, which makes this approach run in circles.3.3 Local mashupAnother way to integrate local position data into a mashup is to move the mashup, at least partly, onto the user’s device, like shown in figure 3.3. If the mashup runs on a local webserver, it is possible to access the GPS device from there before the mashup page is served into the sandbox of the browser. This can, e. g., be done using a CGI-program written in C. Alternatively, a native program running in the background can frequently write a plain file to the webserver’s directory containing the current position. The mashup application can read that file and thus retrieve the user’s position. The latter approach was indeed implemented for an early demonstration system in the beginning of the thesis. For this, the thttpd3 web server was ported to the Internet Tablet and a C program with 300 lines of code (SLOC) and an HTML page of 40 lines were written.Data ProviderDeviceWeb Browser Mashup Site Data ProviderGPS Client Data ProviderFigure 3.3: Local mashup architectureAs this example shows, the approach of the local mashup is very simple and can easily be put into practice. In addition to that, it does not have any built-in privacy problems as the position information never leaves the device—unless the position is used as a query parameter to access other data providers. However, the actual mashup code needs to be installed on the device, in addition to the local web server. This makes the approach a lot less interesting as a lot of flexibility is lost. Moreover, if the user has to install the mashup anyway, it can be questioned whether the mashup application still needs to be accessed via the browser. There are more flexibility, better performance and many other advantages in creating a native application like Maemo mapper (see section 2.1.8), which accesses the GPS device and queries data from the Internet.3.4 Web browser extensionThe approaches discussed above introduce new components to the general mashup architecture from section 2.2.2 in order to serve the web browser a mashup page which in some way has the user’s position included. A fundamentally different approach is to modify the web browser in such a way that it supplies the mashup with the position. The architecture of this approach is shown in figure 3.4 and is nearly identical to the general mashup architecture, as no extra components or servers are used besides the extension inside the browser. Several ways to transfer the position to the mashup using a browser extension can be distinguished and are discussed below.3 http://www.acme.com/software/thttpd/ (accessed July 23, 2007)34 3.4. WEB BROWSER EXTENSIONData ProviderDeviceWeb Browser Mashup Site Data Provider GPS ExtensionData ProviderFigure 3.4: Architecture of a mashup using a browser extension3.4.1 Modifying the page after loading From the user’s point of view it is probably the ideal solution to modify the mashup page after it has been loaded into the browser. A use case could look as follows: The user directs the browser to a web page which happens to include a map, the browser extension notices the map and offers the user the possibility to include the position retrieved from the GPS device into the map. If the user chooses this possibility, the map is modified. This approach has the striking advantage that an overwhelming number of existing mashup pages on the WWW can be immediately utilized, resulting in a richer web browsing experience—a definite commercial advantage for the vendor of such a system over vendors that only support “traditional” web browsing. This approach is indeed being used. The Swedish company Franson Technology AB offers a commercial product named GpsGate4, which includes a browser extension that is able to show the current GPS position in Google Maps. However, modifying the page after loading does not come without drawbacks. First of all, this approach results in very tight coupling of the browser extension to the code of the web page. Franson GpsGate, for instance, only works with Google Maps version 2 and relies on Google Maps creating the window.map JavaScript object. As soon as Google changes this behaviour, GpsGate will stop working. In addition to that, the use cases of this approach are limited. Despite the promising advantage of, e. g., enhancing all existing mashups based on Google Maps, this approach is hardly capable of doing much more than enriching maps. A mashup which presents information based on the current position as text will be almost impossible without hacks like having a hidden map. Concerning privacy, this approach has the advantage that the position is only brought to the web page once the page is fully loaded and thus does not need to be transferred outside the device. However, it is difficult to restrict JavaScript code embedded in bogus web pages from extracting the position from the map and submitting it to a server.3.4.2 Modifying page requests When thinking about how to transfer context information to a web page, one must not forget that the HTTP protocol, which is the basis for most current web content delivery, already provides several ways to do that. HTTP headers are being widely used to transfer context information such as the browser used (User-Agent header), the preferred encoding, character set and language (Accept-Encoding, Accept-Charset and Accept-Language headers) and the supported media types (Accept header). The server can react to this context information returning an appropriate version of a web page. The HTTP standard defines a fixed set of HTTP headers, but allows the definition of new, so-called experimental headers, provided that they carry the prefix X-. Another way to transfer information to a web server is to set parameters of an HTTP GET or POST request. HTTP parameters are arbitrary name–value pairs and are intended to transfer information the user entered into a form. However HTTP parameters are often used to keep state information of a web application, such as a session ID, as well, as web application developers are constantly confronted with the statelessness of the HTTP protocol. Both HTTP headers and HTTP parameters can be used to transfer the user’s position to a web page. A browser extension can be written so that, in principle, every time the browser is about to send an HTTP request, the GPS4http://www.franson.com/gpsgate/ (accessed July 23, 2007)35 CHAPTER 3. TRANSFERRING THE POSITION device is queried for the current position and extra HTTP headers or parameters are added to the HTTP request before sending. In fact, this approach was implemented in the early phases of this work. For this, two Mozilla components were created both for the desktop PC and the Internet Tablet: the PositionService component for accessing the GPS device (returning a hard-coded position on the PC) and the HttpHeaderLocationSubmitter component for setting HTTP headers. The Mozilla browser offers an easy way to hook into the sending of an HTTP request. An observer such as the HttpHeaderLocationSubmitter can be registered at Mozilla’s central observer service to be notified about the http-on-modify-request event, which signals that an HTTP request is about to be made. When being called, the observer can easily examine the HTTP headers and add new HTTP headers to the request. So every time the HttpHeaderLocationSubmitter is notified about an http-on-modify-request event, it obtains the current position from the PositionService and adds the X-TELAR-latitude5 and X-TELAR-longitude HTTP headers to the request. Figure 3.5 shows a screenshot of the PHP page which was used during development. As can be seen from listing 3.1, the PHP page simply iterates over all HTTP request headers and prints them as an HTML definition list. For demonstration purposes, another PHP page of nearly equal simplicity was built during this work which used the HTTP headers to show the current position on a Google map. On the Internet Tablet this system already bears some value and using the same technique mashups of arbitrary complexity can be built.Figure 3.5: A PHP test page displaying all HTTP headers of the HTTP request, including X-TELAR-latitude and X-TELAR-longitude (screenshot)<?php $header_array = apache_request_headers(); echo "<dl>\n"; foreach ($header_array as $header => $value) { echo " <dt>$header</dt><dd>$value</dd>\n"; } echo "</dl>\n"; ?> Listing 3.1: http.php, a PHP page displaying all HTTP request headersThe implemented system that utilizes the approach of modifying page requests shows that this approach does work. It uses the existing context transmission mechanisms of the HTTP protocol and thus has a clean architecture. There is no tight coupling to the web page, as the position is transmitted to the mashup as a discrete datum which the mashup can use freely. Neither does this approach require any extra servers to be set up. All that is needed is to deploy the browser extensions into the browser of the device.5The string “TELAR” refers to the internal project name of this thesis at Nokia Multimedia.36 3.4. WEB BROWSER EXTENSIONHowever, there are disadvantages as well. First of all, the extended HTTP headers are not standardized, and the same would hold for HTTP GET and POST parameters as well. That means that despite every web server receiving those headers only few would actually read and interpret them, which naturally reduces the usefulness of this approach. A second disadvantage comes with the increased use of AJAX. When the position is sent with the page request, the mashup can respond with an appropriate page utilizing the position. A change of the user’s position is only reflected in the page with the next page request, e. g., when the page is reloaded. In AJAX-based web pages, however, the page is rarely refreshed or reloaded as dynamic changes of the page are handled using asynchronous HTTP requests. Consequently, the position is integrated into the mashup page in the beginning when the page is first visited and the longer the page is being used the more outdated the position information gets. This is acceptable for some purposes. But applications such as showing the current position while the user is walking, or even displaying the route the user has already walked, are not cleanly possible. One could, of course, periodically send an asynchronous HTTP request to a script which reads the position information and returns the position back to the browser in the HTTP response, but the author does not consider this as a clean solution. So some people might call modifying page requests an approach for the “Web 1.0”. As this approach in principle adds the position to every page request the browser sends, the privacy aspect is not very well supported. Naturally a whitelist of pages can be introduced so that the position is only sent to web pages which the user explicitly added to that list. This is, however, tiresome as the user has to do a lot of work manually and might not even know which web page supports position awareness. So the web page needs to inform the user. Technically this is not a problem, but it might be prohibitive for a widely used mainstream system.3.4.3 JavaScript API The upper approach of modifying page requests actively sends the position to the mashup page, no matter whether it is actually used or not. An alternate approach is to offer the mashup the possibility to obtain the position information itself when it needs it, following the principle of a pull architecture. Inside the browser this can be done by offering a JavaScript API that can be used by JavaScript code included in the mashup page. This work identifies three ways to expose such a JavaScript API: UniversalXPConnect, a JavaScript position object and the Delivery Context Interfaces (DCI).UniversalXPConnect Section 3.4.2 already mentioned a Mozilla component named PositionService that was implemented for the HTTP header-based system. This component is capable of connecting to the GPS device and offers the current position through a simple interface. This is all that is needed for the JavaScript API approach. The HttpHeaderLocationSubmitter, which was in fact implemented in JavaScript, connects to the PositionService component using XPCOM, the cross platform component framework with which Mozilla is built (see section 6.1.2). It is possible for JavaScript code embedded in a web page to use the internal components of Mozilla as well, if that code has the UniversalXPConnect privilege. The UniversalXPConnect privilege basically allows to leave the sandbox of the browser and is obtained by the following JavaScript call: netscape.security.PrivilegeManager.enablePrivilege("UniversalXPConnect");The behaviour of this call varies between different versions of Mozilla. Depending on its configuration, the browser might ask the user whether the permission shall be granted. As the PositionService component was available already from the HTTP header-based system, a mashup page using the UniversalXPConnect approach was created during this work. While it did work with the Firefox browser on the author’s Linux PC, the development version of the Mozilla-based browser had a bug at that time so that UniversalXPConnect privileges could not be obtained by the JavaScript code embedded in the mashup page. As this experiment shows, the UniversalXPConnect approach is basically feasible, however there are many disadvantages. First of all, web browsers put web pages into a sandbox for the good reason of security and this sandbox should not be broken or worked around. Moreover, the UniversalXPConnect approach is closely coupled to the family of Mozilla browsers and does not even necessarily work with all members of that family. And finally it requires the mashup developer to include JavaScript code into the mashup which is far from being standardized.JavaScript position object The UniversalXPConnect approach discussed above is basically well-suited, except for the way the JavaScript API needs to be used. If instead of making the code of the mashup have to break out of the browser’s sandbox in37 CHAPTER 3. TRANSFERRING THE POSITION order to access the GPS component, the GPS component was available inside that sandbox the problems of the UniversalXPConnect approach listed above were solved. This can be done by introducing a new JavaScript object to the JavaScript API of the browser. Like the window or document JavaScript objects are statically defined objects that scripts in a web page can use, the web browser can be extended so that a similar object is available for obtaining position information. mozGPS is an extension for the (Mozilla-based) minimo browser which exactly does this [Tur06]. Web pages can obtain the GPS position from mozGPS using JavaScript code like shown in listing 3.2. var gps = new window.GPSService; var lon = gps.longitude; var lat = gps.latitude; var alt = gps.altitude; Listing 3.2: Accessing the GPS position from the mozGPS minimo extension [Tur06]This is a very elegant way of getting the position data from the GPS device into a mashup. No external entities besides the browser extension need to be deployed, the approach works for arbitrary mashups and the dynamic behaviour of AJAX-based web pages is supported as well. The only disadvantage the author can find in this approach is that the additional JavaScript object—like the extended HTTP headers in section 3.4.2—is not standardized. Consequently, many web developers will simply not know that it is possible to obtain the position at all, and other implementations like Franson GpsGate mentioned above have other interfaces for the same functionality. A JavaScript position object can—similar to the popular popup blocker browser extensions—ask the user whether a script included in a web page shall be granted access to the position information. It is not possible to determine what the script will subsequently do with the position, but an “all or nothing” way of privacy is possible.Delivery Context Interfaces (DCI) In order to provide a standardized way to access the position via a JavaScript position object as introduced above, the Delivery Context Interfaces (DCI) [WHR+06] can be used. DCI was published by the World Wide Web Consortium (W3C) and has, at the time of writing, the status of a Candidate Recommendation. DCI defines a generic way to make properties describing the user’s context available to a web page. A hierarchical data structure is exposed to the code of a web page by extending the JavaScript API of the browser. DCI can thus be considered a specialization of the JavaScript position object approach introduced above. DCI uses the DOM event model to notify registered event listeners of property changes, which makes dynamic adaptations to position changes especially easy. DCI does not define a privacy model but approaches to address privacy are published, e. g., in [Sat07]. Chapter 4 describes DCI in further detail.3.5 ComparisonThis section compares the most promising approaches introduced in this chapter. The third party position data provider, sending HTTP headers containing the position data, a JavaScript position object and the DCI API, while having their drawbacks, all feature a clean architecture and are feasible without any hacks. The local position data provider, the local mashup, modifying the page after loading and UniversalXPConnect on the other hand are not included here as their disadvantages discussed above are considered prohibitive. Table 3.1 confronts the selected approaches with aspects that are considered important for this thesis. In the context of Web 2.0 it is required that a mashup can dynamically respond when the user’s position changes. An external server is considered a disadvantage in this work, while having definite advantages for other types of application (see section 3.1.4). Along with the external server goes the possibility of using the user’s position in other systems than the mashup which the user is browsing. This is a nice feature making possible application like seeing all friends on a map. It is on the other hand not considered essential in the context of this work and can, besides, be achieved by using AJAX as well. Privacy is an aspect which might be temporarily disregarded in a research or demonstration system. But it is of utter importance for a production system. The same holds for standardization; while everything goes in a lab environment, a production system must comply with existing standards or cooperate with other organizational entities in order to achieve a widely accepted and interoperable way of transferring the position.38 3.5. COMPARISON3rd Party Pos. HTTP Headers Position Object DCI dynamic adaptation yes no yes yes, with events external server required yes no no no externally usable yes no no no privacy possible difficult possible possible standardized no no no yesTable 3.1: Comparison of the most promising approaches to transfer the position to a mashupAs table 3.1 shows, the JavaScript position object is, according to the applied criteria, inferior to DCI for missing standardization. Also the HTTP headers cannot keep up with DCI, as they miss dynamic adaptation in addition to standardization. The approach of the third party position data provider has the advantage of being externally usable. But as discussed above, this is not of such importance for this work that it would justify the required external server, which, in addition to that, is not standardized. Consequently, the result of this comparison is that DCI is considered the most appropriate approach for this work. The following chapter introduces DCI in more detail.39 CHAPTER 3. TRANSFERRING THE POSITION40 CHAPTER 4DELIVERY CONTEXT INTERFACES (DCI)The previous chapter concluded with the result that the Delivery Context Interfaces (DCI) [WHR+06] meet the requirements of this work for transferring the GPS position to a mashup best. This chapter gives a more in-depth description DCI and is based on the works of Sailesh Sathish, one of the authors of DCI [Sat07, SP06].4.1 IntroductionThe majority of existing web pages have been developed for the standard desktop browser and, as such, require hardly any adaptation to the user’s context. But when a web page is accessed through a mobile device with limited resources such as a mobile phone or a PDA, presentation and interaction problems are introduced. In addition to that, such devices also vary in screen size, keypad type, screen orientations etc. As writing web pages tailored to each configuration is not an option, web pages that adapt to the user’s context are required. As mentioned in the previous chapter, it is of utter importance to have standardized interfaces when exposing an API to a huge multi-platform and multi-vendor system such as the WWW. DCI makes an approach to standardize a consumer interface for accessing context information of any kind. It is suited for web applications but can also be used by other frameworks because of the offered generality and extensibility. DCI provides access methods for manipulating static and dynamic properties that may be exposed by the device, system and environment. Static properties, like the screen resolution of the device, hold a fixed value, while dynamic properties, such as the GPS position, change over time. The properties are organized hierarchically and the resulting property tree can be obtained and used by a web page via JavaScript. In addition to that it is possible to add and remove properties dynamically. For instance when an external GPS receiver is connected to the user’s device, the respective GPS property nodes can be added to the property tree. An example of a DCI property tree is shown in figure 5.2 on page 48. DCI is based on the document object model API (DOM) [LLW+00], which is usually used by web browsers in order to expose the HTML document to JavaScript code embedded in a web page. Through DOM, the JavaScript code can access the document as a hierarchy of DOM nodes corresponding to the elements of a well-formed XML document. DOM also supports an event system that involves an event propagation mechanism and handlers for listening to events. DCI uses DOM to expose the property tree to JavaScript. The approach was adopted due to the popularity and familiarity of DOM among application developers and also because it fits well with current browser support for DOM. Moreover, the DOM event system is ideal for giving web pages the possibility to react when dynamic properties change, which corresponds to the criterion of dynamic adaptation in section 3.5. At the time of writing, DCI is in Candidate Recommendation status in the specification process of the World Wide Web Consortium (W3C). Once the candidate recommendation period is passed, the specification is expected to go to proposed recommendation status and finally become a standard. The current editorship of DCI specification is shared by Nokia, France Telecom, IBM, and Canon.4.2 DescriptionLike DOM, DCI is formally defined in terms of the OMG Interface Definition Language (IDL) [Obj02]. The central interface of DCI is DCIProperty, which is implemented by all nodes in the property tree and inherits from the DOM Node interface. Thus, attributes like name, namespace, parent node and sibling nodes are inherited so that navigation through the property tree is done exactly like through any other DOM tree.41 CHAPTER 4. DELIVERY CONTEXT INTERFACES (DCI)DCIProperty carries the value attribute, which is naturally used to hold the value of the property and is of the generic any type. In order to determine the concrete type of the value held, the valueType attribute can be used, which is a string. The content of the valueType string is not specified, however it is suggested to be a URI. Similarly, the DCIMetaDataInterface is of any type and can hold arbitrary meta data and the DCIMetaDataInterfaceType attribute is a string denoting the concrete type of metadata. The contents of these attributes are not specified, either. However, an example is given, in which the DCIMetadataInterfaceType property property is set to "application/rdf+xml", and the value of the DCIMetadataInterface is a URI that points to the RDF meta data information available for this property. In addition, the DCIProperty interface defines the convenience methods hasProperty() and search- Property(), which traverse a property (sub-) tree looking for specific properties. Both methods search by property name and namespace and accept wildcards (*). While hasProperty() only returns a boolean value denoting the existence of respective properties, searchProperty() returns a DOM NodeList instance containing the matching properties. Optionally, searchProperty() accepts a DCIPropertyFilter instance, which may further restrict the result set through a specific implementation of its acceptProperty() method. The event model used by DCI conforms to the DOM Event Specification [Pix00]. Objects implementing the DOM EventListener interface can register as listeners on properties in the DCI tree using the addEventListener method defined in the DOM Node interface. As event listeners can be registered at arbitrary property nodes in the tree, notification at different levels is possible offering fine-grained control of which events are received by which listeners. In accordance with the DOM Event Specification, events are dispatched to the event listeners in two phases. When an event is raised at a property p, the event is first dispatched in the capture phase from the root property down to but not including the property p. All event listeners are notified which were registered with the useCapture option enabled at a property along the path. After the capture phase the event is dispatched in the bubble phase from the property p back up to the root property. This time those listeners are notified which were registered at a property along the path with the useCapture option disabled. It is however undefined in what order the listeners are notified which were registered at the same property for the same event phase and the same event. DCI specifies one additional event that listeners can register for: dci-prop-change is raised after a property changes its value and can thus easily be used to keep track of dynamic properties such as the GPS position. In addition to that, three events from the DOM Event Specification are utilized: DOMNodeInserted and DOMNodeRemoved are raised when a new property has been added as a child of another property or when a property is being removed from its parent property, respectively. Instead, at the implementation’s discretion, the DOMSubtreeModified event can be raised after one ore more structural changes occurring simultaneously or in rapid succession. The latter practice saves many redundant events which notify of logically the same “transaction”. While DCI specifies a generic data structure for a hierarchy of named properties, it does not define an ontology describing the vocabulary for properties and the relations these properties might have to each other. One or more ontologies for DCI are expected to be specified by standards bodies, Original Equipment Manufacturers (OEMs) or others, but are, despite ongoing efforts, simply not present at the time of writing. In addition to that, DCI does not specify how JavaScript code embedded in a web page can access the DCI tree. The proof of concept implementation by Sailesh Sathish and Olli Pettay [SP06] implements DCI as a DOM feature making the DCI root property accessible via a call to document.getFeature(). However, a different implementation might as well introduce a static JavaScript object similar to the position object discussed in section 3.4.3. Leaving access to the DCI tree unspecified creates more flexibility for implementations on various web browsers. However, as it is the very first step when using DCI, no interoperable web pages can be written with the current state of the DCI specification. This adds a certain sense of perspective to the advantage of having a standardized interface for context access.4.3 EvaluationDCI has several advantages and drawbacks. As the previous chapter concluded, one striking advantage is the standardized interface. Secondly, DCI is a generic interface for accessing all kinds of context information rather than being restricted to a particular application domain such as positioning. Thirdly, the hierarchical representation of context information maintains relations between properties and enables efficient search and navigation. Fourthly, being based on DOM, DCI re-uses existing standards rather than introducing yet another interface. This makes existing tools and mechanisms such as XPath available for DCI. Besides, the DOM API is already familiar to application programmers. And finally, by using the DOM Event Specification DCI features, a powerful event system making dynamic adaptation possible.42 4.4. AN ARCHITECTURE USING DCIThe three major drawbacks of DCI are due to the incompleteness of the DCI specification. The most serious issue is that no standardized ontologies exist defining the DCI property hierarchy. The same holds for metadata structures. However, without a defined hierarchy, no interoperable usage of DCI is possible. Secondly, DCI defines no security model. As information about the user’s context is likely to contain sensitive data, this is a definite shortcoming which has to be solved in the specific implementations (see below) and might thus introduce interoperability issues. And thirdly, the fact that access to the DCI tree is not standardized leaving it to browser specific implementation definitely does create those issues. As, at the time of writing, DCI is still in an early state and is not widely used these drawbacks are likely to be addressed in later versions of DCI.4.4 An architecture using DCIAs described above, DCI specifies the consumer interface through which web pages and other client applications can access context information. However, for a context provisioning framework a consumer API is not enough. For clients to access context data from DCI, the DCI tree obviously must hold that data and the data must have been provided by one or more context data providers. In order to achieve this in a flexible and extendable manner, a complete context provisioning architecture is needed. One such architecture was developed internally at Nokia Research Center by Sailesh Sathish and Olli Pettay [SP06] and is illustrated in figure 4.1.Browser ApplicationDelivery Dynamic Context Device Interface ProfileAccess Control Model DCI Provider InterfaceDCI Session ManagerContext Context Data ... Data Provider 1 Provider nFigure 4.1: Context access and adaptation architecture introduced by [SP06]The central part of this architecture is the DCI provider interface. Context data providers connect through the DCI session manager to the DCI provider interface and update the DCI tree. The DCI session manager is responsible for transparent access of all kinds of context data providers, both local and remote. Remote context data providers connect through appropriate protocol stacks. The access control module determines whether and where to provide access for external properties within the DCI tree and might, in a more sophisticated system such as proposed in [SPT06], also perform ontology-based integrity checks. In addition to DCI, the architecture supports a second means of context access. The dynamic device profile API generates a serialized snapshot of the DCI tree for server-sided context adaptation. The architecture proposed by Sathish and Pettay uses DCI as a standardized interface to web applications, but is not standardized itself. Even though it would be good to have a standardized architecture, a context provisioning framework and especially a provider API can also be proprietary. This is because the provider interface is used directly by local applications installed on the user’s device and is thus a part of the device platform. As long as the interface to entities outside the device is standardized, interoperability is not compromised.43 CHAPTER 4. DELIVERY CONTEXT INTERFACES (DCI)4.5 Delivery Context Client Interfaces (DCCI)Shortly before the end of this thesis, a new version of the DCI specification was published with the status of a W3C Working Draft [WHR+07]. The most obvious change is that DCI was renamed to Delivery Context Client Interfaces (DCCI), in order to better express that a client-side interface is specified. As a consequence, all identifiers containing the string “DCI” in the specification were renamed. The only normative change is that the DCCIProperty interface (formerly DCIProperty) no longer inherits from the DOM Node interface but now inherits from the DOM Element. However, this work is entirely based on DCI as published in [WHR+06] and does not consider the changes introduced with DCCI.44 CHAPTER 5ASYSTEM FOR LOCATION-BASED MASHUPSThis chapter introduces the system for location-based mashups which was developed during this thesis. In analogy to the internal project name of this thesis at Nokia, the system is named “TELAR mashup platform”. First, the requirements for the system are specified. Based on these requirements, a system architecture was developed that is presented subsequently. Furthermore, the data format used by the system is introduced.5.1 RequirementsOne task of this thesis is to examine usage scenarios for location-based mashups. The vast majority of mapping mashups in the WWW uses a map API such as Google Maps in order to annotate a map with items of some kind that are represented as POIs. One example is ChicagoCrime introduced in section 1.1.1. A system for augmenting a map with arbitrary POIs from different sources in a simplified way makes developing such mapping mashups easier. If that system also integrates the user’s position new value for both users and developers is created. The TELAR mashup platform is specified to be such a system. A list of functional requirements for the TELAR mashup platform is given below. During the development of the system, an agile development model was used adding new requirements with every iteration as long as time was left. The list below reflects the requirements at the end of the development phase. In addition to these requirements the TELAR mashup platform also must comply with the requirements specified in section 3.1. This means that the TELAR mashup platform must run on a Nokia N800 Internet Tablet, support a Nokia LD-3W GPS device, use the Maemo location framework, and must be accessible through the web browser.MapReq-1 The TELAR mashup platform embeds a map into an HTML page. The map can be integrated into any HTML page. Several maps per page are not required.Req-2 The TELAR mashup platform may be restricted to one map service, e. g., Google Maps. This means that a generic map service layer is not required.Req-3 The initial zoom level and default center of the map is configurable for each mashup.POI data Req-4 POIs from different data providers are displayed on a map.Req-5 Several data providers offering data in several data formats must be supported.Req-6 The different data formats offered by the data providers may be converted into a standard representation understood by the TELAR mashup platform using hard-coded adapters. It is thus legal to have a special wrapper for each data provider, automatic data format transformation is not required.Req-7 The data providers used in a concrete mashup are configurable. A configurable set of data providers is used by the mashup at startup. The user has the possibility to add new data providers or remove used data providers from the mashup once the mashup is loaded into the browser.45 CHAPTER 5. A SYSTEM FOR LOCATION-BASED MASHUPSReq-8 POIs are displayed on the map using arbitrary images. Further data attached to a POI is displayed inside an info window which pops up when the user clicks on the POI.Req-9 If a data provider supports geographically restricted queries, the data provider is only queried for data relevant for the area currently shown on the map.Req-10 Whenever the area shown by the map (called map bounding box) changes, it is ensured that data for the new map bounding box is available. If necessary, the data providers are queried for new data, provided they support geographically restricted queries.Req-11 Data providers are always queried asynchronously in the background, i. e., without a full page reload.The user’s position Req-12 Mashups are usable on a Nokia N800 as well as on a browser (a recent version of Mozilla Firefox is sufficient). On a Nokia N800, mashups work both with and without a GPS device.Req-13 On a Nokia N800, the user’s position is retrieved from a GPS device (if present) and integrated into a mashup by extending the web browser’s JavaScript API. This is done according to the DCI specification [WHR+06].Req-14 Whenever the user’s position is available (i. e., on a Nokia N800 with a connected GPS having a fix), the map is centered to that position. The user may override this behaviour by navigating the map manually. Functionality is provided to re-center the map to the GPS position. In case the user’s position is not available, the map is initially centered to the default position. Re-centering to the default position is not required.Req-15 Whenever the user’s position is available, it is marked on the map using an image that is configurable for each mashup.Req-16 If the user’s position is available, the user can have the current position displayed as WGS84 coordinates.Tracking Req-17 A track of the user’s positions is kept and drawn on the map as a linestring. The user can clear the history. The user can disable keeping the track.A non-functional requirement of great importance is extensibility. In the highly dynamic context of Web 2.0 with numerous new mashups published every day, it is essential that the TELAR mashup platform can easily be extended to comply with new requirements.5.2 ArchitectureBased on the requirements specified in the previous section, a system architecture for the TELAR mashup platform is defined. This section gives an overview of the architecture and describes the parts of the architecture in detail.5.2.1 OverviewA graphical overview of the system architecture for the TELAR mashup platform is given in figure 5.1. The architecture follows the general mashup architecture introduced in section 2.2.2: a mashup is viewed in the web browser, loaded from the mashup site and data from third party data providers is used. A mashup page consists of an HTML page that includes the JavaScript files of the TELAR client. A static XML file named mashup-config.xml defines all values that are specified to be configurable in section 5.1, especially the data providers used in the mashup, and is hosted on the mashup site with the HTML page. The TELAR client asynchronously loads the configuration file when the mashup page is loaded. The data from the data providers is mashed by the TELAR client in the web browser, i. e., the data providers are queried via asynchronous HTTP requests. As the XMLHttpRequest JavaScript object only allows requests to the same server from which the web page was initially loaded, wrappers for accessing the data providers are needed. In addition to that, the wrappers46 5.2. ARCHITECTUREWeb Browser index.htmlGPS Access Telar Client XPCOMDCI DOM EventsPage Load Asynchronous RequestsMashup Site mashup- index.html config.html Wrapper 1 ... Wrapper nData Provider 1 ... Data Provider nFigure 5.1: The system architecture of the TELAR mashup platform convert the data into a uniform data format which the TELAR client understands. Adaptation to the heterogeneity of data formats used by the different data providers is thus done on the mashup site. The user’s position is integrated into the mashup by extending the web browser. For this, two Mozilla extensions are use used: the DCI module and the GPS access module. The DCI module implements the DCI specification API described in chapter 4. The TELAR client obtains the user’s position by registering itself as an event listener to the DCI properties which contain the user’s position. The GPS access module connects to the GPS device using the Maemo location framework (see section 6.1.1) and updates the DCI tree. The two Mozilla modules communicate directly via XPCOM, the component framework of the Mozilla browser (see section 6.1.2). Thus, despite the fact that other modules providing the DCI tree with context data can be easily added, no all-embracing context provisioning framework based on DCI similar the one introduced in section 4.4 is created. There is no session management and in this particular implementation not even access control (see chapter 7). Basically, DCI is used in order to have a standardized interface to be used by the TELAR client and other web applications; the implementation behind that interface is just as powerful as required for the purposes of the TELAR mashup platform.5.2.2 OntologyAs pointed out in section 4.2, the DCI specification does not define any ontologies for the DCI tree. How- ever, this thesis could not wait for standardization bodies to solve this issue, so an unstandardized ontology was defined for the purposes of the TELAR mashup platform. The ontology is defined in the namespace http://www.nokia.com/telar, i. e., all properties described below carry that namespace. Figure 5.2 illustrates the ontology. The ontology affects the GPS access module, the DCI module and the TELAR client. Later changes in the ontology are possible but may require slight adaptations to those three units. The DCI module always creates three basic property nodes under the DCI root property: Hardware, Software and Location. The Hardware property can be used to reflect information about the user’s device like the screen resolution, processing power or the manufacturer. Similarly, the Software property may contain information like the <a href="/tags/Operating_system/" rel="tag">operating system</a>, the browser and its version. The Location property, however, is the only one that is truly needed for the purposes of the TELAR mashup platform and reflects the information which the GPS access module received from the GPS device.47 CHAPTER 5. A SYSTEM FOR LOCATION-BASED MASHUPSDCIHardware Software LocationGPSStatus Latitude Longitude Altitude FIX 3D 65.013388 25.5111122 31.28Figure 5.2: The ontology for the DCI tree used by the TELAR mashup platformAt startup the GPS access module connects to the DCI module and creates the GPS property as a child of the Location property and the Status property as a child of the GPS property. The GPS and Status properties are present in the DCI tree as long as the GPS access module exists in the browser. Depending on the state of the GPS device, three additional child properties might exist below the GPS property: Latitude, Longitude and Altitude. If the GPS has a two-dimensional fix, Latitude and Longitude are present. If there is a three-dimensional fix, the Altitude property also exists. Thus, if the state of the GPS device changes, these properties might be inserted into the DCI tree or removed from it. The value of the Status property indicates what kind of GPS fix is currently reflected in the DCI tree. Legal values are "NO FIX", "FIX 2D" and "FIX 3D". The values of the Latitude, Longitude and Altitude properties, if present, contain the respective data from the GPS fix as a double value represented as a string. The GPS property itself contains no value.5.2.3 DCI moduleThe DCI module provides the interface through which the GPS access module publishes the user’s position to the TELAR client. The DCI module is an XPCOM module implementing the interfaces defined by the DCI specification. The DCI module is implemented in the C++ programming language. It would be technically possible to implement the IDL interfaces of DCI in JavaScript as well, which would save a lot of development effort due to the higher abstraction level of the JavaScript programming language. Moreover, a JavaScript implementation could be re-used on a Mozilla-based PC browser without recompiling. However, it must be considered that the Nokia N800 has only limited computing power and a C++ implementation is simply faster. The interfaces implemented by the DCI module are accessible for a web page as a DOM feature. Thus, a web page can access the DCI root property using document.getFeature("DCI", "2.0") and test whether the browser supports DCI using document.isSupported("DCI", "2.0"). For XPCOM modules, such as the GPS access module, the DCI module is accessible as an XPCOM service, i. e., a handle to the DCI root property can be obtained from the XPCOM service manager. As stated above, the TELAR mashup platform does not feature a full-fledged context provisioning framework. Context data providers like the GPS access module must be XPCOM modules and reside inside the browser. As opposed to the architecture introduced in section 4.4, there is no real provider API, either. Context data providers can manipulate the DCI tree using the methods of the DCIProperty and the DOM Node interfaces. This allows for navigation through the DCI tree, setting property values, and adding and removing properties. The only thing that is missing is the creation of new property objects. For this purpose the DCI module implements an additional, unstandardized interface named nsIDCIPropertyCreator. The DCI specification, which is based on DOM, allows implementations to be based on DOM level 2 or level 3. The DCI implementation of the TELAR mashup platform is based on DOM level 2. As a consequence, property values are represented as strings rather than being arbitrary JavaScript objects. The same holds for the DCIMetadataInterface attribute. In addition, the DCI module does not support the event interfaces described in the DOM Level 3 Events Specification [LP03]. Thus, event namespaces, event groups and event categories are not supported.48 5.2. ARCHITECTUREThe DCI module is put into practice as a singleton. It is initialized when it is first used as an XPCOM service or as a DOM feature. The singleton instance is only destroyed when the browser unloads the DCI module at application shutdown.5.2.4 GPS access module The job of the GPS access module is to obtain the user’s position from the GPS device and insert it into the DCI tree so that the TELAR client can access it. As the GPS access module is not intended to be accessed by other modules, it only implements interfaces that are needed for internal purposes, such as nsIObserver for use with the XPCOM observer service. The GPS access module is implemented in the C++ programming language, because it needs to access the C API of the Maemo location framework. The GPS access module is notified by the XPCOM observer service when the web browser starts up. A background thread is started that establishes a Bluetooth connection to the GPS device, starts gpsd and polls the GPS device for the current position every ten seconds. The Maemo location framework is used for this purpose (see section 6.1.1). The background thread is only terminated when the web browser is closed or an error is received from the location framework. A watchdog timer checks every 30 seconds whether the thread is still alive and restarts it if necessary. The GPS access module uses the DCI module as an XPCOM service. A handle to the DCI root property is obtained and the DCI tree is modified through the various interfaces implemented by the DCI module. At startup, the GPS and the Status property are created in the DCI tree. Every time the GPS device is polled, the child properties of the GPS property are updated with the data which the Maemo location framework returned. If necessary, the Latitude, Longitude and Altitude properties are added to the DCI tree or removed from it. As described in section 5.2.2, the values of the these properties are double values represented as strings. The GPS access module does not set the valueType, DCIMetaDataInterface or DCIMetaDataInterfaceType attributes of any DCI properties, as they are not required for the purposes of the TELAR mashup platform.5.2.5 TELAR clientThe TELAR client assembles the mashup and acts as the user interface of the TELAR mashup platform. It creates a map using Google Maps, shows the user’s position on the map, queries POI data from the data provider wrappers, shows the POIs on the map, and draws a linestring tracking the user’s past positions. Thus, the TELAR client implements all requirements enumerated in section 5.1, except for Req-6 and Req-13, which affect the data provider wrappers and the DCI module. The TELAR client consists of a number of JavaScript files that have to be referenced from the HTML page of the mashup and are executed by the web browser when the mashup is loaded. At startup the TELAR client asynchronously loads the mashup configuration from the mashup site, parses the configuration, and initializes the data providers, the user interface and the map. The JavaScript client registers itself as an event listener for the children of the GPS property in the DCI tree. In addition to that, it registers as a listener to the map listening to all events which change the map bounding box. Such events occur when the map is centered to a different point due to a manual user action or a new GPS position being received. In addition, the map bounding box changes when the user sets the map to a different zoom level. After initialisation the TELAR client only reacts to the events it is notified about. When the children of the GPS property in the DCI tree change and the Status property indicates that a GPS fix is available, the user’s position is obtained from the Latitude and Longitude properties. The Altitude property is never accessed by the TELAR client. The user’s position is used in order to be set or updated on the map and, in case the user did not override this behaviour, center the map. When the TELAR client receives an event about the map bounding box having changed, asynchronous HTTP requests carrying the new bounding box as a number of HTTP GET parameters are sent to the wrappers of those data providers which support geographically restricted queries. The wrappers return a number of POIs in a data format known to the TELAR client (see below). The POI data is parsed and the POI objects are placed on the map. As the web browser of the Nokia N800 does not support any other scripting languages in web pages besides JavaScript, there is no choice about the implementation language of the TELAR client. However, the JavaScript programming language lacks some important concepts that would make the development of bigger applications significantly easier, such as strong typing and modularity. While strong typing allows for powerful development tools, modularity has a strong influence on the extensibility of the application. Extensibility is, however, a non- functional requirement specified in section 5.1. Therefore it was decided to implement the TELAR client using the Google Web Toolkit. The Google Web Toolkit addresses the weaknesses of JavaScript by allowing AJAX49 CHAPTER 5. A SYSTEM FOR LOCATION-BASED MASHUPS applications to be implemented in the much more powerful Java programming language and compiles the Java code to a number of JavaScript files. Moreover, the Google Web Toolkit allows for including hand-written JavaScript code through its JavaScript Native Interface. The TELAR client uses this interface in order to access the JavaScript API exposed by the DCI module. The Google Maps API is usually accessed via JavaScript as well. However, an open source library exists which offers a Google Maps widget for the Google Web Toolkit. Using this library the TELAR client does not need to access the Google Maps API through the JavaScript Native Interface. Section 6.1.3 describes the Google Web Toolkit in further detail. In addition to that, the Google Web Toolkit offers a library of GUI widgets which can be used in the same way as other GUI libraries such as Swing. As the user interface of the TELAR mashup platform, the TELAR client defines a single composite widget. This “TELAR widget” comprises a menu bar and the Google Maps widget. The menu bar lets the user modify the map type (e. g., satellite view or map view) and edit the set of data providers currently included in the mashup. In case the user’s position is currently known, the user may also disable the map to follow the user’s position, disable tracking the position history as a linestring, clear the position history, and show the position as WGS84 coordinates in a popup window.5.2.6 Data provider wrappersThe data provider wrappers are where the TELAR client gets the POI data from. When the TELAR client needs new POI data, it queries the wrappers and the wrappers in turn query the “real” data providers. The wrappers convert the data into a format understood by the TELAR client and answer the queries with the converted data. There are two reasons why the TELAR client cannot directly query the data providers. First, for asynchronous queries the JavaScript XMLHttpRequest JavaScript object is used. For security reasons web browsers restrict the XMLHttpRequest object to HTTP(s) requests to the server from which the web page was loaded, in this case the mashup site. Thus, the data provider wrappers must act as a proxy forwarding the TELAR client’s HTTP requests to the data providers. Secondly, the data providers do not offer their data in a consistent format but return numerous data models and serialisation formats, rivaling the Tower of Babel. Additionally, data providers cannot be accessed in a uniform manner, either. As described in section 2.2.2, data providers offer various web-protocol based interfaces including REST and SOAP. Naturally, the parameters used for querying the data providers also vary. It would be very difficult for the TELAR client to cope with this tremendous diversity. Thus, the architecture of the TELAR mashup platform involves the data provider wrappers as an abstraction layer above the data providers. The wrappers provide the TELAR client a consistent interface to access the POI data. As the wrappers are a number of independent scripts that reside on the mashup site, it is easy to add wrappers for new data providers any time. All that is needed is to implement the wrapper and copy it to the mashup site. In order to use the new wrapper, its URL (see below) needs to be added to the mashup-config.xml file. The TELAR client does not need to be modified. An easy way to implement the data provider wrappers would have been the remote procedure call mechanism included in the Google Web Toolkit. However, this requires a Java Servlet container on the server side, which was not easily available during this thesis. Moreover, using this RPC mechanism would have resulted in an interface which could have been used only by the TELAR client. Thus, a REST-based interface was chosen that is tailored to the needs of the TELAR client. The only action offered by the interface is to return a number of POIs, including title, description, location, URL and an icon for display. Parameters are the bounding box of the area for which POI data is queried, and optionally the zoom level of the map. The bounding box is encoded using the WGS-84 coordinates for the North East corner (neLat, neLng) and the South West corner (swLat, swLng). The zoom level may be used in order to achieve an appropriate level of detail restricting the POI data to a reasonable amount. The parameters are passed to the data provider wrappers via an HTTP GET request using an URL like the following: http://www.mashupsite.com/wrapper123?neLat=65.028&neLng=25.574&swLat=64.998&swLng=25. 447&zoom=13As there is a separate wrapper for each data provider, there is also a separate URL from each data provider. The data format in which the POI data is returned is discussed in section 5.3. The data provider wrappers all perform the following steps:1. Read the HTTP parameters sent by the TELAR client (i. e., bounding box and optionally zoom level).2. Construct a request to the data provider. In the case of a REST-based data provider this means constructing a suitable URL.3. Send a request to the data provider.50 5.3. DATA FORMAT4. Convert the retrieved data to the data format understood by the TELAR client.5. Return the converted POI data to the TELAR client.Steps two through four are dependent on the API of the particular data provider which is abstracted by the wrapper. Steps two and three deal with the protocol through which the API of the data provider is accessed. Step four is the most important one and in most cases requires a manually programmed loop iterating over all POIs returned by the data provider. For those data providers which return data serialized as XML, XSLT could also be used to convert between the data formats. In this case, an individual XSL stylesheet needs to be written for each data provider. The data provider wrappers can be implemented in any server-sided scripting language. As individual wrappers are completely independent of each other, they can be even implemented in different programming languages. For the implementation of the TELAR mashup platform, PHP was chosen for the data provider wrappers, as a server supporting PHP was readily available. Moreover, the XSL extension for PHP 5 provides an easy way to use XSLT to convert between the data formats of the data providers and the data format of the TELAR client. Not all data providers support geographically restricted queries, i. e., queries using a bounding box. Instead, some return all known POIs at once. This basically occurs in two cases. First, some data providers are not intended to be used as a web service, but provide some sort of database dump for download and offline use. An example is the collection of geographically annotated Wikipedia articles, that can be downloaded as a compressed SQL dump of about 10 MB. Secondly, some data providers only own a rather small amount of data. For example, the 340 WLAN access points of panOULU1, the public wireless network in Oulu, Finland, are only available as a single XML file. If a data provider does not support geographically restricted queries, the corresponding wrapper can either implement the selection by itself or always return all POIs. While it is clear that for big data sets the former approach should be used, the latter approach was implemented for a data provider wrapper returning the panOULU access points. As it makes no sense to query the same set of data over and over, data providers which do not support geographically restricted queries are marked as such in the mashup configuration. The TELAR client queries those data provider wrappers only once at startup keeping the result as long as the mashup page is open.5.3 Data formatAs described above, the data provider wrappers convert a variety of data formats returned by data providers into a single uniform data format understood by the TELAR client. This section specifies the logical data model for returning a number of POIs to the TELAR client and discusses serialisation formats for this data model.5.3.1 Logical data modelThe logical data model for returning a number of POIs from the data provider wrappers to the TELAR client is shown as a schematical UML class diagram in figure 5.3. The data model contains all information needed by the TELAR client in order to display the POIs on a map in the way specified in section 5.1. A data provider wrapper returns a collection of POIs to the TELAR client. The collection itself carries a name for display in the data provider management dialogs of the TELAR client. A link URL is provided that can be used to point to the original data provider from which the data was obtained by the wrapper. The POI collection naturally contains a number of POIs, that might be empty in some case as well, indicating that no POIs were found. A POI carries a name, which is used, for instance, for display inside the info window popping up when the user clicks on the POI. In addition, the content of that info window is contained in a POI as an HTML string. Moreover, each POI carries a link URL, that can point to more information about itself. In order to place a POI on the map, the TELAR client naturally must know the position of the POI, that is expressed in WGS-84 coordinates. A POI can be marked on the map with the default icon from Google Maps, but it is also possible to define custom icons. As the number of custom icons is expected to be significantly lower than the number of POIs in a POI collection, the icon definitions are modelled as separate entities and referenced from the POIs using the name of the icon definition similar to a foreign key in a relational database. The icon definitions follow the way the the Google Maps API defines icons. In Google Maps, icons consist of an image (i. e., a string containing the URL of the image) defining the actual icon and, optionally, second image that defines the shadow for the icon. The sizes of both images must be specified. Optionally, the icon anchor can specify which pixel (x and y coordinate) of the icon image should be placed over the position of the POI on the map. Similarly, the window anchor may define where the info window should be rooted when the user clicks on the POI.1http://www.panoulu.net (accessed July 23, 2007)51CHAPTER 5. A SYSTEM FOR LOCATION-BASED MASHUPS fiiiID t conenon iS t namerng:� i iS t magerng:� i idhi tt magen w: lliOCI t� oecon0* i hih i t tP mageeg n:.. il iS ttt� erng: i hdS t� rng sao w: idfiii t i likS conenons t� rng n:� hdidhi tt� saon ww:� hdhih i t t i t saoeg n w: enres�� i h iP t conancor on:� idh iP t0* noancor on ww:�..OIP il iS ttt erng:� i likS t rng n:� iS ttt conenrng:� ii iGS8W4P t t poson on:� � i iS t connamerng: �Figure 5.3: The logical data model for the TELAR mashup platform5.3.2 KML It would be straight-forward to define a serialization format for the logical data model specified above, for instance in some XML language. However, if the data provider wrappers would return the POI data in a standardized or at least widespread language, the wrappers could be re-used by other applications outside the TELAR mashup platform increasing the overall value of the TELAR mashup platform significantly. One such language is KML (Keyhole Markup Language) [Goo07], an XML-based language for describing the display of geospatial data. KML was introduced as the data format of Google Earth and was adopted by many other applications. KML is relatively powerful and supports a variety of features, such as simple three-dimensional modelling of buildings, that are not nearly required for representing the small data model of the TELAR mashup platform. Listing 5.1 shows a KML file expressing an example POI collection containing one POI, the wikipedia article about the ice hall in Oulu, Finland. KML uses containers such as folders and documents to structure a collection of objects. In the example a <Document> element is used to represent the actual POI collection. The title of the POI collection is stored in the <description> element of the document. A custom icon for the POI is defined using a <Style> element. The image of the icon definition is given in an <Icon> element and the icon anchor is carried out as a <hotSpot> element. The POI is represented as a <Placemark> element, its title, content and position are represented using <name>, <description> and <Point> elements, respectively. The description of a KML Placemark may contain HTML code, if angle brackets, apostrophes, and other special characters are escaped or the whole description is put into a CDATA element. The example uses the latter approach. The defined custom icon is linked to the POI using a <styleUrl> element. If the POI collection had more than one POI, each POI would be represented in its own <Placemark> element inside the document. As can be seen, the data model of the TELAR mashup platform can be matched very closely. The only small problems are that the POI collection and the POI cannot provide their links and the icon has no possibility to have a shadow. However, the link of the POI collection is not essential anyway and the POI can include a hyperlink in its description, as shown in the example.5.3.3 GeoRSS GeoRSS (geographically encoded objects for RSS feeds) [RSL+06] is another widespread format for describing geographically annotated objects. GeoRSS is a proposal for geo-enabling, or geo-tagging, RSS and Atom feeds with location information. GeoRSS proposes a standardized way to encode location to satisfy the requirements of most web content to describe its location. In contrast to the very powerful KML, GeoRSS puts a lot of emphasis on simplicity and intentionally does little more than augmenting RSS items with WGS-84 coordinates. GeoRSS is designed for use with Atom 1.0, RSS 2.0 and RSS 1.0, although it can be used in non-RSS XML encodings as well. At the time of writing, there are two GeoRSS serialization formats: GeoRSS GML and GeoRSS Simple. GeoRSS GML is based on GML [CDL+04], and supports a greater range of features, such as coordinate reference systems other than WGS-84. GeoRSS Simple has greater brevity, but is not as extensible. Originating from blog entries with location information GeoRSS has been adopted by numerous websites and APIs.52 5.3. DATA FORMAT<?xml version="1.0" encoding="UTF-8"?> <kml xmlns="http://earth.google.com/kml/2.1"> <Document id="http://en.wikipedia.org"> <description>Wikipedia Articles</description><Style id="wikipedia"> <IconStyle> <Icon> <href>http://www.example.com/icon.png</href> </Icon> <hotSpot x="9" y="8" xunits="pixels" yunits="pixels"/> </IconStyle> </Style><Placemark id="http://en.wikipedia.org/wiki/Oulun_Energia_Areena"> <name>Oulun Energia Areena</name> <description> <![CDATA[ Oulun Energia Areena is an arena in the Raksila district of Oulu, in Finland. It is primarily used for ice hockey, and is the home arena of <a href="http://en.wikipedia.org/wiki/K%C3%A4rp%C3%A4t">Kärpät</a>. It opened in 1975 and holds 6,612 people. <a href="http://en.wikipedia.org/wiki/Oulun_Energia_Areena">Link</a> ]]> </description> <styleUrl>#wikipedia</styleUrl> <Point> <coordinates>25.489,65.0093</coordinates> </Point> </Placemark> </Document> </kml> Listing 5.1: A KML file displaying a POI collection of one wikipedia articleListing 5.2 shows an Atom 1.0 file augmented with GeoRSS GML, that expresses the same POI collection which was serialized as KML in listing 5.1. Basically, the POI collection is represented as a normal Atom feed, with a title, link, update timestamp, author, id and a number of entries. Every POI is mapped to an Atom entry, which itself has a title, link, id, timestamp, and content. The content can be, among others, HTML code, in which case the type attribute of the <content> element must have the value "html".The Atom specification [NS05] allows arbitrary XML elements at virtually any place inside an Atom feed, as long as these elements are defined in a different namespace from the one used by Atom. This is where GeoRSS comes in. Every <entry> element simply gets an additional child element describing the location of the entry. The <where> element is defined in the namespace of GeoRSS and contains, in the case of GeoRSS GML, a GML geometry. For a POI the geometry is a point, but other geometries, such as linestrings and polygons, are supported as well.GeoRSS only adds the location information to objects. Unlike KML, GeoRSS does not define the style in which the objects are displayed, e. g., on a map. However, in the same way GeoRSS adds new XML elements to an Atom feed, the style of the objects, i. e., custom icon definitions, can be defined by introducing new XML elements in a different namespace. This is exactly what is done in listing 5.2. A custom icon is defined using an <icon-def> element in the Atom feed and the definition is referenced using an <icon-ref> element inside the Atom entry representing the POI.An Atom feed augmented with GeoRSS and a proprietary extension for icon definitions can match the data model of the TELAR mashup platform very well. The Atom specification mandates a few unnecessary elements, such as the author or the update timestamp, but these can be ignored by the TELAR client. Through the proprietary format for the icon definitions, the desired data model can, naturally, be matched exactly. It unfortunate that this is not standardized, however, as this kind of extension is compatible with the Atom specification, Atom and GeoRSS processors will simply ignore it.53 CHAPTER 5. A SYSTEM FOR LOCATION-BASED MASHUPS<?xml version="1.0" encoding="UTF-8"?> <feed xmlns="http://www.w3.org/2005/Atom" xmlns:georss="http://www.georss.org/georss" xmlns:gml="http://www.opengis.net/gml" xmlns:telar="http://www.nokia.com/telar/marker"> <title>Wikipedia Articles</title> <link rel="self" href="http://www.example.com/wikipedia-wrapper.php"/> <link href="http://www.dataprovider.com/api"/> <updated>2007-05-09T18:00:00Z</updated> <author> <name>Andreas Brodt</name> <email>%61%6E%64%72%65%61%73%2E%62%72%6F%64%74%40%6E%6F%6B%69%61%2E%63%6F%6D</email> </author> <id>http://en.wikipedia.org</id><telar:icon-def name="wikipedia"> <telar:image width="18" height="17">http://www.example.com/icon.png</telar:image> <telar:shadow width="18" height="17">http://www.example.com/shadow.png</telar:shadow> <telar:icon-anchor x="9" y="8"/> <telar:info-window-anchor x="18" y="0"/> </telar:icon-def><entry> <title>Oulun Energia Areena</title> <link href="http://en.wikipedia.org/wiki/Oulun_Energia_Areena"/> <id>http://en.wikipedia.org/wiki/Oulun_Energia_Areena</id> <updated>2007-05-09T18:00:00Z</updated> <content type="html"> Oulun Energia Areena is an arena in the Raksila district of Oulu, in Finland. It is primarily used for ice hockey, and is the home arena of <a href="http://en.wikipedia.org/wiki/K%C3%A4rp%C3%A4t">Kärpät</a>. It opened in 1975 and holds 6,612 people. </content> <georss:where> <gml:Point> <gml:pos>65.0093 25.489</gml:pos> </gml:Point> </georss:where> <telar:icon-ref>wikipedia</telar:icon-ref> </entry> </feed> Listing 5.2: A GeoRSS GML file displaying a POI collection of one wikipedia article5.3.4 JSONJSON (JavaScript Object Notation) [Cro06] is a lightweight, text-based, and human-readable data format for representing objects and other data structures. JSON finds its main application in AJAX development, as a simple alternative to XML-based data formats. JSON is a subset of the JavaScript language and, as such, can be parsed by a JavaScript engine. The eval() function of JavaScript, that compiles and executes a string containing JavaScript code, returns, when given a string of JSON-encoded data, the corresponding JavaScript objects (for security purposes it can first be tested with a regular expression whether the string really only contains the subset of JavaScript defined by JSON). Thus, as opposed to XML-based data formats, no code needs to be written to deserialize the objects. Although JSON is not built into other programming languages in the same way, libraries for processing the JSON format exist for most major programming languages, including PHP, the language that is used by the data provider wrappers. In JSON an object is represented as an unordered collection of zero or more name : value pairs, where a name is a string and a value is a string, number, boolean, null, object, or array. Like in JavaScript, objects are denoted in curly braces and arrays in square brackets. This makes JSON quite a bit shorter compared to XML, as structures are closed by a single “}” or “]” character, rather than repeating the element name in the closing tag. Listing 5.3 shows the example POI collection from listings 5.1 and 5.2 serialized as a JSON file. At the time of writing there is no standardized way of representing geospatial data in JSON. Thus, a proprietary object structure must be used, which restricts interoperability but on the other hand allows mapping the data format of the TELAR mashup platform to JSON objects exactly. In listing 5.3 one JSON object is defined to represent the POI collection. Besides the string properties for title and link, the object has two array properties; one containing all icon definitions54 5.3. DATA FORMAT{ "title":"Wikipedia Articles", "link":"http://www.dataprovider.com/api", "iconDefs": [ { "name":"wikipedia", "image":"http://www.example.com/icon.png", "imageWidth":18, "imageHeight":17, "shadow":"http://www.example.com/shadow.png", "shadowWidth":18, "shadowHeight":17, "iconAnchorX":9, "iconAnchorY":8, "windowAnchorX":18, "windowAnchorY":0 }, ], "entries": [ { "title":"Oulun Energia Areena", "link":"http://en.wikipedia.org/wiki/Oulun_Energia_Areena", "content":"Oulun Energia Areena is an arena in the Raksila district of Oulu, in Fin¶ land. It is primarily used for ice hockey, and is the home arena of <a href=\"http://en.wik¶ ipedia.org/wiki/K%C3%A4rp%C3%A4t\">Kärpät</a>. It opened in 1975 and holds 6,612 ¶ people.", "iconRef":"wikipedia", "position": { "latitude":65.0093, "longitude":25.489, } }, ], } Listing 5.3: A JSON file displaying a POI collection of one wikipedia article and one containing all POIs. The HTML content of a POI is represented as one long string property (the ¶ symbols in listing 5.3 indicate that the line is only broken for display purposes). As JSON uses quotation marks to mark the bounds of strings, all quotations marks inside the content must be escaped.5.3.5 Comparison KML, GeoRSS, and the proprietary JSON format described above are all capable of representing the data model of the TELAR mashup platform defined in section 5.3. Table 5.1 compares the data formats. In order to compare the space overhead of the data formats, the number of characters used by the upper examples of the POI collection containing one wikipedia article were counted, with all indentation stripped off. The number of characters was put into relation with the number of characters required by the raw data, i. e., without any structural information, which is in the example 476 characters. From this, the percentage of overhead imposed by the data formats was calculated, compared to the raw data. As, in practice, a POI collection is expected to contain many POIs, the space overhead required by one POI is the critical part. So in addition to the characters required by the whole POI collection, also the number of characters for expressing a single POI is given for each data format. In the example, the POI contained 341 characters of raw data. When comparing the data formats from the functional point of view, KML is the clear winner. It is a standardized and widespread format that has not only everything that is needed for the purposes of the TELAR mashup platform, but supports a variety of additional features. While this leaves plenty of room for future extensions of the TELAR mashup platform, it can as well be considered a disadvantage. Implementing full support for KML in the TELAR client would not only mean an unnecessary load of development effort, it also would bloat the JavaScript code, which can slow down the TELAR client on a device with limited computing power like the Nokia N800. On the other hand, by implementing only the required subset of KML in the TELAR client, another data format is created, that is not really standardized, either. Although this way interoperability is not completely lost, it is affected anyway.55 CHAPTER 5. A SYSTEM FOR LOCATION-BASED MASHUPSKML GeoRSS JSON purpose display geospatial data geo-tagging generic standardized yes yes (except style extension) no supports style yes no (only through extension) yes characters 921 (93 %) 1476 (210 %) 784 (65 %) characters / POI 572 (67 %) 626 (84 %) 440 (29 %)Table 5.1: Comparison of data formats for the TELAR mashup platformLacking a way to define the display style of the POIs, GeoRSS has the opposite problem as the format needs to be extended to provide the required functionality. The extended GeoRSS format shown in listing 5.2, however, is in any case a valid Atom 1.0 feed and interoperability is not compromised. As this format has hardly any unnecessary features, it can be fully supported by the TELAR client. As the JSON format shown in listing 5.3 is not anyhow standardized, the question of interoperability does not even arise. The JSON format, however, is the definite winner when it comes to performance. As it can be parsed by the JavaScript engine of the web browser, not only the parsing code is saved, the parsing is also done in native code rather than in interpreted JavaScript. In addition to that, the JSON format is much more compact than the XML-based KML and GeoRSS. As table 5.1 shows, the JSON format imposes only very low space overhead onto the raw data. Based on these considerations the TELAR client and the data provider wrappers were implemented to use GeoRSS in order to achieve at least a certain degree of interoperability with other systems and applications. This worked very well on a PC browser. However, as described in more detail in section 6.3, the performance of the TELAR client on the Nokia N800 was so bad that the implementation was changed to the JSON data format, which gave the TELAR client a considerable speedup.56 CHAPTER 6IMPLEMENTATIONThis chapter provides details about the implementation of the TELAR mashup platform that was carried out during this thesis. First, the most important software frameworks and technologies used by the implementation are addressed. Then, experiences made during the implementation are shared. The performance of the TELAR mashup platform is discussed and finally the results of the implementation are presented.6.1 Technologies6.1.1 Maemo location frameworkThe Maemo location framework comprises a number of programs and libraries included in the platform software of the Nokia N800 Internet Tablet which facilitate accessing an external Bluetooth GPS device. The Maemo location framework deals with searching for GPS devices in the Bluetooth neighbourhood, establishing and managing a serial Bluetooth connection to a GPS device, parsing the data returned by the GPS, and distributing the data to several client applications. Besides the fact that it was Nokia’s requirement to use the Maemo location framework, the framework makes GPS access for the TELAR mashup platform a lot easier. The Maemo location framework is built around gpsd, the Linux GPS daemon. gpsd is a service daemon that monitors one or more GPS devices attached to a host computer through serial or USB ports, making available the data of the GPS devices on TCP port 2947 of the host computer. As opposed to client applications accessing a connection to the GPS device directly, multiple client applications can share access to a GPS device without contention or data loss. Moreover, gpsd parses the NMEA 0183 data emitted by most GPS devices. As several incompatible variants of this data format exist, leaving the parsing up to gpsd, which specializes in this job, makes the client application more robust. A C library named libgps is provided that encapsulates all communication with gpsd and offers the GPS data as a C struct that is easy to use. The gps_open() function provided by libgps opens a socket connection to gpsd. Through the gps_query() function commands and parameters can be sent to gpsd and the gps_poll() function is a blocking call returning the position data from the GPS device. The gps_close() function disconnects the socket connection to gpsd. As gpsd expects a readily initialized serial (or USB) connection to the GPS device, another library is needed to establish a serial Bluetooth connection to a Bluetooth GPS device like the Nokia LD-3W that was used during this thesis work. The libgpsbt library, which is only available for the Maemo location framework, offers a C function named gpsbt_start() which performs the following steps in order to start up the whole Maemo location framework:1. Search for a Bluetooth GPS device in the current Bluetooth neighbourhood which has already been paired with the Internet Tablet.2. Connect to the GPS device using a serial Bluetooth connection, if no such connection is present yet.3. Start gpsd, if it is not yet running.Similarly, the gpsbt_stop() function shuts down gpsd and terminates the Bluetooth connection if no other client applications use them any more. In listing 6.1 a minimal code example in the C programming language is given in order to demonstrate how the Maemo location framework is used.57 CHAPTER 6. IMPLEMENTATION#include <gpsbt.h> /∗ libgpsbt ∗/ #include <gps.h> /∗ libgps ∗//∗ ... ∗/ gpsbt_t gpsbt; struct gps_data_t* gps_data;/∗ Establish the Bluetooth connection to the GPS device and start gpsd. ∗/ gpsbt_start(NULL, 0, 0, 0, NULL, 0, &gpsbt);/∗ Wait for the gpsd process to start . ∗/ sleep(1);/∗ Open the socket connection to gpsd. ∗/ gps_data = gps_open(NULL, NULL);/∗ Set gpsd to watcher mode, so that it reacts whenever the GPS device ships new data. ∗/ gps_query(gps_data, "w+\n");/∗ Get position data from the GPS device and print it . ∗/ gps_poll(gpsdata); if (gps_data->status != STATUS_NO_FIX && gps_data->fix.mode > MODE_NO_FIX) { printf("latitude: %f, longitude: %f\n", gps_data->fix.latitude, gps_data->fix.longitude); } else { printf("No GPS fix available.\n"); }/∗ Close the connection to gpsd. ∗/ gps_close(gps_data);/∗ Stop gpsd and terminate the Bluetooth connection . ∗/ gpsbt_stop(&gpsbt);/∗ ... ∗/ Listing 6.1: Example code using the Maemo location framework6.1.2 Mozilla extensionsThe Mozilla browser and its derivatives provide an extension framework through which new features can be added and existing features can be modified. They allow the application to be customized to fit the personal needs of each user, while keeping the basic browser application fairly minimal as well as small to download. A large number of extensions exists for all kinds of purposes including RSS readers, bookmark organizers, toolbars, mouse gestures, or web development tools. As described in section 5.2, the TELAR mashup platform extends the web browser in order the integrate the user’s position into a mashup. Mozilla extensions are usually shipped as XPI (cross-platform installer) packages, for which Mozilla provides an installation and update mechanism. JavaScript is used as the primary programming language. In case the extension needs a user interface, it is typically defined using XUL (XML user interface language), a technology used throughout the Mozilla platform to provide a simple and portable definition of common user interface widgets. In order to access functionality provided by the browser, XPCOM (cross-platform component object model, see below) can be used. Moreover, an extension may encapsulate functionality in its own XPCOM components. A Mozilla-based browser for the Nokia N800 was used in the thesis, which was still under development. When the Mozilla extensions of the TELAR mashup platform were implemented, this browser did not include complete support for Mozilla extensions as described above. It was however possible to extend the browser using one or more bare XPCOM components. The components were loaded by the browser at startup when put into the /home/user/.mozilla/components directory on the Internet Tablet.XPCOMXPCOM (cross-platform component object model) is the component framework on top of which all Mozilla-based applications are built. It is intended for writing cross-platform, modular software and is available for a multiplicity of operating systems. XPCOM has many similarities to frameworks like CORBA or Microsoft COM, it is, however,58 6.1. TECHNOLOGIES designed to be used principally at the application level and does not directly support components being distributed on multiple machines or even across processes. In order to allow interoperability between components within an application, XPCOM separates the implementation of a component from the interface. Interfaces in XPCOM are defined in a dialect of OMG IDL [Obj02] called XPIDL. The main implementation language for XPCOM is C++, but multiple language bindings exist allowing the XPCOM components to be used and implemented in JavaScript, Java, Python, and other languages. A set of core components and classes is included in XPCOM providing functionality such as file and memory management, threads, and basic data structures (strings, arrays, etc.). This makes XPCOM applications truly platform independent, as an XPCOM application only uses, i. e., an nsIThread component object in order to create a thread, thus leaving the mapping to the thread API of the particular operating system up to XPCOM. The XPCOM framework provides two ways of obtaining an instance of a particular component. First, a new component instance can be obtained from the central XPCOM component manager. Given the contract ID of the component, a human readable string identifying the component, the component manager creates a new instance. Secondly, a component like nsDCIComponent contained in the DCI module of the TELAR mashup platform, that is meant to be used as a service of which only one central instance is needed, can be obtained through the XPCOM service manager. The service manager ensures that at most one instance of the component is created. For example the GPS access module obtains a handle to the DCI module like this: nsresult retval; nsCOMPtr<nsIDCIComponent> dci(do_GetService("@research.nokia.com/DCI/DCIComponent;2", &retval)); XPCOM components implemented in the C++ programming language are compiled into a dynamic library, which is what the XPCOM component manager calls a module. In order to create an XPCOM module containing one or more XPCOM components in C++, typically the following sequence of steps is performed:1. Define one or more interfaces in the XPIDL format. 2. Compile the XPIDL files to a binary typelib file (XPT file) using the xpidl compiler. 3. Generate a C++ header file containing an abstract C++ class from each XPIDL file using the xpidl compiler. 4. Write one or more C++ classes which inherit and implement the abstract classes generated in the previous step. 5. Implement the component registration code comprising the symbol exported by the dynamic library, which tells XPCOM which components the module contains and that provides constructor functions to instantiate the components. 6. Compile the C++ code into a dynamic library, usually using the make-based Mozilla build system.The first three steps are only required if the components need to offer functionality through a new interface rather than implementing existing interfaces. In the case of a component implemented in JavaScript, steps three to six are replaced by the creation of a JavaScript file containing both the module code and an object which implements a number of interfaces. In order to write XPCOM components in C++, a number of XPCOM-specific peculiarities must be understood, as they have a big impact on code. The most obvious influence on XPCOM code is the fact that XPCOM uses reference counting as its memory management strategy. Consequently, every XPCOM object must keep a reference counter and implement the methods AddRef() and Release(), which increment or decrement the reference counter, respectively. By convention, every getter method returning an XPCOM object has already “addrefed” the object. As reference counting generally cannot cope with cyclic structures, it is, by convention, forbidden to create a cycle of owning references. In order to prevent the likely bugs when dealing with raw C++ pointers to XPCOM objects, a “smart-pointer” class named nsCOMPtr is provided. nsCOMPtr is a template class that acts, syntactically, just like an ordinary pointer in C++, but has overloaded operators, such as the assignment operator, and a constructor and destructor that transparently manage the reference counter. If an nsCOMPtr object goes out of scope, its destructor is called, which decreases the reference counter of the referenced XPCOM object. When the reference counter of an XPCOM object reaches zero, it is deallocated. In addition to that, XPCOM strictly forbids the use of exceptions in C++ code. As exceptions have not always been portable, XPCOM uses return values to report about the success of a method call. This means that the return value of the method should be checked whenever an interface method is called. Moreover, as a method must return the status code used for error reporting, it cannot return any “real” return value any more, so that all data must be returned via output parameters. The logical return value, as defined in an XPIDL file, is mapped to an additional method parameter in the C++ code, which can be confusing if the programmer is not used to this practice.59 CHAPTER 6. IMPLEMENTATIONAnother peculiarity of XPCOM C++ is the frequent use of preprocessor macros. XPCOM is designed for utter portability and in many cases platform-specific behaviour is abstracted through macros. Moreover, as XPCOM is not integrated into a programming language but built on top of C++, component management code and application code is constantly mixed. Using macros it is attempted to encapsulate the component management code to a certain degree, which in practice creates a new programming language that is not immediately understood by programmers knowing standard C++. Also, it is important to understand that only the methods of the particular interface are available via an interface pointer to an XPCOM component. If a component implements more than one interface and a second interface of the component needs to be used, a second interface pointer must be retrieved that points to the same component, but offers the second interface. The nsCOMPtr class assists with this task. Similarly, it is not possible to obtain a pointer to a raw C++ object from an interface pointer, as the component pointed to could be as well implemented in, e. g., JavaScript. However, this can make the component implementation complicated when interface methods are used internally as well. Listing 6.2 shows the C++ implementation of an XPCOM interface method. In the implementation of the DCI component explained in section 5.2.3, the CreateEvent factory method is used to create DOM event objects (implementing the nsIDOMEvent interface) of a specific type that is specified as a string.// NS_IMETHODIMP is a preprocessor macro defining the return code of an interface method used for error handling . // The aEvent parameter is the logical return value of this method. NS_IMETHODIMP nsDCIProperty::CreateEvent(const nsAString& aEventType, nsIDOMEvent** aEvent) { nsresult retval; nsDCIEvent* rawEvent = new nsDCIEvent(); if (!rawEvent) { return NS_ERROR_OUT_OF_MEMORY; }// Create an interface pointer to the nsIDOMEvent interface from the raw C++ object. // The C++ cast is needed as the nsDCIEvent class implements several XPCOM interfaces. nsCOMPtr<nsIDOMEvent> domEvent(do_QueryInterface((nsIDCIEvent*) rawEvent, &retval)); if (NS_FAILED(retval)) { delete rawEvent; return retval; }// Initialize the event . This is an interface method call that could fail . retval = domEvent->InitEvent(aEventType, true, true); if (NS_FAILED(retval)) { // No need to delete rawEvent, as domEvent will go out of scope and free the raw object . return retval; }// Set the logical return value . By convention, getters must increment the reference counter . NS_ADDREF(*aEvent = domEvent); return NS_OK; } Listing 6.2: An example of an XPCOM method implementation in C++In contrast, implementing an XPCOM component in JavaScript is much easier. As the JavaScript programming language is interpreted, all platform-specific behaviour can be abstracted by the JavaScript interpreter making the application code much more enjoyable. In JavaScript, memory is managed using garbage collection. As exceptions are managed by the interpreter as well, they can be freely used in component code, which also allows methods return “real” return values. Listing 6.3 illustrates how the CreateEvent method shown in C++ in listing 6.2 could be implemented in JavaScript.6.1.3 Google Web Toolkit The Google Web Toolkit is a development framework for AJAX applications that abstracts browser-specific behaviour, and allows the use of the Java programming language for development, compiling the Java code to a JavaScript application for deployment. As stated in section 5.2.5, the TELAR client is put into practice using the Google Web Toolkit.60 6.1. TECHNOLOGIES// ...CreateEvent: function (aEventType) { var event = new DCIEvent(); // May throw an exception. var domEvent = event.QueryInterface(Components.interfaces.nsIDOMEvent); // May throw an exception. domEvent.InitEvent(aEventType, true, true); // May throw an exception. return domEvent; },// ... Listing 6.3: An example of an XPCOM method implementation in JavaScriptBeing the only web scripting language widely supported by web browsers, JavaScript is an integral part of AJAX. JavaScript was originally intended as a simple way to add small scripts to web pages for tasks such as opening popup windows or evaluating form data. However, there are several drawbacks of JavaScript as a language for big applications. First, the DOM API, which is used by AJAX applications to generate the HTML-based user interface, is not part of the language standard. Actually, it is standardized by the World WideWeb Consortium (W3C); in practice the DOM interfaces are implemented by different web browsers in ways that differ among both browsers and the standards. Secondly, the JavaScript programming language lacks some important concepts that would make the development of bigger applications significantly easier, such as strong typing and modularity. Strong typing allows for powerful development tools supporting features like automatic code completion, static program analysis and code refactoring. These can provide considerable speedup to application development. Modularity is the base for software re-use and extensibility, which might not be that important for small scripts but are essential when developing big applications. The Google Web Toolkit addresses the weaknesses of JavaScript by allowing AJAX applications to be implemented in the much more powerful Java programming language, compiling the Java code to a number of JavaScript files. Thus, existing high quality Java development tools like Eclipse JDT and JUnit can be used. A runtime environment is provided, with which an AJAX application can be run in the Java Virtual Machine at development time. This enables the use of Java runtime tools including debuggers, test frameworks and test case coverage analyzers as well. In order to cope with browser incompatibilities, the Google Web Toolkit generates a separate JavaScript file for Mozilla, Microsoft Internet Explorer, Safari, and Opera. An additional startup script detects, which browser is being used and loads the appropriate variant of the AJAX application. In order to provide interoperability with JavaScript APIs or existing JavaScript code, the Google Web Toolkit allows to include hand-written JavaScript code through its JavaScript Native Interface. The syntax of the Java Native Interface is used in order to keep the code valid Java, the JavaScript code is added in specially marked comment. In addition to that, it is possible to call Java methods from JavaScript code as well. Listing 6.4 illustrates how the JavaScript Native Interface is used. The defineDciListenerCallback() Java method is declared “native” and contains JavaScript code defining a callback function that can be used for listening to DCI events. When the callback function is invoked, it extracts the location data from the DCI tree and calls a static Java method with the location data. Applications built with the Google Web Toolkit consist of one or more modules. A module is defined in an XML file and can import (“inherit”) other Google Web Toolkit modules. The XML file defines the entry point of the module, a Java class implementing the EntryPoint interface. The onModuleLoad() method defined by the EntryPoint interface can be considered the “main” method of a Google Web Toolkit module. Following the paradigm of event-based programming used by JavaScript, the onModuleLoad() method is called once by the startup script and may perform initialization tasks, such as creating the user interface, sending asynchronous HTTP requests, and registering event listeners. At a later point, an application only responds to events. The Google Web Toolkit includes modules providing various functionality. Most notably, a class hierarchy for creating user interfaces is provided. The com.google.gwt.user.User module can be used similarly to other GUI toolkits like Swing or AWT and abstracts all interaction with the DOM API. So-called panels, areas of space corresponding to a <div> element in HTML, are filled with widgets like menus, buttons, text blocks, input fields, dialogs, etc. Composite widgets provide panels for child widgets, creating hierarchical structures. The topmost panel of such a hierarchy, the so-called root panel, corresponds to a <div> element in the HTML page into which the user interface of an AJAX application is integrated. The design of widgets can be modified to a large degree using cascading stylesheets (CSS). Listing A.3 in the appendix shows how a Google Web Toolkit application is included into an HTML page.61 CHAPTER 6. IMPLEMENTATION private native void defineDciListenerCallback()/*-{ // Listener function for changes of the /Location/GPS/Status DCI property. // It’s easier to make this a property of the HTML document ($doc in Google Web Toolkit). $doc.telar_onGpsStatusChangeCallback = function(event) { var statusProp = event.target;// Set lat and lng if there is a GPS fix. if (statusVal == "FIX 2D" || statusVal == "FIX 3D") { var latProp = statusProp.nextSibling; var statusVal = statusProp.value; var latVal = latProp.value; var lngVal = latProp.nextSibling.value;// Call a static Java method. "Ljava/lang/String;" means one String parameter. @com.nokia.telar.client.dci.DciWrapper::dciListenerCallback (Ljava/lang/String;Ljava/lang/String;Ljava/lang/String;) (statusVal, latVal, lngVal); } }; }-*/; Listing 6.4: An example of the JavaScript Native Interface of the Google Web ToolkitIn addition to the user interface module, the Google Web Toolkit provides, among others, modules for asynchronous HTTP requests, XML and JSON handling, and a special RPC mechanism. An abstraction layer on the XMLHttpRequest JavaScript object is generally required for every AJAX application (also those implemented directly in JavaScript), as the implementations of this object among different browsers are incompatible. As most AJAX applications either use XML or JSON for data exchange, an access framework for those data formats is essential. It should be noted that the JSON framework of the Google Web Toolkit does not make use of the eval() JavaScript function but provides a parser implemented in Java/JavaScript. In addition to that, the JSON data format is meta-modelled by classes like JSONObject, JSONArray, or JSONValue, in a similar way the DOM API meta-models XML. Thus, the JSON framework of the Google Web Toolkit is not only slow but also requires a lot of memory. The RPC mechanism of the Google Web Toolkit is an easy way to transfer entire object hierarchies between an AJAX application and the server, as the objects are automatically marshalled and unmarshalled. The RPC mechanism, however, uses a proprietary serialization format and requires a Java Servlet container on the server side. The fact that the Google Web Toolkit is entirely published as open source has not only attracted a user community but also developers contributing to the framework and providing additional modules. The TELAR mashup platform uses two such third-party modules for using Google Maps and for direct unmarshalling of JSON data to Google Web Toolkit Java objects. The GoogleMaps GWT module1 makes the Google Maps API accessible as a number of Java classes and provides a Google Maps widget for the user interface framework of the Google Web Toolkit. This saves the cumbersome work of replicating the large API of Google Maps using the JavaScript Native Interface. Jsonizer2 is a framework turning JSON data into Java objects of the Google Web Toolkit and vice versa. It uses a mechanism similar to Java reflection to create objects from JSON data without any meta-modelling and is thus significantly more efficient than the JSON framework included in the Google Web Toolkit.6.2 Implementing the TELAR mashup platform 6.2.1 Browser extensions For implementing the DCI module introduced in section 5.2.3, an early demonstration implementation of a DCI XPCOM module from Nokia Research Center was used, which Sailesh Sathish generously provided for this thesis work. This demo implementation was of great value, as it provided many insights into DCI and XPCOM programming. It was, however, far from being a complete implementation of the DCI specification. Consequently, the DCI module for the TELAR mashup platform was written from scratch re-using very little of the demonstration code, but applying a design that is very similar to the one of Nokia Research Center. The same course of action as described in [Sat07] was used to implement the DCI module. First, the IDL interfaces defined by the DCI specification were transformed to XPIDL interface definitions. For this step also the referenced DOM interfaces like Node, from which the DCIProperty interface inherits, had to be replaced by the1http://sourceforge.net/projects/gwt/ (accessed July 23, 2007) 2http://code.google.com/p/gwt-jsonizer/ (accessed July 23, 2007)62 6.2. IMPLEMENTING THE TELAR MASHUP PLATFORMXPIDL interfaces used by the DOM implementation of Mozilla, e. g., nsIDOMNode. Secondly, the resulting XPIDL files were compiled to C++ header files using the xpidl compiler. Finally, a number of concrete C++ classes were implemented, which inherit the abstract C++ classes generated from the XIPDL files. The implementation of those C++ classes uses the methods defined in the interfaces for internal purposes as well, which result in interface pointers to DCI property objects. The interface pointers, however, only grant access to those methods of the property object which are specified in the interface. As in some cases the implementation needs, e. g. write access where the interface is defined read only, an additional interface named nsIDCIPropertyInternal had to be added for internal use only. This interface contains the operations required by the DCI implementation and by casting the interface pointers to this interface, the problem could be solved. For implementing the DCI module, a debug build of Mozilla Seamonkey was used. Thus, the DCI module was first implemented like an extension for a Mozilla-based PC browser. This made compiling the component much easier, saved the work of installing the DCI module on the Internet Tablet for every test run, and simplified debugging a lot, as programming errors often generated a log message instead of, e. g., just crashing the browser with a segmentation fault. Only when the DCI module had been tested on the PC it was ported to the Nokia N800. Porting and cross-compiling the DCI module to the Nokia N800 required a certain amount of extra effort later, as a slightly different version of Mozilla was used on the device, which resulted in numerous linking errors. However, this way of development saved a lot of time anyway. The DCI module was first tested with a hard-coded mock ontology of DCI properties. Using a timer, an integer property was incremented every three seconds. A web page was written that registered a listener to this property and displayed the value as it changed continuously. After this web page displayed the ascending counter on the Nokia N800 as well, the implementation of the GPS module was started. As the GPS access module depends on the Maemo location framework, which is not available on the PC, the GPS access module was developed in the cross-compilation framework for the Nokia N800 from the start. In order to keep debugging simple, a strategy of small steps and continuous integration and testing was pursued. Thus, for the first version of the GPS access module, only the hard-coded mock ontology with the integer property was moved into a separate XPCOM module. In a second step, the mock-ontology was replaced by the ontology of the TELAR mashup platform (see section 5.2.2), but the values for the Status, Latitude, Longitude and Altitude DCI properties were still integer values, which were incremented by a timer. Another web page using the DCI API for displaying the properties was written in order to test this development step. Subsequently, the timer was replaced with a background thread incrementing the integer values. Only when the test page verified the success of this step, the Maemo framework was finally integrated with the GPS access component replacing the integer properties with real values retrieved from the GPS device. When the background thread was introduced in the GPS access module, it became obvious that the DCI module does not support multiple threads. This is because the DCI methods which create DOM events, such as the SetValue() method defined in the DCIProperty interface, directly call the HandleEvent() method defined in the EventListener DOM interface in order to notify the registered event listeners of a DCI property. However, the DOM API of the web browser is single-threaded, i. e., all JavaScript code embedded in web pages must run in the main thread of the browser, which naturally also holds for event listeners. On the other hand, the background thread of the GPS access module is absolutely necessary. The GPS position is retrieved from the Maemo location framework using gps_poll(), which is a blocking call. The whole browser would not react any more if this was done in the main thread. It would have been possible to make the DCI module thread-safe by dispatching the calls to the HandleEvent() method to the main thread. XPCOM threads are equal to event queues, to which nsIRunnable objects can be dispatched, thus the main thread would have called the event listeners sometime later when idle. However, it was considered less work and a smaller risk to define the DCI module as single-threaded and deal with the problem inside the GPS access module. For this, the GPS access module was divided into two XPCOM components. The nsTelarGps component starts up the background thread and accesses the Maemo location framework. The nsGpsDataHandler component implements the nsIRunnable interface and takes over the job of updating the DCI tree with the data received from the Maemo location framework. The UML sequence diagram in figure 6.1 illustrates how the two components of the GPS access module interact. Every time the nsTelarGps component retrieves new data from the GPS device, which happens in the background thread, the data is copied into the nsGpsDataHandler component object. Then the nsGpsDataHandler component is dispatched to the main thread, so that the Run() method of the nsGpsDataHandler accesses the DCI tree in the main thread. In order to avoid race conditions, it must not be forgotten to synchronize all access to the GPS data inside the nsGpsDataHandler component using a mutex. When implementing the GPS access module, the lacking XUL support of the Mozilla-based broswer for the Nokia N800 became an unpleasant restriction. Not only for development but also for practical use it would have been very handy to have a user interface for the GPS access module. Most users would probably appreciate the63CHAPTER 6. IMPLEMENTATION il l dl dl lif kkkihdhdS GG GT H H LPRL TIT t t t t sneonnsearpsmpsaaanernspsaaanermaemooaonrameormoomanreansrea w: : : : : g D D c cc ll(d) t pspopsaa:1gg__(d)S G t t t e psaapsaa: k()PRL2 Dg o:_3c_ op y c d lk()PRU t psaa no: g4c_ _ i h( dl)GH t t spa mpsaaaner:5D cD()R n u:6 k()PRL o:7c_ dif mo yCI t ree lk()PRUD no:8c _Figure 6.1: UML sequence diagram illustrating the threads in the GPS access module possibility to turn off the GPS access module once in a while. As this is not possible, the GPS access module was implemented so, that it is always on, from browser startup to browser shutdown. As the user cannot even engage when the Maemo location framework creates an error, e. g., because the Bluetooth GPS device was switched off or gpsd died, the GPS access module must be very robust. Consequently, a watchdog timer was introduced. Every 30 seconds the watchdog timer checks whether the background thread is still running or whether it terminated due to an error. If the background thread is not running any more, the watchdog timer restarts it. It is thus possible to execute a command like killall -9 gpsd on the console of the Nokia N800 and at most 30 seconds later gpsd will be running again. While this increases the robustness of the GPS access module a lot, it can be annoying, if, for some reason, the user does not want the Maemo location framework to run, but does not want to close the browser, either. Moreover, the GPS access module searches for Bluetooth devices very frequently. If there is no Bluetooth device at all, a lot of battery power is wasted, because the user cannot switch off the GPS access module. Thus, it might be a future improvement to create an external program for controlling the GPS access module. For instance, a section in the control center application of the Nokia N800 could be included to edit the settings of the GPS access module. Such an external program could communicate with the GPS access module via dbus, the communication platform used by the Nokia N800.6.2.2 TELAR clientDuring implementation of the TELAR client it became more and more obvious that it had been the right decision to implement the TELAR client with the Google Web Toolkit. Using the powerful eclipse Java development tools the implementation progressed very quickly and without big problems. The TELAR client was divided into five Java packages, as shown in figure 6.2. The main package is named com.nokia.telar.client. It has four subpackages named data, dataProvider, dci, and ui, which contain classes for POI collections and their unmarshalling, classes for interaction with the data provider wrappers, the JavaScript code for interaction with the DCI API, and the user interface, respectively. The central class, which also constitutes the entry point of the TELAR client, is named TelarModule and resides in the main package. There is some little coupling between the data and the dataProvider packages, but besides that, the packages do not know of each other and all communication is done via the TelarModule class. For this, every subpackage defines an interface which contains exactly those methods of the TelarModule class which the package needs to64 6.2. IMPLEMENTING THE TELAR MASHUP PLATFORM access. This leads to a relatively high number of interfaces to implement for the TelarModule class, but it makes it possible to modify the packages independently of each other. When, for instance, the dataProvider package has received a new POI collection from a data provider wrapper, it calls the TelarModule class in order to draw the POIs on the map, which internally forwards the POIs to the ui package, so that no coupling between the two subpackages is created. killidi killii killididkillidP t t t t t tt t tt comnoaearcenccomnoaearcencomnoaearcenaaroercomnoaearcenaa u v...... if if if t t t nerace nerace nerace» » »« « « iii lidll l llG C CPL TW T tt tt t psosonsener eargeonroer earonroerI I I ldlM earoe uT killi t t comnoaearcen...Figure 6.2: The Java package structure of the TELAR client and the interfaces of the TelarModule class for different packagesWhen the TELAR client receives new POI data from a data provider wrapper, that data is first unmarshalled into a number of objects, before it is processed and drawn on the map. This practice causes some inefficiency, as a lot of space is allocated each time new POIs are received and a lot of garbage is created when the old POIs are removed. It would be much more efficient to translate the POI data into a number of calls to the map API directly. However, there are two advantages with creating the POI objects. First, the POI objects enable modularity, as unmarshalling the POI objects is decoupled from the map. And secondly, the POI objects make it possible to add other ways to represent the POIs in addition to the map. For instance, with the POI objects it is easy to list the POIs next to the map in addition to showing them on the map, generating a presentation similar to the one in figure 2.15 on page 27. As mentionend in section 6.1.3, the TELAR client uses the GoogleMaps-GWT Google Web Toolkit module in order to create a map. As the module makes available nearly the complete Google Maps API in Java, it also includes classes for geometric objects, such as GLatLng for WGS-84 coordinates or GPolyline for linestrings. For reasons of simplicity and efficiency, the TELAR client does not replicate these classes, but uses them directly throughout the code. This creates great coupling not only to Google Maps, but also to the GoogleMaps-GWT module. It was not a requirement to be independent from a particular map API, and this does not restrict future extensions of the TELAR client too much, either. Thus, this practice was considered acceptable. The only real problem when developing the TELAR client occurred with the XML parser of the Google Web Toolkit. As described in section 5.3.3, it is important to use XML namespaces in an Atom or GeoRSS feed, in order to comply with the Atom specification. However, it turned out that the Google Web Toolkit does not really support XML namespaces. In the runtime environment of the Google Web Toolkit, which uses a browser based on Mozilla Seamonkey, the data which the data provider wrappers returned to the TELAR client was parsed correctly. Yet, on other browsers including Mozilla Firefox, Microsoft Internet Explorer, and the Mozilla-based browser of the Nokia N800, the TELAR client could not deal with the namespaces in the GeoRSS feed. This is not primarily the fault of the Google Web Toolkit. For efficiency, the Google Web Toolkit uses built-in capabilities of a browser wherever possible, which also includes the XML parser. However, the XML parsers of most browsers do not support XML namespaces. The problem was solved by adding an additional parameter to the interface of the data provider wrappers, with which the XML namespaces could be disabled. Thus, it was still possible to retrieve a valid GeoRSS feed, although the TELAR client reads a slightly different format.6.2.3 Data provider wrappersThe hardest pieces of work concerning the data provider wrappers was to find the right libraries for functionality such as sending HTTP requests, handling XSLT, and parsing JSON data, as well as to get access to a server with a public IP address and the right software installed. Writing the data provider wrappers did not cause any problems, as soon as the right software packages were correctly configured and the data providers were sufficiently explored.65 CHAPTER 6. IMPLEMENTATIONAs this functionality was needed by several data provider wrappers, a number of PHP classes for representing the data model of the TELAR mashup platform was written. Using these classes, a data provider wrapper only needs to instantiate a number of objects, pass the data received from a data provider to the getter methods of the objects, and call the toJSON() or toGeoRSS() method, which serializes the data into a string of GeoRSS or JSON data, respectively. As table 6.4 on page 70 shows, these classes are not only by far the biggest amount of code of the data provider wrappers, they also help to keep the actual wrappers very small. In a few cases the API of a data provider was to some extent reverse-engineered, as the data provider was principally not intended to be publicly used but was only a part of an AJAX-based web page. The Firebug browser extension3, which provides a lot of functionality to analyze web pages in the Mozilla Firefox browser, was used to track the asynchronous HTTP requests sent by the web page. Then, it was often easily possible to determine the semantics of the different HTTP parameters. Thus, HTTP requests could be replicated in the PHP script of a data provider wrapper. Similarly, by looking at the XML or JSON data returned by the data provider it became easily clear, what information was represented. So transforming the data to fit the data model of the TELAR mashup platform was not particularly difficult.6.2.4 Supported data providers Data provider wrappers for the following data providers were written:FON. The “FON Maps” web page4 was reverse-engineered in order to obtain the WLAN access points of the FON WLAN sharing community. Via a REST-based API, JSON-encoded data is queried, which is transformed using hand-written PHP code.Panoramio. The REST-based API5 of Panoramio was used to retrieve geotagged photos from the Panoramio photo sharing site. The JSON-encoded collection of pictures is transformed using hand-written PHP code.Panoulu. The access point map of panOULU6 was reverse-engineered in order to obtain public WLAN access points in Oulu, Finland. The XML-encoded data is queried from a REST-based API and transformed using XSLT. Unfortunately this data provider does not support geographically restricted queries and always returns all 340 access points.Wikipedia. The REST-based API offered by geonames.org7 was used to query geotagged Wikipedia articles. The proprietary XML format, in which the articles were encoded, is converted using XSLT.6.3 PerformanceWhen the TELAR client and some data provider wrappers were implemented, the first tests showed, that the performance of the TELAR mashup platform was very bad. While the TELAR client worked fine on the desktop PC, it took up to four minutes until a mashup was completely constructed on the Nokia N800. A similar experience was made on a Pentium II PC. In order to measure, why the mashup was so slow, a number of log messages were inserted into the TELAR client. The log messages showed, that most of the time was spent for parsing the GeoRSS data, which was retrieved from the data provider wrappers. In addition to that, it took time to add the parsed POIs to the map. Both steps are done by JavaScript code interpreted in the browser. In contrast to the desktop PC, the processor of the Nokia N800 was not powerful enough to do this job quickly. In order to speed up performance, the standardized GeoRSS data format was replaced by a proprietary JSON format. The parser of the TELAR client was modified accordingly. At first, the JSON framework included in the Google Web Toolkit was used to parse the JSON data. The logs showed, that the amount of data had decreased by about one third. However, it now took roughly six minutes to load the mashup on the Nokia N800. This can be explained by the fact that both the DOM XML parser and the JSON framework create a meta-model of the data, which requires extra processing time and memory. However, the Google Web Toolkit uses the XML parser of the web browser, whereas the JSON framework is completely interpreted as JavaScript. In any case, loading times of six minutes were outrageous. Consequently, the Jsonizer framework was used to unmarshall POI objects from JSON data. Although Jsonizer was still very new and carried the version number 0.0.1, it worked perfectly well. Using3http://www.getfirebug.com/ (accessed July 23, 2007) 4http://maps.fon.com (accessed July 23, 2007) 5http://www.panoramio.com/api/ (accessed July 23, 2007) 6http://www.panoulu.net/mappings/apmap.php (accessed July 23, 2007) 7 http://www.geonames.org/export/wikipedia-webservice.html (accessed July 23, 2007)66 6.3. PERFORMANCEJsonizer, the loading time of the mashup decreased below two minutes. This was an enormous progress, but still not nearly acceptable.28 25 23 20 18 Parsing GeoRSS [s] s 15 d n Adding GeoRSS to map [s] co 13 Parsing JSON [s] se Adding JSON to map [s] 10 8 5 3 0 10 20 30 40 50 60 70 80 90 100 110 120 130POIsFigure 6.3: Time for processing POIs in GeoRSS and JSON formatConsequently, the time spent for processing the POIs in the TELAR client was further investigated. Figure 6.3 shows how the number of seconds increases with the amount of POIs. From the figures it can be seen that for GeoRSS the parsing takes much longer than adding the POIs to the map. Parsing 100 POIs of GeoRSS data takes more than 20 seconds, which is far beyond reasonable. For JSON, however, parsing 100 POIs takes less than three seconds. As POIs are always unmarshalled to JavaScript objects first, adding POIs to the map is independent of the serialization format. Displaying 100 POIs on the map takes, according to the figures, between eight and ten seconds. Thus, by using JSON as the serialization format for the POIs, the parsing time is reduced dramatically. But adding the POIs to the map still takes too long. The task of adding the POIs to the map cannot be accelerated as easily as parsing, though. As the POIs are only passed to the map API, there is not much one can change. The GoogleMaps GWT module used for creating the map replicates the Google Maps API for the Google Webtoolkit. It would have been technically possible to abandon this module and access Google Maps directly via the JavaScript Native Interface. A more rigorous step would have been to re-implement the TELAR client completely in JavaScript and without the Google Web Toolkit. Naturally, the GoogleMaps GWT module and the Google Web Toolkit do impose additional overhead on the TELAR client. Yet it is not really possible to measure this without creating a second implementation and comparing the performance directly. A second implementation of the TELAR client was, however, not an option, as this would have gone beyond the time-frame of this thesis. Given that adding to POIs to the map is expensive, there are two things that can be done to improve performance: reducing the number of POIs and adding POIs to the map less often.6.3.1 Reducing POIsWhen the performance of the TELAR mashup platform was analyzed, it became obvious that it attempted to load roughly 500 POIs from the data providers. Looking at figure 6.3 it is not at all surprising that it took several minutes to load such a page. Yet, a mashup like this does not only provide bad user value due to the outrageous time performance. A map that is plastered with POIs as shown in figure 6.4 is likely to be less useful than a map without any POIs at all. For example, when looking at a whole town, the user does not need to see every single WLAN access point. It is sufficient to indicate the parts of town, in which a wireless network is available. Thus, it is important to provide an appropriate level of detail. It is sufficient to keep the number of POIs below a certain threshold for achieving acceptable time performance. Yet, as the example of the WLAN access points shows, it is desirable to include only POIs providing user value. This is difficult to achieve, as user value is hard to define and changes frequently. It can only be attempted to67 CHAPTER 6. IMPLEMENTATIONFigure 6.4: A mashup displaying by far too many POIs estimate the user value, for instance by evaluating context information, user ratings or by categorizing the POIs and giving the user the possibility to choose. Systems like REAL (see section 2.1.5) attempt to determine what the user is interested in, from context data, such as the user’s walking speed. The Nexus platform (see section 2.1.6) supports nearest neighbour queries, which select POIs based on the distance of the user’s position to the POI. Panoramio8, a web page for sharing geographically annotated photos, sorts pictures based on user ratings. Querying n pictures for a certain area results in the n pictures which most users liked. A simpler approach to determine the user value of POIs is to ask the user. Req-7 in section 5.1 mandates that the user can remove data providers from the presentation. So if the user is not hungry, all data providers serving restaurants can be excluded. Given that a data provider only owns POIs of one category, e. g., restaurants, this enables the user to select the appropriate categories. If POIs cannot be ordered by the user value they provide, it is desirable that POIs are at least uniformly distributed. In order to reduce the number of POIs, it is sensible to restrict the amount of data on the server side. This saves processing time on the client side and reduces the amount of transferred data. It can be done using sophisticated approaches as done by the Nexus federation (see section 2.1.6)[SHG+04]. Yet, this thesis chose a much simpler approach. Some data provider APIs, including Panoramio, provide a parameter indicating the desired amount of data. If such functionality is not available, the number of POIs can be still easily reduced by restricting the data provider wrappers to a certain hard-coded limit. This practice at least prevents single data providers from being drastically overrepresented. For simplicity, the TELAR mashup platform was modified so that the data provider wrappers either passed a limit to the data provider or cut off the result set before passing the data to the TELAR client. Moreover, the interface of the data provider wrappers was extended to accept the current zoom level of the map from the TELAR client. The data provider wrappers may use the zoom level in order to provide the appropriate level of detail. However, at the end of the implementation phase of this thesis, no data provider wrapper actually used the zoom level. In spite of that, as the data provider wrappers are very well isolated, they can be easily modified without any changes to other parts of the TELAR mashup platform. At a later point, algorithms of arbitrary complexity could be introduced to the data provider wrappers in order to determine the POIs with the highest user value.6.3.2 Reducing map modificationIn order to improve the performance of the TELAR client, it should be attempted to avoid unnecessary calls to the map API, as these can be expensive. At first, the TELAR client queried the data provider wrappers every time the bounding box of the map changed. All old POIs were thrown away and replaced with new data. This happened very frequently if the map was set to follow the user’s position, as the GPS access module delivers a new position every ten seconds. Although the map bounding box changes continuously, the map does not change very much when the user is walking. Thus, it would be enough the query POIs for the area which was added to the map in the last position update. This would decrease transmission times, parsing overhead and shorten the time to add the POIs to the map dramatically, as the old POIs do not need to be modified or queried again. However, as the Nokia N800 has only limited memory, POIs that are not visible any more should be deleted. Consequently, after every position update8http://www.panoramio.com/ (accessed July 23, 2007)68 6.4. IMPLEMENTATION RESULTS the TELAR client would have to find the POIs that moved out of the map bounding box in the last position update. Without complex indexing structures this is time-consuming. The Google Maps API provides such indexing with the GMarkerManager class, which is designed for working efficiently with large amounts of POIs. All POIs are simply handed over to the marker manager, which dynamically adds the POIs to the map and removes them again, depending on whether their position is inside the map bounding box. However, the GMarkerManager is not designed for deleting POIs. It can only clear all POIs but does not support deleting POIs selectively. One could have attempted to replicate the marker manager and implement the desired functionality manually in the TELAR client. However, for simplicity, it was decided to take a different approach than this strategy of incremental querying. Instead of querying the data provider wrappers by the map bounding box, a query bounding box was introduced. Whenever the TELAR client queried the data providers, 25 % of extra padding is added to the map bounding box. The resulting query bounding box is sent to the data provider wrappers. Whenever the map bounding box changes, it is first tested, whether the new map bounding box is still within the query bounding box of the last query. Only if this is not the case, a new query bounding box is calculated and the data provider wrappers are queried for new data. query bounding box 1 map 2 query bounding box 2 map 1 map 3 p2 p1 p3 p4 map 4 user traceFigure 6.5: Query bounding boxes for reducing the number of queriesFigure 6.5 illustrates the approach of the query bounding box. In order to display POIs for map 1, query bounding box 1 is calculated. POIs for the whole query bounding box are retrieved. As the user moves from position p1 to p2, map 2 is displayed. But as the map bounding box of map 2 is within query bounding box 1, no query to the data provider wrappers is required. Only when the user walks to position p3, new data must be queried, as the map bounding box of map 3 is not entirely within query bounding box 1. For map 4, the POI data fetched for query bounding box 2 is available again. As the area for which the data providers are queried is a lot larger in the approach of the query bounding box, a larger number of POIs is retrieved and the initial loading time of the mashup even increases. But once the mashup is loaded, significantly fewer queries are needed. In addition to that, the approach of the query bounding box can cope with changes of the user’s walking direction very well. The query bounding box is extended in all directions, so if the user changes direction or walks back to a former position, the POIs will be still available for a while.6.4 Implementation resultsAfter roughly 350 hours of development time, a system was available that fulfilled all requirements defined in section 5.1. A screenshot of the TELAR mashup platform taken on a Nokia N800 is shown in figure 6.6. The dialog for editing the data providers is open, showing the three data providers used in this particular mashup. POIs obtained from the data providers are spread throughout the map. The picture of a Nokia N800 in the middle of the map indicates the GPS position. The Bluetooth icon in the status bar is activated, which shows that the Nokia LD-3W Bluetooth GPS device is connected.69 CHAPTER 6. IMPLEMENTATIONFigure 6.6: Screenshot of the TELAR mashup platform on the Nokia N800Table 6.4 lists the size and development time of the TELAR mashup platform and its parts. The amount of physical Source Lines of Code (SLOC)9 shows that the browser extensions constitute the biggest part of the TELAR mashup platform. Yet, the TELAR client is not significantly smaller. The fact that the development time of the TELAR client makes up only 60 % of the time spent developing the browser extensions, emphasizes the importance of powerful software development tools and good documentation. Moreover, table 6.4 gives an impression of how small the data provider wrappers are. The development time for the wrappers is not very high, either. Thus, the architecture of the TELAR mashup platform is capable of including new data providers with little effort, albeit not automatically. The data provider wrappers still need to be hand-written, but this is not a lot of work to do.Architectural unit Component Language SLOC Dev. time DCI XPCOM C++ 1500 Web browser extensions GPS access XPCOM C++ 415 total XPCOM C++ 1915 200 hTELAR client total Java 1789 120 h GeoRSS classes PHP 258 FON access points PHP 69 Panoramio pictures PHP 49 Data provider wrappers Panoulu access points PHP + XSLT 33 + 93 Wikipedia PHP + XSLT 39 + 34 total PHP + XSLT 409 + 127 28 hTable 6.1: The implementation effort of the TELAR mashup platform and its parts9The physical Source Lines of Code were generated using David A. Wheeler’s sloccount program available from http://www. dwheeler.com/sloccount/ (accessed July 23, 2007).70 CHAPTER 7PRIVACYThe user’s position is a sensitive piece of very personal information. Great care must be taken when dealing with such critical private data. As the TELAR mashup platform is not yet intended to be a production system, the privacy aspect was temporarily disregarded. However, it must not be forgotten. This chapter discusses how the user’s privacy can be protected in the TELAR mashup platform. First, the Geopriv privacy model is introduced. Then, this model is applied to the TELAR mashup platform and a simple way to introduce privacy to the TELAR mashup platform is presented.7.1 Geopriv privacy modelThe Geographic Location/Privacy (Geopriv) IETF working group assesses the authorization, integrity and privacy requirements that must be met in order to transfer the user’s position information. The Geopriv working group published a Request for Comments [CMJP04], which acts as a requirements specification for the privacy aspect of location-based systems. The DCI specification, which does not explicitly address privacy, references [CMJP04]. [CMJP04] defines the Location Object as the primary data structure for secure transfer of location data. In order to control access to such a Location Object, the user defines a set of Privacy Rules, according to which the information of the Location Object is passed on. Four primary entities are identified in a basic model, as shown in figure 7.1. The entities are not necessarily physically separate.Rule Holder rule interfaceLocation Location Location Generator Server Recipient publication interface notification interfaceFigure 7.1: The four primary entities of the Geopriv privacy model (based on [CMJP04])Location Generator. The Location Generator determines the user’s position and creates Location Objects. The Location Objects are passed to the Location Server via the publication interface. It is not specified how the location information is gathered.Location Server. The Location Server manages the distribution of Location Objects. Its design follows the principle of a push architecture. Location Recipients subscribe to the Location Server and receive notifications containing Location Objects. The Location Server obtains the Privacy Rules from the Rule Holder and applies them.Location Recipient. The Location Recipient consumes Location Objects. It subscribes to the Location Server and receives Location Objects via the notification interface.71 CHAPTER 7. PRIVACYRule Holder. The Rule Holder houses the Privacy Rules, which the user defined. Via the rule interface, the Location Server may query the Rule Holder for the Privacy Rules or the Privacy Rules may be pushed from the Rule Holder to the Location Server. The Privacy Rules must be authenticated and protected.7.2 Applying the Geopriv privacy modelMapping the Geopriv privacy model to the TELAR mashup platform is not as simple as it might seem at first. The TELAR mashup platform transfers the user’s position between numerous components. Given that the Maemo location framework lies outside the TELAR mashup platform, the user’s position is passed first from the DCI module to the TELAR client. Secondly, the TELAR client passes the query bounding box to the data provider wrappers. This is not exactly the user’s position, but the query bounding boxes contain the position implicitly as their center point. Finally, the data provider wrappers query the data providers using the query bounding box. Thus, the Location Server could be the DCI module, the TELAR client and the data provider wrappers, although only the DCI module supports subscription and notification. In spite of that, the most critical part is DCI. The communication between the TELAR client and the data provider wrappers can be done via HTTPS connections. This is not generally possible with the connections between the data provider wrappers and the data providers, as most data providers do not offer HTTPS. However, one might argue that it is not very important to secure the connections to the data providers, as the connections are not associated with the user. If the TELAR mashup platform is used by many users, at least some additional knowledge, e. g., the approximate position of a user, is required in order to sort out the requests which belong to a particular user. In order to achieve k-anonymity [SS98], the data provider wrappers can send additional requests to the data providers. This practice achieves a certain degree of fuzziness, which makes it not impossible, but more difficult to monitor a single user. In contrast to that, it is easy to write a bogus web page, which obtains the user’s position from the DCI module and uploads it to a server. Thus, the remainder of this chapter focuses on DCI only.Web Browser index.html Location GPS Access Generator Telar Client Publication Interface Location Location DCI Server Recipient Notification InterfaceMashup Site mashup- index.html config.html Wrapper 1 ... Wrapper nData Provider 1 ... Data Provider nFigure 7.2: Mapping the entities of the Geopriv privacy model to the architecture of the TELAR mashup platformFigure 7.2 illustrates, how the entities of the Geopriv privacy model can be mapped to the architecture of the TELAR mashup platform. The GPS access module can be considered the Location Generator (disregarding the Maemo location framework, which lies outside of the TELAR mashup platform). The GPS access module creates DCI properties containing the user’s position, which map to the Location Object. The DCI module is responsible for making the user’s position available and supports event listeners that are notified. Thus, the DCI module plays72 7.2. APPLYING THE GEOPRIV PRIVACY MODEL the role of the Location Server. Finally, a web page accessing the DCI module in order to obtain the user’s position is the Location Recipient. As the TELAR mashup platform, as it was implemented in this thesis, does not support any access control, Privacy Rules and the Rule Holder do not exist. Consequently, in order to protect the user’s privacy, a module acting as the Rule Holder as well as a means of defining Privacy Rules have to be introduced to the TELAR mashup platform.7.2.1 Privacy in the context access and adaptation architecture The DCI specification does not mandate any particular security aspects. The context access and adaptation architecture introduced in section 4.4, which is based on DCI, includes the access control model. In addition to managing access to the information contained in the DCI tree, the access control model is also responsible for the integrity of the DCI tree. The context access and adaptation architecture was not entirely implemented. Yet, [Sat07] proposes a security policy for the context access and adaptation architecture. A set of security classes is defined. Each security class possesses certain privileges. When accessing the DCI tree, both context consumers and context providers must register to a security class. This is done according to a class identifier, which is assigned by the operating system or a middleware. For remote components, a third party assignment service or direct negotiation with the device middleware is envisioned. The access control model looks at the particular security class to which a component belongs and then grants the appropriate rights. The DCI metadata interface is used in order to link the properties of the DCI tree to access rights. Metadata tags indicating the owner of a property and the visibility of the property to a particular security class are added to the DCI properties. In terms of the Geopriv privacy model, the security classes and the visibility tags of the properties constitute the Privacy Rules.7.2.2 Whitelist Whereas the former approach envisions a sophisticated means of access right negotiation, a simple way to introduce privacy to the TELAR mashup platform could be a user-defined whitelist. Every time a web page attempts to access the DCI tree, the DCI module could ask the user whether permission should be granted. The user could have the possibility to save the decision, in order not to be bothered any more in the future. In the TELAR mashup platform, the GPS access module is the only context data provider, so that integrity of the DCI tree is not really an issue. The implementation of this thesis does not restrict modification of the DCI tree in any way. So it would be possible to delete the GPS properties from the DCI tree using some JavaScript code in a web page. However, for the purposes of the TELAR mashup platform, it is sufficient to restrict write access to the DCI tree to XPCOM modules installed on the user’s device and block all other parties. Thus, the only real problem is restricting read access to those web pages which the user really wants to know the current position. The DCI module could be extended by a whitelist module taking the role of the Rule Holder. This whitelist module keeps a list of the web pages to which the user granted read access to the DCI tree. Every time a web page accesses the DCI module, this rule holder module is queried. If the web page is not known to the whitelist module, the user is asked whether to grant access to the web page and whether to include the web page into the whitelist. It must be considered, that the browser extensions of the TELAR mashup platform do not have the possibility to create user interfaces. In spite of that, using the XPCOM prompt service, it is possible to create confirmation dialogs. If a full-featured management application for the whitelist is desired, the whitelist must be stored on the device in a way that enables other applications to access it. The gconf framework, which is used to store configuration data throughout the platform software of the Nokia Internet Tablets, could be appropriate for this task. Then, a management application that is independent of the browser can be written to edit the whitelist. In terms of the privacy architecture of [Sat07] it can be stated that there are two security classes in the whitelist approach: Full access to the DCI tree for XPCOM modules inside the web browser and read only access for web pages contained in the whitelist.73 CHAPTER 7. PRIVACY74 CHAPTER 8CONCLUSIONIn this thesis, a system enabling location-based mashups is presented. First, a number of approaches is discussed, how the user’s position can be integrated into a mashup despite the sandbox of the web browser. Comparing the approaches, a web browser extension following the specification of the Delivery Context Interfaces (DCI) is considered the best solution for the requirements of this thesis. Secondly, an architecture for a system is developed, enabling location-based mashups on a Nokia N800 Internet Tablet. The system creates mashups which show the user’s position on a map and integrate POIs from different data providers. The mashups work on other browsers and devices, too, only without being location-aware. As the different data providers offer their data via a variety of protocols and data formats, server-sided data provider wrappers convert the POIs into a uniform data format. Thirdly, the architecture is put into practice. Two extensions for a Mozilla-based browser are implemented in order to provide the user’s position to mashups. A JavaScript client taking on the job of creating the mashups is written using the Google Web Toolkit. The server-sided data provider wrappers are put into practice as small and independent PHP scripts. In order to cope with performance problems, the concept of the query bounding box is introduced. POI data is fetched not only for the area which is currently displayed but also for the surroundings, which results in fewer queries. Finally, it is discussed, how privacy aspects can be regarded in the developed system. Although the system is not a production system, it is able to provide user value. With this system it is possible to create web pages which can be used both at home and on the go. For instance a tourist information system built like this can be used both when planning a journey and during the trip. Despite the working system, there is plenty of potential future work. First of all, in a next step, privacy should be introduced to the system. This might be done in a simple way by introducing a whitelist of web pages which the user allows to access the position. In addition to that, performance of the system still needs work. It should be measured, how much processing time can be saved by implementing the client using hand-written JavaScript code instead of the Google Web Toolkit. More elaborate approaches to reduce queries to the server side should be explored, as the query bounding box is most likely not optimal. On the server side, more intelligent ways to reduce the number of POIs can be introduced, in order to determine the POIs which provide most user value. Moreover, the system could be extended to support other geographic objects, such as linestrings and polygons, in addition to POIs. In the future, a system is envisioned which does not need hand-written data provider wrappers, but is able to integrate the diversity of data providers into mashups automatically.75 CHAPTER 8. CONCLUSION76 APPENDIX ASAMPLE HTMLPAGESThe following sections contain sample HTML pages, which demonstrate how the system developed in this work can be used. First an example is given which uses the DCI API directly. Subsequently, an HTML page is shown which uses the TELAR mashup platform and thus needs no included JavaScript code.A.1 An HTML page using the DCI APIThe HTML page shown in listing A.1 was used in order to test the DCI implementation. It displays the GPS data from the DCI tree both textually and by marking the position on a Google map. The HTML file includes two JavaScript files, one for Google maps and one for accessing DCI, the latter being shown in listing A.2. The page by itself contains only three <div> elements as placeholders, into which the JavaScript code shown in listing A.2 inserts content. The first placeholder is filled with the names and values of the child nodes found below the GPS property in the DCI tree. For debugging purposes a timestamp is added as well. In case the GPS Status node in the DCI tree indicates that a GPS fix is available, the second placeholder is filled with a Google map that is centered on the current GPS position. The position is additionally marked on the map. The third placeholder is used for error messages, for instance if the page is visited with a browser that does not support DCI. Figure A.1 shows a screenshot of the dcimap.html page taken on the Internet Tablet when a two dimensional GPS fix was available. As one can see in the status bar on top, the bluetooth icon is enabled, which is due to the connected bluetooth GPS device.Figure A.1: Screenshot of the DCI Map web page on the Internet TabletThe JavaScript code shown in listing A.2 demonstrates how the DCI API is used. First of all, line 12 checks whether the browser supports DCI at all. As the DCI implementation carried out in this work puts DCI into practice as a DOM feature, checking for DCI support is done by using document.isSupported(). In case the browser does support DCI, line 13 requests the DCI DOM feature and gets access to the DCI root node. While it would be possible to navigate through the DCI tree using the firstChild and nextSibling attributes, it is easier and more robust to find the GPS Status node using the DCI search method searchProperty(). This is done in line 14. Once the GPS Status node is found, line 23 adds the showPosition function as an event listener to the Status node. The function showPosition is defined in line 46. It uses the nextSibling attribute of the Status77 APPENDIX A. SAMPLE HTML PAGES<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"/> <title>DCI Map</title> <script src="http://maps.google.com/maps?file=api&v=2&key=..." type="text/javascript"></script> <script src="ctrl.js" type="text/javascript"></script> </head><body onload="ctrl.load()" onunload="ctrl.unload()"> <div id="coordinates"></div> <hr/> <div id="map" style="width: 100%; height: 200px; text-align: center"></div> <hr/> <div id="error"></div> </body> </html> Listing A.1: dcimap.html, a sample HTML page directly accessing the DCI tree node for iterating over all its siblings in line 54 and extracts their names and values for output in the HTML page in line 54. Line 60 checks whether a GPS fix is present and if that’s the case, the map is updated in line 67.1 /∗∗ 2 ∗ Put everything into one controller object . This makes ‘‘ global ’’ variables for 3 ∗ map, marker and statusNode a bit nicer . 4 ∗/ 5 var ctrl = new Object(); 6 7 /∗∗ 8 ∗ Checks whether DCI is available . If yes, registers an event listener at the 9 ∗ /Location/GPS/Status DCI Node. 10 ∗/ 11 ctrl.load = function() { 12 if (document.isSupported("DCI", "2.0")) { 13 var dci = document.getFeature("DCI", "2.0"); { 14 var nodelist = dci.searchProperty("http://www.nokia.com/telar", "Status", null, true); { 15 if (nodelist.length < 1) { 16 ctrl.error("DCI Node http://www.nokia.com/telar::Status not found."); 17 } else { 18 // Save the status node in a member variable, so that unregistering is easier . 19 ctrl.statusNode = nodelist.item(0); 20 21 // The current DCI implementation fires change events every time the value is ∗set∗ 22 // (not necessarily changed). So all that ’s needed here is listen for the status . 23 ctrl.statusNode.addEventListener("dci−prop−change", ctrl.showPosition, false); { 24 // Don’t wait for the next event . 25 ctrl.showPosition(); 26 } 27 } else { 28 ctrl.error("DCI is not supported by your browser."); 29 } 30 } 31 32 /∗∗ 33 ∗ Unregisters the DCI event listener and unloads the Google Maps objects. 34 ∗/ 35 ctrl.unload = function() { 36 if (ctrl.statusNode) { 37 ctrl.statusNode.removeEventListener("dci−property−change", ctrl.showPosition, false); 38 } 39 GUnload(); 40 } 41 42 /∗∗ 43 ∗ Checks the /Location/GPS/Status value and if there is a GPS fix updates the map 44 ∗ with the current position . If not yet present , the map is first created . 45 ∗/78 A.2. AN HTML PAGE USING THE TELAR MASHUP PLATFORM46 ctrl.showPosition = function(event) { 47 // We could as well get the status DCI node from event . target . 48 var gpsChild = ctrl.statusNode; 49 50 // Show all children of the GPS node in the DCI tree in an unordered list . 51 var html = "<ul><li>Date: " + new Date() + "</li>"; 52 while (gpsChild) { 53 html += "<li>" + gpsChild.nodeName + ": " + gpsChild.value + "</li>"; 54 gpsChild = gpsChild.nextSibling; 55 } 56 html += "</ul>"; 57 document.getElementById("coordinates").innerHTML = html; 58 59 // Update the map, if we have a fix . 60 if (ctrl.statusNode.value == "FIX 2D" || ctrl.statusNode.value == "FIX 3D"){{ 61 var latitudeNode = ctrl.statusNode.nextSibling; 62 var longitudeNode = latitudeNode.nextSibling; 63 var position = new GLatLng(latitudeNode.value, longitudeNode.value); 64 65 // Create the map and the marker object for the current position if necessary . 66 if (ctrl.map) { 67 ctrl.marker.setPoint(position); 68 ctrl.map.setCenter(position, 13); // Zoom level 13 is quite close. 69 } else { 70 if (GBrowserIsCompatible()) { 71 ctrl.map = new GMap2(document.getElementById("map")); 72 ctrl.map.setCenter(position, 13); 73 ctrl.marker = new GMarker(position); 74 ctrl.map.addOverlay(ctrl.marker); 75 } else { 76 ctrl.error("Your browser is not supported by Google Maps."); 77 } 78 } 79 } 80 } 81 82 /∗∗ 83 ∗ Puts an error message into the error <div> element. 84 ∗/ 85 ctrl.error = function(msg) { 86 document.getElementById("error").innerHTML = msg; 87 } Listing A.2: ctrl.js, the JavaScript file included in dcimap.htmlA.2 An HTML page using the TELAR Mashup PlatformThe HTML page in listing A.3 does hardly anything else than defining a placeholder for the TELAR widget. In the head the JavaScript file for Google maps is included, which is required for the TELAR widget to work. A Stylesheet is included with which the appearance of the widgets can be significantly modified. For reasons of simplicity the stylesheet is not shown here as it is rather lengthy. The reader can refer to the Google Webtoolkit’s documentation for information how to define the style of widgets. Using the meta element “gwt:module” it is defined, which widget class shall be loaded. The Google Webtoolkit requires further including the JavaScript file gwt.js. Ultimately, the <div> element with the ID “telarmap” is created. This element constitutes the root pane into which the TELAR widget will put its content. It is important that the ID of the <div> element is exactly “telarmap”, otherwise the TELAR widget will not find it. The <div> element has style information defining its size, in the given example it covers the whole browser area, which is also the default behaviour in case the size is not defined. However in case the HTML page shall have other content as well, the size can be set to a different value, e. g. style="width: 400px; height: 400px;".79 APPENDIX A. SAMPLE HTML PAGES<html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Telar Mashup Platform</title> <script src="http://maps.google.com/maps?file=api&v=2&key=..." type="text/javascript"></script> <link rel="stylesheet" type="text/css" href="telar.css"/> <meta name="gwt:module" content="com.nokia.telar.TelarModule"/> </head> <body> <script type="text/javascript" src="gwt.js"></script> <div id="telarmap" style="width: 100%; height: 100%;"></div> </body> </html>Listing A.3: telar.html, a sample HTML page embedding the TELAR widget80 BIBLIOGRAPHY[ATT02] “The active badge,” web page, 2002. [Online]. Available: http://www.cl.cam.ac.uk/research/dtg/ attarchive/thebadge.html[BKW02] J. Baus, A. Krüger, and W. Wahlster, “A resource-adaptive mobile navigation system,” in IUI ’02: Proceedings of the 7th international conference on Intelligent user interfaces. New York, NY, USA: ACM Press, 2002, pp. 15–22.[BLHL01] T. Berners-Lee, J. Hendler, and O. Lassila, “The semantic web : a new form of web content that is meaningful to computers will unleash a revolution of new possibilities,” Scientific American, vol. 284, no. 5, pp. 34–43, May 2001.[CDL+04] S. Cox, P. Daisey, R. Lake, C. Portele, and A. Whiteside, “Opengis geography markup language (gml) implementation specification,” Open Geospatial Consortium Inc., Recommendation Paper OGC 03-105r1, February 2004.[CDM+00] K. Cheverst, N. Davies, K. Mitchell, A. Friday, and C. Efstratiou, “Developing a context-aware electronic tourist guide: some issues and experiences,” in CHI ’00: Proceedings of the SIGCHI conference on Human factors in computing systems. New York, NY, USA: ACM Press, 2000, pp. 17–24.[CMJP04] J. Cuellar, D. Mulligan, J.Peterson, and J. Polk, “Geopriv requirements,” The Internet Society, Request for Comments 3693, February 2004.[Cro06] D. Crockford, “The application/json media type for javascript object notation (json),” The Internet Society, Request for Comments 4627, July 2006.[DCMF99] N. Davies, K. Cheverst, K. Mitchell, and A. Friday, “Caches in the air: Disseminating tourist information in the guide system,” in Proceedings of the 2nd IEEE Workshop on Mobile Computing Systems and Applications. IEEE Computer Society, 1999, pp. 11–19.[Eva06] C. Evans, “QEDWiki, IBM, and "Situational Applications",” web article, July 2006. [Online]. Available: http://devzone.zend.com/node/view/id/678[Fie00] R. T. Fielding, “Architectural styles and the design of network-based software architectures,” Ph.D. dissertation, University of California, Irvine, 2000, chair-Richard N. Taylor.[Goo07] Google, “Kml 2.1 reference,” web page, 2007. [Online]. Available: http://code.google.com/apis/kml/ documentation/kml_tags_21.html[Gra05] P. Graham, “Web 2.0,” web article, November 2005. [Online]. Available: http://paulgraham.com/ web20.html[GUI] “The guide project,” web page. [Online]. Available: http://www.guide.lancs.ac.uk/screenshots.html[HKL+99] F. Hohl, U. Kubach, A. Leonhardi, K. Rothermel, and M. Schwehm, “Next century challenges: Nexus- âan open global infrastructure for spatial-aware applications,” in MobiCom ’99: Proceedings of the 5th annual ACM/IEEE international conference on Mobile computing and networking. New York, NY, USA: ACM Press, 1999, pp. 249–255.81 BIBLIOGRAPHY[HMK05] D. F. Huynh, S. Mazzocchi, and D. R. Karger, “Piggy bank: Experience the semantic web inside your web browser,” in The Semantic Web - ISWC 2005: 4th International Semantic Web Conference, Y. Gil, E. Motta, V. R. Benjamins, and M. Musen, Eds., vol. 3729. Secaucus, NJ, USA: Springer-Verlag New York, Inc., November 2005, pp. 413–430. [Online]. Available: http://simile.mit.edu/papers/iswc05.pdf [Kaa03] E. Kaasinen, “User needs for location-aware mobile services,” Personal Ubiquitous Comput., vol. 7, no. 1, pp. 70–79, 2003. [Kap05] Kapow Technologies, “Web integration technical whitepaper,” 2005. [Online]. Available: http://www.kapowtech.com/graphics/KapowEnterpriseMashupWhitePaper.pdf [Kuw05] S. Kuwamoto, “Web 2.0, rias, ajax, and the semantic web (lowercase s),” weblog article, August 2005. [Online]. Available: http://kuwamoto.org/2005/08/19/ web-20-rias-ajax-and-the-semantic-web-lowercase-s/ [Leh07] V. Lehmuskoski, “Mobiililaajakaistan ja avoimen langattoman internet-yhteyden julkistus helsingin joukkoliikenteessä,” internal project presentation, January 2007. [LKAA96] S. Long, R. Kooper, G. D. Abowd, and C. G. Atkeson, “Rapid prototyping of mobile context-aware applications: the cyberguide case study,” in MobiCom ’96: Proceedings of the 2nd annual international conference on Mobile computing and networking. New York, NY, USA: ACM Press, 1996, pp. 97–107. [LLW+00] A. Le Hors, P. Le Hégaret, L. Wood, G. Nicol, J. Robie, M. Champion, and S. Byrne, “Document object model (dom) level 2 core specification,” W3C, Recommendation, November 2000. [Online]. Available: http://www.w3.org/TR/DOM-Level-2-Core/ [LP03] P. Le Hégaret and T. Pixley, “Document object model (dom) level 3 events specification,” W3C, Working Group Note, November 2003. [Online]. Available: http://www.w3.org/TR/2003/ NOTE-DOM-Level-3-Events-20031107/ [Mer06] D. Merrill, “Mashups: The new breed of web app,” web article, August 2006. [Online]. Available: http://www.ibm.com/developerworks/xml/library/x-mashups.html [MMD06] S. Murthy, D. Maier, and L. Delcambre, “Mash-o-matic,” in DocEng ’06: Proceedings of the 2006 ACM symposium on Document engineering. New York, NY, USA: ACM Press, 2006, pp. 205–214. [MMDB04] S. Murthy, D. Maier, L. Delcambre, and S. Bowers, “Putting integrated information in context: superimposing conceptual models with sparce,” in APCCM ’04: Proceedings of the first Asian-Pacific conference on Conceptual modelling. Darlinghurst, Australia, Australia: Australian Computer Society, Inc., 2004, pp. 71–80. [NGS+01] D. Nicklas, M. Großmann, T. Schwarz, S. (ifp) Volz, and B. Mitschang, “A model-based, open architecture for mobile, spatially aware applications,” in Proceedings of the 7th International Symposium on Spatial and Temporal Databases: SSTD 2001; Redondo Beach, CA, USA, July 12-15, 2001, ser. Lecture Notes in Computer Science; 2121, C. S. Jensen, M. Schneider, B. Seeger, and V. J. Tsotras, Eds. Berlin, Heidelberg, New York: Springer-Verlag, July 2001, Article in Proceedings, pp. 117–135, ISBN 3-540-42301-X. [Online]. Available: http: //www.informatik.uni-stuttgart.de/cgi-bin/NCSTRL/NCSTRL_view.pl?id=INPROC-2001-41&engl=1 [Nic07] S. Nickolas, “Qedwiki,” Screencast, February 2007. [Online]. Available: http://files.zend.com/qedwiki/ [NS05] M. Nottingham and R. Sayre, “The atom syndication format,” The Internet Society, Request for Comments 4287, December 2005. [Obj02] Object Management Group, “Omg idl syntax and semantics,” July 2002. [Online]. Available: http://www.omg.org/technology/documents/formal/corba_2.htm [O’R05] T. O’Reilly, “What is web 2.0 - design patterns and business models for the next generation of software,” web article, September 2005. [Online]. Available: http://www.oreillynet.com/pub/a/oreilly/ tim/news/2005/09/30/what-is-web-20.html [par] “Parctab picture gallery,” web page. [Online]. Available: http://sandbox.parc.xerox.com/parctab/pics. html82 BIBLIOGRAPHY[Pix00] T. Pixley, “Document object model (dom) level 2 events specification,” W3C, Recommendation, November 2000. [Online]. Available: http://www.w3.org/TR/2000/ REC-DOM-Level-2-Events-20001113/ [Por06] “Portland state university campus map,” web page, 2006. [Online]. Available: http: //sparce.cs.pdx.edu/cmap/index.html [RSL+06] C. Reed, R. Singh, R. Lake, J. Lieberman, and M. Maron, “An introduction to georss: A standards based approach for geo-enabling rss feeds,” Open Geospatial Consortium Inc., White Paper OGC 06-050r3, July 2006. [Online]. Available: http://www.opengeospatial.org/pt/06-050r3[SAG+93] B. N. Schilit, N. Adams, R. Gold, M. Tso, and R. Want, “The PARCTAB mobile computing system,” in Proceedings Fourth Workshop on Workstation Operating Systems (WWOS-IV). IEEE, October 1993, pp. 34–39. [Sat07] S. Sathish, “Delivery context access for the mobile web,” Licentiate thesis, University of Tampere, Department of Computer Sciences, May 2007. [SHG+04] T. Schwarz, N. Hönle, M. Grossmann, D. Nicklas, and B. Mitschang, “Efficient domain-specific information integration in nexus,” in Proceedings of the 2004 VLDB Workshop on Information Integration on the Web : IIWeb-2004 ; Toronto, Canada, August 30, 2004, H. Davulcu and N. Kushmerick, Eds. online, August 2004, Article in Proceedings, pp. 122–127. [Online]. Available: http://www.informatik.uni-stuttgart.de/cgi-bin/NCSTRL/NCSTRL_view.pl?id= INPROC-2004-40&engl=1 [SP06] S. Sathish and O. Pettay, “Delivery context access for mobile browsing,” in ICCGI ’06: Proceedings of the International Multi-Conference on Computing in the Global Information Technology. Washington, DC, USA: IEEE Computer Society, 2006, p. 18. [Spi05] J. Spinney, “Wireless location uses in the user plane and control plane,” June 2005. [Online]. Available: http://www.lbszone.com/index2.php?option=com_content&do_pdf=1&id=148 [SPT06] S. Sathish, D. Pavel, and D. Trossen, “Context service framework for the mobile internet,” in FUMCA ’06: Proceedings of the International Workshop on System Support for Future Mobile Computing Applications. Washington, DC, USA: IEEE Computer Society, 2006, pp. 17–24. [SS98] P. Samarati and L. Sweeney, “Protecting privacy when disclosing information: k-anonymity and its enforcement through generalization and suppression.” in Proceedings of the IEEE Symposium on Research in Security and Privacy. IEEE, May 1998. [Tre06] W. Treese, “Web 2.0: is it really different?” netWorker, vol. 10, no. 2, pp. 15–17, 2006. [Tur06] D. Turner, “Exposing geo-location in minimo,” weblog article, July 2006. [Online]. Available: http://weblogs.mozillazine.org/dougt/archives/016719.html [WHFG92] R. Want, A. Hopper, V. Falcao, and J. Gibbons, “The active badge location system,” ACM Trans. Inf. Syst., vol. 10, no. 1, pp. 91–102, 1992. [WHR+06] K. Waters, R. A. Hosn, D. Raggett, S. Sathish, M. Womer, and M. Froumentin, “Delivery context: Interfaces (dci) accessing static and dynamic properties,” W3C, W3C Candidate Recommendation, October 2006. [Online]. Available: http://www.w3.org/TR/2006/CR-DPF-20061019 [WHR+07] K. Waters, R. A. Hosn, D. Raggett, S. Sathish, M. Womer, M. Froumentin, and R. Lewis, “Delivery context: Client interfaces (dcci) 1.0,” W3C, Working Draft, July 2007. [Online]. Available: http://www.w3.org/TR/2007/WD-DPF-20070704/ [Wik05] Wikipedia, “Mashup (web application hybrid),” wiki page, September 2005. [Online]. Available: http://en.wikipedia.org/w/index.php?title=Mashup_(web_application_hybrid)&oldid=123993806All links were accessed on July 23, 2007.83 BIBLIOGRAPHY84 LISTOF FIGURES1.1 Crime reports shown on a Google Map by www.chicagocrime.org (screenshot) ...... 10 1.2 The Nokia N800 Internet Tablet ...... 102.1 Active Badges of different device generations ...... 13 2.2 Xerox ParcTab computer ...... 14 2.3 The map view and the information view of the indoor Cyberguide system ...... 15 2.4 Screenshot of GUIDE ...... 16 2.5 The outdoor version of the REAL system ...... 16 2.6 The architecture of the Nexus platform ...... 17 2.7 Nokia Mobile Search ...... 18 2.8 The Maemo Mapper application showing a satellite-based map ...... 18 2.9 The Navicore application ...... 19 2.10 Public transport passenger information system ...... 20 2.11 “HKL Ajoneuvot kartalla” showing busses and trams in real-time on a Google Map ...... 20 2.12 General architecture of a mashup ...... 23 2.13 A Yahoo! pipe translating German news to English ...... 26 2.14 Piggy Bank browsing and searching the saved RDF data ...... 27 2.15 A mashup of Portland State University campus created by Mash-o-Matic ...... 27 2.16 The data model used by Mash-o-Matic ...... 28 2.17 A simple Kapow robot for performing a Google search ...... 29 2.18 IBM QEDWiki ...... 293.1 Mashup architecture using a third party position data provider ...... 32 3.2 Mashup architecture using a local position data provider ...... 33 3.3 Local mashup architecture ...... 34 3.4 Architecture of a mashup using a browser extension ...... 35 3.5 A PHP test page displaying all HTTP headers of the HTTP request ...... 364.1 Context access and adaptation architecture introduced by [SP06] ...... 435.1 The system architecture of the TELAR mashup platform ...... 47 5.2 The ontology for the DCI tree used by the TELAR mashup platform ...... 48 5.3 The logical data model for the TELAR mashup platform ...... 526.1 UML sequence diagram illustrating the threads in the GPS access module ...... 64 6.2 The Java package structure of the TELAR client and the interfaces of the TelarModule class for different packages ...... 65 6.3 Time for processing POIs in GeoRSS and JSON format ...... 67 6.4 A mashup displaying by far too many POIs ...... 68 6.5 Query bounding boxes for reducing the number of queries ...... 69 6.6 Screenshot of the TELAR mashup platform on the Nokia N800 ...... 707.1 The four primary entities of the Geopriv privacy model (based on [CMJP04]) ...... 71 7.2 Mapping the entities of the Geopriv privacy model to the architecture of the TELAR mashup platform 72A.1 Screenshot of the DCI Map web page on the Internet Tablet ...... 7785 LIST OF FIGURES86 LISTINGS3.1 http.php, a PHP page displaying all HTTP request headers ...... 36 3.2 Accessing the GPS position from the mozGPS minimo extension [Tur06] ...... 38 5.1 A KML file displaying a POI collection of one wikipedia article ...... 53 5.2 A GeoRSS GML file displaying a POI collection of one wikipedia article ...... 54 5.3 A JSON file displaying a POI collection of one wikipedia article ...... 55 6.1 Example code using the Maemo location framework ...... 58 6.2 An example of an XPCOM method implementation in C++ ...... 60 6.3 An example of an XPCOM method implementation in JavaScript ...... 61 6.4 An example of the JavaScript Native Interface of the Google Web Toolkit ...... 62 A.1 dcimap.html, a sample HTML page directly accessing the DCI tree ...... 78 A.2 ctrl.js, the JavaScript file included in dcimap.html ...... 78 A.3 telar.html, a sample HTML page embedding the TELAR widget ...... 8087 LISTINGS88 LISTOF TABLES2.1 Summary of the location-based applications introduced above ...... 213.1 Comparison of the most promising approaches to transfer the position to a mashup ...... 395.1 Comparison of data formats for the TELAR mashup platform ...... 566.1 The implementation effort of the TELAR mashup platform and its parts ...... 7089 LIST OF TABLES90 DeclarationAll the work contained within this thesis, except where otherwise acknowledged, was solely the effort of the author. At no stage was any collaboration entered into with any other party.(Andreas Brodt) </div> </article> </div> </div> </div> <script type="text/javascript" async crossorigin="anonymous" src="https://pagead2.googlesyndication.com/pagead/js/adsbygoogle.js?client=ca-pub-8519364510543070"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.6.1/jquery.min.js" crossorigin="anonymous" referrerpolicy="no-referrer"></script> <script> var docId = '01effefc1737a54fe148ecb8a4f2fcdf'; var endPage = 1; var totalPage = 92; var pfLoading = false; window.addEventListener('scroll', function () { if (pfLoading) return; var $now = $('.article-imgview .pf').eq(endPage - 1); if (document.documentElement.scrollTop + $(window).height() > $now.offset().top) { pfLoading = true; endPage++; if (endPage > totalPage) return; var imgEle = new Image(); var imgsrc = "//data.docslib.org/img/01effefc1737a54fe148ecb8a4f2fcdf-" + endPage + (endPage > 3 ? ".jpg" : ".webp"); imgEle.src = imgsrc; var $imgLoad = $('<div class="pf" id="pf' + endPage + '"><img src="/loading.gif"></div>'); $('.article-imgview').append($imgLoad); imgEle.addEventListener('load', function () { $imgLoad.find('img').attr('src', imgsrc); pfLoading = false }); if (endPage < 7) { adcall('pf' + endPage); } } }, { passive: true }); </script> <script> var sc_project = 11552861; var sc_invisible = 1; var sc_security = "b956b151"; </script> <script src="https://www.statcounter.com/counter/counter.js" async></script> </html>