Re: [PROPOSAL] Chainable requests

[Giovanni Lenzi <g....@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 <er...@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 <jo...@b2w.com>:
>
> > Ermouth,
> >
> > > On 25. nov. 2015, at 18.18, ermouth <er...@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
>

Re: [PROPOSAL] Chainable requests

[Giovanni Lenzi <g....@smileupps.com>]

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 <er...@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....@smileupps.com>:
>
> > 2015-12-01 18:04 GMT+01:00 ermouth <er...@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....@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 <er...@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 <jo...@b2w.com>:
> > > > >
> > > > > > Ermouth,
> > > > > >
> > > > > > > On 25. nov. 2015, at 18.18, ermouth <er...@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
> > > > >
> > > >
> > >
> >
>

Re: [PROPOSAL] Chainable requests

[ermouth <er...@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....@smileupps.com>:

> 2015-12-01 18:04 GMT+01:00 ermouth <er...@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....@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 <er...@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 <jo...@b2w.com>:
> > > >
> > > > > Ermouth,
> > > > >
> > > > > > On 25. nov. 2015, at 18.18, ermouth <er...@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
> > > >
> > >
> >
>

Re: [PROPOSAL] Chainable requests

[Giovanni Lenzi <g....@smileupps.com>]

2015-12-01 18:04 GMT+01:00 ermouth <er...@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....@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 <er...@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 <jo...@b2w.com>:
> > >
> > > > Ermouth,
> > > >
> > > > > On 25. nov. 2015, at 18.18, ermouth <er...@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
> > >
> >
>

Re: [PROPOSAL] Chainable requests

[ermouth <er...@gmail.com>]

Off: I like your new logo (your avatar?) very much! Nice and professional
work, gratz to logo‘s author.

> 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.

> trying to simply kill them, may negatively affect some use cases

It‘s in any way inevitable if you have transactional-style architecture for
a DB that can not perform transactions. So make it in non-transactional
style )



ermouth

2015-12-01 16:17 GMT+03:00 Giovanni Lenzi <g....@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 <er...@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 <jo...@b2w.com>:
> >
> > > Ermouth,
> > >
> > > > On 25. nov. 2015, at 18.18, ermouth <er...@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
> >
>