couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: Proposal for changes in view server/protocol
Date Mon, 02 Aug 2010 20:02:40 GMT
On Mon, Aug 2, 2010 at 8:56 PM, Mikeal Rogers <mikeal.rogers@gmail.com> wrote:
>>
>> Before doing any changes to view server protocol, I would prefer to
>> start working on a better implementation of js insde CouchDB. The
>> current implementation (ie using one os process for each call/request
>> ) even limited in a pool of process limit what you can do for obvious
>> reason.
>>
>
> What limitations do you mean?

- difficult to watch processes
- number of fds used under big load witch could limit in the same time the db
- passing message in json from and back (this imo could be at some
time removed imo
- can't stream in this os process without creating another
....


>
> I don't think the view server should ever *block* on anything other than
> processing and should still be forbidden from doing IO.

There some IO you want like process http in a show to get another
message, some other stuff can be imagined.

>
> We do need to implement a non-blocking line protocol for external processes
> and maybe some better support for a long term generic changes listener but
> allowing the view server to go off and do IO is an *incredibly* bad idea.
>
>
external processes have  disadvantages I said. I never speak about
view server in this case. Actually using view server to handle shows,
lists & such is like a big hack . It could be done in a simpler
manner.

We could imagine js contexts making RPC to pure erlang and erlang
sending back the response, stuff like it.

- benoit

Mime
View raw message