a draft
Here's an early draft of the spec for Fotola2. I hope it doesn't suffer too much from "second system syndrome" -- it is a little ambitious, but not overboard.
Never mind that there aren't any other open-source distributed content sites out there. Somebody has got to be first!
By the way, this will include things like a plain-text email option, who linked to me? feature, and utf-8 unicode support.
Fotola Too Upgrading Fotola
Now that I know what Fotola is, and have a better understanding of some of the problems that growth will cause, it's time to ditch Berylium in favor of a more self-contained and templatized solution. This is a pain because it means a complete rewrite of all the logic. But the benefits of doing so will be obvious as soon as we plug in the second distributed Fotola server, or enable a Portuguese translation of the interface, or take on a million hits a day. :-)
The goal of this phase of development is to rewrite the Fotola backend using a new, custom system, so that it reimplements the current front-end user interface with only minor changes. Exception: there will be no publish via email, or incoming XML-RPC support in this version.
Areas to address:
Registration / Authentication / Authorization
Homepage
Fotola View
Image View
Log View
Favorites
Linking
Resource Usage -- disk, cpu, and transfer
Comment System
Republishing
Fotola Settings
Templates / Caching
Broad Requirements:
Distributed hosting with central registration / authentication
Local authorization using a realm/role system
Multilingual template system
Cached and cacheable output for public pages
Hooks for paid accounts and/or a la carte services at local server
Pre-compression image masters kept, available to owner and optionally to others
Three roles: viewer (for private fotolae / entries), editor (can add/edit entries), admin (site administrator)
Fotola owner has the ability to assign viewer/editor roles within that fotola
Central Server and Satellite Servers
Scaling a photologging service to thousands or hundreds of thousands of users is beyond the means of a low-budget/no-budget organization. Disk storage requirements increase daily, bandwidth multiplies as more photos become available, and every new upload results in a cpu-intensive image-processing and page-rendering routine. Then there is user support and the enforcement of copyright and obsceneity laws, which can easily become a full-time job.
Even a properly-funded operation will need to scale to multiple servers, and hire additional administrators, fairly quickly.
But Fotola is not properly funded, and may never be. Fortunately, we can design around this limitation. If local providers are willing to host Fotola servers, thereby assuming the hardware, bandwidth, and administration costs, then nobody has to bear the entire burden. If setting up and running a Fotola server is easy and free, then neightborhood servers can spring up anywhere, worldwide, to host anywhere from 1 to 1000 users.
The advantages of this should be obvious: your images will be served from a local server, managed by a local administrator. Yet you will still be an active member of a single photoblogging community.
How Will It Work?
Fotola.com will act as a registration and authentication server. When you login from a satellite server you will be redirected to Fotola.com. After login is completed, you will be issued a fotola.com session cookie, and sent to whichever satellite server contains your primary fotola. A special token will be included as part of that redirect.
The satellite server will attempt to redeem this token by making a secure request to Fotola.com on your behalf. If the token is successfully redeemed, the satellite server will consider you logged-in, and issue a session cookie of its own. This session cookie gives you your logged-in status while you are anywhere on the satellite server.
But what about when you move to another satellite?
This is where the fotola.com session cookie that you were issued comes into play. There are two areas of the page that are personalised when you are looking at someone else's fotola: the toolbar in the upper left, and your identity in the add-comment form at the bottom of the page. Those areas will now rendered via a Javascript include from Fotola.com, which will take your fotola.com cookie and send back a personalised toolbar and add-comment form. A side benefit is that the rest of the page can be static-- it doesn't need to be processed code, which makes it at least 10 times more efficient to serve.
Then what about the Fotola.com homepage?
Each of the satellites will provide at least two RDF-based newsfeeds according to some established criteria: recent entries and featured entries. The Fotola homepage will simply aggregate the newsfeeds of all the satellites, and use the results to build the Feaured and Recent lists. Search is going to be tricky, and may need to be restricted to the satellite servers at first.
The fun thing about this is that there can be four different kinds of Fotola server:
The server code needs to be able to authenticate users via an HTTP POST to Fotola.com, and needs to provide the two newsfeeds detailed above. The interface will need to employ the Javascript includes. And that's about it.
- The free, official, PHP-based server
- Other free, PHP-based derivatives written by other developers (go ahead, write one that works with IIS on Windows)
- Free implementations in other programming languages (go ahead, write one in Perl or Python or JSP)
- Non-free, licensed or from-scratch implementations (buy a commercial license and build your own service)
Central Server Database Schema:
Does not include indexes yet...
CREATE TABLE IF NOT EXISTS qtuser ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, created DATETIME, updated DATETIME, email VARCHAR(255), username VARCHAR(255), password VARCHAR(255), hint VARCHAR(255), domain VARCHAR(255), INDEX index_domainuser ( domain(64), username(64) ) );
CREATE TABLE IF NOT EXISTS f2_userprefs ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, uid INT UNSIGNED, siteid INT UNSIGNED, properties TEXT, status VARCHAR(255) );
CREATE TABLE IF NOT EXISTS f2_uplink ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, uid INT UNSIGNED, created DATETIME, updated DATETIME, flavor VARCHAR(255), title VARCHAR(255), properties TEXT, status VARCHAR(255), rank INT );
CREATE TABLE IF NOT EXISTS f2_event ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, uid INT UNSIGNED, created DATETIME, effective DATETIME, flavor VARCHAR(255), value VARCHAR(255), properties TEXT, status VARCHAR(255), rank INT );
CREATE TABLE IF NOT EXISTS f2_site ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, created DATETIME, updated DATETIME, uri VARCHAR(255), properties TEXT, status VARCHAR(255) );
Satellite Server Database Schema:
Note that user records are handled by the authentication server, which hands off UID and username to local session.
Fotola flavors include single and shared.
Entry flavors include image and log.
Link flavors include link and favorite.
Does not include indexes yet.CREATE TABLE IF NOT EXISTS f2_role ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, uid INT UNSIGNED, created DATETIME, updated DATETIME, realm VARCHAR(255), role VARCHAR(255) );CREATE TABLE IF NOT EXISTS f2_session ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, uid INT UNSIGNED, username VARCHAR(255), created DATETIME, updated DATETIME, properties TEXT, cpu INT UNSIGNED, transfer INT UNSIGNED );CREATE TABLE IF NOT EXISTS f2_fotola ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, uid INT UNSIGNED, created DATETIME, updated DATETIME, uri VARCHAR(255), flavor VARCHAR(255), title VARCHAR(255), properties TEXT, status VARCHAR(255), public CHAR(4), locked CHAR(4) );CREATE TABLE IF NOT EXISTS f2_entry ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, fotolaid INT UNSIGNED, uid INT UNSIGNED, created DATETIME, updated DATETIME, uri VARCHAR(255), flavor VARCHAR(255), title VARCHAR(255), description TEXT, keywords VARCHAR(255), properties TEXT, status VARCHAR(255), rank INT, public CHAR(4), locked CHAR(4) );CREATE TABLE IF NOT EXISTS f2_comment ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, fotolaid INT UNSIGNED, parenturi VARCHAR(255), uid INT UNSIGNED, created DATETIME, updated DATETIME, flavor VARCHAR(255), subject VARCHAR(255), comment TEXT, properties TEXT, status VARCHAR(255), rank INT, public CHAR(4), locked CHAR(4) );CREATE TABLE IF NOT EXISTS f2_link ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, fotolaid INT UNSIGNED, parenturi VARCHAR(255), linkuri VARCHAR(255), uid INT UNSIGNED, created DATETIME, updated DATETIME, flavor VARCHAR(255), title VARCHAR(255), description TEXT, properties TEXT, status VARCHAR(255), rank INT, public CHAR(4), locked CHAR(4) );
CREATE TABLE IF NOT EXISTS f2_message ( id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY, uid INT UNSIGNED, created DATETIME, effective DATETIME, flavor VARCHAR(255), subject VARCHAR(255), message TEXT, properties TEXT, status VARCHAR(255), rank INT );
By csnyder on September 26, 2003 at 11:12pm