Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Mon, 29 Apr 2013 15:14:18 +0000 (UTC)
From: "Samuel Williams (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: <JIRA.12639374.1364401220825.242329.1367248458053@arcas>
In-Reply-To: <JIRA.12639374.1364401220825@arcas>
References: <JIRA.12639374.1364401220825@arcas>
Subject: [jira] [Commented] (COUCHDB-1743) Make the view server & protocol
 faster
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/COUCHDB-1743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13644570#comment-13644570 ] 

Samuel Williams commented on COUCHDB-1743:
------------------------------------------

Alexander, thanks for your input. The main issue as I see it, especially in light of the points you make, is that the current communication mechanism is a very limited form of RPC. In many ways, RPC is already a solved problem. However, we do have some specific use cases in CouchDB (e.g. scheduling queries and returning results out of order which is not a typical in existing RPC mechanisms). Re-engineering the protocol from scratch allows to build a general RPC interface on which more advanced features can be built, rather than building custom RPC mechanisms as presently implemented.

The proposal I wrote is based on JSON, and this is in line with what you've suggested. However, there is the possibility for optional extensions as per the proposal. One option to reduce data going across the wire is to use some form of compression. There are many compression mechanisms that improve overall performance by sacrificing relatively fast CPU for relatively slow IO.

With the existing "RPC" mechanisms, I think the situation going forward will only get more complex and less maintainable. It also increases the burden on the implementor for the query server as they must support each facet of the protocol specifically. What CouchDB needs to solve this problem is a standard communication mechanism on which more advanced functionality can be built, rather than trying to push all this functionality down into the communication mechanism itself, and in this sense, a general functional execution model (e.g. what I've proposed) such that new features in CouchDB don't require proportional number of changes across all query servers (i.e. maintainability).
                
> Make the view server & protocol faster
> --------------------------------------
>
>                 Key: COUCHDB-1743
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1743
>             Project: CouchDB
>          Issue Type: Improvement
>            Reporter: Dave Cottlehuber
>              Labels: couchdb, erlang, gsoc2013, html, javascript, nodejs, rest
>
> View server protocol enhancements/refactoring - unix sockets, pipelining, different wire format etc. Faster!!

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira