On Mon, Jul 9, 2012 at 3:59 PM, Paul Davis <[email protected]> wrote:
> Benoît,
>
> Lately I've been contemplating removing a lot of the Erlang mechanics
> for this by rewriting couchjs as a single process/multi threaded
> application. I've seen a lot of issues related to our process handling
> and I also think we can probably speed things up considerably if we
> change how this works. Ie, if we move to an asynchronous message
> passing interface instead of the serialized stdio interface we should
> be able to get some nice speedups in throughput while also removing a
> lot of the resource usage.
What would be the difference/advantage with using something like emonk?
>
> As part of that we should also do what you suggest and look into
> refactoring the top layer to make this stuff a lot cleaner where we
> call it in places like the rewriter and what not.
>
> I'm also not sure what you mean about the couchapp module. Right now
> if I had to guess I could see a couple Erlang apps: one that
> encompasses couchjs for JS code, one for Erlang code (for the
> view/list/show etc) etc etc. I could also see having the
> rewriter/list/show stuff in its own app as well but its early and I'm
> not quite awake yet.
I'm thinking to have a new structure like:
{src|apps}/
couch_qs -> everything really needed for indexation|m/r
couch_ape -> everything related to the couchapps
>
>
> On Mon, Jul 9, 2012 at 8:10 AM, Benoit Chesneau <[email protected]> wrote:
>> I'm working on the couch_query_server refactoring:
>> - extract it from the couch app
>> - introduce generic way to add query servers written in Erlang or
>> calling OS processes like couchjs (so rather than distinct os
>> processes from native only call an erlang module with some arguments)
>> - split the couchapp engine in its own module.
>>
>> I'm actually wondering why you have one proc / ddoc? Any reason for
>> that? Apart for the rewriter?
>>
>> - benoît
