On Mon, Aug 2, 2010 at 1: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 > I would argue that it's trivial to watch processes because they are only allowed to do processing in between request/response cycles in the protocol. > - 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 > I want to see this in the external process handler but not in the view server. Again, I think the view server should remain in scopeing documents, queries, and other operations to clear functional transforms. > - can't stream in this os process without creating another > So, the process shouldn't be able to actually handle another call until the current one returns. It should only block the response on processing. I would like to see some alternative for languages like Java that take forever to start a new process and can scope the multi-core on their own. > .... > > > > > > 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. > No, it shouldn't. The HTTP response for a document should be deterministically generatable for that revision of the document. If you actually generate a different response for a d...@rev based on some external IO call then you break all the caching. > > > > > 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. > I'm going to writeup my proposal for a better external processes protocol in another email. It needs to get significantly better. I don't see the value in overloading the current view server with an RPC back to erlang. It breaks far more things than it solves. If we want a bigger application platform that can do all these things and doesn't want the caching and wants to break the functional tranform model of the view server perhaps we should design an alternative that doesn't also deal with the views and current work load of the view server but is scoped to a design document instead of being like the external process handler. -Mikeal
