> Are all the scheduled hops completely
> executed, or the chain will be interrupted?
I also have this question in mind (and several others of comparable
complexity) – thats why I‘m still deciding is overall ‘loop’ approach
reasonable.
As for me, it should not be interrupted until one of chain members
explicitly tries to send data to closed connection. But even in this case
I‘m not sure chain must stop.
Your considerations?
ermouth
2015-12-03 12:25 GMT+03:00 Giovanni Lenzi <g.le...@smileupps.com>:
> 2015-12-01 18:04 GMT+01:00 ermouth <ermo...@gmail.com>:
>
> > Off: I like your new logo (your avatar?) very much! Nice and professional
> > work, gratz to logo‘s author.
> >
>
> :) Thanks, really appreciated!!
>
>
> >
> > > Would it be possible to make external http calls too?
> >
> > Not sure if it‘s possible. But will investigate, mb loop through proxy or
> > smth.
> >
> > > requests generating infinite loops
> >
> > Well, rewrite counts number of hops. This feature also can count and have
> > upper limit of iterations.
> >
>
> Great, a hop counter is simple and nice to have. It may eventually allow
> developers to catch unwanted long-running operations or simply know how
> many hops are left.
>
> One question: from what I understand client connections are kept open by
> the server until all hops are finished. But what if a client closes the
> connection before hops chain end? Are all the scheduled hops completely
> executed, or the chain will be interrupted?
>
>
> -- Giovanni
>
>
>
> >
> > 2015-12-01 16:17 GMT+03:00 Giovanni Lenzi <g.le...@smileupps.com>:
> >
> > > Wow, very useful!!!
> > >
> > > It would be finally possible to aggregate multiple document updates on
> > the
> > > server-side, thus implementing server-side actions in a secure and
> > complete
> > > way, calling a single application api method. I also like the two new
> > ways
> > > of priting output: chunked and reduced.
> > >
> > > Would it be possible to make external http calls too? That would allow
> > > developers to build full js integration libraries for third party
> > services,
> > > withouth the need for any node.js external process!!
> > >
> > > I'm afraid about requests generating infinite loops, but I'm more
> afraid
> > > that trying to simply kill them, may negatively affect some use cases.
> > >
> > >
> > > --Giovanni
> > >
> > > 2015-11-26 6:07 GMT+01:00 ermouth <ermo...@gmail.com>:
> > >
> > > > > is not like multiple lines of code in a server side .asp php or
> node
> > > > program
> > > > > it is more like "ask for this, and depending on the answer,
> > > > > ask for this" like a "request tree"
> > > >
> > > > Actually, that _is_ like asp, php or node program :) As for php guys
> > > > approach is nearly native, sync program code runs inbetween DB
> > requests.
> > > >
> > > > As for node.js guys it also could be understood in native paradigm:
> > think
> > > > couchapp functions are kinda middleware in request processing chain,
> > and
> > > > each middleware function can determine next step.
> > > >
> > > > Somehow like express.js maybe, but in express you call next(args)
> when
> > in
> > > > CouchDB you just return {path:"...", body:"args"}. Also in node your
> > > > middleware can be async, but in CouchDB it should be sync.
> > > >
> > > >
> > > >
> > > > ermouth
> > > >
> > > > 2015-11-26 5:11 GMT+03:00 Johs Ensby <j...@b2w.com>:
> > > >
> > > > > Ermouth,
> > > > >
> > > > > > On 25. nov. 2015, at 18.18, ermouth <ermo...@gmail.com> wrote:
> > > > > > chunked response and reduce approach
> > > > >
> > > > >
> > > > > I think both modes are valuable, conceptually we end up with 3
> modes
> > of
> > > > > respons
> > > > > Technically it makes sense to describe as server response.
> > > > >
> > > > > I am trying to think of how we want to spin this to the new
> > developers
> > > > >
> > > > > I would recommend that we name the feature as seen from the
> front-end
> > > > > developer
> > > > >
> > > > > - single request
> > > > > - chained request
> > > > > - progressive load
> > > > >
> > > > > The 3rd being a variant of chained request not accumulating but
> > > spitting
> > > > > output into the client for as long as it takes
> > > > >
> > > > > "Single reqest" is the normal thing, but what we see as one of the
> > > > painful
> > > > > limitations of Couch
> > > > > "Chained request" is the new thing that is not like multiple lines
> of
> > > > code
> > > > > in a server side .asp php or node program, it is more like "ask for
> > > this,
> > > > > and depending on the answer, ask for this" like a "rewuest tree"
> > > > > "Progressive load" is a super way to improve performance, it is
> > writing
> > > > > for UX, "what the user needs right away is... then .... and
> > eventually
> > > > > she/he will be looking for .. if a link in the first chucks has
> been
> > > > > clicked yet"
> > > > >
> > > > > johs
> > > >
> > >
> >
>
