On Mon, Aug 2, 2010 at 8:56 PM, Mikeal Rogers <mikeal.rog...@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
