On Jun 8, 2009, at 3:26 PM, Paul Davis wrote:
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.
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
