couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mikeal Rogers <mikeal.rog...@gmail.com>
Subject Re: Proposal for changes in view server/protocol
Date Mon, 02 Aug 2010 22:00:59 GMT
On Mon, Aug 2, 2010 at 1:18 PM, Benoit Chesneau <bchesneau@gmail.com> wrote:

> On Mon, Aug 2, 2010 at 10:02 PM, Benoit Chesneau <bchesneau@gmail.com>
> wrote:
> > 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.
> >
> >>
> >> 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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message