As we anticipate submission of multiple implementations of the same web application, we need to ensure that each implementation follows certain guidelines to make the implementations equivalent. This document is an attempt to lay out some of the feature requirements for the application. This is not a full-fledged document but rather is intended to be used along with the PHP application.
All implementations of the Olio web application must use the same CSS, screen layout and images as the original implementations. Differing color schemes are encouraged as to segregate the looks of one implementation from the others. But beyond color, the images used as part of the web page decoration must all be the same.
The web pages must exactly mimic the page for the current
application. The list below only specifies the amount of data and
the display/ordering semantics for the pages showing such data. It
does not define the page layout which should be taken from the web
application and style sheet directly.
1. Home Page
Show 10 events on each page
By default, show the 10 nearest upcoming events.
Provide options to select events by:
zip code
Shows the 10 nearest upcoming events
Or the 10 farthest out events if descending order is chosen
date
ascending or descending order
Each event shows the event image thumbnail, the title, and the event date
On mouse-over, show creation date and summary text
Allow pagination of 10 events, each.
Tag cloud shows 50 most popular tags. The font size for the tag reflects the number of reference counts. The tag cloud is ordered in alphabetical order.
2. Event Page
Show the event image in full (not thumbnail).
Show full event info
Lists all signed up attendees
If user is logged on, the user can choose to attend the event if he/she is not already attending.
Show tags tagging this event.
Show all comments and ratings on this event.
3. User Page
Show person image in full (not thumbnail)
Show full person info
List 10 most recently posted events
List all incoming friend requests
List all outgoing friend requests
Friend cloud listing all the current friends this user has in no particular order.
Ajax is used in certain areas of these significant pages to
communicate and fetch data for a page in the background without
having to reload the page. Currently, the Ajax requests returns an
XML that represents the DOM tree to replace in the current document.
The followings list the places AJAX is used in the application:
1.
Home page
Browse calendar month and year
Delete events from the top 10 events (if user is logged on).
2. Event page (logged on user)
Add yourself as an attendee to an event
Add and edit rating
Delete comments and rating
3. User page (logged on user)
Revoke an outgoing friendship request
Reject an incoming friendship request
Approve an incoming friendship request
Sample data used for performance testing is loaded by a database
loader. The database loader controls the number of entities loaded.
Many software frameworks provide object-relational mappers (O-R
mappers) that prescribe certain elements in the schema and how the
schema is broken down (i.e. Rails demands a separate record id). In
effect, the database schema may not be exactly the same for each
platform/implementation. However, the number of entities loaded and
their relationship must be the same no matter what implementation is
used.
The tags - and any entity dependent on the number of
tags - do not scale linearly with the number of concurrent users.
They use a cumulative half-logistic curve to scale. Effectively, at
low concurrent users, such entities will scale close to linear. As
the scale gets higher, they will gradually top off and converge to a
predefined cardinality.
The following table specifies the
number of entities loaded with the loader. Slight
modifications to the data loader should be able to make it work with
any platform-specific schema requirements.
|
Relationship |
# of entities |
# of entities |
|
|
Conc. users |
n |
n |
1,000 |
|
Person |
10 x n |
10 x n |
10,000 |
|
Friends |
[2..28]/person |
150 x n |
150,000 |
|
Address |
1/person |
10 x n |
10,000 |
|
Tags |
1 - e^(-person/10000) |
1 - e^(n/1000) |
2,311 |
|
Events |
3 x tags |
3 x (1 - e^(n/1000)) |
6,933 |
|
Event_Tag |
[1..7]/event |
12 x (1 - e^(n/1000)) |
27,732 |
|
Attendees |
[10..100]/event |
165 x (1 -
e^(n/1000)) |
381,315 |
|
Comments |
[0..20]/event |
30 x (1 - e^(n/1000)) |
69,330 |
Note: Total number of records (avg) for 1,000 concurrent
users is 657,621.
Non-structured data (images, documents) used by the application are stored in an unstructured filestore. By default, we assume a normal filesytem – either a local filesystem for small single webserver deployments or a distributed file system like NFS. The PHP implementation does include code for MogileFS but this needs to be tested.
The web application implements a mashup using web services call to an external Geocoder. In the Olio environment, we emulate the geocoder using a very simple servlet running in Tomcat. This Geocoder Emulator is a required component. The emulator in the repository should be used as is by all implementations.