Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com
 designates 74.125.46.28 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=sFFDbKkdYgbm3wT5LeMZUg0UVYlghPiDY6O7Huy5abp7c6vPO2VQ+3EAiWvveyF+UF
         3G3xyLDaw9h3T2T7w3W5pCx009tTnKqhy1n87nduUu6yNKyAdX9472JOPgOyRiouLDIH
         Z/YEOpsCmaQhH0gkAFw2qwZgikK1IPuRWXrMM=
MIME-Version: 1.0
In-Reply-To: <581DFFC9-7C51-48C8-83E1-B28598DA6E3E@apache.org>
References: <e2111bbb0906052206v186c3e52l24122e38c917cf1f@mail.gmail.com>
	 <F6B68400-6899-41DD-91BE-C7BC698E93FE@apache.org>
	 <e2111bbb0906081226v18bfee97q734e97823105e3f@mail.gmail.com>
	 <581DFFC9-7C51-48C8-83E1-B28598DA6E3E@apache.org>
Date: Mon, 8 Jun 2009 19:55:29 -0400
Message-ID: <e2111bbb0906081655y42d1a145gf4ff6bf5584b7000@mail.gmail.com>
Subject: Re: OTP-ification
From: Paul Davis <paul.joseph.davis@gmail.com>
To: dev@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Mon, Jun 8, 2009 at 7:39 PM, Adam Kocoloski<kocolosk@apache.org> wrote:
> 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> wrot=
e:
>>>
>>> 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.
>>> =A0I
>>> 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 an=
d
> an HTTP server together as an "HTTP" requirement?), but it's tangential. =
=A0We
> both agree that replication code belongs in its own "collection".
>

I was gonna try and explain, but we agree and the original idea isn't
very clear anyway...

> <snip>
>
>>> Regardless of how many applications we use, we could still organize the
>>> code
>>> with a multi-level hierarchy like
>>>
>>> src
>>> =A0|-core
>>> =A0|-couch_db.erl
>>> =A0|-...
>>> =A0|-httpd
>>> =A0|-replication
>>> =A0|-...
>>>
>>> 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. =
=A0This
> isn't Java :-)
>

Oh. Wicked. I've only ever seen the horrible Java-ism method of
packages that follow directory structure.

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

The megaco example definitely made things click. For some reason I
kept assuming that the src and ebin directory structures would be
mirrored but of course there's nothing requiring this anywhere. I'm
down with doing things this way.

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

I'm not at all caught up with the multiple OTP apps other than that
it'd help keep groupings of source files together. Seeing the megaco
example has made me all but throw the idea under the bus. The only
thing I'm left pondering is how best to minimize spaghetti-ness.
Perhaps I can just write a source code analyzer that draws
embarrassing diagrams of dependencies.

As a side benefit, doing things the megaco way sure does make the
refactor path much more incremental.

> Adam
>
>

Thanks for the whack on the head,
Paul Davis