N ECESSARY S YSTEM A RCHITECTURE C HANGES

As illustrated in State of the Art, WRS faces several problems pointing to design changes.

The most important change is the location of the user ratings. After moving from the article page to user pages, the current approach of using Wikipedia as a central repository seems an impossible scenario. We will therefore look at other options for moving away from Wikipedia towards a central location for the ratings, even at the cost of having to maintain another online system. This change is mandatory as the current implementation does not work anymore.

Another change is the usage of Scone Proxy. The use of this framework slows down web browsing as all the content is bridged through Scone Proxy. Scone Proxy also has a series of restrictions which point to the fact that it might not be appropriate for a normal user. It conflicts with popular software as Skype and WAMP (Windows Apache MySQL PHP) Server. Another weakness of the Scone Proxy is that it doesn’t follow the no-cache command in HTML and it caches pages. This means the user will have to pay attention to the output from the Scone Proxy Command Window and empty the cache manually, a task most users do not want to repeat whenever they return to a page they visited before. The last argument against using Scone Proxy is the installation of WRS. Even if the installation steps have been reduced over time, installing WRS is not an easy task as it requires some specific steps to be performed by the user in order to set up Scone Proxy. While this change is not mandatory, it will contribute to the development of WRS in the long run and will set the ground for wide distribution and usage of WRS.

The last motivation for change is the lack of advanced debugging provided by modern IDEs. The current implementation of WRS makes it hard to debug. As pointed out by (Pilkauskas, 2010) the limited way to debug the code is by dumping messages to either the console or log files or by a similar technique. The system does not benefit from the modern IDEs debugging tools which will otherwise enable a faster speed of development. Improving the debugging options while making the other changes will accelerate the current and future development. This change is optional, but highly necessary in the author’s opinion.

After analysing the current state of the project which dictates several design changes (and keeping in mind the big goal of the thesis of solving the cold start problem) the following approach has been suggested:

Necessary System Architecture Changes 27

Server Services

In order to get rid of Scone Proxy, the current functionality can be implemented as a service running on a server that exposes specific methods through web services. The goal is to keep the core of WRS unchanged and adapt it to fit the new architecture.

Having these services will significantly reduce WRS installation complexity and it will change the distribution method, as such services can be used across platforms with virtually no limitations.

Independent Storage for Ratings

As the article ratings can no longer be kept on Wikipedia user pages, we have to move them to an independent location, accessible by the new WRS services. The server that holds these WRS services is a good candidate for this purpose as we can use it with no restrictions.

Currently, the ratings are being kept in plaintext in the user pages, and moving them to our own server would mean saving them in simple text files. Performing the supported operations (read, write) would translate to handling files on the server’s file system. While these operations can be implemented, we have to be aware that their number, as well as their size, will be expanding consistently, along with the usage of WRS. In order to simplify things and focus on the main goal of this project, we turn our attention to already existing technologies for handling this scenario. We will therefore use a relational database, where all the needed operations are implemented and ready to be used with no or little extra work. Furthermore, the relational databases have already implemented mechanisms for fast lookup and transactional operations that we can take advantage of.

Browser Extension for Client Interaction

As all the complex operations will be executed by the server services, we can develop a lightweight client to access them. The client will have to be able to call web methods (exposed by the server services) and support a basic client interaction.

These requirements, as well as the need of a simple and easy-to-distribute application, point towards implementing the WRS client as a browser extension.

Ultimately, publishing this browser extension in an online marketplace as a free download will make it ideal for wide distribution and usage.

The current feedback could be improved as it is too intrusive, distracting the user from browsing. An interface where the article rating is presented without distracting the user from browsing, and displaying the feedback interface only on demand would be preferred to the existing one.

28 Analysis In the process of implementing this new browser extension, several improvements will have to be applied to the existing WRS Feedback interface in order to fix some of the problems it has in terms of user interaction. More specifically, the new interface should be less intrusive, more intuitive and optionally more esthetically appealing.

This is an optional change, but it can contribute to a better user experience, which leads to attracting more users and keeping the existing ones.

An overview of the new proposed architecture can be observed in Figure 8: New WRS Architecture.

Local machine Local machine Wikipedia

Web Browser

http://en.wikipedia.org/wiki/Barack_Obama

Internet

Server Server WikiTrust

Services Database

WRS

Figure 8: New WRS Architecture

Notice that we want to preserve the current core functions of the WRS (the ones that are dealing with trust management, trust dynamics etc.) and change only the adjacent components.

Implementing all these changes represent a major swift in the current WRS architecture. A much detailed plan for performing these changes is presented in Design, while in Implementation we take a closer look at the specifics of implementing the changes.

Summary 29

3.2. Summary

In this chapter we have discussed some of the mechanisms WikiTrust is using for building an article rating, which can be perceived as a reputation as it is the result of authors assigning trust in each other’s contributions through their own revisions. We have also looked at the differences between WikiTrust and WRS and how they can be changed in order for the two systems to work together.

In the second part of the chapter we have presented several architecture changes that will be implemented before the cold start problem can be addressed.

Chapter 4