On Mon, Aug 2, 2010 at 1:18 PM, Benoit Chesneau <[email protected]> wrote:
> On Mon, Aug 2, 2010 at 10:02 PM, Benoit Chesneau <[email protected]> > wrote: > > On Mon, Aug 2, 2010 at 8:56 PM, Mikeal Rogers <[email protected]> > 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. > > There is also some node.js experiments I've done with this that I'll be refining this week. > > > > 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. >
