A Domain Specific Language For A Distributed Social

Transcription

A Domain Specic Language For
A Distributed Social Networking
System
Ólafur Tor Yngvason
Kongens Lyngby 2010
IMM-MSC-2010-93
Technical University of Denmark
Informatics and Mathematical Modelling
Building 321, DK-2800 Kongens Lyngby, Denmark
Phone +45 45253351, Fax +45 45882673
[email protected]
www.imm.dtu.dk
IMM-MSC
i
ii
Contents
Contents
1 Introduction
1.1 Privacy concerns . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Lack of exibility . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 This thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Current Social Network Analysis
2.1
2.2
2.3
2.4
Short historical overview . . . . . . . . .
Denition . . . . . . . . . . . . . . . . .
Value of Social Networking Services . .
Current Social Networking Site Analysis
3 SNS Analysis
3.1
3.2
3.3
3.4
Common functionality . . . . .
Current Situation . . . . . . . .
Appeal of the distributed SNS .
Facebook API . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Conceptual Distributed Social Network Design
4.1
4.2
4.3
4.4
4.5
4.6
System . . . . . . . . . . .
Functional Requirements .
Account Management . .
Data Sharing . . . . . . .
Networking . . . . . . . .
Summary . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Design and Languages Used for Prototype
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
2
3
5
5
6
7
8
15
15
17
23
24
25
26
30
40
44
46
49
51
5.1 The specication language . . . . . . . . . . . . . . . . . . . . . . 51
5.2 The Klaim Project . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.3 m4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
iv
CONTENTS
5.4 Java Server Pages . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6 Prototype
6.1
6.2
6.3
6.4
X-Klaim web server engine . . . . . . . . .
Alternative Framework . . . . . . . . . . . .
Web server engine using Java Swing Applet
m4 . . . . . . . . . . . . . . . . . . . . . . .
7 Summary, Conclusions and Future Work
7.1
7.2
7.3
7.4
The Distributed Social Networking System
The Specication Language . . . . . . . . .
Conclusions . . . . . . . . . . . . . . . . . .
Future Work . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
63
63
67
67
70
73
73
74
74
75
A Prototype Tests
77
B User Manual
79
C Sequence Diagrams and Use cases for functionalities.
81
D The private social networking site class diagram
E Code Listings
E.1
E.2
E.3
E.4
E.5
E.6
E.7
E.8
User.xklaim .
Server.xklaim
CompileAll.sh
MakeBlog.m4
GetBlogs.m4
swingJApplet
Server.m4 . .
BlogK.m4 . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
119
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
125
127
131
136
137
143
150
159
160
Chapter
1
Introduction
Social networks are gaining more and more importance in sharing information
with ones peers. They come in many dierent avors, but all of them oer
similar core functionalities, even though sometimes in dierent disguises, and
add-on functionality that may dier between networks.
1.1 Privacy concerns
With users posting all sorts of informations onto social networking services(SNS),
concerns over what happens with this information and who is accessing them
is bound to be an issue. User privacy settings, allowing users to control access
to personal material published on a prole has become a focus area of current
SNSs.
But the fact remains, that SNS providers control all data users put there, such
as demographic information, sent messages or even photos. They are in full
control of using this data for any advertising, marketing or other commercial
purposes they choose to see t. Mostly the data is used for data mining, giving
the user personalized advertisements to increase the value of the advertisements
for both parties. But not all users are comfortable with sharing their usage data
with corporations, or anybody for that matter.
2
Introduction
Another important, and often under-valued risk with these networks, is that the
user hierarchy is at, meaning one can not distinguish between dierent friend
groups, such as co-workers, family, or friends. This leads to often unwanted
information ows.
1.2 Lack of exibility
Most SNSs on the market today oer the same or extremely similar services.
What separates these sites is mostly their user base and not the services oered.
Of course their interest is serving their users to keep them happy, whilst still
satisfying their customers. But users develop their accounts with use, adding
what friends they nd to their friend-lists, posting information and personal
data as well as getting used to using the site.
This makes changing from one site to another a hard task, which means that it
is hard for very big social networking services to serve niche groups, since their
focus is serving the general public with mainstream features. And due to their
size these niche groups are not being satised since they will put up with a lot,
simply because of the fact that their friends are on that site, and that's where
they interact with them.
1.2.1 Photo sharing
An example of a big unsatised niche group is the people who don't like the
quality of photos shared on social networks. Besides the obvious disadvantage
previously mentioned, of SNSs claiming ownership over all photos a user publishes there and are able to use them for whatever purpose they want. Meaning
that users wanting to share photos with their friends, are also sharing the information with a third party that has permission to share it with the rest of the
world.
For the users of social networks, the SNSs are becoming the norm in photo
sharing. This applies not only to photo based social networks such as Flickr.
In general, in SNSs, the user has no control, or in many cases awareness, of the
loss in picture quality when sharing the photo using any of the existing SNSs,
leading to dissatisfaction among the niche people who want to be able to share
their photos in full quality.
1.3 This thesis
3
1.3 This thesis
This thesis describes social networking services an analyses the current market
of social networks, identifying their functionalities, leading to the design of a
distributed social networking system emulating the core functions of the current
social networking service market. To spark the creation of such a distributed
networking system, a domain-specic language that paves the way for users
to create social networking services, while fullling the requirements needed
for participation in the distributed network is designed, and a prototype for it
created.
4
Introduction
Chapter
2
Current Social Network
Analysis
2.1 Short historical overview
With our denition of a social network, social networks rst started popping
up in the beginning of the 21st century. But it has value to investigate shortly
what lead to their development.
As we move into the digital age, the web begins to take a bigger and bigger part
in peoples' need to communicate and socialize with their peers. Social networks
facilitate the environment to fulll those needs.
In the early 1990's Internet rst started to become publicly accessible. The rst
sites that can in the most general sense be described as a social network were
forums, where people could post messages into certain categories and receive
comments.
The big commercial success Match.com, a dating website, was launched in 1995
and in 2009 it had approximately 1,3 million paying customers, reecting over
250m.usd income from sales revenue [3], and over 15 million users.
6
Current Social Network Analysis
In 1997 Jorn Barger coined the term "blog" from the term "web log". Blogs
very quickly gained enormous popularity as a great way for people to express
themselves, their opinions or news from their daily lives.
Throughout the blog boom, people came to realize the value of social networks.
And in the early/mid 2000's social networks such as Friendster, Last.fm, Hi5,
MySpace, Orkut, Facebook and Bebo popped up, capturing the attention of
millions upon millions of users. Being Facebook and its user-base growth, by
far, the most popular and the fastest, respectively.
2.2 Denition
A social network, in its most general sense, is just connections among people. In
real life, your social network is just the people you know, are around you or you
are somehow in contact with. Denotatively, is your direct social environment's
activity.
Sticking to the more practical semantics, computer-science-wise, we would include almost all non-static websites in the concept since they basically just need
to facilitate any kind of communication among users or people. This includes
e-mail servers, blogs, forums, dating websites, torrent sites, any kind of sharing
website such as Youtube and the list goes on. Therefore the term social network
would become nearly meaningless.
A well known article written by Danah m. Boyd and Nicole B. Ellison [1] denes
a social network as a web-based services that allow individuals to
1. Construct a public or semi-public prole within a bounded system.
2. Articulate a list of other users with whom they share a connection.
3. View and traverse their list of connections and those made by others within
the system. The nature and nomenclature of these connections may vary
from site to site.
In our search for an existing denition of what a social network is, we ran into
this very same denition time and time again. The denition seems to all right,
but seems to be aimed at excluding web-sites rather than capturing the term
itself.
2.3 Value of Social Networking Services
7
Firstly, there is no apparent reason for it to be a requirement to allow users
to traverse lists of others, except that it excludes a lot of sites, like forums, for
falling under the denition of "social network".
Secondly the denition does not presume any kind of communication between
the users, except the information shown on the users' prole.
Coming up with a denite denition of what a social network is not easy, but
the aim is to capture as objectively as possible its implications in terms of a
web-based service. A social network is a web-based service that has the following
properties
1. Public or semi-public proles within a bounded system.
2. Find, access and interact with other users and set relationship status with
them.
3. Publish material privately, publicly and semi-publicly with other users.
Obviously a social network can have other functionalities too, but as we dene
those as the core ones, only sites or applications that fulll these requirements
will qualify as a social network. There is no reason why forums, and sites
alike, should not be considered a social network. In the absence of what is
today considered a social networking service, much of its functionalities could
be achieved through the usage of forums. The dierence mainly being that what
are considered social networks oer the standardized user interface that most
social networks share. Most likely since sites may be afraid to overly dierentiate
and risk loosing their users.
2.3 Value of Social Networking Services
In real life, one's social network is restricted by one's physical barriers. A webbased social networking service helps breaking down these barriers, allowing
people to reconnect with lost friends, keep connected with friends physically
located far away and sharing information at once to a large group.
8
2.4 Current Social Networking Site Analysis
In this section, we will briey have a look at which Social Networking sites
are available on the market today, which features they oer as well as their
demographical targets. As we will notice, most social networks have the same
or similar features and their popularity at rst approach seems to be somewhat
coincidental. Meaning that putting the nger in what seems to be the decisive
factor in their success is not so easy. Many factors come to play, such as ease
of usage, privacy, site focus and general approach, application availability, sitename and the list goes on.
But the trend appears to be that the biggest motivation for joining the site is
where they are most likely to nd their friends. For this reason, even though
dierent sites gained popularity in specic regions, people are slowly moving
towards Facebook through international communities and, as Facebook takes
over the Social Networking site scene, it will become more and more dicult for
other commercial sites to compete with it.
2.4.1 Basic Features
All social networks discussed in this chapter t with our denition of a social
network, you can make a prole consisting of picture(s), demographic information and self-description. You can list your friends. You can write testimonials
about your friends and write private messages to other users. All those things
except the private messages, are by default visible on the users prole, but the
user can restrict users from seeing it. Facebook for an example has three levels
of access controls, information can be visible to friends only, friends of friends
or to everyone.
2.4.2 Friendster, www.friendster.com
2.4.2.1 History
Friendster is a social network created in 2002, and set to compete Match.com. It
is based upon the assumption that friends of friends are more likely to be good
dates than strangers [1]. It can be considered the rst really successful social
network, but started loosing its user base in the western world through bad site
focus[1]. Although it remains popular in south-eastern Asia and Indonesia.
9
2.4.2.2 Specialization
Friendster separates itself from most other social networks by oering "Fan
Proles" and free text messages, where public gures can create proles that are
accessible without authentication. The free text messaging service is currently
only available in a few countries in south-eastern Asia and Indonesia. But it
allows users to receive updates from their friends on Friendster via sms'.
Furthermore Friendster oers mobile access and API giving external access to
the site content.
2.4.3 Couch Surng, www.couchsurfing.com
2.4.3.1 History
Couchsurng is the world's largest hospitality exchange network. Users have a
prole sorted mainly by their location in the globe and it is based on trust among
strangers who share their homes and a piece of their culture. Couchsurng was
launched in 2003 but had a slow increase ratio in its early years. In 2006, due
to a major database breakdown, it almost vanished, being relaunched due to
its users' pressure. Today it counts with 2,2 million users in 237 countries and
territories.
Couchsurng stands out from a lot of other social networks for actually enabling
people to meet each other, hence being very easy to sort people very specically
through location almost anywhere in the world, as well as age and language.
2.4.4 LinkedIn, www.linkedin.com
Being a business-oriented social networking site, interaction among LinkedIn's
users is more formal and mostly professional. Launched in May 2003, it counts
with more than 80 million registered users and grows at the rate of one user per
second. [6]
10
LinkedIn is based on a mutual and trusted contact with someone you have a
limited degree of acquaintanceship with. Employers can list jobs and assess
potential candidates, whilst job seekers are able to check the prole of hiring
crew as well as their common network in an attempt for a recommendation,
being also able to bookmark jobs for later applications.
2.4.5 MySpace, www.myspace.com
2.4.5.1 History
MySpace was launched in 2003 and quickly became a huge success. In 2005 it
had become the fth most viewed internet domain in the US, and was sold to
News Corp for the hefty sum of 580 million usd. [2]. For a long time it opposed
to Facebook growth in the US. People get to get in touch with bands, artists and
interpreters from all over the world, as famous and unreachable as they might
be and with other people sharing the same musical taste. It is moreover a mean
for amateur musicians to promote their amateur projects to a larger public.[7]
MySpace terms themselves as a social entertainment network, focusing on the
13-35 year old demographic. It connects its users with the music artists, movies
and videos, having unique joint venture content deals with studios. Users of
my space can really easily nd a network of people sharing common musical
interest.[27]
2.4.6 Last.fm, www.lastfm.com
2.4.6.1 History
Lastfm is an interactive music database site founded in the United Kingdom
in 2002. It has more than 40 million users in 200 countries. However, it has
been target of many controversies. For example the removal of the entire track
preview feature, preventing smaller artists to disseminate their projects.
11
Building up a prole in Lastfm can be an active process, like most of the fore
mentioned networks, by listening to personal music on an Audioscrobbler plugin,
or a passive one, listening to the Lastfm internet radio service, which customizes
a prole automatically. After this is done, Lastfm's main aim is to amalgamate
random users with the same tastes in music, adding new artists and recommendations. This happens either when the user asks to get to know other similar
users, to listen to similar artists or when a common background group is created.
2.4.7 Bebo, www.bebo.com
2.4.7.1 History
Bebo was launched in 2005 by a british couple after they observed the rise of
Friendster and took some general hints from its site structure to apply to their
own networking website. It stands for "Blog Early, Blog Often" and focuses
largely on blogging and sharing music. It is mostly famous in the UK and it
counts with over 36 million users worldwide.[8]
Bebo is an early entry stage social network, oering general social networking
features such as Facebook. It has nice pre-made prole skins as well as 3rd party
applications.
2.4.8 Orkut, www.orkut.com
2.4.8.1 History [9]
Orkut was one of the early sites launched in early 2004. It was a google project
but somehow only managed to gain regional popularity with a vast majority
of its users in India and Brazil. It was also very popular in Iran until it was
blocked by the government in order to avoid rapid messages spread due to
national security reasons. It also goes against Islamic ethics regarding dating
and matching.
12
Apart from common features that are seen in other general social networks, such
as proles with demographic information, photo albums coming with interaction
with friends, blogging and vlogging, orkut allows high management of friends'
hierarchy while enjoying the aforementioned features. Users are able to create
groups of friends with dierent privileges of access to information, such as photo
albums and blog posts. This hierarchy is implemented to imitate the "real life
social network" described in [10].
2.4.9 Flickr, www.flickr.com
2.4.9.1 History, [11]
Flickr is an image and video hosting website created by an American couple,
launched in 2004 and later on bought by the giant Yahoo. It is reported to
host more than 5 billion images nowadays. Flicker's has been kept very low
prole, aiming to be proliferated by mouth to mouth publicity, with no huge
advertisements but with a hip and stylish picture display.
It stands out from most photo-sharing websites by its snazzy sharing features.
Friends can reach pictures much easier by searching and making their own notes
on them, or bloggers can simultaneously post photos on their own blogs and
ickr, for example. However, it is not as easy to navigate as other homologous sites. It has a lot of own terminology and has the deliberate omission of
restraining sharing via e-mail due to lack of potential in their server.
2.4.10 Facebook, www.facebook.com
2.4.10.1 History[12]
Facebook was launched in 2004 by famous Mark Zuckerberg, a Harvard student
at the time, initially as an internal social website within the University. The
adhesion was so auent that in some months it was opened to other faculties,
including Europe, by the end of the year to high schools, one year after to public
13
internet users and today it counts with 500 million users worldwide, being the
most used social network used worldwide. It is general social network, despite
having become famous for extra features like online games and quizzes.
The focus of Facebook has developed severely, to begin with it was mostly
based on 3rd party software/widgets on user's proles. To become a very general
social network, focusing on its "news feed", which is essentially a micro blogging
service. Facebooks most recent development is introducing the Facebook email
service [13].
2.4.11 Twitter
2.4.11.1 History [14]
Twitter was founded in 2006 and is the fastest growing micro-blogging software.
It has foot-printed a neologism in contemporary pop-culture with the term tweet,
a "140 maximum character messages posted on Twitter", following the new verbs
"to google" or "to text". Twitter is a very alternative way of communication,
even for social networks' standards, for being very fast paced. However, its
popularity has been growing astonishingly since the messages are short and
users can divide their attention to even more numerous users and activities.
Being dierent from the majority of social networks, Twitter created some additional features to help people getting used to a new format of communication.
BigTweet, a plugin for your Web browser for instance, is a Twitter tool that
allows the user to instantaneously post a tweet by selecting the text extract
to be quoted and pressing the bigTweet button. Also Tweet Later, a Twitter
management application, accomplish basic twitter tasks like sending welcoming
messages to new friends (called followers) or following followers back (being able
to check their blogging).
14
Chapter
3
SNS Analysis
In this chapter, the functionalities of the current SNSs described in Chapter 2
will be analyzed, leading to a suggestion of a problem along with a solution to
that problem. Often Facebook is given special focus, but in this writer's opinion
such focus is just due to the overwhelming size of Facebook on the SNS scene.
3.1 Common functionality
Almost all current SNSs seem to have the same functionalities. Some variation
exist in for example what information that appear on the prole, and how the
site handles 3rd party software. But some of the most common functionalities
are:
•
Create a prole. Normally contains demographic information and some
•
Upload photo(s). An important factor of networking online is sharing
form of self-description, though details on what kind of self-description it
is may vary.
images, every big SNS allows photo uploading, though the quality of the
photos may vary.
16
SNS Analysis
•
Tag photos. Tagging photos is a great way of increasing relevance of
•
Listing friends. Listing friends was dened as one of the requirements
•
Send private messages to other users. Hardly needs further explain-
•
Write testimonial. Messages to other users visible on their prole are
•
Add applications/widgets to the prole. Most of the bigger SNSs
•
Customize prole appearance. Weather it is pre-made skins, HTML,
•
Access controls. Privacy has become one of the main concerns of SNSs.
•
Create and join special interest groups. Joining groups and creating
•
Post blogs and videos. Posting status updates or videos for your friends
to see is an option most SNSs have.
•
Search for other users or material. How the search engines work and
•
Friend Hierarchy. Most sites have at user hierarchy. All blogs posted
photos. Most but not all sites oer tagging.
of a social networks, so all networks have that functionality. All current
sites also allow traversing the list of friends.
ing. As the purpose of SNSs is communication, all SNSs oer users to
send private messages to each other.
a feature available on most sites. Facebook calls it a "wall", Friendster
calls it a testimonial, we'll stick to that name in this paper, although the
meaning is essentially the same.
have a number of applications available on their site to enhance the user
experience of the SNS. Many have a set of supplied application to select
from, while others oer 3rd parties opportunity to publish their applications on their site. 3rd party applications were to a high degree the source
of Facebooks success.
CSS or any combination there of. Most sites oer some form of customizing prole appearance. Facebook being an/the exception as it oers no
customization of prole looks.
Therefor they all oer some tools to limit the group of people that can
view the prole or contact the user.
events is an excellent way to reach people and organize activities with
friends or others. All sites have some form of functionality for groups or
events.
how eective they are may vary, but all sites have them.
go out to all friends following you, except for Orkut, which lets you split
your friends into groups and post your material visibly only to specic
groups. as explained in Section 2.4.8.
3.2 Current Situation
•
17
Mobile Access. Users are able to access most of the existing popular so-
cial networks through their mobile browsers or smart-phone applications.
As the SNS market looks today, it seems to be that few sites focused on networking spread regionally, which ts with the theory that the main attraction of an
SNS is its user-base. This can be seen with Friendsters popularity in South-east
Asia and Indonesia and Orkuts popularity in India and Brazil. These communities have a large part of their population already using these sites, which drives
other users in that region to use them as well. Not only because of users becoming aware of their existence through other users in the region, but because
they go there because thats where their friends are.
Figure 3.1: Map of highest ranking Social Networks in the world in Oct 2008,
by country [20]
As one can see in Figure 3.1, in October 2008 it is seemingly random which social
network gets popular in each country. The maps shows the highest ranking social
network for each country based on network trac [20].
The map of the world has changed signicantly in the last two years, and it seems
Facebook is slowly taking over, as it's users have gone from being 100million
to 500million since then [21]. Despite Facebooks recent popularity, some sites
have managed to retain their popularity in their region, such as Friendster in
Indonesia and Orkut in India and Brazil. Other sites have changed their focus
from being general SNSs to becoming niche sites. An example of this is MySpace
18
SNS Analysis
which has according to its CEO Michael Jones become a social entertainment
website instead of an SNS [27], and is no longer contending with Facebook in
the race for users on the SNS scene.
There are more niche sites which aim to serve smaller groups. Other examples of
these sites are BlackPlanet, CouchSurng and several other sites with millions of
users. These sites appeal to niche groups or oer some additional functionality
that other more general SNSs fail to oer. Many of its users also have an account
on a more general site such as Facebook, where they interact with their other
friends in a more general way. Yet others are unsatised with all existing SNSs
and the market needs to bend further to meet their needs. The issue remains,
Figure 3.2: User satisfaction venn diagram
the SNS market is inexible since the usage of a site is based on the usage of
others. And it's hard for users to simultaneously switch to a new service in spite
of that new service oered being better than the previous one. The niche sites
on the market manage to cover some of the niche groups but many more users
are unsatised.
3.2.1 What could be improved?
If social networks could interact with each other, this would mean that all users
on all sites could be treated as one big user base, making it possible for users
to choose the SNS that best meets his needs or wishes and then interact from
there with other users on other SNSs.
If it could be made even easier to create a social network, easy enough for a
common user, that added with the fact that all previous users of a social network
being in a big user base, would make it extremely much easier for social networks
to enter and leave the SNS market, since the user base is the same for every
site.
19
If instead of being able to share only photos, users could share any data they
see t peer to peer.
3.2.2 How could this be done?
Creating a distributed social networking system, where the SNSs let users communicate with other users on dierent sites through their service. This needs a
method of sharing data, as well as agreeing on what data needs to be shared. It
would be a colossal task to get all social networking sites to work together, but
some of them, such as Facebook and Twitter, already oer API that gives access
to almost any of the information and functionalities the sites have to oer. The
Facebook API will be discussed later.
The solution is to design a distributed social networking system, that uses the
API of existing SNSs to allow users to view and communicate with friends on
existing SNSs, and combining it with paving the way for the creation of SNSs
on this distributed network.
This could be done by creating a specication language that allows people to
create their own SNS fairly easily. Making a SNS creation possible, even for
private people. Two ways should be considered when designing a language for
making these private social networking systems (PSNS).
1. Single person social networking site (SPSNS) Where a user would
use the specication language to create a social network for only himself.
2. Small social networking service (SSNS) A social network, aimed at
being small in scale to allow small groups to run a social networking service
together.
Ideally both ways could be implemented and communicate with each other.
Soon we will have a look at, and analyze these two dierent kinds of SNSs. But
it is clear that having these kinds of networks, allowing as much exibility for
the site creator plus the benet of scale would make it much easier for social
networks to cater to the needs and desires of all dierent sorts of niche groups.
And it would also give the social networking scene leeway to develop even faster
in any direction based on the shared functionality of all the sites.
Another possible advantage could be, that with the sites creators' permission
these sites could be used for other distributed applications such as distributed
computing.
20
SNS Analysis
A disadvantage to this distributed system described is, that a big part of the
social networking experience such as browsing photos, proles, friendlists could
be compromised, or at least encumbered since information would have to pass
through more channels.
Another thing is that the shared functionalities between sites would possibly be
taken down to a basic level to meet the functionality or aimed for functionality
of as many sites as possible.
Yet another thing to be considered is that with the running of a service such as a
social network belonging to big commercial corporations, in-spite of signicant
hacker interest in manipulating the site. The corporations can make sure that
enormous amounts of resources go into updating and maintaining security and
xing bugs.
To add on that, in a distributed social networking system, such as the one
being presented, information is being shared from multiple dierent sources,
new sources coming and going, giving attackers a number of additional entry
points, and this is likely to lead to security problems. And to even add on top
of that updating the various sites on the network is not necessarily an easy task.
So should such a system be released, security will become a dicult task to
handle.
Security should also be of the utmost importance because a PSNS on the network
is sharing its users information with the rest of the network, believing it is in full
control of its access. Thus the framework needs to be trusted. Breach of such
trust will have dire consequences. And as silly as it sounds, the importance of
the trust gives script kiddies and terrorist hackers even more incentive to attack
the site, making security even more important.
Yet another thing to be considered is that even though this API exists for sites
such as Facebook and Twitter, the distributed social networking system is fairly
reliant on it, at least to begin with. Thus if these existing sites change the API
or decide to stop oering it, it could have detrimental eects on the distributed
social networking system.
3.2.3 Single Person Social Networking Site
As said, this would be a site where a user would use the specication language
to create a social network for only himself.
21
3.2.3.1 Advantages
A person controlling his own SPSNS, would mean that he himself is the administrator of his own data and assuming security holds, he would be in total control
it. He would also be in complete control of what his site could do (beside the
shared functionality of all SNSs on the distributed social networking system).
3.2.3.2 Disadvantages
Obviously not all users will resort to these private sites, for several reasons. Not
to the least the lack of technical knowledge, cost and ease of use. And since
these sites would have small or very small user data bases, they would be based
on interaction with other social networks or similar sites, and this interaction
would form the social network.
Even with a specication language that would ease the creation of a SPSNS
signicantly, customization and administration would still require signicant
eort and skill. Especially if one would wish to customize the site to a high
degree to meet his exact needs and wishes.
Extremely many networks would exist, spreading data needed to be accessed
by a user of a social network widely over the internet, making operations work
slower.
3.2.4 Small, private social networking system
These small sites aimed at allowing smaller groups to run their SNS together,
such as a family, a workplace or a school faculty.
3.2.4.1 Advantages
Most people are a part of one group or another that would be capable of creating
and hosting such a site. That would make it easy for mainstream users to nd
one network or another to join and enjoy its benets. No unknown party is in
control of your information, and the chances of your data being used for any
marketing or commercial reason would be signicantly decreased as it could
even be illegal.
22
SNS Analysis
3.2.4.2 Disadvantages
Even though no unknown party is in control of your information, it might be
considered worse that a known party is controlling it, even with implemented
user hierarchy and great access controls. The site controller could still view all
of the users' data, and it is easy to see circumstances where a user would prefer
not to let a site controller have access to his data, especially if it is a family
member, a co-worker or even boss.
This could possibly be solved with a system of access controls, or yet another
layer of distribution. One such solution could be to have an application on the
user-side, where he would have to access the social networking service through.
This application would come from a trusted third party, and would control the
data handling and communication between the user and the social network.
Allowing the user for example to categorize his information, locally on his computer and then send them peer to peer to users with permission to access them.
This would bring about the problem of relying on the user's internet connection
for sharing the data making his information not being accessible all the time and
encumber the users connection itself. But considering the speed of development,
who knows if users will still be using hard disks in the future, and not just relying
completely or almost completely on online storage spaces.
3.2.5 The Global Server
A problem with this system is that the private networks do not necessarily
know of the existence of the other private networks, where they are and who
is on them. They can start with the knowledge of a number of existing SNSs,
but some kind of system where new sites could publish their location, existence,
friendlists etc. could be useful. This system would also be essential for updating
the system software in order to update the shared functionalities.
One solution to this problem could be to have a specialized server for these
private networks. All new private networks would register their location as well
as other specic information about the network on this global server. Besides the
before mentioned functionalities of the global server, it could also co-ordinate
and generally help communication between networks, enforce standardization
in shared functionalities and facilitate system updates. This will be further
described in the following chapters.
3.3 Appeal of the distributed SNS
23
3.2.6 Ideal Social networking scene presented
The ideal SNS scene displayed in gure 3.3 displays visually the system being
described. A number of PSNSs communicating between themselves and a GS,
as well as communicating with the other CSNSs to combine the user bases of
all the networks.
Figure 3.3: Social networking scene with distributed SNSs
3.3 Appeal of the distributed SNS
The biggest appeal will probably be for smaller groups such as work-places,
family or friend groups. Where someone keeps a small PSNS running. With
the addition of a capability le sharing system as discussed in [26]. Allowing
people to access additional storage space through virtual storage spaces as will
be discussed later.
The beauty of creating this kind of a specication language paving the way
24
SNS Analysis
for anyone making their own PSNSs on a distributed social network. Is that
anyone will have the oppertunity to put their creativity to the test, nd what
what people desire and need and create the site servicing those needs. Designing
a site who it appeals the most to can be left up to these designers of the PSNSs,
a form of distributed creativity. Let the market decide, even though in the initial
design it is intended for those smaller groups.
3.4 Facebook API
As Facebook is the SNS with by far the biggest user base and is showing no sign
of stagnating in it's growth, the API oered by Facebook is the most important
for the success of a distributed social network such as the one discussed in this
thesis. Facebooks API consists of its open graph protocol [24], social plugins
[25], authentication and authorization [22]. Social plugins will not be discussed
here since they are not relevant since they merely add features to a web page
through HTML. Taking advantage of that is the task of the PSNS developer, if
he wishes so.
3.4.1 Authentication and authorization [22]
Access to essentially all of what has become the core features of Facebook can be
acquired through its API, even access to user's photos and management of his
pages. The user will need to authorize the application using the API explicitly
to access these features. Without explicit authorization the application can have
access to basic prole information, such as friends and prole pictures.
3.4.2 Graph API [23]
The Graph API is a new term, and is only oered by Facebook. It uniformly
represents objects (Users, pages, events,groups, applications, status messages,
photos, photo albums, prole pictures, videos, notes and check-ins). And their
connections (Friends, news feed, prole feed, likes, movies, books, notes, photo
tags, photo albums, video tags, video uploads, events, groups and check-ins).
Coupled with authentication FBGraph can allow the distributed SNS access to
any of users information it needs to transfer/duplicate his account over to a new
PSNS.
Chapter
4
Conceptual Distributed
Social Network Design
In this chapter the design of a distributed social networking system will be
explained, along with most of the necessary functionalities needed for such a
system. These functionalities are split into functional and non-functional requirements.
The main challenge of designing a system like this, is making it as customizable as possible without it losing much simplicity or functionality. Every single
operation should be customizable without losing the inter-mutually shared functionality of social networks. Furthermore, an API could be made so that any
social network wanting to participate on the distributed social networking system could do so.
An example of this could be that you may want to customize blogs in a way that
one SNS has a maximum length of the blog is longer than is longer than that of
any other SNS, and the blog has a subject. To make the operation inter-mutual
and still allowing customization, all SNSs could always send data based on full
functionality (subject, blog). This would allow the SNSs to store the full blogs,
and then implement functionality allowing the users to read the rest of the blog
in case it came from a network with less length restriction on the blog.
26
Conceptual Distributed Social Network Design
Alternatively, a centralized server (such as the global server from Section 3.2.5)
could be used to distribute the blogs, to make sure that each SNS gets the
information they want (the server could cut o the subject and part of the blog
text body).
In this chapter, the functionalities of a distributed social networking system are
designed along with appropriate use case tables, sequence diagrams and class
diagrams. Use case tables and sequence diagrams for the functional requirements
of the system have been included in this chapter. The rest may be found in
Appendix C.
In the class diagrams presented in this chapter, classes contain properties and
operations needed for communication between PSNSs, users, CSNSs and the
GS.
4.1 System
As suggested in Chapter 3, the suggested distributed social networking system
design consists of a number of privately created social networking sites (PSNS)
and a global server (GS) co-ordinating the network. The PSNSs communicate
between themselves and the GS, as described later, using shared functionalities.
The communication with existing commercial social networking sites, such as
Facebook, occurs through their API, and to the extent the API allows. This
gives the PSNSs access to receive and post blogs, get friendlists and more, as
described in Section 3.4.
Each PSNS consists of a database, a user interface (UI) and a web server engine
as shown in Figure 4.1 The specication language designed in this thesis includes
automatic generation of all of these three parts of a PSNS.
The GS is the only one that should be able to edit/update the web server
engine and the database to keep standardization and eectiveness of shared
functionalities, but the creator/administrator of the PSNS can edit the UI to
add additional functionality as he pleases.
The external resources that communicate with the UI in Figure 4.1 represent any
3rd party application or other customization the creator of the PSNS may want
to use. This could also be a database managed by the creator/administrator of
the PSNS for other functionalities of the site.
When a new PSNS is instantiated, it registers itself with the GS. The GS stores
4.1 System
27
Figure 4.1: PSNS parts and related parties
various data, such as friendlists of all users as well as information about all
groups and events. It makes sure that all friendlists are updated correctly.
When a new user with another account on an existing commercial social networking site (CSNS) is added, the PSNS gets his entire friendlist from that site
and sends it to GS. To get this information from the CSNSs, the operation must
be explicitly authorized by the user, as explained in Section 3.4.1. The GS then
updates the friendlists of all the users that are on his CSNS friendlist and also
have a PSNS account, and sends updates to the corresponding PSNS.
Making a design like this is a long iterative process, one repeatedly discovers
new methods and functionalities that need to be included, adds them and then,
more often than not, needs to go back to rethinking many others. Therefore,
the list of methods and functions is not complete, but can be considered close
enough to a primitive design of a fully working distributed social networking
system. Some of the non-included functions are:
28
• Add/Conrm Friend on CSNS
• Join group/event on CSNS
• Modify access of permission group
• Mobile access support
4.1.1 Private Social Networking Services (PSNS)
The design of the PSNS is aimed at making it easy for small to medium groups
to create and run a service. Each account is partitioned a set amount of space,
and groups and events can be created on that.
Ideally this system would mainly be the basic building blocks for the distributed
networking system. The PSNSs would have to add as much customization on
top as possible to create a diverse a ora of PSNSs on the market, and to make
the focus of the distributed network the shared core functionalities. But to make
it as easy as possible for anyone to make a PSNS, this design will include all
or nearly all important features, in-spite of what could possibly be considered a
lack of necessity.
Each PSNS communicates with other CSNSs when user accounts are created, or
when new CSNS accounts are added to a users account, as well as communicating
with all other PSNSs and the GS. This means that operations for communicating
with all those parties need to be implemented.
4.1.1.1 PSNS Class diagram
The PSNS class diagram, as seen in Figure 4.2, portrays a design for a private
social network. It does not contain operations, as it would become too large. A
full class diagram can be seen in Appendix D. It goes together with the design
for the GS as later described in Section 4.1.2.
The functionalities later described in this chapter and how they are used clarify
the operations in the class diagram.
The functionalities later described in this chapter and how they are used clarify
the operations in the class diagram. Similar to Dropbox, the system design
should have a capability le name system, as described in [26]. However, the
class diagram only contains classes for handling photos and information related
to them.
4.1 System
Figure 4.2: Class diagram for a private social networking service
29
30
4.1.2 The Global Server (GS)
As said, the server we call the GS is a specialized server for the PSNSs. All
new private networks will have to register their location as well as other specic
information about the network on this global server. It also co-ordinates and
generally enables communication between networks.
This server would store the locations of all private networks, all users and their
friendlists as well, as well as information about groups and events. When the
private network adds a new user, it gets the user's friendlist from his other
existing network(s) and sends it to the server. The server then sends back
information about which private network(s) the friends of that user can be
found on, as well as what other identities that user is sharing so that he can
send information directly to that network.
All private networks would have to register with this server. It could send
information on the location of other PSNSs to PSNSs. The locations of other
PSNSs are also stored under every PersonReference in the friendlists of all users
on the PSNS. Perhaps, it would be enough to be kept only there, meaning that
a PSNS would only have the location of other PSNSs where a user on that PSNS
has friends. Seen as the PSNS uses the locations of its peers when its users use
the search engine (As it will be explained later), either the searches have to go
through the GS, or the PSNSs have to know the locations of their peers.
4.1.2.1 GS class diagram
The GS class diagram as seen in Figure 4.3, portrays a design for a global
server. It goes together with the design for PSNSs as described earlier. The
functionalities later described in this chapter help clarify the operations in this
class diagram and how they are used. It displays classes for user, group, event
and friendlist handling, which are the classes needed for the functionalities designed in this thesis. Other features of the GS, such as updating applications
on the PSNSs, are not included since they are not strictly a feature of a running
distributed SNS.
4.2 Functional Requirements
Some of the functional requirements are debatable about, as to whether or not
it is necessary to count them among functional requirements. But in accordance
31
Figure 4.3: Class diagram for the global server
with our denition of a social networking system in Section 2.2, the following
have been chosen as functional requirements:
•
Create an Account It is easy to imagine a site where the user does not
create his own account. And this is something that should be addressed in
the specications of the PSNS during its creation. Some form of accounts
are necessary, and they must be created somehow, so it is fair to assume
that even if a user is not creating his own account, then someone else is.
32
•
Add Friend As with creating an account, it is easy to imagine a site where
•
Send Message Some form of communication is needed for the system to
•
Blog Same as with sending private messages, one can imagine a social
•
Login/out Logging in and out needs no further explanation, it is some-
the user himself is not able to choose his friends (a system where everyone
is friends with everyone for example). But again it's fair to assume that
some form of friendships should be designed, and some form of customizing
friendlists should exist. Adding a friend is essential for that.
be dened as a SNS, whether it is simply a blog feature or a mail system.
Sending private messages is considered among functional requirements of
a SNS.
networking system without the blog feature, but it is the only functional
requirement that separates this system from a mail server should only the
functional requirements be implemented.
thing that PSNS creators or administrators could perhaps be allowed to
fully control. But having the GS in charge of login mechanisms would
bring more security since compromised PSNSs could lead to compromising the network. Amateur users are more likely to congure an unsafe
login mechanism. The same happens with the current CSNS, depending
on the level of their wanted integration, safe login mechanisms for their
API should be designed.
Since the functional requirements are mainly chosen for the site to be considered
a social networking site according to the denition in Section 2.2, a distributed
social networking system would be considered quite incomplete if these functionalities were the only shared ones. Thus the PSNS on the network should be
identied given their level of shared functionality services.
An example could be, a social network having only the functional requirements
being labeled as a "basic service" PSNS, a PSNS having all the functionalities
of Facebook being labeled as having "general service". And a PSNS oering all
shared functionality made available by the specication language be labeled as
a "full service".
4.2.1 Create Account
Creating an account involves the PSNS, where the account is being created,
the GS, a mail server of the user creating the account, a number of alternative
CSNSs, as well as all PSNS' that have accounts of users that are also on the
friendlist of the user creating the account on his other CSNS accounts.
33
The user sends the appropriate information to the PSNS when he creates an
account (user name, password, email address, prole information, login information for any alternative CSNS (if applicable)). The PSNS then checks if the
email address sent is in use by another user at that PSNS, and, if not, it sends
a verication email to that email address.
Once the owner has veried his address, the PSNS uses any CSNS login information given, to get the users friendlists o that CSNS and sends them to GS.
The GS then checks if the users friends have also registered for this or another
PSNS on the distributed network. If so, it updates the friendlists of those user's,
associating the users CSNS address with their friendlists, sending their PSNSs
an update, as well as associating the user's friendlist with his friends existing
account.
Use Case 1
Summary
Preconditions
Basic Scenario
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Alternate Path
2a.
.1
.2
6a.
.1
.2
Create Account
User wanting to create a prole on a private network. He
needs to be registered with the GS. And he may need to
get external information for other CSNS's and then register
them with the GS
User has access to PSNS and GS is online
Action
User submits name, password and email.
PSNS server checks database if email is registered
Verication email sent to email address
User veries email address, sending conrmation to PSNS
User enters login information for any other CSNS
PSNS gets friendlist at CSNS
PSNS registers user with his friendlist at GS
GS compares email from CSNS with other peoples
friendlists
GS associates new email address of with existing email address in friendlists
GS sends updates to PSNSs where information has been
changed.
Email already registered
PSNS sends error message to user.
Prole creation process ends
User has no login at other CSNS
PSNS registers user at GS
Process ends.
34
Figure 4.4: Sequence diagram for creating an account
35
4.2.1.1 Notes
The design for creating an account assumes that a user has only a single alternative CSNS account for simplication . No method is created for handling additional alternative accounts or allowing users to congure alternative accounts
at a later date. Thus it assumes that user is willing to submit this information when he makes his account. The user might not be willing to submit such
information immediately at account creation for several reasons:
1. He does not have an account already, but creates it later. Many
users create accounts on several networks to try them out and see what
they have to oer, but never use them until much later. By that time
much may have changed, and he may have new accounts he would like to
associate with his account on the distributed SNS.
2. He forgets or makes a mistake. The PSNS gets the CSNS information
after the account has been created. Thus a mistake like f.ex. a typing error
or mistaken password would result in failed authentication.
He may be in a hurry, just creating the account to try out the site, not
bothering with giving information about his alternative accounts right o
the bat.
3. He does not want to share his information on the network. Reasons for a users unwillingness to share his information on a social network
(or in this case migrate, information between social networks) can be several. One such reasons could be that he wants to learn how to manage the
access controls on the new SNS before he migrates the information.
4. He does not trust the network security. It does not take a big breech
in security to cause a great deal distrust from users. Users are often very
careful about their information and have every reason to be.
All the reasons counted above give full cause for designing a mechanism to
modify alternative accounts and to update the information from them.
User verication in steps 1. - 5. should also be customizable by the PSNS site
creator or administrator, to be able to control admittance requirements.
4.2.2 Add Friend
Adding a friend simply sends the PSNS of the target friend a friend request.
PSNS then checks if the adder is on the block list of the added. If not, the
36
notication is saved on the prole of the user being added.
Figure 4.5: Sequence diagram for adding a friend
Use Case 2
Summary
Precondition
Basic Scenario
1.
2.
3.
4.
Alternate Path
3a.
.1
Add Friend
Adding a friend is simply a request that is sent to the added,
no changes will be made to friendlist until conrmed
User is already viewing the subject so he knows his location
Action
User requests to add another User
Requester sends a friendship request to the requesteds
PSNS
Requesteds PSNS checks if requester is on requesteds
Blocked list
Requested requested for conrmation
User is on subjects blocked list
Terminate sending
4.2.2.1 Notes
The user who tries to add someone who previously blocked him, does not get a
message informing him about his message request being blocked. The function
of a blockedlist is pretty self explanatory, people on user's blockedlist cannot
communicate with that user.
37
Adding a friend on CSNSs should also be possible on some CSNSs such as
Facebook. It is not included in this design, but it would be one of the rst
things to be added if this design would be fully implemented.
4.2.3 Send Message
Sending a message works exactly in the same way as adding a friend, except
that instead of saving a notication, it saves a message. The dierence only
being the slight dierence on the sent content data (message and subject instead
of notication reason). Sending a message to friends on CSNSs is possible
too on some CSNSs. With Facebook API this can be done without explicit
authorization.
Figure 4.6: Sequence diagram for sending a message
38
Use Case 3
Summary
Preconditions
Basic Scenario
1.
2.
3.
4.
Alternate Path
2a.
.1
3a.
.1
Send Message
Sending another user on any network a private message
User is viewing subject so he already knows his location
Action
User submits a message to send to a subject
Users PSNS sends the message to subjects PSNS
Subjects PSNS checks if User is on subjects blocked list
Message is committed to subjects inbox
Subject is on a CSNS.
Message is sent as an email
Terminate sending
4.2.3.1 Notes
Strictly speaking, sending a message does not need to be a functional requirement according to the denition made in Section 2.2, but a form of communicating is needed according to the denition. Sending messages to other users is
a basic feature no SNS should/could be without and is therefore included here
in the functional requirements.
4.2.4 Blog
The implementation of blogging is quite important since it is the most used
feature of social networks. There are many dierent ways to implement blogging
but in this design, blogs are stored on the accounts of the users that can read
them, to make them accessible faster.
When a blogger posts a blog, the blog is sent to all PSNSs where that user has
friends as well as all CSNSs, where that user has accounts, and the CSNSs oer
API for blogging such as Facebook does through its mini-blogging feature called
"NewsFeed".
The receiving PSNS checks if the blogger is on the receiving users blockedlist or
hidelist before it commits the blog to.
39
Figure 4.7: Sequence diagram for blogging
Use Case 4
Summary
Preconditions
Basic Scenario
1.
2.
3.
Notes
Blog
Blog is general term for what can be called a tweet on
twitter and news feed on Facebook. It is basicly a text
message visable to all users who are following you. These
will be posted on the CSNS as well as PSNS' but PSNS will
remove any repeated blogs
Action
User posts a message for his blog
PSNS, sends the message to all SNS the user is part of
PSNS goes through users list and sends the message to all
PSNSs where user has friends
4.2.4.1 Notes
To hide a user is only to block his blogs, f.ex. if that user is the friend of the
hider, but usually blogs in a dierent language and the hider does not want to
be bothered with the blogs.
40
4.3 Account Management
In this section some of the non-functionally required operations dealing with a
users account will be briey described. Used case tables, as well as sequence
diagrams for all of them, may be found in appendix.
4.3.1 Modify User Information
To modify one's account information, a user simply re-sends/updates all account
information and thus the modied ones will be included in the modication.
4.3.1.1 Notes
Account information to be updated is only username, password and information
strings. The information string can of course be as long as needed and contain
all user information. What is mostly missing here is a prole photo, but if
photos in photo albums/ data sharing had a unique identier, this identier
could be included in the information string.
4.3.2 Create Group/Event
Events and groups are very similar, the only dierence is that events have a time
and date. They both have a creator and a list of administrators and participants.
Those two groups have dierent access, and those accesses are set originally by
the creator and then depending on how the privileges are set. The group and
event are saved on the creator's own space on his PSNS.
Basic information about groups and events are also saved on the GS to aid
searching.
4.3.2.1 Notes
Actually having basic information about groups and events isn't necessary, but
in this implementation it is included to make it possible to have a search option
where you can search for groups, events and people without searching at all
41
existing PSNS, as the number of PSNSs increased, the network trac due to
search requests would grow exponentially.
4.3.3 Join Group/Event
Groups and events can be open for all users, password protected or require
administrator conrmation. When a user requests to join group, a password is
always sent along with the request (it can be an empty string). If the group
is open, the user is simply added directly on participants list, if it is password
protected the password sent is compared with the password required and if it
requires conrmation a "joinRequest" is saved on the group and only users with
high enough privileges can accept such a request.
4.3.4 Group/Event Invitation
Similarly to adding a friend, after checking the blockedlist, a group or event
invitation is saved on a users account as a notication. When conrmed the
group or account is added on the user's group or account list and the user is
added on the groups or events participant list.
4.3.4.1 Notes
One can think of more options for groups or events. For example the new
Facebook group system where users are simply added to a group without any
conrmation required. But that option is not included in this design since such
a design is considered inferior. It is so since users do not want to be aliated
with all groups they get invited to. However, any variation in design should be
considered for designing customization options.
4.3.5 Conrm Request
When a friendship, group or event request is conrmed, both the adder and the
added are added to the the corresponding friendlists of the other.
42
4.3.5.1 Notes
This should happen not only on their PSNSs but also on any CSNS account they
might have, where API for conrming friends is oered. But just like adding a
friend on a CSNS isn't included in this design, conrming them is not either.
4.3.6 Modify Friend Information
Friend information consists of his name, location and email pertaining to the
PersonReference class, alternative account info from the Friend class, permission
group and degree of following in the FriendFull class. FriendFull objects are then
stored in the friendlist. The modiable information with "modifyFriend" is the
information in the Friend class and subclasses. This information is modied by
resending all the information.
4.3.6.1 Notes
Users can set permission for dierent groups through the permission group variable. This means that he could make a permission group called "family" which
would have read/write permission to some family photos. Whereas the permission group "friends" would not have. But how the PSNS handles permission
groups has not been included in the design, nor how the user controls which
permissions a permission group has.
4.3.7 Blocking/Hiding Users
Being able to block/hide or otherwise control incoming information is very important for the success of a social networking site. The purpose of blocking is
to prevent communication from another user entirely. The purpose of hiding is
if you do not want to remove a user from your friends or block him, but you
may still not want to read his blogs and see his pictures all the time, and still
wanting them to be able to see your blogs and photos.
Blocking, hiding, un-blocking or un-hiding a user does not require any conrmation, the user is simply placed on or removed from the corresponding list.
43
4.3.7.1 Notes
Blocked or hidden users should never be notied that they are being blocked,
hidden, un-blocked or un-hidden.
4.3.8 Withdrawing information
A user may want to remove a prole, leave a group/event or remove a photo,
friend or blog. Simple versions of these methods have been included in this
design and may be found in the appendix.
Removing blogs can be slightly problematic since they are saved on all accounts
that were friends with the blogger at the time of the blogging. Since the friendlist
may have changed not all blogs may have been removed. Even so, one could
implement an operation for removing a blog where the blogs would be removed
based on the current friendlist, or having a form of logging the friendlist and
then removing the blogs of a subject based on when the friendship was removed,
the last of which probably being the easiest.
But as it is with speaking, once words leave your mouth someone might always
remember. The blog removal in this design only removes or attempts to remove
your blog from all users currently on the removers friendlist. A copy of the blog
could exist in multiple dierent places, such as search engines or disconnected
PSNSs. An improved blog removal mechanism could be added later but is likely
to be incomplete and considered unnecessary at this point.
Removing a prole simply removes all users data (including blogs if blog removal
mechanism is implemented), This data is and should be unrecoverable, since the
reason a person removes his account, as opposed to just staying inactive, is that
he wants to get rid of everything connected with his account. Removal is sent
to GS since user needs to be removed o all his friends' friendlists.
4.3.8.1 Notes
Methods for removing information are very repetitive and in theory quite unnecessary for achieving a working SNS. Therefor, discussing them is not done
in detail here.
44
4.4 Data Sharing
As discussed in Chapters 2 and 3, most SNSs give you the ability to upload
photos. For that they have various dierent applications but focus on photo
and video sharing. To make the PSNSs as wide a range of services as possible,
it could be built upon a complete le sharing system, the PSNSs then in their
design or specications can dene what data they would like to show and how.
For a user sharing photos and other data, a system such as Dropbox oers,
or a capability le system as is described and designed in [26] could be used,
where les are shared using a virtual hard disk, although it would need to be
implemented on all platforms, since the implementation presented in [26] is only
for Linux. As well as some form of partitioning to allocate a certain amount of
space to each user.
But since the les should ideally also be accessible in a browser as this is how
all social networks function, we implement methods for managing photos which
are sucient for imitating all current SNSs, the capability le system only being
a very useful addition, and especially applicable for smaller PSNSs.
4.4.1 Photo Albums
An photo album is an item that can contain pictures. The album functions as
a folder on the users virtual hard drive, two albums belonging to the same user
can not have the same name. Albums can be created and removed just like any
folder and methods for doing so through a browser have been included in this
design. But in the virtual space, only the owner of the virtual space can create
or remove albums in his space.
4.4.1.1 Notes
Inside this virtual space, albums should be identied by the user as photo albums
to create a photo album object and treat them as such when viewing them in a
browser. However, little features for this virtual space are implemented in this
thesis.
4.4 Data Sharing
45
4.4.2 Photo management
All SNSs investigated in chapter 2 had a size limit on photos, their own compression etc. In this system such functionality should be controllable in the
specications, thus the PSNS rst checks the size of the photo/le being uploaded, calculates if it will t in users free space and then compresses the photo
if needed/oered.
Each photo is saved along with a smaller thumbnail of that photo to be used
for other users browsing the album.
Only the owner can remove his photos. In the case of group/events, it depends
on access privileges. And these methods have been included.
4.4.2.1 Notes
Each photo object belongs to an album and contains tags, comments, taggedPeople, ags, description, name and a thumbnail. Therefore folders in the virtual
space should be dened as photo albums, and only contain photos so that they
can be added as a photo object and given this additional information for being
better viewable in a browser.
4.4.3 Browse photos
When a user browses a photo album in a web browser, he gets only the thumbnails of photos in that album, as well as a link to view the rest of the information
about the photo and the album information.
To view a full size photo, the owner of the photo should be able to entirely
control the view-ability save for the fact that users tagged in a photo should
always have viewing rights. In this design, the access to photos is done through
a permission group variable in owners friendlist.
4.4.3.1 Notes
How the thumbnails are sent has not been included in the design. As it is
already implemented in [26] and only needs to be combined with the specication
language.
46
4.5 Networking
Interacting with other users is the main purpose of social networks. The interactions with other user that have been designed and are not in functional
requirements or have to do with le sharing are described.
4.5.1 Tagging
Tagging photos is an excellent way to increase the eectiveness of photo browsing and improve the social networking experience through giving photos added
relevance when browsing since relevant photos become easier to nd and photos
become easier to analyze.
When a photo is tagged, the tagging request is sent to the PSNS where the
photo is located. Then if the user has privileges enough, the tag is saved. When
a photo has been successfully tagged, the subject, the photo owner and friends
of the tagged subject are notied of the tagging. The tagged subject is then
given viewing and tagging privileges to that photo if he hasn't already.
Who has un-tagging rights could also be specied in the specications, but
owner and tagged should always have un-tagging rights.
4.5.1.1 Notes
Tagging is saved in photo object and sent to users when they seek to view the
full size photo.
4.5.2 Search
A search engine needs to search a lot of material on dierent places. To make
it fast, the GS could keep a copy of some of the information most commonly
searched for, to decrease network trac between PSNSs. This is chosen to be
users, events and groups in this design. This is also done for being independent
on replies from PSNSs in case they are oine.
For a full search, the search has to take place on the PSNS where the search
is made as well as all other PSNSs. The search engine searches rst the PSNS
4.5 Networking
47
where the search is made, then the GS and nally all other PSNS. Results
appear in the order they are received.
4.5.2.1 Notes
As mentioned in Section 4.3.2, with the increasing size of the distributed networking system. Not only the amounts of searches done per time unit, but also
the amount of places where the search needs to be executed in case of a full
search will increase the network trac exponentially. However, one solution to
this problem could be to meet this exponentially increasing network trac by
making full searches only on the users PSNS, the GS and all PSNSs where the
user has friends.
4.5.3 View Prole
Viewing a prole of a person on another PSNS, standardized information is
sent to the home PSNS of the user to be displayed in the way the home PSNS
displays websites. A request is simply sent to the home PSNS of the prole
being requested to view. Permissions are checked and appropriate information
then sent to the user through the users PSNS.
4.5.3.1 Notes
This information sent with the prole request should be standardized as much
as possible with the information oered by the API of existing CSNSs.
4.5.4 Modify Event or Group Privileges
Group and event privileges are a bit dierent than user account privileges. This
can be a design choice, but in this design, we will apply role based access controls
with three levels of access: Creator, administrator and participant. Creator
will have full access to everything in the group or event and all participants
and administrators will have their permissions set separately as a group. The
permissions are fully customizable so, in theory, there is nothing stopping a
participant to have access to things an administrator does not have access to.
48
4.5.4.1 Notes
Nothing stops groups from having permissions congured in the same way a
user account does. However, this method is a simplication to ease usability.
4.5.5 Write Testimonial
Writing a Testimonial is a completely unnecessary addition and could be controlled in the specications. They are very similar to blogs, except they are
placed on the blog of the user who the testimonial is written to and not the
writer's blog. The testimonial is sent to the GS to nd which friends are mutual
between the writer and the users whose blog the testimonial is written on. Then,
the GS noties those mutual friends, as well as any user tagged or referred to
in the testimonial.
4.5.5.1 Notes
Inspite of being unnecessary, having the testimonial option is available at almost
all current SNSs, and was thus included in this design since some people might
miss it. It is a dierent variation of blogging as it is basically blogging on another
person's blog. The dierence being in who gets it sent to their prole.
4.5.6 Comment
Comments are saved on the item where they apply, to comment a user must not
be on the blockedlist of the owner of the item. The comment is sent through
the GS since it needs to be saved along with the item in every place where the
item is saved.
Comments can be applied to both blogs and photos. When a blog is removed,
the comment is removed with it since it "belongs" to the blog.
4.5.7 Reply to Message
Replying to a message is exactly the same as sending a message except that the
receiver and the message subject is pre-decided.
4.6 Summary
49
4.5.7.1 Notes
The sequence diagram and use case table for sending a message also applies for
replying to a message.
4.5.8 Flagging
Flagging is saved as a string, it can either be used to report oensive material
or to express xed opinions in a countable way. Such as "like" on Facebook, or
be a vote on a poll.
4.5.8.1 Notes
Here Facebooks social plugin API could be used to combine likes.
4.6 Summary
In this chapter we have described many of the needed operations for a distributed
SNS, but they are only the beginning. Many of the non-functional requirements
that have not been designed for this system, but would direly need to be addressed for a fully functional SNS, have been partly overlooked in this design.
Examples of such are performance requirements, security and reliability, but
knowing this design, they will be left aside.
50
Chapter
5
Design and Languages Used
for Prototype
5.1 The specication language
For a distributed social network like the one described in this thesis, it is vital
that it is very easily set up and maintain. For a user of the specication language
to create a customized SNS to meet their needs and desires, all he should have to
do is modify simple variables in one single le. Let's call this le specications.
5.1.1 Framework design
The skeleton for the framework of the specication language is seen in Figure
5.1. The skeleton around the framework itself is little more than a description
of steps taken in creating a working SNS. On top of that then comes what tools
were used to create a fully functional framework, which will be discussed later.
The specication language should be aimed at both giving the users the ability
to choose what functionality should be on his PSNS, as well as customizing it
as much as possible without compromising the shared functionality needed for
52
Design and Languages Used for Prototype
Figure 5.1: General framework for specication language
the distributed network. Thus the user will be allowed to specify some options
in the specication that modify the functionality of each operation.
An example can be seen in Figure 5.2. A choice of conguration can be made
from a number of variations of blogging, the basic functionality is the same,
the variations only extending it or specializing in some way. Same goes for
the group functionality. The red line outlines a possible selection specied for
a PSNS. In this particular selection the PSNS creator has chosen Blog with
variation1, basic group functionality as well as all functional requirements and
some other functionalities. The unimplemented "Other" operation variation he
will have to design himself since it's outside the implemented operations in the
specication language.
Of course the amount of variations and added functionalities is endless, so in
this thesis focus was given not to designing and implementing too many variations, but rather make more basic functionalities and show an example of how
5.1 The specication language
53
Figure 5.2: Options in the Specication language
a variation could be congured.
The tools to be used for the framework of the prototype are mostly chosen based
on simplicity, to get a fully working prototype for this thesis. Basic knowledge
of Java is assumed of the reader, and therefore we will not describe it in-spite
of it's use on many levels of the framework.
5.1.2 The Web Server Engine
To create the web server engine the Klaim project was chosen for its simplicity,
number of built in features such as the Klava network (Klava.Net), access
controls and security mechanisms.
The Klaim project is made up of two parts, X-Klaim [17] and KLAVA [18]. And
makes it fairly easy to use to create distributed mobile applications. The XKlaim framework as described in [17], X-Klaim programs are made which then
compile into Java programs, which then need the KLAVA package to compile
and run in the Java runtime environment as seen in Figure [?]. A missing
link between the Klava package and the Java Interpreter was added, as the
interpreter also needs the Klava package for running the application.
Instead of running the application, the Java code received from the X-Klaim
54
Figure 5.3: The Klaim project framework for using X-Klaim, corrected from
[17]
compiler, is then modied manually, combined with specications, JPS (HTML)
code and nally made into m4 code. m4 was also chosen for its power and ease
of use as will be explained later. m4 then compiles into the JSP and Java code
which is used for the server. The PSNS engine is run in Java using the Klava
package on the server, and the web application is published on the server using
the JSP.
The only document the user (of the specication language) edits for customizing
the functionality of his page, is the specications le, specications.m4. The Web
application using JSP code is the User Interface which uses the Klaim generated
Java les as the Web Server Engine. The auto generated Java code using Klava,
uses the memory as its database, therefore no database implementation needs
to be included in this prototype.
After compiling everything the user has a functioning web server, and can then
5.2 The Klaim Project
55
Figure 5.4: Specication language for creating a PSNS in a Distributed SNS.
edit the web application using JSP code to add any additional functionality to
the page or edit its looks, as long as he should not jeopardize the part of the JSP
code that deals with the Java application and the shared functionality (cannot
be assumed).
Several languages and tools are used in the making of this prototype. Let's now
move on to explain the underlying methods in order to familiarize the reader
with the tools used for this thesis.
The Klaim project consists of two parts. One is "X-Klaim: A Programming
Language for Object-Oriented Mobile Code"[17], and the second on is KLAVA,
which is a Java package for distributed and mobile applications[18]. X-Klaim
56
is built upon KLAIM [16] as an extension, to program distributed systems who
interact with each other through multiple tuple spaces. KLAIM is on the other
hand built on top of "Linda, the portable parallel"[19]. The X-Klaim code
compiles into java code that utilizes the Klava package, as shown in 5.3. But
before we further describe the KLAIM project, let us quickly introduce what
KLAIM and Linda are.
5.2.1 Linda [19]
Linda is a coordination language, created in the mid 80's, and since then there
have been a number of various articles and summaries written on it. In Linda
concurrent processes communicate with a shared memory called a tuple space.
It can contain two types of tuples, static data tuples and process tuples. There
are 6 dierent operations in Linda: in, inp, out, rd, rdp and eval. Each time
an operation is called, a process tuple is dropped into the tuple space where it
remains under active evaluation until it is removed from the tuple space.
•
in(s): Searches for a tuple t that matches s. If no tuple t matches s, the
•
inp(s): Searches for a tuple t that matches s. If it nds a match, it
•
out(t): Produces/executes a tuple t and writes it to tuple space.
•
rd(s): Searches for a tuple t that matches s. If it nds a match it reads
•
rdp(s): Searches for a tuple t that matches s. If it nds a match it will
•
eval(t): Creates a new parallel process to evaluate tuple t and write its
process suspends until it nds a match. If it nds a match, it reads and
removes tuple t from tuple space.
removes tuple t from tuple space and returns "true". Otherwise it returns
"false".
tuple t from tuple space (does not remove it). If no match is found the
process is suspended until it nds a match.
return "true" (does not remove tuple). If no match is found the process
returns "false"
result to tuple space.
A tuple space is an associative memory. Tuples can have any number of elds
and they are said to match if those elds are identical. The operations in, inp,
rd and rdp check if tuples match using pattern-matching, rst checking how
many elds a tuple has before matching the elds.
57
Furthermore formal parameters can be used for match-templates. In Linda these
parameters are represented with a question mark before the variable name. For
instance, if you have a tuple (1,"foo"), inp(1,?a) will return "true", and the
variable name a will be given the value "foo".
5.2.2 KLAIM: A Kernel Language for Agents Interaction
and Mobility
KLAIM [16] extends Linda by allowing multiple tuple spaces, they are placed
on specic sites of a net (nodes). And they are accessed through their locality.
Localities can be twofold.
•
S(s) is a set of sites (or physical localities). A site can be considered as
•
Loc(l) is a set of (logical) localities. A locality may be thought of as
the symbolic name for a site. Localities permit structuring programs over
distributed environments while ignoring their precise allocations. A distinguished locality self ( Loc) is assumed. Programs can use self to refer
to their execution site.
the address of a node where processes and tuple spaces are allocated.
With the introduction of localities, all operations in KLAIM are executed at a
locality, syntactically that is done by adding a "@<locality name or address>".
KLAIM implements all operations of Linda, except that it modies eval to have
processes as arguments instead of tuples, to allow for mobile agents. Additionally it has a newloc(u) operation. newloc() creates a new locality and binds it
to u. Furthermore KLAIM introduces simple data types to tuple elements.
5.2.3 "X-Klaim: A Programming Language for ObjectOriented Mobile Code"[17]
X-Klaim has the same operations as KLAIM and they can be executed at dierent locations <operation>(<tuple>)@<location> as in KLAIM. Important things
are added to X-Klaim. It provides the tools to dene subroutines, arguments,
variables, conditional testing, programming statements and arithmetic capabilities. Each running process is run from or within a node. A node starts with a
name and can have a mapping from a logical locality to a physical locality like
this.
58
example_node::{<logical locality variable> ~
<physical locality constant>}
Each node has one and only one "begin" and an "end". It functions much like
a "main" function in many other languages such as Java, wherein you can use
any number of external subroutines. Furthermore subroutines can be imported
to be used on a dierent node. An example of a node and subroutine could be:
rec StringRetriever[<locality name> : loc, <string name> : string]
declare
var <variable name> : <type>
begin
if inp(<string name>,!<variable name>)@<locality name> then
out(<variable name>)@self
endif
end
nodes
tupleBank::{}
port <tuple bank port>
begin
out("foo","tuple found")@self
end
endnodes
This node will simply write a tuple with two string elements to its tuple space.
When called, the subroutine will check if a tuple ("foo", <any variable of type
<type>>) exists on <locality name>. If it does, the variable <variable name>
will get the second element of the rst matching tuple it nds. That tuple will
then be removed from tuple space on <locality name>. Lastly before ending the
subroutine a tuple with the value of <variable name> will be dropped onto the
tuple speed of "self", which is the node where the subroutine is run from. It
could be dened on any node, and could be imported to another one using:
rec <subroutine name>[<parameters>] extern
To import more than one subroutine, all but the last one have to be followed by a
semi-colon, as is the case with most things in xklaim. In X-klaim separators are
only used between parameters, variables, lines of code and import statements.
59
An example of a node using a subroutine dened elsewhere, could look something
like this:
rec StringRetriever[<locality name> : loc] extern
nodes
caller::{tuple_bank ~ <physical address>:<tuple bank port>}
port <port number>
begin
eval(Example(tuple_bank, "foo"))@self
end
endnodes
Here the example subroutine is imported and the caller node calls it. The
subroutine will in this case nd a tuple with the rst element being "foo". If
found, it will output the second element into its tuple space, that element in
this case being the string "tuple found".
5.2.4 Klava [18]
The Java code received from compiling the X-Klaim code requires features not
supplied by Java, such as tuples, tuple spaces, localities and nodes. Klava is
a package containing a framework used by Java to compile and run the Java
program. Thus it is a middle ware between Xklaim and Java. Knowledge of
Klava is not needed when programming in Xklaim, but since the code received
from X-Klaim is manually customized before it is made into m4 code, some
knowledge of at least the data types and their handling is required. In this
thesis, Klava data types are mostly handled by converting them to basic data
types before using them in computation and then converting back to Klava data
types if needed. An example of Klava data type computation is as follows
timestamp = new KInteger() ;
in( new KString( "timestamp" ), timestamp, self ) ;
timestamp = new KInteger( timestamp.intValue() + 1 ) ;
out( new KString( "timestamp" ), timestamp, self ) ;
Lines 112-115 from MakeBlog.m4
60
Here you see a KInteger() (Klava object) being created, then the KLAIM operation in(s)@l is called, namely in("timestamp", timestamp)@self where "timestamp" is a KString and self is a logical locality expressing the node upon
which the process is being executed. Timestamp is then incremented before
it's dropped back into the tuple space of the logical locality where the process
is being executed.
5.3 m4
m4 is a general purpose macro processor and macro language. It provides features such as.
• arguments
• condition testing
• arithmetic capabilities
• string and substring functions
• le manipulation
In m4 # is used to mark the beginning of a comment and $<argument number>
is the number of an argument, passed to the macro in the order they are passed.
Quotations are used to manipulate how macros are expanded. The processor
removes one layer of quotes each time it processes the macro.
Inspite of its range, the built in commands used for this thesis, listed in the
order they appear are [15]:
•
changequote(left,right). Dene quote characters as left and right.
•
include(lename). Expand contents of lename.
•
dene(name,text). Denes the macro name to be text.
•
ifelse(text1,text2,ifeq,ifne). If text1 and text2 are equal strings, expand to ifeq. If not, expand to ifne.
To explain we can imagine two les, Definitions.m4 and Example.m4. Definitions.m4
could look something like this:
5.4 Java Server Pages
61
define(a,10)
And Example.m4, something like this:
changequote(þ,ð)
include(Definitions.m4)
ifelse(a,0,
þdefine(Execute,$1 * 2)ð
,
þdefine(Execute,þ $2 * 2 ð)ð
)
Execute(20,40)
If Example.m4 is compiled, it starts by changing quotation marks from being
single quotes to be "þ" to start quote and "ð" to close it. It expands the contents
of the le Definitions.m4, which dene a variable a to have the value 10. Then
it checks if the value of a is the same as the value 0 (the value of a being 10).
If it is, it denes Execute to multiply its rst argument by two. If it is not,
then it would dene Execute to display "verb|<|second parameter> * 2". It
would not compute the multiplication since the processing would only remove
the most outer layer of quotations. It then processes the macro Execute with
the parameters 20 and 40.
m4 is well suited for this project since it's very easy to use, it allows us to read
specication from the user from a separate le. In this specication le the user
denes the size of some control arguments (macros). These control arguments
are then expanded into other m4 les that generate customized java code.
5.4 Java Server Pages
Java Server Pages are a cross-platform method that dynamically generates web
pages based on HTML and Java. Java code is simply embedded into your web
page alongside your HTML code. JSP was chosen for its ease of use both for
the user and the maker of the specication language.
The method of inputing the Java into the JSP is extremely simple. There are
62
3 main methods of importing, you can import "page directives" by surrounding
the syntax like so:
<%@ -PAGE DIRECTIVE SYNTAX- %>
Similarly you can add declarations surrounding the declaration syntax like so:
<%! -DECLARATION SYNTAX- %>
And java expressions like so:
<%= -JAVA EXPRESSION SYNTAX- %>
And nally, you can place blocks of Java code like so:
<% -JAVA BLOOCK CODE SYNTAX- %>
As said, JSP code is the nal product the user receives and deploys to have a
working social networking site. Basic HTML code surrounding the JSP code
is supplied to the user when the m4 les are compiled, using simple forms to
get input from the visitors of the social networking site. This code can then be
modied by the user to obtain whatever outlook he seeks, or even congured
directly to extend an existing web service he has.
Core functionality needed by the distributed social networking system will be
kept as much as possible in the Java les to help ensure uniform functionality.
Although these les can easily be tampered with to corrupt the functionality or
even to make it malicious.
Chapter
6
Prototype
In this chapter we will explain the prototype system implemented. The prototype does not attempt to reach the full functionality of the system designed
in Chapter 4. It is merely to show how the designed framework designe creates a functional SNS. No functionality needed for a distributed SNS has been
implemented in this prototype.
6.1 X-Klaim web server engine
The X-Klaim program made consists of two les, Server.xklaim and User.xklaim.
They compile into a Server class as well as a set of other classes that contain
the Klava based java methods for the web server. These other classes are a set
of subroutines that function as the web service engine as displayed in Figure
4.1. The Server class is executable, and starts a Klava node on the the Klava
network. All activity on the PSNS, goes through the Klava network, and is
stored on the tuple space of either the Server node or the node created for the
active item (Account, Group or Event). Thus the Klava network along with the
Server node, function as the PSNS Database as it is displayed in Figure 4.1.
The Klava network Klava.Net, is built into the Klava package. It can in theory be run from anywhere as long as the Server class and all subroutine method
64
Prototype
classes are passed its location. The Java application aquired by compiling the Xklaim les Server.xklaim and \verbUser.xklaim| form a fully functional web
service. The web service is deployed by running Klava.Net and then creating
and running the Server node on it. Although no user interface has been developed at this stage, it would only be accessible by users running Klava based
Java applications.
To engage in any kind of activity on Klava.Net, the user must be registered
with Klava.Net with a node. This node has an address and a tuple space.
For engaging in any kind of activity on the server, the user is involved with
three dierent registered nodes: The Server Node, his account node as well as
the node with which he is registered at Klava.Net. For simplication let's call
these nodes: ServerNode (SN), YourNode (YN) and *Self.
6.1.1 Security
The server, that functions as the database for the web server can only be accessed
by a xed number of methods imported in the Server class. These methods have
to be located in the same folder as they are being run from. Should a method
try to access the SN tuple space from a dierent location, Klava.Net will deny
access and print a "untrusted thread:..." error message.
Furthermore the methods are serialized. Should they be modied and recompiled it will result in a runtime java.io.InvalidClassException, due to incompatible serialVersionUID.
No further security mechanisms than those built into the Klava package were
implemented due to time constraints.
6.1.2 Methods Implemented
Out of the many requirements described in chapter 4, only a few have been
chosen to be implemented for a X-Klaim prototype of a social networking system. All functional requirements were implemented along with a few other
non-functional requirements. The functional requirements implemented were
create account, login/out, add friend, send message and blog.
Non-functional requirements implemented were methods for creating a group or
event and inviting users to join groups or events. Events and groups are treated
6.1 X-Klaim web server engine
65
in exactly the same way as an account. A user even has to log into that event
or group to post and view things about that event.
6.1.2.1 Create Account, Authentication
As mentioned in chapter 3, you can have three kinds of accounts, User, Group
and Event accounts. These accounts are created in the same way. They are
passed a user/event/group-name, a password and the location where the request
is coming from. If the account name is available the account will be successfully
created. When a user logs in, the same information is sent for verication on
the Server node.
To use the methods a user needs to have the following information available at
*Self: User/Group/Event-name, SN address and YN address. This information
is outputted as a tuple to the tuple space at *Self. He is then taken to his
prole.
When an account is created, the account is assigned a unique node. The assigned
node stores all material posted on the network by that user in its tuple space.
When logging out, the information put on the tuple space on *Self is removed,
and the "Frontpage" method called with *Self as a parameter, resulting in no
messages, invites or blogs.
6.1.2.2 Prole
No mechanism viewing the proles of others was implemented. When viewing
your own prole, all that is done on the web service engine side is viewing new
messages, invites and the activity of friends (Blogs). This is done by executing
the Frontpage method on SN, with his YN as a parameter. The Frontpage
method checks invites, new messages and all blogs made by friends of the user.
•
Check Invites. Check Invites takes a YN as parameter, and checks if
that node has received any new invites or friend requests. It then calls the
"Conrm Friend/Group/Event" method which should request a conrmation from the user. But such a conrmation has not been implemented, so
the next time the invited User/Group/Event logs on, it will automatically
conrm the invite.
66
Prototype
A friendship is registered by putting a tuple containing information about
the other user on both parties' YN. A group or event membership is registered only on the users side, since the group or event has no interest in
reading the blogs of users.
•
Check New Messages. Checking new messages works similarly to check-
•
Get Blogs. Just as in checking invites and messages, getting blogs takes
YN as a parameter. It then reads every blog made by any user or group on
the SN, in the order they are made. For every blog, it checks if the blogger
is a Friend/Group/Event that he "follows". If it is, then it displays the
blog, along with username of the blogger and subject if available.
ing invites, all messages marked as "unread" are read from the YN passed
to it as a parameter. The messages are then placed back on the node as
"read".
No method is implemented in X-klaim for replying or for reading previously read messages. Although it would require very little tuning, as
replying to a message would simply be to send a message with a xed subject and sender. Reading previously read messages would be exactly the
same as reading new messages, except instead of the last element of the
tuple being searched for being "read", it would be changed to "unread".
6.1.2.3 Add Friend, Event/Group Invite
Adding a friend sends target node a friend request. The friend request consists
of a tuple with a string identifying the type of request, the username of the
adder and the node of the adder. This information is put there to pave the
way for implementing a friendship conrmation mechanism, but it has not been
implemented as explained in Section 6.1.2.2. Group or event invitations work
in exactly the same way as adding a friend.
Inviting to groups or events and sending messages works very similarly, except
that inviting to groups or events rst checks if the group or event exists before
dropping a tuple into the target users' tuple space. Sending a message just does
it outright.
6.1.2.4 Blog
Blogging is done with the "MakeBlog" method. Makeblog is the method that
will in the prototype example shown how its functionality can be changed using
m4. The variable functionality is blog length restriction (many sites have this
6.2 Alternative Framework
67
restriction, especially sites that oer sms message services), whether or not a
blog comes with a subject and subject length restriction.
MakeBlog takes the blog content (includes subject if applicable), YN and *Self
as parameters and outputs the blog into the YN tuple space. *Self is only taken
as parameter for debugging.
6.2 Alternative Framework
Implementing the system using the framework designed in chapter 5, using JSP
with Klava and X-Klaim proved problematic due to errors with access controls
on the server. These errors can most likely be traced back to built in access
controls in the Klava package. Fixing these errors turned out to be a dicult
task to overcome. Thus I gave up on implementing the framework using JSP,
and resorted instead to an alternative implementation.
This alternative implementation, uses a Java Swing Applet instead of JSP. This
changes the framework to become as displayed in gure 6.1.
The site creator still only has to edit the Specications le before deploying the
Java Applet. In essence, the functionality is the same as if it had used JSP, but
to customize the site, the site creator now has to edit the Java les. Furthermore
the Java Interpreter now runs on the user side, instead of the server.
6.3 Web server engine using Java Swing Applet
The methods used are still the Klava based Java methods. The database is the
same, i.e. a combination of Klava.Net and Server.class. The applet is mainly
the User interface. When the application starts, it is in the an idle state. From
there a user can take 4 actions, to log in or create an account/group/event.
6.3.1 Addresses
Each time a user logs in or creates an account/group/event a new node is logged
into Klava.Net. This node is made on the address "localhost:10000" in this
implementation. Some algorithm for nding an unused node when logging in
should be implemented, to avoid clashes with other users trying to log in with
68
Prototype
Figure 6.1: Framework for specication language using Java Applet
the same node. This node functions as the *Self node, YN is assigned using
newloc(), and SN is hard-coded to be 11000.
Due to the fact that an address assigning mechanism was not implemented,
two users logging into the Klava.Net can have problems because of the location
starting at "localhost/10000", and two nodes with the same location cannot be
logged into Klava.Net at the same time. To solve this, the physical location of
the user could be used, or using the newloc() operation to nd a free node.
6.3.2 User Interface
The UI as shown in Figure 6.2, consists of a number of JTextFields, JButtons
and a JTextArea. The JTextField are to enter information to submit. Information is submitted according to which JButton pressed. JTextArea is used to
6.3 Web server engine using Java Swing Applet
69
display output.
Figure 6.2: PSNS user interface in a Java Swing Applet
When a JButton event is triggered (Button pressed), a Klava process is created
and then started on YN. This process runs in a separate thread, therefore we
put the application to sleep for a second while the we wait for the process to
nish. The resulting text is then displayed on the JTextArea. Displaying the
result output was solved with a bit of a quick x. All output from any method
was modied to be written into a le test.txt, in addition to the command
line output.
6.3.3 State Machine
When the application is started, it starts in the idle state. A node is registered
with the Klava.Net environment with the Create Account/Group/Event and
Log in JButton events. This node is the *Self node. After those events the node
is stored until another one of those events occur, the application is terminated,
or if the Log out JButton event occurs. While this node is stored the user is
considered logged in, since all other JButton events are processed with that
node as *Self. This can be visualized in Figure 6.3
6.3.4 Scalability
Time constraints resulted in quick xes such as hard-coding localities and using
test.txt to display text. These quick xes result in the site having complete
lack of scalability. In fact using a le to display text means that the site can
give unwanted results if more than one user access it at the same time. Since
both users read and write to the same le.
70
Prototype
Figure 6.3: State machine diagram
6.4 m4
m4 is the language the user of the specication language deals with for deciding
which shared features he wants in his program. Our prototypes m4 code consists
of one m4 le for each le that needs to be created, plus the specifications.m4
le. Each le imports specifications.m4 and uses the macros dened there
as parameters for condition testing, to determine the code output.
The prototype specifications.m4 has the following macros dened.
define(BlogLengthRestriction, 2254)
define(BlogSubject,222)
Listing 1: Lines 1-2 from Specifications.m4
This denes the variable BlogLengthRestriction to have the value 2254, and the
BlogSubject to have the value 222.
BlogLengthRestriction denes the length of each blog users are able to make.
Since it is considered an essential part of a social network, not having it is not
an option. Should BlogLengthRestriction be set to 0, it will mean that there
6.4 m4
71
is no restriction on the length of a blog. If it is any other natural number, it
represents the length of the string the blog can be. Not having a blog possibility
is not given as an option, since blogs are considered a functional requirement.
Similarly BlogSubject represents the length of the string that can be used as
a subject of a blog, but here 0 represents that no Subject option is available.
Having subject without a length restriction is not an option.
6.4.1 Customization
As mentioned in Section 6.1.2.4, MakeBlog is the only method in this prototype,
where customization has been implemented using the specications le. Here is
a run-down on how it works.
changequote(þ,ð)
include(Specifications.m4)
ifelse(BlogSubject,0,
þdefine(MakeBlog,þþ
import java.io.* ;
import Klava.* ;
public class MakeBlog extends KlavaProcess {
... #Java code
textLength = new KInteger(\$1);
... #Java code
}
}
ðð)ð,
þdefine(MakeBlog,þþ
import java.io.* ;
... #Java code
72
Prototype
}
ðð)
ð)
MakeBlog(BlogLengthRestriction,BlogSubject)
Listing 2: Various lines from MakeBlog.m4
In listing 1 and 2 you see how the specications are included and used to determine the output code of the MakeBlog le when compiled. First it changes
quotes to ð and þ. Second it checks if the macro text BlogSubject equals 0.
Third it removes one set of quotations from the resulting text of the ifelse
condition. Fourth it denes the MakeBlog macro to be the code to be used
on the web server surrounded by quotations. And nally it calls the MakeBlog
macro with the Specifications.m4 dened macro texts as parameters. The
execution of MakeBlog.m4 is piped to MakeBlog.java, which is used directly on
the web server.
A simple .sh or .bat le is made to compile and pipe all .m4 les into the correct
corresponding les.
6.4.2 m4 security issues
Some issues may arise as to the safety of using m4 in the way it is used in
this prototype. The macros dened in Specifications.m4, don't have to be
a number, instead of dening one of the macros to be a number, an attacker
can dene it as any malicious Java code, which will be executed every time the
method is executed:
define(BlogLengthRestriction,þ25); <Malicious java code>ð)
The code can be any malicious Klava based Java code. Possible solutions to this
would be to generate the java method le remotely, and use input validation
to check if the dened macros are in fact numbers, along with serialization and
version control could help solve the problem. But the same as goes for all social
networks, the user has to trust the site administrator.
Chapter
7
Summary, Conclusions and
Future Work
Since their appearance in the beginning of the 21st century, internet sharing
trends are shifting fast towards social networking sites such as Facebook, Twitter and LinkedIn. Most of these sites are created or run with the same or similar
concepts. Their purpose is similar, and they oer similar features. What separates them is largely just their user-base. In this thesis we researched a great
deal of social networking services, designed a distributed social networking system, a specication language and nally made a prototype implemented on top
of the aforementioned things.
7.1 The Distributed Social Networking System
After researching and analyzing most of the largest general social networks available, a distributed social networking system was designed. This system would
be made up of many smaller social networking sites. All these smaller sites share
a number of common functionalities. These functionalities are chosen from functionalities oered by a specication language also designed in this thesis. The
functionalities designed are chosen from what common functionalities almost all
of the social networks investigated in this thesis had in common.
74
Summary, Conclusions and Future Work
All users of social networking sites on the distributed network, can access posted
material by other users on other sites on the network almost as if it was their
own. All functionality on the network are based on the common functionalities
shared between sites on the network.
7.2 The Specication Language
To help standardizing the functionality of the Smaller social networking sites,
as well as making it easier for people to create a social networking site. A
framework for a specication language was designed. The
A prototype for a specication language, using the framework designed was
created. Creating this prototype required considerable research of available
tools to aid the creation of this prototype. Finally a Java based solution was
approached. An attempt to use X-Klaim, Klava, m4 and JSP to create the
specication language was made, then deploying the site using tomcat. But
Klava built in access controls prevented the JSP Java code to access the Klava
methods created with X-Klaim. After considerable time spent on debugging,
this framework was abandoned.
Just in the nick of time, to present the functionality of the designed Specication
language prototype, a Java Swing Applet was used to create the necessary user
interface to present the Social Networking Site.
7.3 Conclusions
In this thesis, focus was put on researching and designing the distributed social
networking system. For a system as proposed in this thesis, it is imperative that
it is built on rm foundations. Especially since the developers of the Network
and the Specication language are not the same as the developers of the social
networking sites, that use their products. Thus the elaboration of the prototype
is only useful if the networking system is complete.
Nevertheless each step of the thesis was executed suciently. A nearly complete
distributed social networking system was designed. A framework for a specication language was designed (in fact two, since the rst couldn't be executed) as
well as a prototype using that framework implemented. That prototype showed
a functional social networking site, with all functional requirements dened in
the design implemented and working.
7.4 Future Work
75
In retrospect, perhaps it would have been a more handy solution to use straight
up Java classes or even enterprise Java beans (EJBs) to reach the same result.
The project would then have become more of a building block towards a well
scalable, functional social networking service.
7.4 Future Work
The distributed social networking system opens up a world of future work.
Besides nish creating the specication language for a PSNS on the design
distributed social networking system. The amount of possible functionalities
oered with the specication language are countless, even though not all of
them would have to be compulsory as a shared functionality.
Added use of existing social networks' API could be implemented to better
migrate information between them and networks on the distributed system.
The amount of entry points for information is likely to reveal countless security
vulnerabilities. These vulnerabilities can be investigated and perhaps prevented.
Creating API for all the functionalities, to give currently existing social networks
access to the distributed network.
Should this future work be concluded, not only would it greatly enhance peoples
online social networking experience, it could also be lucrative.
76
Summary, Conclusions and Future Work
Appendix
A
Prototype Tests
To test the prototype I created a SNS where blog length restrictions were 15
characters.
Then I tried creating 3 accounts. 2 of which had the same name. The two
successfully created account tried adding each other as friends, tried blogging,
sending messages and logging back in to receive those blogs and messages. This
included trying to send a blog too long for the length restrictions.
• Create Account with JTextField1:"username", and JTextField2:"password".
the JTextAerea returned
user username successfully created, with nodenumber 127.0.1.1:55434
No new invites
• Create Account with JTextField1:"blogger", and JTextField2:"password".
user blogger successfully created, with nodenumber 127.0.1.1:41398
No new invites
• Add Friend with JTextField6:"username". the JTextAerea returned
78
Appendix A
blogger has sent friend request to username
• Blog twice with JTextField5:"Blog text body", and password:"password".
user blogger successfully created, with nodenumber 127.0.1.1:41398
No new invites
• Blog with JTextField5:"Blog text body, but this time a really really long
one.", and password:"password". the JTextAerea returned
Blog too long
• Send Message with JTextField3:username, and JTextField4:Message text
body. the JTextAerea returned nothing
• Log in with JTextField1:"username", and JTextField2:"password". the
JTextAerea returned
blogger has sent you a friend invite
bloggerhas been added to your friendlist
No new invites
blogger wrote: Blog - Blog text body
blogger wrote: Blog - Blog text body
• Log in again with JTextField1:"username", and JTextField2:"password".
No new invites
blogger sent you the following message: Message text body
• Create Account with JTextField1:"username", and JTextField2:"password".
username taken
All test results turned out exactly as expected, except for the fact that the
logging did not return all awaiting information. Most likely because the tread
was not put to sleep long enough before it made the process terminate.
Appendix
B
User Manual
Here is a step by step introduction on how to compile and deploy the prototype.
This Prototype was made with NetBeans on Linux.
1. Download and extract the PSNS.zip le into your workspace. PSNS.zip
contains a working Java Swing Applet SNS.
2. Add klava-2b1.jar to you system CLASSPATH. klava-2b1.jar can be found
in .../PSNS/lib.
3. Modify Specications.m4 to customize your SNS.
4. Run the shell script CompileAll.sh. This will overwrite relevant java les
and recompile.
5. Open a terminal and navigate to your .../PSNS/src folder.
6. Run the following commands: java Klava.Net 9999 and java autogen.Server.
7. Open NetBeans, go to le menu and open existing project. Navigate to
the folder where you extracted PSNS.zip, and select the PSNS4 folder.
8. Recompile PSNS project and run the swingJApplet.java le.
9. SNS ready
80
Appendix B
Appendix
C
Sequence Diagrams and
Use cases for functionalities.
In this appendix you may nd sequence diagrams and use case tables for all
functionalities designed in Chapter 4. Many of the use case tables have been
split into two parts for better page tting.
Figure C.1: Block User
.
82
Use Case 5
Summary
Preconditions
Basic Scenario
1.
2.
.
Block User
A user is blocked by placing him on blockers blocked list
Blocker is viewing user
Action
Blocker requests to block a user to his own PSNS
User is placed on blockers blocked list
.
Use Case 6
Summary
Preconditions
Basic Scenario
1.
2.
3.
4.
5.
6.
Alternate Path
2a.
.1
5a.
.1
.2
.
Appendix C
Browse photos
When a user browsers through a friends photos he will view
thumbnails of the photo(s)
Action
User requests photos from a subject
User requests location of subject from GS
GS sends location of subject to user
User requests access to a photo album of subject
Subjects PSNS checks users access in subjects friendlist
Subjects PSNS sends user a number of thumbnails along
with photo info (tags, location and description)
User already has location of subject
Go directly to 4.
User does not have access to subjects photo album
Send error message to user
Terminate process
.
Use Case 7
Summary
Preconditions
Basic Scenario
1.
Conrm Friend Request
A conrmed friendship needs to be registered with both
PSNS and the GS
User has received a friend request from another user
Action
User accepts friend request from Requester
Sequence Diagrams and Use cases for functionalities.
Figure C.2: Browse Photos
.
83
84
Appendix C
Figure C.3: Conrm Friend Request
Use Case 7
2.
3.
4.
Notes
Conrm Friend Request - Continued
Conrmation sent to requesters PSNS and GS
Requester added to users friendlist at users PSNS and GS
User added to requesters friendlist at requesters PSNS and
GS
This is abstract, it does not take into account package loss
and thus inconsistencies in friendlists
.
.
Figure C.4: Conrm Event Request
.
85
86
Appendix C
Figure C.5: Conrm Group Request
Use Case 8
Summary
Preconditions
Basic Scenario
1.
2.
Conrm Group or Event invitation
Similarly to conrming a friend request, except conrmation not sent to sender of request but to the group or event.
User has received a invitation from another user
Action
User accepts invitation
Conrmation sent to group or event home PSNS.
.
Use Case 8
3.
4.
5.
.
87
Conrm Group or Event invitation - Continued
Requester added to group or events participantlist at home
PSNS
Conrmation sent to requester
User adds group or event to his grouplist or eventlist
.
Figure C.6: Create Album
88
Use Case 9
Summary
Preconditions
Basic Scenario
1.
2.
3.
Alternate Path
2a.
.1
Notes
.
Appendix C
Create Album
Action
User requests to create a new album with a specic name
PSNS checks if album name already exists
Folder with requested name created in users space
Album with specic name already exists
Send error message
Creating an album and uploading photos through browsing
is an alternative method, to upload photos to their account
from not their own workstation. On their own workstation
they would have a system to Dropbox, where there would
be a home photo folder and they could manage their photos
there and they would upload automatically
.
Figure C.7: Create Event
.
89
Figure C.8: Create Group
Use Case 10
Summary
Preconditions
Basic Scenario
1.
2.
3.
4.
Alternate Path
2a.
.1
.
.
Create Group/Event
A group shares many characteristics of a user, it
has blog/testimonials, photos and photo albums and a
userlist(friendlist), but also an adminlist. It is created at
the creators PSNS and how much space it is allowed and
such should be design choices of that particular PSNS. And
an event is exactly the same as a group except it also has
a date
Creator is logged into a PSNS
Action
User submits event name and password.
PSNS server checks database if event-name is registered
Event is created at PSNS
PSNS registers event at GS
Event-name already registered
PSNS sends error message to user
90
Appendix C
Figure C.9: Flag
Use Case 11
Summary
Preconditions
Basic Scenario
1.
2.
Notes
.
91
Flag
Flagging is a bit of an alternate way to comment on an
item. It's fast and countable way to collect opinions
User has viewing permission to item
Action
User choses an item to ag, and ag(message, dislike or
text describing oense)
Users PSNS sends notication to owner(s)' (The writer
and/or the person whos account the item belongs to) PSNSs
Oensive agging should be monitored by the PSNSs and
perhaps even the GS as well
.
Figure C.10: Hide User
Use Case 12
Summary
Preconditions
Basic Scenario
1.
2.
.
.
.
Hide User
User is creator of group or has permission to modify permissions
Action
User sends in permission number to host PSNS
Host PSNS updates permission number
92
Appendix C
Figure C.11: Join Group
Use Case 13
Summary
Precondition
Basic Scenario
Join Group/Event
Since joining a group or event is treated in exactly the same
way, we will just make one use case for it. It's a design decision, but we decide groups and events can be open(requires
no conrmation), closed(require conrmation), password
protected(open but require password)
User is already viewing the subject so he knows his location
Action
Figure C.12: Join Event
.
93
94
Use Case 13
1.
2.
Alternate Path
2a.
.1
.2
2b.
.1
.
Join Group/Event - Continued
User requests to join a group/event
Conrmation sent to group/event object
Event/group is open or password protected
User is added to event/group userlist
User adds group/event to his grouplist or eventlist
User entered wrong password
.
Use Case 14
Summary
Basic Scenario
1.
2.
3.
4.
Notes
.
Appendix C
Leave Group
Leaving a group requires no permission or conrmation
Action
User requests to leave a group
a removal request is sent to the groups host PSNS
Group is removed from participation list
User is removed from admin or participant list at host PSNS
Group or event creator cannot leave group or event, but
only remove it, a problem with the host PSNS can cause
problems for users leaving a group as they would not be
removed from participant or admin lists. One way to solve
this could be to store those lists at GS.
.
Use Case 15
Summary
Preconditions
Basic Scenario
1.
2.
3.
Modify Event or Group Privileges
Action
User sets a class to a certain level of view-ability or accessibility at home PSNS
PSNS checks which userlist on group or event user belongs
to.
Privileges of that list are checked.
Figure C.13: Leave Group or Event
.
95
96
Appendix C
Figure C.14: Modify Event or Group Privileges
Use Case 15
4.
Alternate Path
2a.
.1
3a.
.1
Notes
Modify Event or Group Privileges - Continued
Class' accessibility modied at home PSNS
User is not on any list.
Send error
User does not have privileges.
Send error
creators can only set items to be only viewable or editable
by creator
.
.
Use Case 16
Summary
Preconditions
Basic Scenario
1.
2.
.
Preconditions
Basic Scenario
1.
2.
Notes
Action
User sets subjects access to item
subjects' access privileges are updated in Users friendlist
on PSNS
Modify User information
User may want to change his name, password or prole information. This is done by resending the new information.
Action
User sends updated name, password and information
Users PSNS updates users Account
Modifying Group info is done in exactly the same way.
.
Use Case 18
Summary
Basic Scenario
1.
2.
2.
.
Modify Friend Access
Access to pictures and other personal information needs
to be controlled. The actual implementation of this would
ideally be controlled by the PSNS, but let's assume it's done
by editing the individual permission
.
Use Case 17
Summary
.
97
.
Remove Album
Removing an album will remove all the photos inside that
album. Only the owner can remove albums. Except in the
case of groups/events where it depends on the privileges
Action
User sends request to remove album to PSNS
PSNS checks if user is creator of that album
PSNS removes album along with all photos
98
Appendix C
Figure C.15: Modify Friend Access
Figure C.16: Modify User Information
Figure C.17: Remove Album
99
100
Appendix C
Figure C.18: Remove Blog or Testimonial
Use Case 19
Summary
Preconditions
Basic Scenario
1.
2.
3.
Notes
.
101
Remove Blog or Testimonial
The writer of a blog or testimonial can remove it. So can
the user whos account a blog is written to. And so can technically anyone, depending on the designated access controls
of a group or event
User has permission to remove the blog
Action
User activates removal process
Users PSNS sends the id number of the blog to the GS,
along with a list of people referred to in the blog or testimonial
GS sends removal activation to all PSNS's where the blog
or testimonial would be sent sent
It can cause a problem with a blog being not completely
removed in all SNS' because of changes in peoples friendlists
and because the SNS' can manipulate the removal request.
.
Figure C.19: Remove Photo
Use Case 20
Summary
Preconditions
Basic Scenario
1.
2.
3.
.
Remove photo(s)
User has privileges to delete the specic photo(s)
Action
User selects photo(s) to delete
Photo(s) are removed from PSNS database
No guarantee that photo(s) or smaller versions of photo(s)
don't exist at friends' pages (nodes)
102
Appendix C
.
Figure C.20: Remove Prole
Use Case 21
Summary
Preconditions
Basic Scenario
1.
2.
3.
4.
5.
6.
.
.
Remove prole
A user wishes to remove his prole o a PSNS along with
all of it's contents
User has a prole at the PSNS
Action
User requests a removal of his prole
PSNS sends removal notication to GS
GS sends notication to all friends on users friendlist
GS and all users friends' PSNS remove user from his friends'
friendlist
GS removes users friendlist
Users PSNS removes all of users data
103
Figure C.21: Remove Friend
Use Case 22
Summary
Preconditions
Basic Scenario
1.
2.
3.
4.
Remove Friend
Friendship removal requires no conrmation, the subject removed is removed from users friendlist and user is removed
o subject friendlist at corresponding PSNSs as well as GS.
Action
User removes a subject from his friendlist
Removal is sent to subjects PSNS and GS
User is removed from subjects friendlist at subjects PSNS
and GS
Subject is removed from Users friendlist at users PSNS and
GS
104
.
Appendix C
.
Figure C.22: Remove Group or Event
Use Case 23
Summary
Preconditions
Basic Scenario
1.
.
Remove Group or Event
A user wishes to remove a group o his PSNS along with
all of it's contents
User is group or event creator
Action
User requests a removal of the group or event
Use Case 23
2.
3.
4.
Notes
105
Remove Group or Event - Continued
GS sends notication to all users on groups or events participation or admin lists
GS and all users friends' PSNS remove group or event from
their participation list
host PSNS removes all of groups or events data
An alternate possibility here would be to oer users in the
group being removed to become it's host, and then moving
it to one of their PSNSs for hosting
.
Use Case 24
Summary
Preconditions
Basic Scenario
1.
2.
3.
4.
Alternate Path
3a.
.1
Notes
.
Terminate sending
identical to sending a message, only dierence is that user
does not modify receiver and subject of the message
.
Use Case 25
Summary
Preconditions
Basic Scenario
1.
2.
.
Reply To Message
Action
User submits a message to send to a subject
Users PSNS sends the message to subjects PSNS
Subjects PSNS checks if User is on subjects blocked list
Message is committed to subjects inbox
.
Unblock
Unblocking takes a subject of users blockedlist
Action
User requests to block a subject to his own PSNS
Subject is removed from users blocked list
106
Appendix C
Figure C.23: Unblock
Figure C.24: Upload Photo
Use Case 26
Summary
Preconditions
Basic Scenario
1.
2.
3.
4.
5.
6.
Alternate Path
2a.
.1
.2
.3
.4
.5
2a.3a.
.1
4a.
.1
Notes
.
107
Upload Photos
Uploading photos to PSNS, they will be stored in full or
near full quality at the PSNS, then also compiled to show
thumbnail at other PSNS
User is successfully logged into a PSNS
Action
User requests to upload photo(s) to PSNS
PSNS checks size of photo(s)
PSNS checks if there is available space on users PSNS space.
Space requirements met, conrmation given.
User uploads photo(s)
PSNS saves the photo(s) along with a compressed thumbnail
PSNS has size limitations(s)
PSNS calculates how much space photos will take after
compilation
PSNS checks if there is available space on users PSNS space
User uploads photo(s)
PSNS checks if there is available space on users PSNS space
PSNS compresses the photo(s) and saves them in the
database along with a even more compressed thumbnail
Not enaugh space on PSNS space
Error message sent to user
Not enaugh space on PSNS space
Error message sent to user
Also only an alternative method for uploading photos (See
create album). Size limitation(see alternate path 2a, is
judged uneccesary to implement right away so will be left
out of sequence and class diagrams
108
Use Case 27
Summary
Preconditions
Basic Scenario
1.
2.
3.
Alternate Path
2a.
.1
.2
.
View photo
User select a photo from subject to view in full quality
User already has the location of subject because he's already viewing the thumbnail photo
Action
User sends view request to subjects PSNS
Subjects PSNS checks for view permission
Subject PSNS sends photo to user
User does not have access to subjects photo
Terminate process
.
Use Case 28
Summary
Preconditions
Basic Scenario
1.
2.
3.
Notes
.
Appendix C
Untag
User has viewing and tagging privileges to the photo
Action
User untags a photo or blog
Users PSNS removes tag in item
Item owner, tagged subject and friends of tagged subject
are notied of tagging
People that don't have viewing privileges to the photo
should perhaps not be notied of tagging.
.
Use Case 29
Summary
Basic Scenario
1.
2.
3.
4.
5.
Search
Basic keyword search, the search should be done in two
places, on the PSNS and on the GS
Action
User Searches for some keywords
Search engine searches data available to the user on the
PSNS
Search engine displays search results
Search engine sends search keywords to GS
GS searches through data available in its database
Figure C.25: Untag
.
109
110
Appendix C
Figure C.26: Search
Use Case 29
6.
7.
8.
9.
10
Notes
.
.
Search - Continued
GS sends search results to PSNS
PSNS displays search results
GS sends keywords to other PSNSs as well as address of
PSNS where the search came from
Other PSNSs send search results to PSNS
PSNS displays results on the y
This means that having prole information or picture information that are only available on other PSNSs in the
search keywords will not give wanted results as the search
engine never searches other PSNSs as it is congured in this
example.
111
Figure C.27: Tag Person
Use Case 30
Summary
Preconditions
Basic Scenario
1.
2.
3.
4.
Notes
Tag Person
Tagging items really helps users nding relevant item. All
relevant parties being tagged must be notied of tagging. A
subject tagged in a photo will be given viewing and tagging
privileges to that photo. User on tagged subjects' friend list
will be notied about tagging.
User has viewing and tagging privileges to the photo
Action
User tags a photo or blog
Users PSNS saves tag in items class
Items owner, tagged subject and friends of tagged subject
are notied of tagging
Tagged subject is given viewing and tagging privileges to
the photo if it does not have it already.
People that don't have viewing privileges to the photo
should perhaps not be notied of tagging.
112
.
Appendix C
.
Figure C.28: Testimonials
Use Case 31
Summary
Preconditions
Basic Scenario
1.
2.
.
Write Testimonial
A testimonial is something a user writes on a subjects prole page. In our system it is treated in every way the same
as a blog, except the owner is not the just the subject but
the user writing it as well. So both can remove it
User has viewing privileges to subjects wall
Action
User posts a testimonial message for a subjects blog
Subjects PSNS checks if user is on subjects blockedlist
Use Case 31
3.
4.
Alternate Path
2a.
.1
Notes
.
Write Testimonial - Continued
Users PSNS saves and sends the entire blog to GS along
with user and subject references and a list of all people
who are referred to in the blog.
GS chompares friendlists of user and subject and sends the
blog to all PSNS' where they have a mutual friend or where
they are in the list of people referred to in the blog
Terminate blogging
It is a design choice that this a notifaction is only sent
to mutual friends. It is also not posted on the "wall" or
"prole" of the subject on any CSNS as the user may not
have an account on that specic CSNS
.
Use Case 32
Summary
Basic Scenario
1.
2.
3.
4.
5.
6.
Alternate Path
2a.
.1
.
113
View Prole
Information on a requested prole is stored at that requested users' PSNS, when requester requests to view the
requesteds prole, and the requested is not on the requesters PSNS. The requester must get the location of the
requested from the GS, before the requester can request
the prole information of the requested, from the requesteds PSNS
Action
User requests to view the prole of another user
Requestee user is not on the requesters PSNS
Requester requests the prole information from requestees
PSNS
Requestees PSNS checks if/what prole information requester has privileges to view
Requestees PSNS sends requesters PSNS appropriate information
Requesters PSNS displays the information in its own way.
Requestee is on the requesters PSNS
Go straight to steps 4. and then 6.
114
Appendix C
Figure C.29: View Prole
.
Figure C.30: Write Comment
115
116
Use Case 33
Summary
Preconditions
Basic Scenario
1.
2.
3.
4.
Alternate Path
2a.
.1
Notes
Appendix C
Comment
A comment can be written on blogs, testimonials
User has viewing privileges to a subjects blog or testimonial
Action
User sends a comment for a subjects item
Subjects PSNS checks if user is on subjects blockedlist
Users PSNS sends the comment to GS along with user and
subject references, along with a list of all people who are
referred to in the item
GS compares friendlists of user and subject, and user and
the list of people referred to in the item. It then sends the
comment to all PSNS' where the item is stored at, and a
notication to where those compared have a mutual friend,
and those directly referred to in the item.
Terminate blogging
It is a design choice that this a notifaction is only sent
to mutual friends. It is also not posted on the "wall" or
"prole" of the subject on any CSNS as the user may not
have an account on that specic CSNS
117
118
Appendix
D
The private social
networking site class
diagram
This is a more detailed version of Figure 4.2. showing a Private Social Networking site's class diagram.
Figure D.1: The Search Results Data Type
120
Appendix D
Figure D.2: The Account Class on PSNS
The private social networking site class diagram
Figure D.3: Upper Left part of PSNS Class diagram
121
122
Appendix D
Figure D.4: Upper Right part of PSNS Class diagram
The private social networking site class diagram
Figure D.5: Lower left part of PSNS Class diagram
123
124
Appendix D
Figure D.6: Upperleft part of PSNS Class diagram
Appendix
E
Code Listings
In this chapter you will nd most of the code used for this project, a big part
of it is repetitive since it is rst made from compiling Server.xklaim and
User.xklaim. Then they are edited to be used in the Java Swing Applet. The
m4 les contain all the code for the java les used in the applet. They become
Java les when compiled, therefore the java les are not included in the code
listing.
The listing package does not display icelandic letters, therefore Ã◦ is displayed
instead of ð and Ã3/4 instead of þ.
• Both X-Klaim programs. Since they contain the web server engine in very
easily readable code.
• The CompileAll.sh script used to compile the m4 les into java les in the
appropriate place, and then compile the java les.
• MakeBlog.m4 and GetBlogs.m4, since they are modied based on Speci-
cations.m4, and also contain some minor tweaks displaying the output.
• swingJApplet.m4 since it compiles into the UI code.
• Server.m4 since it compiles into the auto-generated java le by X-Klaim.
Used as a database in this project, and shows how xklaim makes Klava
executable nodes.
126
Appendix E
• BlogK.m4 since it is one example of a hand made Klava process that is
executed on JButton events.
r e c ConfirmGroup [ adder : s t r , groupName : s t r , groupNode : l o c ]
declare
var myNode : l o c
begin
r e a d ( " yourNode " , ! myNode ) @ s e l f ;
p r i n t adder + " has i n v i t e d you t o j o i n t h e " + groupName + " e v e n t . " ;
out ( groupName , groupNode )@myNode
p r i n t " your node number wasn ' t found . "
endif ;
r e a d ( "yourName" , ! myName) @ s e l f ;
p r i n t adder + " has added you a s a f r i e n d " ;
out ( adder , adderNode , " f o l l o w " )@myNode ;
out (myName, myNode , " f o l l o w " ) @adderNode
end ;
else
r e c ConfirmFriend [ adder : s t r , adderNode : l o c ]
declare
var myNode : l o c ;
var myName : s t r
begin
i f readp ( " yourNode " , ! myNode ) @ s e l f then
p r i n t " t h i s i s your node number− " + myNode
r e c ConfirmEvent [ adder : s t r , eventName : s t r , eventNode : l o c ]
declare
var myNode : l o c
begin
p r i n t adder + " has i n v i t e d you t o j o i n t h e " + eventName + " e v e n t . " ;
out ( eventName , eventNode )@myNode
#i n s t e a d o f f o l l o w i t c o u l d be , " b l o c k " o r " not f o l l o w "
end ;
E.1 User.xklaim
E.1 User.xklaim
127
r e c CheckNewMessages [ myNode : l o c , r e c e i v e d : b o o l ]
declare
var message : s t r ;
var senderNode : l o c ;
p r i n t "No new i n v i t e s : ) "
endif
endif
endif
end ;
else
e v a l ( ConfirmGroup ( anyAdder , anyName , anyNode ) ) @myNode ;
e v a l ( C h e c k I n v i t e s ( myNode ) ) @ s e l f
else
i f i n p ( " group i n v i t e " , ! anyAdder , ! anyName , ! anyNode )@myNode then
e v a l ( ConfirmEvent ( anyAdder , anyName , anyNode ) ) @myNode ;
else
i f i n p ( " e v e n t i n v i t e " , ! anyAdder , ! anyName , ! anyNode )@myNode then
#s i n c e check i n v i t e s e x i s t s i n both u s e r s g r o u p s and e v e n t s ,
#you can i n v i t e gr o u p s t o g r o u p s e t c . . .
r e c C h e c k I n v i t e s [ myNode : l o c ]
declare
var anyAdder : s t r ;
var anyNode : l o c ;
var anyName : s t r
begin
i f i n p ( " f r i e n d r e q u e s t " , ! anyAdder , ! anyNode )@myNode then
p r i n t anyAdder + " has added you a s a f r i e n d " ;
e v a l ( ConfirmFriend ( anyAdder , anyNode ) ) @ s e l f ;
#A l l t h e i n f o r m a t i o n a r e about adder a r e g o t t e n h e r e
#a l r e a d y , even though you c o u l d j u s t add h i s name and then
#ask t h e s e r v e r l a t e r for t h e r e s t
end ;
128
Appendix E
#This GetBlogs s i m p l y g e t ' s a l l b l o g s t h e u s e r i s f o l l o w i n g from t h e s e r v e r
r e c GetBlogs [ myNode : l o c ]
declare
var s e r v e r I P : l o c ;
var timestampNow : i n t ;
var timestampLast : i n t ;
r e c CreateAccount [ userName : s t r , password : s t r , i p : l o c ] e x t e r n ;
r e c GiveTimestamp [ i p : l o c ] e x t e r n ;
r e c Frontpage [ node : l o c ]
begin
e v a l ( C h e c k I n v i t e s ( node ) ) @ s e l f ;
e v a l ( CheckNewMessages ( node , true ) ) @ s e l f ;
e v a l ( GetBlogs ( node ) ) @ s e l f
end ;
rec DisplayError [ error : s t r ]
begin
print error
end ;
p r i n t "No new messages . . . . . . . . . . "
endif
endif
end ;
else
i f not r e c e i v e d then
var s e n d e r : s t r
begin
i f readp ( ! message , ! senderNode , " unread " )@myNode and readp ( ! s e n d e r , senderNode , " f o l l o w " )@myNode then
out ( message , senderNode , " r e a d " )@myNode ;
i n ( message , senderNode , " unread " )@myNode ;
p r i n t s e n d e r + " s e n t you t h e f o l l o w i n g message : " + message ;
e v a l ( CheckNewMessages ( myNode , true ) ) @ s e l f
E.1 User.xklaim
129
nodes
User : : { s e r v e r I P ~ l o c a l h o s t : 1 1 0 0 0 }
p o r t 10000
declare
var myNode : l o c ;
var blogNumber : i n t
begin
var blogDispCount : i n t ;
var blogNumber : i n t ;
var anyUser : s t r ;
var anyBlog : s t r ;
var a n y S u b j e c t : s t r
begin
blogDispCount := 0 ;
i f readp ( " s e r v e r I P " , ! s e r v e r I P ) @ s e l f then
p r i n t " t h i s i s t h e s e r v e r I P − " +s e r v e r I P
else
p r i n t "no s e r v e r I P found "
endif ;
p r i n t " t h i s i s your node ip − " + myNode ;
read (" serverIP " , ! serverIP ) @ s e l f ;
i n ( " blogNumber " , ! blogNumber )@myNode ;
e v a l ( GiveTimestamp ( myNode ) ) @serverIP ;
i n ( " timestamp " , ! timestampNow )@myNode ;
#readp ( " b l o g " , ! anyBlog , ! anyNode , ! timestampLast ) @serverIP ;
f o r a l l readp ( " b l o g " , ! anyBlog , ! anySubject , ! anyNode , ! timestampLast ) @serverIP do
p r i n t "now t r y t o s e e i f you and t h e b l o g g e r you found a r e f r i e n d s " ;
i f readp ( ! anyUser , anyNode , " f o l l o w " )@myNode then
p r i n t anyUser + " wrote − " + a n y S u b j e c t + " − " + anyBlog
else
p r i n t " you and t h i s b l o g g e r a r e not f r i e n d s "
endif
enddo
end
130
Appendix E
r e c CreateAccount [ userName : s t r , password : s t r , i p : l o c ]
declare
var anyUser : s t r ;
r e c Frontpage [ node : l o c ] e x t e r n ;
rec DisplayError [ error : s t r ] extern ;
p r i n t " u s e r " + added + " not found "
endif
end ;
else
#Some s m a r t e r way for a f r i e n d l i s t c o u l d be u s e f u l
r e c AddFriend [ adderNode : l o c , added : s t r ]
declare
var addedPass : s t r ;
var addedNode : l o c ;
var adder : s t r ;
var adderPass : s t r
begin
i f readp ( added , ! addedPass , ! addedNode ) @ s e l f then
r e a d ( ! adder , ! adderPass , adderNode ) @ s e l f ;
out ( " f r i e n d r e q u e s t " , adder , adderNode ) @addedNode ;
p r i n t adder+" − "+adderNode+" s u c c e s s f u l l y t r i e d t o add "+added+" − "+addedNode
E.2 Server.xklaim
e v a l ( CreateAccount ( " t e s t u s e r " , " t e s t p a s s w o r d " , ∗ s e l f ) ) @serverIP
#r e a d ( " yourNode " , ! myNode ) @ s e l f
#e v a l ( C h e c k I n v i t e s ( ) ) @myNode ;
#e v a l ( CheckNewMessages ( ) ) @myNode ;
#e v a l ( GetBlogs ( ) ) @myNode
end
endnodes
E.2 Server.xklaim
131
r e c CreateEvent [ eventName : s t r , password : s t r , i p : l o c ]
declare
var anyEvent : s t r ;
var anyPass : s t r ;
var newNode : l o c
begin
newloc ( newNode ) ;
i f readp ( eventName , ! anyPass , ! anyNode ) @ s e l f then
out ( userName , password , newNode ) @ s e l f ;
p r i n t " User : " + userName + " − has been s u c c e s s f u l l y c r e a t e d ! " ;
p r i n t " h i s node i s " + newNode ;
out ( " s e r v e r I P " , ∗ s e l f ) @newNode ;
out ( " blogNumber " , 0 ) @newNode ;
out ( " yourNode " , newNode ) @ip ;
e v a l ( Frontpage ( newNode ) ) @ip
#out ( " b l o g " , "Welcome t o D i g i t a l T o r f i " , " O l a f u r " , 0 , 0 ) @newNode
#u s e r made , u s e r i s l o g g e d i n o r taken t o a l o g i n page .
endif
endif
end ;
else
e v a l ( D i s p l a y E r r o r ( " This Should Not Happen , node i s taken " ) ) @ip ;
p r i n t " User : " + userName + " i s a l r e a d y taken "
else
i f readp ( ! anyUser , ! anyPass , newNode ) @ s e l f then
var newNode : l o c
#newloc i s used even when a c c o u n t not c r e a t e d
begin
#newNode := newloc ( ) ;
i f readp ( userName , ! anyPass , ! anyNode ) @ s e l f then
e v a l ( D i s p l a y E r r o r ( " username taken " ) ) @ip
132
Appendix E
r e c E v e n t I n v i t e [ adder : s t r , eventName : s t r , added : s t r ]
out ( groupName , password , newNode ) @ s e l f ;
e v a l ( Frontpage ( newNode ) ) @ip ;
#e v e n t made , u s e r i s l o g g e d i n o r taken t o a l o g i n page .
out ( " groupNode " , newNode ) @ip ;
i f readp ( ! anyGroup , ! anyPass , newNode ) @ s e l f then
e v a l ( D i s p l a y E r r o r ( " This Should Not Happen , node i s taken " ) ) @ip
endif
endif
end ;
else
r e c CreateGroup [ groupName : s t r , password : s t r , i p : l o c ]
declare
var anyGroup : s t r ;
var newNode : l o c
begin
i f readp ( groupName , ! anyPass , ! anyNode ) @ s e l f then
e v a l ( D i s p l a y E r r o r ( " groupname i s taken " ) ) @ip
#groupName i s taken − some d i s p l a y e v e n t
out ( eventName , password , newNode ) @ s e l f ;
e v a l ( Frontpage ( newNode ) ) @ip ;
#e v e n t made , u s e r i s l o g g e d i n o r taken t o a l o g i n page .
out ( " eventNode " , newNode ) @ip ;
i f readp ( ! anyEvent , ! anyPass , newNode ) @ s e l f then
e v a l ( D i s p l a y E r r o r ( " This Should Not Happen , node i s taken " ) ) @ip
endif
endif
end ;
else
e v a l ( D i s p l a y E r r o r ( " eventname i s taken " ) ) @ip
#eventName i s taken − some d i s p l a y e v e n t
E.2 Server.xklaim
133
r e c LoginUser [ name : s t r , password : s t r , i p : l o c ]
declare
var anyNode : l o c
begin
i f readp ( name , password , ! anyNode ) @ s e l f then
r e c G r o u p I n v i t e [ adder : s t r , groupName : s t r , added : s t r ]
declare
var groupPass : s t r ;
var groupNode : l o c
begin
i f readp ( added , ! addedPass , ! addedNode ) @ s e l f and readp ( groupName , ! groupPass , ! groupNode ) @ s e l f then
out ( " group i n v i t e " , adder , groupName , groupNode ) @addedNode
endif
end ;
r e c GiveTimestamp [ i p : l o c ]
declare
var timestamp : int
begin
r e a d ( " timestamp " , ! timestamp ) @ s e l f ;
out ( " timestamp " , timestamp ) @ip
end ;
declare
var e v e n t P a s s : s t r ;
var eventNode : l o c
begin
i f readp ( added , ! addedPass , ! addedNode ) @ s e l f and readp ( eventName , ! eventPass , ! eventNode ) @ s e l f then
out ( " e v e n t i n v i t e " , adder , eventName , eventNode ) @addedNode
endif
end ;
134
Appendix E
r e c SendMessage [ s e n d e r : l o c , r e c e i v e r : s t r , message : s t r ]
declare
r e c MakeBlog [ senderNode : l o c , b l o g : s t r , s e n d e r : l o c ]
declare
var timestamp : int
begin
i n ( " timestamp " , ! timestamp ) @ s e l f ;
timestamp := timestamp + 1 ;
out ( " timestamp " , timestamp ) @ s e l f ;
out ( " b l o g " , blog , senderNode , timestamp ) @ s e l f ;
e v a l ( D i s p l a y E r r o r ( " d i s p l a y e r r o r t o t a l l y works wohoo" ) ) @sender
end ;
r e c LogoutUser [ i p : l o c ]
declare
var name : s t r ;
var s e r v e r N o d e : l o c
begin
in ( " serverIP " , ! serverNode ) @self ;
i n ( " yourNode " , ! anyNode ) @ s e l f ;
i n ( "yourName" , ! name ) @ s e l f ;
e v a l ( Frontpage ( ∗ s e l f ) ) @ip
end ;
e v a l ( D i s p l a y E r r o r ( "Wrong username o r password . " ) ) @ip
endif
end ;
else
out ( " s e r v e r I P " , ∗ s e l f ) @ip ;
p r i n t ∗ s e l f + " put on " + i p ;
out ( " yourNode " , anyNode ) @ip ;
p r i n t anyNode + " put on " + i p ;
out ( "yourName" , name ) @ip ;
e v a l ( Frontpage ( anyNode ) ) @ip
E.2 Server.xklaim
135
m4
m4
m4
m4
m4
m4
m4
m4
m4
m4
m4
AddFriend . m4 > s r c / autogen / AddFriend . j a v a
C h e c k I n v i t e s . m4 > s r c / autogen / C h e c k I n v i t e s . j a v a
CheckNewMessages . m4 > s r c / autogen / CheckNewMessages . j a v a
ConfirmEvent . m4 > s r c / autogen / ConfirmEvent . j a v a
ConfirmGroup . m4 > s r c / autogen / ConfirmGroup . j a v a
ConfirmFriend . m4 > s r c / autogen / ConfirmFriend . j a v a
CreateAccount . m4 > s r c / autogen / CreateAccount . j a v a
CreateEvent . m4 > s r c / autogen / CreateEvent . j a v a
CreateGroup . m4 > s r c / autogen / CreateGroup . j a v a
D i s p l a y E r r o r . m4 > s r c / autogen / D i s p l a y E r r o r . j a v a
E v e n t I n v i t e . m4 > s r c / autogen / E v e n t I n v i t e . j a v a
E.3 CompileAll.sh
nodes
server ::{}
p o r t 11000
declare
var timestamp : int ;
var b l o g : s t r ;
var senderNode : s t r
begin
timestamp := 0 ; #i t would be n i c e t o r e p l a c e this with a r e a l timestamp
out ( " timestamp " , timestamp ) @ s e l f
end
endnodes
var anyPass : s t r
begin
i f readp ( r e c e i v e r , ! anyPass , ! anyNode ) @ s e l f then
out ( message , s e n d e r , " unread " ) @anyNode
endif
end
136
Appendix E
Frontpage . m4 > s r c / autogen / Frontpage . j a v a
GetBlogs . m4 > s r c / autogen / GetBlogs . j a v a
GiveTimestamp . m4 > s r c / autogen / GiveTimestamp . j a v a
G r o u p I n v i t e . m4 > s r c / autogen / G r o u p I n v i t e . j a v a
LoginUser . m4 > s r c / autogen / LoginUser . j a v a
LogoutUser . m4 > s r c / autogen / LogoutUser . j a v a
MakeBlog . m4 > s r c / autogen /MakeBlog . j a v a
SendMessage . m4 > s r c / autogen / SendMessage . j a v a
AddFriendK . m4 > s r c / methods /AddFriendK . j a v a
BlogK . m4 > s r c / methods /BlogK . j a v a
CreateAccountK . m4 > s r c / methods / CreateAccountK . j a v a
CreateEventK . m4 > s r c / methods / CreateEventK . j a v a
CreateGroupK . m4 > s r c / methods / CreateGroupK . j a v a
LoginK . m4 > s r c / methods / LoginK . j a v a
SendMessageK . m4 > s r c / methods / SendMessageK . j a v a
changequote (Ã 43 , Ã◦ )
i n c l u d e ( S p e c i f i c a t i o n s . m4)
E.4 MakeBlog.m4
j a v a c s r c / autogen / AddFriend . j a v a s r c / autogen / C h e c k I n v i t e s . j a v a s r c / autogen / CheckNewMessages . j a v a
s r c / autogen / ConfirmEvent . j a v a s r c / autogen / ConfirmFriend . j a v a s r c / autogen / ConfirmGroup . j a v a
s r c / autogen / CreateAccount . j a v a s r c / autogen / CreateEvent . j a v a s r c / autogen / CreateGroup . j a v a
s r c / autogen / D i s p l a y E r r o r . j a v a s r c / autogen / E v e n t I n v i t e . j a v a s r c / autogen / Frontpage . j a v a
s r c / autogen / GetBlogs . j a v a s r c / autogen / GiveTimestamp . j a v a s r c / autogen / G r o u p I n v i t e . j a v a
s r c / autogen / LoginUser . j a v a s r c / autogen / LogoutUser . j a v a s r c / autogen /MakeBlog . j a v a
s r c / autogen / SendMessage . j a v a s r c / autogen / S e r v e r . j a v a
m4 SwingJApplet . m4 > s r c / t h e A p p l e t / SwingJApplet . j a v a
m4
m4
m4
m4
m4
m4
m4
m4 S e r v e r . m4 > s r c / autogen / S e r v e r . j a v a
m4
m4
m4
m4
m4
m4
m4
m4
E.4 MakeBlog.m4
137
// parameters
protected L o c a l i t y senderNode ;
protected KString b l o g ;
protected L o c a l i t y s e n d e r ;
protected KString b l o g S u b j e c t ;
// v a r i a b l e s
protected K I n t e g e r timestamp ;
// used d e f i n i t i o n names
protected D i s p l a y E r r o r __dummy_DisplayError ;
protected Tuple myTuple ;
//−−−−−−−−−−−−−−−−
protected K I n t e g e r blogLength ;
protected K I n t e g e r s u b j e c t L e n g t h ;
// temporary s t r i n g f o r c o n c a t i n a t i o n
S t r i n g output ;
// p r o t e c t e d K i n t e g e r s u b j e c t L e n g t h
//−−−−−−−−−−−−−−−−
public MakeBlog (
L o c a l i t y senderNode ,
KString b l o g S u b j e c t ,
KString blog ,
Locality sender
//
KInteger s u b j e c t L e n g t h
) {
// parameters
public c l a s s MakeBlog extends K l a v a P r o c e s s {
import j a v a . i o . ∗ ;
import Klava . ∗ ;
import methods . S t r i n g T o F i l e ;
package autogen ;
i f e l s e ( $2 , 0 ,
Ã 34 define ( MakeBlog ,Ã 34 Ã 34
138
Appendix E
t e x t L e n g t h = new K I n t e g e r ( $1 ) ;
i f ( ! ( t e x t L e n g t h == null ) && ! ( b l o g . t o S t r i n g ( ) . l e n g t h ( ) == 0 ) ) {
i f ( b l o g . t o S t r i n g ( ) . l e n g t h ( ) >t e x t L e n g t h . i n t V a l u e ( ) ) {
e v a l ( new D i s p l a y E r r o r ( new KString ( " Blog t o o l o n g " ) ) , s e n d e r ) ;
}
else {
timestamp = new K I n t e g e r ( ) ;
i n ( new KString ( " timestamp " ) , timestamp , s e l f ) ;
timestamp = new K I n t e g e r ( timestamp . i n t V a l u e ( ) + 1 ) ;
out ( new KString ( " timestamp " ) , timestamp , s e l f ) ;
out ( new KString ( " b l o g " ) , blog , senderNode , timestamp , s e l f ) ;
output = b l o g . t o S t r i n g ( ) ;
w r i t e . S t r i n g T o F i l e ( output ) ;
}
}
else {
i f ( t e x t L e n g t h == null ) {
out ( new KString ( " b l o g " ) , blog , senderNode , timestamp , s e l f ) ;
output = b l o g S u b j e c t . t o S t r i n g ( ) + " − " + b l o g . t o S t r i n g ( ) ;
}
else {
S t r i n g T o F i l e w r i t e = new methods . S t r i n g T o F i l e ( ) ;
public void e x e c u t e ( ) throws KlavaException {
}
this . senderNode = senderNode ;
this . b l o g S u b j e c t = b l o g S u b j e c t ;
this . b l o g = b l o g ;
this . s e n d e r = s e n d e r ;
E.4 MakeBlog.m4
139
eval (
new D i s p l a y E r r o r ( new KString ( " you can ' t b l o g with n o t h i n g " ) ) , s e n d e r ) ;
// parameters
protected L o c a l i t y senderNode ;
protected L o c a l i t y s e n d e r ;
protected KString b l o g S u b j e c t ;
protected D i s p l a y E r r o r __dummy_DisplayError ;
protected Tuple myTuple ;
//−−−−−−−−−−−−−−−−
protected K I n t e g e r blogLength ;
protected K I n t e g e r s u b j e c t L e n g t h ;
// p r o t e c t e d K i n t e g e r s u b j e c t L e n g t h
//−−−−−−−−−−−−−−−−
public MakeBlog (
public c l a s s MakeBlog extends K l a v a P r o c e s s {
package autogen ;
}Ã◦ Ã◦ )Ã◦ ,
Ã 34 define ( MakeBlog ,Ã 34 Ã 34
}
}
}
140
Appendix E
myTuple = new Tuple ( ) ;
myTuple . add ( new KString ( " b l o g " ) ) ;
myTuple . add ( b l o g S u b j e c t ) ;
myTuple . add ( b l o g ) ;
else {
}
else i f ( blogSubject . toString ( ) . length () > subjectLength . intValue ()){
e v a l ( new D i s p l a y E r r o r ( new KString ( " S u b j e c t t o o l o n g " ) ) , s e n d e r ) ;
}
//−−−−−−−−−−−−−−−−
blogLength = new K I n t e g e r ( $1 ) ;
s u b j e c t L e n g t h = new K I n t e g e r ( $2 ) ;
i f ( ! ( blogLength==null ) && ! ( b l o g . t o S t r i n g ( ) . l e n g t h ()==0) &&
! ( s u b j e c t L e n g t h==null ) && ! ( b l o g S u b j e c t . t o S t r i n g ( ) . l e n g t h ()==0)){
i f ( b l o g . t o S t r i n g ( ) . l e n g t h ( ) >blogLength . i n t V a l u e ( ) ) {
e v a l ( new D i s p l a y E r r o r ( new KString ( " Blog t o o l o n g " ) ) , s e n d e r ) ;
L o c a l i t y senderNode ,
KString b l o g S u b j e c t ,
KString blog ,
Locality sender
//
KInteger s u b j e c t L e n g t h
) {
// parameters
this . senderNode = senderNode ;
this . b l o g S u b j e c t = b l o g S u b j e c t ;
this . b l o g = b l o g ;
this . s e n d e r = s e n d e r ;
}
E.4 MakeBlog.m4
141
}
}
e v a l ( new D i s p l a y E r r o r ( new KString ( " you can ' t b l o g with no t e x t body o r s u b j e c t " ) ) , s e n d e r ) ;
else {
}
myTuple . add ( b l o g S u b j e c t ) ;
myTuple . add ( b l o g ) ;
myTuple . add ( senderNode ) ;
myTuple . add ( timestamp ) ;
out ( myTuple , s e l f ) ;
MakeBlog ( B l o g L e n g t h R e s t r i c t i o n , B l o g S u b j e c t )
Ã◦ Ã◦ )Ã◦
)
}
}
}
else {
i f ( ( blogLength == null ) | | ( s u b j e c t L e n g t h == null ) ) {
myTuple = new Tuple ( ) ;
myTuple . add ( new KString ( " b l o g " ) ) ;
myTuple . add ( senderNode ) ;
myTuple . add ( timestamp ) ;
out ( myTuple , s e l f ) ;
}
142
Appendix E
// parameters
protected L o c a l i t y myNode ;
protected L o c a l i t y s e r v e r I P ;
protected K I n t e g e r timestampNow ;
protected K I n t e g e r timestampLast ;
protected K I n t e g e r blogDispCount ;
protected K I n t e g e r blogNumber ;
protected KString anyUser ;
protected KString anyBlog ;
protected L o c a l i t y anyNode ;
protected KString a n y S u b j e c t ;
protected Tuple __tuple_7 ;
protected L o c a l i t y __backup_8_serverIP ;
protected KBoolean __to_7 ;
protected KString __backup_9_anySubject ;
protected KString __backup_10_anyBlog ;
protected L o c a l i t y __backup_11_anyNode ;
protected K I n t e g e r __backup_12_timestampLast ;
public c l a s s GetBlogs extends K l a v a P r o c e s s {
i f e l s e ( $2 , 0 ,
Ã 34 define ( GetBlogs ,Ã 34 Ã 43
package autogen ;
E.5 GetBlogs.m4
E.5 GetBlogs.m4
143
__backup_8_serverIP = s e r v e r I P ;
s e r v e r I P = new P h y s i c a l L o c a l i t y ( ) ;
__tuple_7 . add ( s e r v e r I P ) ;
__to_7 = new KBoolean ( read_nb ( __tuple_7 , s e l f ) ) ;
i f ( ! __to_7 . b o o l e a n V a l u e ( ) ) {
s e r v e r I P = __backup_8_serverIP ;
}
i f ( __to_7 . b o o l e a n V a l u e ( ) ) {
P r i n t ( new KString ( " t h i s i s t h e s e r v e r I P − " . c o n c a t ( s e r v e r I P . t o S t r i n g ( ) . t o S t r i n g ( ) ) ) ) ;
} else {
P r i n t ( new KString ( "no s e r v e r I P found " ) ) ;
}
P r i n t ( new KString ( " t h i s i s your node ip − " . c o n c a t ( myNode . t o S t r i n g ( ) . t o S t r i n g ( ) ) ) ) ;
r e a d ( new KString ( " s e r v e r I P " ) , s e r v e r I P , s e l f ) ;
blogDispCount = new K I n t e g e r ( 0 ) ;
__tuple_7 = new Tuple ( ) ;
__tuple_7 . add ( new KString ( " s e r v e r I P " ) ) ;
L o c a l i t y myNode
) {
// parameters
this . myNode = myNode ;
}
public GetBlogs (
KBoolean _forall_exp_1 ;
Tuple __tuple_9 ;
KString __backup_13_anyUser ;
KBoolean __to_9 ;
protected GiveTimestamp __dummy_GiveTimestamp ;
protected
protected
protected
protected
144
Appendix E
blogNumber = new K I n t e g e r ( ) ;
i n ( new KString ( " blogNumber " ) , blogNumber , myNode ) ;
e v a l ( new GiveTimestamp ( myNode ) , s e r v e r I P ) ;
timestampNow = new K I n t e g e r ( ) ;
i n ( new KString ( " timestamp " ) , timestampNow , myNode ) ;
__tuple_8 . s e t H a n d l e R e t r i e v e d ( true ) ;
__tuple_8 . add ( new KString ( " b l o g " ) ) ;
__backup_9_anyBlog = anyBlog ;
anyBlog = new KString ( ) ;
__tuple_8 . add ( anyBlog ) ;
__backup_10_anyNode = anyNode ;
anyNode = new P h y s i c a l L o c a l i t y ( ) ;
__tuple_8 . add ( anyNode ) ;
__backup_11_timestampLast = timestampLast ;
timestampLast = new K I n t e g e r ( ) ;
__tuple_8 . add ( timestampLast ) ;
__to_8 = new KBoolean ( read_nb ( __tuple_8 , s e r v e r I P ) ) ;
anyBlog = __backup_9_anyBlog ;
anyNode = __backup_10_anyNode ;
timestampLast = __backup_11_timestampLast ;
}
_forall_exp_1 = __to_8 ;
while ( _forall_exp_1 . b o o l e a n V a l u e ( ) ) {
P r i n t ( new KString ( "now t r y t o s e e i f you and t h e b l o g g e r you found a r e f r i e n d s " ) ) ;
__backup_12_anyUser = anyUser ;
anyUser = new KString ( ) ;
__tuple_9 . add ( anyUser ) ;
__tuple_9 . add ( new KString ( " f o l l o w " ) ) ;
__to_9 = new KBoolean ( read_nb ( __tuple_9 , myNode ) ) ;
anyUser = __backup_12_anyUser ;
}
E.5 GetBlogs.m4
145
package autogen ;
Ã 43 define ( GetBlogs ,Ã 34 Ã 34
}
}
}Ã◦ Ã◦ )Ã◦ ,
output = anyUser . t o S t r i n g ( ) + " wrote : " + anyBlog . t o S t r i n g ( ) ;
} else {
P r i n t ( new KString ( " you and t h i s b l o g g e r a r e not f r i e n d s " ) ) ;
}
__tuple_8 . r e s e t ( ) ;
}
P r i n t ( new KString ( anyUser . c o n c a t ( " wrote − " . t o S t r i n g ( ) ) . c o n c a t ( anyBlog . t o S t r i n g ( ) ) ) ) ;
146
Appendix E
L o c a l i t y myNode
) {
// parameters
public GetBlogs (
// parameters
protected L o c a l i t y s e r v e r I P ;
protected K I n t e g e r timestampNow ;
protected K I n t e g e r timestampLast ;
protected K I n t e g e r blogDispCount ;
protected KString anyUser ;
protected KString anyBlog ;
protected L o c a l i t y anyNode ;
protected KString a n y S u b j e c t ;
protected L o c a l i t y __backup_8_serverIP ;
protected KString __backup_9_anySubject ;
protected KString __backup_10_anyBlog ;
protected L o c a l i t y __backup_11_anyNode ;
protected K I n t e g e r __backup_12_timestampLast ;
protected KBoolean _forall_exp_1 ;
protected KString __backup_13_anyUser ;
protected GiveTimestamp __dummy_GiveTimestamp ;
public c l a s s GetBlogs extends K l a v a P r o c e s s {
E.5 GetBlogs.m4
147
this . myNode = myNode ;
__backup_8_serverIP = s e r v e r I P ;
__tuple_7 . add ( s e r v e r I P ) ;
__to_7 = new KBoolean ( read_nb ( __tuple_7 , s e l f ) ) ;
s e r v e r I P = __backup_8_serverIP ;
}
P r i n t ( new KString ( " t h i s i s t h e s e r v e r I P − " . c o n c a t ( s e r v e r I P . t o S t r i n g ( ) . t o S t r i n g ( ) ) ) ) ;
} else {
P r i n t ( new KString ( "no s e r v e r I P found " ) ) ;
}
P r i n t ( new KString ( " t h i s i s your node ip − " . c o n c a t ( myNode . t o S t r i n g ( ) . t o S t r i n g ( ) ) ) ) ;
r e a d ( new KString ( " s e r v e r I P " ) , s e r v e r I P , s e l f ) ;
blogNumber = new K I n t e g e r ( ) ;
i n ( new KString ( " blogNumber " ) , blogNumber , myNode ) ;
e v a l ( new GiveTimestamp ( myNode ) , s e r v e r I P ) ;
timestampNow = new K I n t e g e r ( ) ;
i n ( new KString ( " timestamp " ) , timestampNow , myNode ) ;
__tuple_8 . s e t H a n d l e R e t r i e v e d ( true ) ;
__backup_9_anySubject = a n y S u b j e c t ;
a n y S u b j e c t = new KString ( ) ;
__tuple_8 . add ( a n y S u b j e c t ) ;
blogDispCount = new K I n t e g e r ( 0 ) ;
__tuple_7 . add ( new KString ( " s e r v e r I P " ) ) ;
}
148
Appendix E
a n y S u b j e c t = __backup_9_anySubject ;
}
while ( _forall_exp_1 . b o o l e a n V a l u e ( ) ) {
P r i n t ( new KString ( "now t r y t o s e e i f you and t h e b l o g g e r you found a r e f r i e n d s " ) ) ;
__backup_13_anyUser = anyUser ;
anyUser = new KString ( ) ;
__tuple_9 . add ( anyUser ) ;
__tuple_9 . add ( new KString ( " f o l l o w " ) ) ;
__to_9 = new KBoolean ( read_nb ( __tuple_9 , myNode ) ) ;
anyUser = __backup_13_anyUser ;
}
P r i n t ( new KString ( anyUser . c o n c a t ( " wrote − " . t o S t r i n g ( ) ) . c o n c a t ( a n y S u b j e c t . t o S t r i n g ( )
) . c o n c a t ( " − " . t o S t r i n g ( ) ) . c o n c a t ( anyBlog . t o S t r i n g ( ) ) ) ) ;
output = anyUser . t o S t r i n g ( ) + " wrote : " + a n y S u b j e c t . t o S t r i n g ( ) + " − " + anyBlog . t o S t r i n g ( ) ;
} else {
P r i n t ( new KString ( " you and t h i s b l o g g e r a r e not f r i e n d s " ) ) ;
}
__tuple_8 . r e s e t ( ) ;
E.5 GetBlogs.m4
149
}
E.6 swingJApplet
GetBlogs ( B l o g L e n g t h R e s t r i c t i o n , B l o g S u b j e c t )
}
Ã◦ Ã◦ )Ã◦
)
}
__backup_9_anySubject = a n y S u b j e c t ;
a n y S u b j e c t = new KString ( ) ;
__tuple_8 . add ( a n y S u b j e c t ) ;
a n y S u b j e c t = __backup_9_anySubject ;
}
150
Appendix E
Klava . KString ;
Klava . K l a v a A p p l i c a t i o n ;
j a v a . i o . FileNotFoundException ;
j a v a . i o . IOException ;
Klava . KlavaException ;
Klava . N e t U t i l s ;
Klava . Node ;
java . io . F i l e ;
java . io . FileInputStream ;
j a v a . u t i l . Scanner ;
java . u t i l . logging . Level ;
j a v a . u t i l . l o g g i n g . Logger ;
methods . AddFriendK ;
methods . BlogK ;
methods . CreateAccountK ;
methods . CreateEventK ;
methods . CreateGroupK ;
methods . LoginK ;
methods . SendMessageK ;
methods . S t r i n g T o F i l e ;
// V a r i a b l e s
int yourLoginNode = 0 ;
public c l a s s swingJApplet extends j a v a x . swing . JApplet {
∗
∗ @author O l a f u r
∗/
/∗ ∗
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
import
∗
∗ Created on 1 0 . 1 1 . 2 0 1 0 , 2 0 : 3 4 : 1 4
∗/
d e f i n e ( SwingJApplet ,Ã 34 Ã 34
package t h e A p p l e t ;
/∗
∗ swingJApplet . java
E.6 swingJApplet
151
j a v a . awt . EventQueue . invokeAndWait ( new Runnable ( ) {
public void run ( ) {
initComponents ( ) ;
}
});
} catch ( E x c e p t i o n ex ) {
public void i n i t ( ) {
try {
// t e s t methods and c l a s s e s
public void d i s p l a y t e x t ( ) {
try {
S t r i n g B u i l d e r t e x t = new S t r i n g B u i l d e r ( ) ;
S t r i n g NL = System . g e t P r o p e r t y ( " l i n e . s e p a r a t o r " ) ;
Scanner s c a n n e r = new Scanner ( new F i l e I n p u t S t r e a m ( f i l e ) ) ;
try {
while ( s c a n n e r . hasNextLine ( ) ) {
t e x t . append ( s c a n n e r . n e x t L i n e ( ) ) . append (NL ) ;
}
jTextArea1 . append ( t e x t . t o S t r i n g ( ) ) ;
} finally {
scanner . c l o s e ( ) ;
}
f i l e . delete ();
F i l e f i l e = new F i l e ( " t e s t . t x t " ) ;
w r i t e . S t r i n g T o F i l e ( "" ) ;
} catch ( FileNotFoundException ex ) {
Logger . g e t L o g g e r ( swingJApplet . c l a s s . getName ( ) ) . l o g ( L e v e l . SEVERE, null , ex ) ;
}
}
/∗ ∗ I n i t i a l i z e s t h e a p p l e t s w i n g J A p p l e t ∗/
int nodeNum = 1 0 0 0 0 ;
private Node yourNode ;
public S t r i n g monitored = "" ;
F i l e f i l e = new F i l e ( " t e s t . t x t " ) ;
152
Appendix E
ex . p r i n t S t a c k T r a c e ( ) ;
} catch ( I n t e r r u p t e d E x c e p t i o n ex ) {
} catch ( IOException ex ) {
System . out . p r i n t l n ( ex ) ;
} catch ( KlavaException ex ) {
// Create Account
try {
S t r i n g userName = j T e x t F i e l d 1 . getText ( ) ;
S t r i n g password = j T e x t F i e l d 2 . getText ( ) ;
K l a v a A p p l i c a t i o n app = new K l a v a A p p l i c a t i o n ( ) ;
nodeNum++;
Node User = new Node ( " User " , nodeNum , " l o c a l h o s t " , I n t e g e r . p a r s e I n t ( " 9999 " ) ) ;
yourNode = User ;
yourNode . addToEnv ( " s e r v e r I P " , N e t U t i l s . c r e a t e N o d e A d d r e s s ( " l o c a l h o s t : 1 1 0 0 0 " ) ) ;
app . addNode ( yourNode ) ;
yourNode . a d d P r o c e s s ( new CreateAccountK ( new KString ( userName ) , new KString ( password ) ) ) ;
app . s t a r t N o d e s ( ) ;
Thread . s l e e p ( 1 0 0 0 ) ;
System . out . p r i n t l n ( " I have now s l e p t l o n g enough f o r you t o c o n t i n u e " ) ;
app . removeNode ( yourNode ) ;
displaytext ();
private void j B u t t o n 1 A c t i o n P e r f o r m e d ( j a v a . awt . e v e n t . ActionEvent e v t ) {
\∗
∗
∗ Here was code needed for i n i t ( )
∗ i t was a u t o m a t i c a l l y g e n e r a t e d and un− n e c c e s a r y t o show h e r e .
∗
∗/
}
}
E.6 swingJApplet
153
// Log i n
try {
nodeNum++;
Node Login = new Node ( " Login " , nodeNum , " l o c a l h o s t " , I n t e g e r . p a r s e I n t ( " 9999 " ) ) ;
yourNode = Login ;
yourNode . a d d P r o c e s s ( new LoginK ( new KString ( userName ) , new KString ( password ) ) ) ;
Thread . s l e e p ( 1 5 0 0 ) ;
displaytext ();
// Make Blog
try {
}
}
}
}
154
Appendix E
// Add Friend
try {
S t r i n g friendName = j T e x t F i e l d 6 . getText ( ) ;
// app . addNode ( yourNode ) ;
yourNode . a d d P r o c e s s ( new AddFriendK ( new KString ( friendName ) ) ) ;
Thread . s l e e p ( 1 0 0 0 ) ;
displaytext ();
}
}
// LOG OUT:
nodeNum++;
yourNode = null ;
private void j T o g g l e B u t t o n 4 A c t i o n P e r f o r m e d ( j a v a . awt . e v e n t . ActionEvent e v t ) {
}
}
S t r i n g blogBody = j T e x t F i e l d 5 . getText ( ) ;
yourNode . a d d P r o c e s s ( new BlogK ( new KString ( blogBody ) ) ) ;
Thread . s l e e p ( 1 0 0 0 ) ;
displaytext ();
}
E.6 swingJApplet
155
// Create Group
try {
nodeNum++;
yourNode = User ;
yourNode . a d d P r o c e s s ( new CreateGroupK ( new KString ( userName ) , new KString ( password ) ) ) ;
Thread . s l e e p ( 1 0 0 0 ) ;
displaytext ();
}
// SEND MESSAGE:
try {
S t r i n g message = j T e x t F i e l d 4 . getText ( ) ;
// app . addNode ( yourNode ) ;
yourNode . a d d P r o c e s s ( new SendMessageK ( new KString ( userName ) , new KString ( message ) ) ) ;
Thread . s l e e p ( 1 0 0 0 ) ;
displaytext ();
}
156
Appendix E
// Create Event
try {
// jTextArea1 . removeAll ( ) ;
// F i l e f i l e = new F i l e (" t e s t . t x t " ) ;
nodeNum++;
yourNode = User ;
yourNode . a d d P r o c e s s ( new CreateEventK ( new KString ( userName ) , new KString ( password ) ) ) ;
Thread . s l e e p ( 1 0 0 0 ) ;
displaytext ();
}
}
E.6 swingJApplet
157
SwingJApplet ( )
Ã◦ Ã◦ )
}
// V a r i a b l e s d e c l a r a t i o n − do not modify
private j a v a x . swing . JButton jButton1 ;
private j a v a x . swing . JLabel j L a b e l 1 ;
private j a v a x . swing . J S c r o l l P a n e j S c r o l l P a n e 1 ;
private j a v a x . swing . JTextArea jTextArea1 ;
private j a v a x . swing . J T e x t F i e l d j T e x t F i e l d 1 ;
private j a v a x . swing . JToggleButton j T o g g l e B u t t o n 1 ;
// End o f v a r i a b l e s d e c l a r a t i o n
}
}
158
Appendix E
}
app . addNode ( s e r v e r ) ;
s e r v e r . a d d P r o c e s s ( new __server_1 ( ) ) ;
app . waitForNodesAndTerminate ( ) ;
public c l a s s S e r v e r {
s t a t i c public void main ( S t r i n g a r g s [ ] ) throws IOException , KlavaException {
Node s e r v e r = new Node ( " s e r v e r " , 1 1 0 0 0 , " l o c a l h o s t " , I n t e g e r . p a r s e I n t ( " 9999 " ) ) ;
}
}
// main c l a s s
timestamp = new K I n t e g e r ( 0 ) ;
public __server_1 ( ) {}
protected KString senderNode ;
c l a s s __server_1 extends K l a v a P r o c e s s {
package autogen ;
d e f i n e ( S e r v e r ,Ã 34 Ã 34
E.7 Server.m4
E.7 Server.m4
159
// parameters
protected KString blogBody ;
protected K I n t e g e r l o g i n N o d e ;
protected L o g i c a l L o c a l i t y s e r v e r I P = new L o g i c a l L o c a l i t y ( " s e r v e r I P " ) ;
protected CreateAccount __dummy_CreateAccount ;
protected MakeBlog __dummy_MakeBlog ;
protected SendMessage __dummy_SendMessage ;
public c l a s s BlogK extends K l a v a P r o c e s s {
∗
∗ @author o l a f u r
∗/
/∗ ∗
import autogen . ∗ ;
package methods ;
d e f i n e ( BlogK ,Ã 34 Ã 34
E.8 BlogK.m4
Server ()
Ã◦ Ã◦ )
}
160
Appendix E
}
KString blogBody / ∗ ,
KInteger l o g i n N o d e ∗ /
) {
// parameters
this . blogBody = blogBody ;
t h i s . loginNode = loginNode ;
}
myNode = new P h y s i c a l L o c a l i t y ( ) ;
r e a d ( new KString ( " yourNode " ) , myNode , s e l f ) ;
e v a l ( new MakeBlog ( myNode , new KString ( " Blog " ) , blogBody ,
new P h y s i c a l L o c a l i t y ( g e t P h y s i c a l L o c a l i t y ( s e l f ) ) ) , s e r v e r I P ) ;
BlogK ( )
Ã◦ Ã◦ )
}
//
public BlogK (
protected AddFriend __dummy_AddFriend ;
E.8 BlogK.m4
161
162
Appendix E
Bibliography
[1] danah m. boyd, Nicole B. Ellison. Social network sites: Denition, history, and scholarship. Journal of Computer-Mediated Communication Article, 2007, available at http://jcmc.indiana.edu/vol13/issue1/boyd.
ellison.html
[2] News Corp in 580m.usd. internet buy. 2005, available at http://news.bbc.
co.uk/2/hi/business/4695495.stm
[3] IAC Annual Report. United States, securities and exchange commission, 2010 available at http://ir.iac.com/secfiling.cfm?filingID=
1047469-10-1538
[4] Christopher
Nickson.
2009,
available
at
The
History
of
Social
Networking.
http://www.digitaltrends.com/features/
the-history-of-social-networking
[5] Gary Rivlin. YourMoneyArticle, 2006, available at http://www.nytimes.
com/2006/10/15/business/yourmoney/15friend.html?_r=1
[6] Je
2009,
Weiner, LinkedIn:
available
at
[7] The
History
50
million
professionals
worldwide,
http://blog.linkedin.com/2009/10/14/
linkedin-50-million-professionals-worldwide/
Of
Myspace,
2010,
available
webhostingreport.com/learn/myspace.html
at
http://www.
[8] Paul Glazowski, Bebo Founders Talk History Of Network And Past Web Efforts, 2008, available at http://mashable.com/2008/03/16/bebo-history/
164
BIBLIOGRAPHY
[9] Askwiki, History of Orkut, 2006, available at http://askwiki.blogspot.
com/2006/09/history-of-orkut.html
[10] Paul Adams, The Real Life Social Network v2 2010, available at http:
//www.slideshare.net/padday/the-real-life-social-network-v2
[11] USA Today, Flickr of idea on a gaming project led to photo
website, 2006, available at http://www.usatoday.com/tech/products/
2006-02-27-flickr_x.htm
[12] Linda Roeder, Where Did Facebook Come From?, About.com, 2007,
available at http://personalweb.about.com/od/makefriendsonfacebook/
a/whatisfacebook_5.htm
[13] John
Hudson,
Will
Facebook's
E-Mail
Service
Demolish Gmail and Hotmail?,
AtlanticWire, 2010, available at
http://news.yahoo.com/s/atlantic/20101112/cm_atlantic/
willfacebooksemailservicedemolishgmailandhotmail5782
[14] Jerry L Work, The History of Twitter and What it Means to Tweet EzineArticles, 2009, available at [?]
[15] Kenneth J. Turner, Exploiting the m4 Macro Language, University of Stirling, Department of Computing Science and Mathematics 1994, available at
http://www.bloomberg.com/video/64042122/
[16] Rocco De Nicola, Gian Luigi Ferrari, and Rosario Pugliese. KLAIM: A
Kernel Language for Agents Interaction and Mobility, IEEE Transactions
on Software Engineering, Vol.24, No.5. 1998. Available at http://www.cs.
unicam.it/merelli/Calcolo/TSE98-Klaim.pdf
[17] Lorenzo Bettini. X-KLAIM: A Programming Language for Object-Oriented
Mobile Code, Universitá di Firenze, Dipartimento di Sistemi e Infor-matica,
2004, available at http://music.dsi.unifi.it/download/xklaim.pdf
[18] BettiniLorenzo Bettini. KLAVA: a Java package for distributed and mobile
applications, Universitá di Firenze, Dipartimento di Sistemi e Informatica,
2004, available at http://music.dsi.unifi.it/download/klava.pdf
[19] Robert Björnson, Nicholas Carriero, David Gelernter and Jerrold Leichter Linda, the Portable Parallel, Yale University, Department of Computer Science, 1988, available at http://www.cs.yale.edu/publications/
techreports/tr520.pdf
[20] oxyweb.co.uk/blog, available at http://francisanderson.wordpress.
com/2008/11/01/\social-media-world-map-of-social-nets-\
blogs-are-over-craigslist-crime-qik-tribesmart/
BIBLIOGRAPHY
165
[21] Facebook company timeline, available at http://www.facebook.com/
press/info.php?timeline
[22] Facebook Developers, Authentication, available at http://developers.
facebook.com/docs/authentication/
[23] Facebook Developers, Graph API Overview, available at http://
developers.facebook.com/docs/api
[24] Facebook Developers, Open Graph Protocol, available at http://
developers.facebook.com/docs/opengraph
[25] Facebook Developers, Social Plugins, available at http://developers.
facebook.com/plugins
[26] Fahad Owais Capability File Names over HTTP, Technical University of Denmark, 2010, available at http://orbit.dtu.dk/getResource?
recordId=266178&objectId=1&versionId=1
[27] Bloomberg, Article: MySpace's Michael Jones Interview About Site Relaunch 2010, available at http://www.bloomberg.com/video/64042122/

A Domain Specific Language For A Distributed Social

Transcription

Similar documents

49 - Effect of myofascial techniques applied to the cranial region on

Jimmy Gnecco (of Ours) at Schubas | Live Review

Module 1 Communica ion

Lawlor`s Personal Branding Checklist

CS 268: Computing Networking People

investigating invariant pattern recognition using a flexible

Deana Allen, RN, AIC, ARM, CPHRM SVP, National Health Care

Connected - Center for Development and Disability

1 Highlights of Memorial Day Congressional Recess Radio Tour

Programme - Gauteng Film Commission