If possible, I'm for letting the chain go on, unstopped, until completion.
Probably we can do even better: write chains, intented to affect the state
of the db, should go on, unstopped, until completion. Read chains instead,
could stop withouth issues. So, how to distinguish different types of
chains? Maybe developer can specify a boolean attribute (e.g. something
like "executeFullChain") within the rewriting rule definition?!
--Giovanni
2015-12-03 12:08 GMT+01:00 ermouth <ermo...@gmail.com>:
> > 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
> > > > >
> > > >
> > >
> >
>
