Project Proposal
Jen-Cheng Huang
Vinit Shah
Mike Wilt
CS8803—Advanced Internet
Application Development
Prof. Ling Liu
Spring 2008
Project Overview
Project Title
BuzzPost: A new architecture for online forums
Website
http://www.buzzpost.net
Summary
BuzzPost is fast and fluid like a chat room but stable like a traditional
message board.
Ajax programming techniques enhance the user
experience. For example, when viewing a thread, the conversation
updates as soon as a reply is posted, like an AIM conversation. In
addition, a separate page refresh is not required to log in or sign up for a
new account; all database queries are executed “on the fly.” We believe
this feature will lower the barrier to entry for users.
Individuals can create their own online forums using the BuzzPost
architecture. Individuals can customize the design of their forum using
CSS, predefined “skins,” and a variety of layouts. Forums are hosted for
free by BuzzPost. Revenue generated by advertisements offsets this
cost. To the extent feasible, revenue is shared with individuals who create
and administer forums.
Technologies
Many technologies cooperate to make BuzzPost work, including:










AJAX
PHP
MySQL
Javascript
Javascript Object Notation (JSON)
CSS
Cookies
SHA-1 Encryption
CAPTCHA Authentication
HTTPS
-1-
Objectives
Most online forums—even the most vibrant ones—rely on a static message
board. A separate page load is required to log in, start a thread or post a reply.
Threads are not updated automatically. Conversely, most chat applications
update instantaneously. The goal of BuzzPost is to combine the stability and
structure of a traditional message board with the fluidity and speed of a chat
application.
Users appreciate instantaneous feedback. Imagine if AOL’s instant messenger
required a page refresh to send and receive messages. No doubt its appeal
would be diminished. The best part about chatting with someone is that you’re
interacting with them in real time. Chats are usually private conversations
between to two people and tend to occur between people who aleady acquainted
with each other.
Online forums possess a different dynamic. There are many participants at
once. Participants share a similar interest, be it a sports team, programming
language or television show, but rarely is the entire community on a first name
basis with one another. Nonetheless, we believe that applying the “instant”
nature of chat applications to an online forum will enhance the user experience.
We intend to change expectations for the behavior of an online forum in the
same way that Gmail altered expectations for webmail applications.
Chats tend to be ephemeral. Once the chat window is closed the conversation is
effectively over. On the other hand, exchanges that occur in an online forum
don’t necessarily recede into the ether once someone leaves. BuzzPost is
designed to afford concurrent, synchronous communication as well as
asynchronous communication from users who visit (or revisit) the thread at a
later date.
Table 1. Comparing a chat application to an online forum
Attribute
Chat Application
Online Forum
Participants
Two, typically
Many
Feedback
Instant
Static; requires page reload
Relationship
People you know in real life
People with similar interest(s)
After you leave…
Conversation disappears
Thread remains
Examples
AIM, Google Chat, Yahoo!
Messenger, MSN Messenger,
etc.
phpBB, vBulletin, ProBoards
-2-
A static approach befits the pace of most message boards, particularly those with
low traffic. But it’s easy to imagine the opposite situation where many users flock
to a particular thread, and the nature of the conversation changes quickly. For
this reason, a message board that automatically updates can be advantageous.
It transforms a static experience into one that is more dynamic.
Even in low traffic situations, the user experience improves if Ajax is employed to
make the application more seamless. This might seem trivial to some; after all, a
fast server can reduce the overhead from page refreshes. However, one only
has to look at the praise garnered by Google Maps, flickr, and the rising
popularity of online office suites to know that Ajax —if employed tastefully—can
make the user experience infinitely more satisfying.
One problem with existing forum software is that the user must install the
software on his or her own server. What’s more, it can be difficult to customize
the layout. To lower these barriers, we propose to host all forums that use the
BuzzPost architecture for free and provide tools that enable users to customize
their own forums. Blogger does this already for blogs; in the late 1990s, ONElist
(which later merged with eGroups and was purchased by Yahoo!) provided a free
mailing list service to anyone who wanted to start a listserv. Our strategy is
similar. To offset the cost of hosting many virtual communities, we expect to
generate revenue from advertising. Ideally, we will share revenue with forum
administrators.
In summary, the objectives for BuzzPost are as follows:
1.
2.
3.
4.
Design an online forum that is fast, responsive and scalable.
Enable users to create and customize their own forums.
Host forums for free.
Develop a sustainable revenue model to support the service.
Proposed Work
BuzzPost is borne out of a prototype built last semester by Mike Wilt for the class
6235: Real Time Systems with Dr. Calton Pu. This semester we will optimize the
existing code, implement new features and conduct usability and scalability tests.
A successful outcome is contingent upon completion of the tasks described
below, positive feedback from users and the overall usability of the architecture.
In addition to emphasizing a user experience that is fast, simple and reliable, we
will develop the following components:
1. Automatic updates. The list of threads and individual conversations will
update automatically, like an AIM conversation.
-3-
2. Enhanced forum functionality. Users will be able to create and edit
profiles, format submissions, moderate posts, and report inappropriate
content. Similar to Facebook, users will be able to send private messages
to one another.
3. Seamless log in and user authentication system. Users will be able to
log in, log out and/or register without loading a separate page. Database
lookups and insertions will be done “on the fly.”
4. Secure transactions. We will take appropriate steps to ensure BuzzPost
is reliable and secure. For example, passwords will be encoded with
SHA-1 encryption and Session IDs will be used prevent XSS attacks. We
will consider using HTTPS for some aspects of the site.
5. Moderation system. A moderation system will be implemented for users
to rate comments and flag inappropriate content. Our approach will be
similar to Digg and Slashdot.
6. Search engine. A search engine will be developed to find content
quickly. We will implement an algorithm that considers the forum’s
moderation system.
Feedback from the search engine will be
instantaneous, much like Instant Search [http://www.instantsearch.org].
7. Cross-platform compatibility. It is important that everyone be able to
access BuzzPost forums regardless of web browser or operating system.
8. Alternate layouts. We will develop alternate layouts to display content.
9. Alternate versions. We will implement a javascript-free version and a
version compatible with mobile devices.
10. Content syndication. We will enables RSS feeds of the forum and/or
individual threads. In addition, users will be able track thread thanks to
email notifications.
11. GUI for webmasters. We will create a GUI for webmasters to manage
and design their communities. Forum statistics will also be available here.
12. Advertising model and business plan. We will develop a business plan
to assess the feasibility of supporting many forums via advertising. We
will consider the pros and cons of “open sourcing” the BuzzPost code.
-4-
Architecture
How will Buzzpost work? In a nutshell, clients repeatedly make HTTP requests
to BuzzPost asking if new content has been added to the database. If new
content exists, that data is returned to the client in JSON format. The client
parses this data and appends it to existing content. To minimize strain on the
database, every time a new message is added to the database the result from
this insertion is cached. This way other clients can determine the dataset has
changed without executing an actual query.
A diagram of our proposed architecture is contained in Appendix A.
Our approach is informed by programming techniques described in the books [1]
Beginning Ajax with PHP by Lee Babin and [2] Ajax and PHP: Building
Responsive Web Applications by Cristian Darie, et al. In addition, numerous
websites devoted to PHP, MySQL and Ajax programming helped us formulate
our approach.
Evaluation and Testing
The architecture will be assessed from the following angles:



Scalability
Security
Usability
We are considering a number of approaches to conduct these tests. We expect
to implement one or more forums. This will enable us to monitor performance
and collect feedback from actual users. We also hope to simulate a number of
scenarios to understand how performance is affected by certain variables.
Related work
BuzzPost will provide a unique user experience and numerous innovations
compared to existing forums. However it is wise to analyze online forums that
already exist. Wikipedia contains descriptions of nearly one hundred forums. 1
We have examined each one in detail. Some are open source, others are
1
http://en.wikipedia.org/wiki/Comparison_of_Internet_forum_software_%28ASP%29,
http://en.wikipedia.org/wiki/Comparison_of_Internet_forum_software_%28PHP%29,
http://en.wikipedia.org/wiki/Comparison_of_Internet_forum_software_%28Other%29
-5-
proprietary; some are free, others are not. A variety of programming languages
are used: PHP, ASP, Ruby, Perl and others. Most forums do not offer remote
hosting as we plan to offer; instead users must install the code on their own
server. The first table contains details about popular forum software. The
second table points to existing forums that appear to have been developed
independently.
Table 2. Popular Forum Software
Name
Website
Cost
Technology
Remote Host?
phpBB
http://www.phpbb.com
Free
PHP
No
V Bulletin
http://www.vbulletin.com
$85/yr
PHP
No
EZ Board
(now Yuku)
http://www.ezboard.com
Free (Ad
supported). Can
upgrade to “pro”
version for $36/yr.
Smalltalk
Yes
Vanilla
http://www.getvanilla.com
Free
PHP/Ajax
No
ProBoards
http://www.proboards.com
Free (Ad
supported)
PHP (?)
Yes
Orca
http://www.demozzz.com/o
rca/demo/
Free
PHP/Ajax
No
Table 3. Existing Forums
Name
Website
Comment
Adobe
http://www.adobe.com/cfusion/webforums/forum
Similar to phpBB with some
unique features.
FLV
Media
Player
http://www.jeroenwijering.com/?forum=All
Sleek but simple. Cool
emoticons and search engine.
Phantasy
Tour
http://www.phantasytour.com/phish/boards.cgi
Clean layout and simple
functionality.
QBN
http://www.qbn.com/filter/all/public_voice/recent/2
4_hours/
Innovative layout.
I Love
Everything
http://www.ilxor.com/ILX/index.jsp
Proof that a popular forum
doesn’t have to look pretty.
Think
Tank
http://www.thinktankforums.com/
Minimalist design.
-6-
Schedule
Phase 1: Revise and improve existing code


Log in and user authentication
Automatic updates, like AIM
Phase 2: Add new features









Caching mechanism
Moderation system
Private message system
User profiles
Content formatting
Search engine
Content syndication
Alternate layouts
Management tools for webmasters
Phase 3: Testing


Deploy actual message board(s)
Test:
o Scalability
o Security
o Usability
Phase 4: Advertising model and business plan.



Estimate cost to support a large number of users
Estimate potential revenue from advertising
Consider releasing code as open source
Table 4. Project Schedule
Weeks 1-2
Weeks 3-4
Weeks 5-6
Weeks 7-8
Weeks 8-9
Feb 18—Mar 2
Mar 3—Mar 16
Mar 17—Mar 30
Mar 31—Apr 13
Apr 14—Apr 27








Phase 1

Phase 2

Phase 3
Phase 4
-7-
Important Dates:



February 26-28: Selected Proposal Presentation in Class
April 21-25: Final project demos
April 27: Final project deliverable due (6:00PM)
Bibliography
[1] Babin, Lee. Beginning Ajax with PHP. Apress, 2007.
[2] Darie, Cristian, et al. Ajax and PHP: Building Responsive Web Applications.
Packt Publishing, 2006.
-8-
Appendix A
A diagram of the proposed architecture for BuzzPost.
Step 1: Clients repeatedly check the value contained in a document
cached by the database. Our prototype sets an interval of 1000
milliseconds.




Step 2: One client inserts a new message into the database. A new result
is cached.




-9-
Step 3: The clients detect that the cached value has changed.




Step 4: The clients query the database and new content is returned to the
client. Return to Step 1.




- 10 -