On Mon, Aug 2, 2010 at 10:02 PM, Benoit Chesneau <bchesn...@gmail.com> wrote: > 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. > >> >> Some better support for a long term generic changes listener
There is the work done by fdmanana in replicator db branch could be very useful for that. I would love a generic way to handle such stuff. > 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. So in this case each handler will use the js driver and speaking directly to ther couchdb api. No need anymore to pass by the view server. And view server canthen only be used for its own purpose.
