On Mon, Jun 8, 2009 at 3:03 PM, Adam Kocoloski<[email protected]> 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
