Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8F7616157 for ; Sat, 2 Jul 2011 23:59:31 +0000 (UTC) Received: (qmail 70573 invoked by uid 500); 2 Jul 2011 23:59:29 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 70512 invoked by uid 500); 2 Jul 2011 23:59:29 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 70504 invoked by uid 99); 2 Jul 2011 23:59:28 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 02 Jul 2011 23:59:28 +0000 X-ASF-Spam-Status: No, hits=0.7 required=5.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [204.13.248.74] (HELO mho-02-ewr.mailhop.org) (204.13.248.74) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 02 Jul 2011 23:59:21 +0000 Received: from 67-6-222-36.hlrn.qwest.net ([67.6.222.36] helo=[192.168.0.2]) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.72) (envelope-from ) id 1QdA5T-0000dr-Tg for user@cassandra.apache.org; Sat, 02 Jul 2011 23:59:00 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 67.6.222.36 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/Gik1q4vMNIQHxiMFtBPq8/ViKshlUZNo= Message-ID: <4E0FB0B9.3010409@dude.podzone.net> Date: Sat, 02 Jul 2011 17:58:49 -0600 From: AJ User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11 MIME-Version: 1.0 To: user@cassandra.apache.org Subject: Re: Strong Consistency with ONE read/writes References: <4E0E7A07.2050807@dude.podzone.net> <2B2CF529-F505-40C0-9663-36907FB3FA34@civicscience.com> <7d70b195-e8cb-4ad9-93d2-af5ce928fa6b@email.android.com> <8910389677256918425@unknownmsgid> In-Reply-To: <8910389677256918425@unknownmsgid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/2/2011 6:03 AM, William Oberman wrote: > Ok, I see the "you happen to choose the 'right' node" idea, but it > sounds like you want to solve "C* problems" in the client, and they > already wrote that complicated code to make clients simple. You're > talking about reimplementing key<->node mappings, network topology > (with failures), etc... Plus, if they change something about > replication and you get too tricky, your code breaks. Or, if they > optimize something, you might not benefit. > I'm only asking if this is possible working within the current design and architecture and if not, then why. I'm not interested in a hack; just exploring possibilities.