Re: [PROPOSAL] Chainable requests

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 cha

Re: [PROPOSAL] Chainable requests

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

Re: [PROPOSAL] Chainable requests

2015-12-01 18:04 GMT+01:00 ermouth : > 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

Re: [PROPOSAL] Chainable requests

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 coun

Re: [PROPOSAL] Chainable requests

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

Re: [PROPOSAL] Chainable requests

> 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

Re: [PROPOSAL] Chainable requests

Ermouth, > On 25. nov. 2015, at 18.18, ermouth 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 de

Re: [PROPOSAL] Chainable requests

http://jquerymy.com/kod/rewritelist.png > On 25. nov. 2015, at 21.08, Alexander Shorin wrote: > > Hi, > > On Wed, Nov 25, 2015 at 8:18 PM, ermouth wrote: >> http://bit.ly/1NrTddP > > URL seems broken: Unable to connect > > -- > ,,,^..^,,,

Re: [PROPOSAL] Chainable requests

Hi, On Wed, Nov 25, 2015 at 8:18 PM, ermouth wrote: > http://bit.ly/1NrTddP URL seems broken: Unable to connect -- ,,,^..^,,,

Re: [PROPOSAL] Chainable requests

if this is low-hanging fruit, pick it! I see no downside in implementing this, it removes a frustrating limitiation. johs > On 25. nov. 2015, at 18.18, ermouth wrote: > > > Implementation doesn‘t seem to be very difficult – only existing well known > paradigms are used, nearly nothing new adde

[PROPOSAL] Chainable requests

TL;DR: Allow list, show and update (lsu) functions return special object for chaining requests. In short, I propose lsu fns could return object of same structure as JS rewrite does: {path:"...", method:"...", body:"..."}. If query server receives this kind of object as lsu fn result, user connect