couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: OTP-ification
Date Mon, 08 Jun 2009 19:26:49 GMT
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.

> I do think the code and build system should be reorganized into a more
> standard src/include/ebin etc. layout, but I'm not yet sold on the idea that
> CouchDB should be comprised of more than one OTP application.  I don't see
> much precedent for that in the applications included with Erlang/OTP.
>

I'm still waffling on what I think the best idea would be. You're
right that most apps don't appear to do nearly as fined grained
splitting of applications. I'm not even sure that its a good idea. I
really haven't seen any documentation on "Packaging best practices"
for what should be in one app vs. multiple apps.

> Why not just require a registered top-level supervisor for each of these
> sets of modules?  I suppose the counter-argument is that bundling the
> modules as multiple applications lets you leverage OTP's built-in dependency
> tracking.

It's not quite the supervision tree that I was trying to split up so
much as the logical grouping of functionality. It could end up with a
1:1 mapping that wasn't the intended consequence.

  Still, I don't think we want to bundle multiple applications
> unless we're prepared to distribute them separately.
>

I disagree on this one. The multiple application aspect should be
purely for internal organization and not as some indication that we're
going to distribute bits and pieces separately. Ie, its not like
people are expecting us to make mochiweb and ibrowse distributions and
what not.

> 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.


Bottom line, I haven't the slightest. One some levels I think my
original idea might be splitting too much, but it sure do seem like we
could do with some divorcing of interests in the source. On the other
hand, looking at things like tasks and stats, I feel as though some
things are becoming nebulous in implementation. Splitting things into
separate apps just seemed like the best way to force us to confront
the tangles. Plus it'd have the added benefit of showing people how to
add functionality as Erlang applications so that adding things like a
new view type are more approachable by people unfamiliar with the core
code base.

Anyway, I'm still letting things simmer to see if I can find something
that smells better.

Paul

Mime
View raw message