Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Fri, 3 May 2013 13:12:17 +0000 (UTC)
From: "Benoit Chesneau (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: <JIRA.12639374.1364401220825.265094.1367586737541@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=13648389#comment-13648389 ] 

Benoit Chesneau commented on COUCHDB-1743:
------------------------------------------

[~ioquatix] about "Most modern operating systems are perfectly happy managing multiple processes." sentence that's not true for all modern oses. For example you can't run OS processes in iOS for now. 

Imo the protocol is independent of the implementation and we should first describe it in a a more generic fashion so it can be adapted to different platforms with a minimum lost of features.

About benchmarks , I disagree that it should be the key to decide if a protocol is inherently good or not. And before to start we should first describe somewhere what are current drawbacks of the protocol? What features are expected etc... 

To list some drawbacks i have right now:

- too much serialisation/deserialisation steps in the procole
- only based on stdio. the protocol should be able to work on other protocol
- bad error handling: the new protocol should improve the way we trace a map function execution
- the implementation of the parallelisation imo should be a view server implementation decision, couch only have to know when it can pass docs to it and when they can be indexed. As a result, the external or internal (erlang) view server would be treated the same by couchdb, the only thing that would change is the way to send the message (using erlang messages, using stdio or using another network transport)

...


Anyway if we want to start an implementation let's define the protocol first then we will think about the performance....
                
> 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