Return-Path: 
 <commits-return-4089-apmail-zookeeper-commits-archive=zookeeper.apache.org@zookeeper.apache.org>
X-Original-To: apmail-zookeeper-commits-archive@www.apache.org
Delivered-To: apmail-zookeeper-commits-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id 7078217EDD
	for <apmail-zookeeper-commits-archive@www.apache.org>;
 Fri, 10 Oct 2014 14:04:12 +0000 (UTC)
Received: (qmail 1490 invoked by uid 500); 10 Oct 2014 14:04:12 -0000
Delivered-To: apmail-zookeeper-commits-archive@zookeeper.apache.org
Received: (qmail 1460 invoked by uid 500); 10 Oct 2014 14:04:12 -0000
Mailing-List: contact commits-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:commits-help@zookeeper.apache.org>
List-Unsubscribe: <mailto:commits-unsubscribe@zookeeper.apache.org>
List-Post: <mailto:commits@zookeeper.apache.org>
List-Id: <commits.zookeeper.apache.org>
Reply-To: dev@<zookeeper.apache.org>
Delivered-To: mailing list commits@zookeeper.apache.org
Received: (qmail 1449 invoked by uid 99); 10 Oct 2014 14:04:12 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Oct 2014 14:04:12 +0000
X-ASF-Spam-Status: No, hits=-2000.0 required=5.0
	tests=ALL_TRUSTED
X-Spam-Check-By: apache.org
Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4)
    by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 10 Oct 2014 14:04:10 +0000
Received: from eris.apache.org (localhost [127.0.0.1])
	by eris.apache.org (Postfix) with ESMTP id E163B2388A56
	for <commits@zookeeper.apache.org>; Fri, 10 Oct 2014 14:03:50 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: svn commit: r925272 - in /websites/staging/zookeeper/trunk/content:
 ./
 bookkeeper/index.html
Date: Fri, 10 Oct 2014 14:03:50 -0000
To: commits@zookeeper.apache.org
From: buildbot@apache.org
X-Mailer: svnmailer-1.0.9
Message-Id: <20141010140350.E163B2388A56@eris.apache.org>
X-Virus-Checked: Checked by ClamAV on apache.org

Author: buildbot
Date: Fri Oct 10 14:03:50 2014
New Revision: 925272

Log:
Staging update by buildbot for zookeeper

Modified:
    websites/staging/zookeeper/trunk/content/   (props changed)
    websites/staging/zookeeper/trunk/content/bookkeeper/index.html

Propchange: websites/staging/zookeeper/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Fri Oct 10 14:03:50 2014
@@ -1 +1 @@
-1630042
+1630899

Modified: websites/staging/zookeeper/trunk/content/bookkeeper/index.html
==============================================================================
--- websites/staging/zookeeper/trunk/content/bookkeeper/index.html (original)
+++ websites/staging/zookeeper/trunk/content/bookkeeper/index.html Fri Oct 10 14:03:50 2014
@@ -57,7 +57,48 @@
 
 <p>The Apache BookKeeper subproject of ZooKeeper is made up of a distributed logging service called BookKeeper and a distributed publish/subscribe system built on top of BookKeeper called Hedwig.</p>
 
-<h2>What is BookKeeper?</h2>
+<h2>What is Bookkeeper?</h2>
+
+<p>Bookkeeper is a replicated log service which can be used to build<br />
+[http://en.wikipedia.org/wiki/State_machine_replication replicated state machines]. A log contains a sequence of events which can<br />
+be applied to a [http://en.wikipedia.org/wiki/Finite-state_machine state machine]. Bookkeeper guarantees that each replica<br />
+state machine will see all the same entries, in the same order.</p>
+
+<h2>Eh? What good is that to me?</h2>
+
+<p>Imagine for example that you have a database that you want to be able<br />
+access even if the database server goes down. You'll need to replicate<br />
+it to multiple servers. You need to ensure that if one database sees an<br />
+update, all databases see the update. But what happens if one database<br />
+server is cut off from the network for a time? Or if two clients try to<br />
+update the same field at exactly the same instance? This is where a<br />
+replicated log comes in.</p>
+
+<p>A database can be seen as a state machine. It is the sum of all the<br />
+updates which is has applied since its initial state. Therefore, if you<br />
+consider your replicated database as a replicated statemachine, you can<br />
+do the replication using a replicated log service. If all updates are<br />
+written to the log replication service before being applied to the<br />
+database, then the database will continue to be available and consistent<br />
+even if some of the replicas fail.</p>
+
+<p>This approach can be applied to many types of distributed systems, such<br />
+as messaging systems, coordination systems, filesystems, etc.</p>
+
+<h2>What bookkeeper is not?</h2>
+
+<p>Bookkeeper has nothing to do with application/error/trace logging. There<br />
+are already many projects (link to log4j, slf4j, logback) dedicated to<br />
+that problem.</p>
+
+<p>Bookkeeper does not provide leader election. You'll need to use something like [http://zookeeper.apache.org Zookeeper] for that.</p>
+
+<h2>How about Hedwig?</h2>
+
+<p>Hedwig is a distributed publish and subscribe system, which uses<br />
+bookkeeper to replicate its messages.</p>
+
+<h2>More information</h2>
 
 <p>Learn more about BookKeeper on the <a href="https://cwiki.apache.org/confluence/display/BOOKKEEPER/BookKeeper">BookKeeper Wiki</a>.<br />
 Learn more about Hedwig on the <a href="https://cwiki.apache.org/confluence/display/BOOKKEEPER/HedWig">Hedwig Wiki</a>.</p>