Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of adam.kocoloski@gmail.com
 designates 209.85.221.203 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=sender:message-id:from:to:in-reply-to:content-type
         :content-transfer-encoding:mime-version:subject:date:references
         :x-mailer;
        b=vqSragOsBF9h2GbKuvBsPtpyZna11gBj7MRdoRNRu6MD7FtA/ISKavy+itTvl39YDp
         Sk/i2AT8zUv6dFXkz1SbJM2r7hX5s3wVQ1POqv0W5Gi6HcLOeutG/nJBoQ/J7L+Z7BCg
         /LUYpEYcBa4UyzxQXY0ESfQnCc+cOuKOhNCgE=
Sender: Adam Kocoloski <adam.kocoloski@gmail.com>
Message-Id: <581DFFC9-7C51-48C8-83E1-B28598DA6E3E@apache.org>
From: Adam Kocoloski <kocolosk@apache.org>
To: dev@couchdb.apache.org
In-Reply-To: <e2111bbb0906081226v18bfee97q734e97823105e3f@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: OTP-ification
Date: Mon, 8 Jun 2009 19:39:17 -0400
References: <e2111bbb0906052206v186c3e52l24122e38c917cf1f@mail.gmail.com>
 <F6B68400-6899-41DD-91BE-C7BC698E93FE@apache.org>
 <e2111bbb0906081226v18bfee97q734e97823105e3f@mail.gmail.com>

On Jun 8, 2009, at 3:26 PM, Paul Davis wrote:

> On Mon, Jun 8, 2009 at 3:03 PM, Adam Kocoloski<kocolosk@apache.org>  
> wrote:
>> On Jun 6, 2009, at 1:06 AM, Paul Davis wrote:
>>
>>> * CouchRep - Ideally, I'd like to keep this in core, but I don't  
>>> know
>>> the logic in it to know if we can split it into an Erlang core  
>>> version
>>> and add an HTTP layer on top. Or something. Anyway, that's all I  
>>> got.
>>
>> The replicator doesn't need an HTTP server, just a client (ibrowse  
>> atm), so
>> it should not have any dependency on a future "CouchHTTPd"  
>> application.  I
>> think I'd still prefer to keep it separate from core, though.
>>
>
> I meant to layer the protocol so that it could work over Erlang
> message passing or an HTTP protocol, the goal being that core CouchDB
> doesn't require HTTP to work, hence why I pulled replication into its
> own module. I don't actually think we should actually try and make the
> replicator this abstract, I was more just trying to reason out why I
> was putting it outside of the core directory.

Not quite sure I follow your reasoning (are you lumping an HTTP client  
and an HTTP server together as an "HTTP" requirement?), but it's  
tangential.  We both agree that replication code belongs in its own  
"collection".

<snip>

>> Regardless of how many applications we use, we could still organize  
>> the code
>> with a multi-level hierarchy like
>>
>> src
>>  |-core
>>   |-couch_db.erl
>>   |-...
>>  |-httpd
>>  |-replication
>>  |-...
>>
>> Adam
>>
>
> This is possible, but I thought I read that the submodule stuff was
> another one of those "implemented on a whim and not really supported"
> Erlang features.

I think you're referring to packages (http://www.erlang.se/publications/packages.html 
) -- that's really a separate issue from how the modules' source code  
is organized on disk.  This isn't Java :-)

The snmp and megaco applications (possibly others) are organized this  
way, with nested folders of source code.  Neither one uses packages.

Thanks for getting the ball rolling on this.  I still prefer to build  
CouchDB as one OTP application, but if the community agrees to split  
it out into lots of smaller ones I won't object.  Best,

Adam