License/Questions

[mmitkevich]

Hi Andre,

I liked your API (especially all these async/await stuff) and I would like to use your library and probably commit some efforts to do it less GC-dependent and integrate some Reactive Extensions-style Observable/Observer logic.

Currently I can't find information about license. Can you publish it under MIT license?

Thanks, Mikhail

[Andrepuel]

Hello, Mikhail

I guess you've noticed that I've added MIT license.

My point when doing this library was to to steer away from the approach done by vibed, i.e. using fibers. What I liked most about promises is that every async flow has an instance to represent it. Also, there is the performance gain (less memory used) of not having to allocate a stack.

Eventually chaining then methods became a burden, thats when I've implemented async/await. But then we've got back to were we begun, we are using fibers. Node, for instance, does not implement async/await using fibers. I consider that the best of both worlds.

I am planing on using operator overloading (and opDispatch) to implement a programming pattern where one could invoke methods and operators in Promise before they are fulfilled. The result of doing such call would be a new promise that would contain the result of invoking the method on the result of the first promise. This way I would not need to do then all the time and would not need to create a new stack.

GC dependency is a though one. Without closure, async programming can become cumbersome, so I don't know what could be done here. The inner workings of the Promise class could be improved so to avoid so many memory allocations, but I don't know how to become one hundred percent GC free.

regards, Andre

[Andrepuel]

If you are doing anything open source using upromised, please let me know was I would love to take a look and perhaps chime in.

[mmitkevich]

Thanks for your answers.

Actually I'm going to start a new project which should perform a lot of latency-sensitive http/websocket client requests in parallel. I'm investigate D as replacement for java for this project. Its algorithmic trading, so latency issues due to gc could become a problem. There is a strong @nogc initiative in D community, but I'm not sure that there is mature async socket library with @nogc or minimal gc pressure.

I saw some manual memory management techniques in vibe.d HttpClient, but yet its not completely @nogc solution. I'm watching tanya as well, but it has no SSL or websockets integration as of now.

Your library looks interesting because you have a lot of http client stuff done (except websockets) and you have both promise and fiber logic so one could choose.

I noticed that your PromiseIterator looks like anObserver from reactive programming. Probably moving towards unification with some rx library (unfortunately it also uses gc much) could make your library a good choice for functional network programming, where I could write something like

Observable!IpAddress ip = resolveDns("https://host.name");
Observable!byte[] slices =  ip.get("/my/very-long-file.csv");
Observable!string lines = slices.split("\n");
Observable!double items = lines.flatMap!(line=>line.split(",").map(parseDouble));
items.reduce(0, (a,b)=>a+b).subscribe(s=>writefln("%f", s));

to sum all the items in a long CSV file located on some remote server. Note that being written as

resoveDNS("https://host.name")
  .get("/my/very-long-file.csv")
  .split("\n").flatMap(l=>l.split(","))
  .map(parseDouble)
  .reduce(0, (a, b)=>a+b)
  .subscribe(s => writefln("%f",s))

it starts looking as very concise stream manipulations.

Main difference between Observable and Promise that promise has single item to return and could fail. Observable could return multiple items (stream of them) before failing or completing

Actually Promise Is a case of Observable, while Observable is generalization of Promise.

So, ideal networking library for D (from my point of view) should be a) Observable-based b) nogc / gc-aware allocation c) has SSL, HTTP1/2, websockets support (probably through libuv) d) http client and server

But in reality I think I'll have to stick with vibe.d for my project because

• it has c) and d)
• partially it has b)

and AFAIK it has some callback-mechanisms (without fibers) so that it is possible to wrap it with some Observable implementation of my choice.

Thank you for your efforts.