Setup

[benmerckx]

I'm trying to get something very basic running:

public static function main() {
  var container = new TcpContainer(2000);
  var response: OutgoingResponse = 'it works';

  container.run({
    serve: function (x) {
      var trigger = Future.trigger();
      trace('new request');
      trigger.trigger(response);
      return trigger.asFuture();
    },
    onError: function(e) trace(e),
    done: Future.trigger()
  });
}

This compiles and runs. The first request to localhost:2000 (through a browser or wget/curl) always works, subsequent requests fail. The 'new request' trace however prints for every request, so everytime I refresh in the browser I get a line in the console, but connection drops before a response goes through. I do not get this behaviour when trying out foxhole, so I guess I'm doing something wrong here..

[back2dos]

Well, it becomes quite obvious that this thing needs a doc and some API polish :D

The problem is, that a response is stateful. More precisely: a response's body is stateful. It is a stream. If you return the same response twice, then the first time, it's whole body is streamed to the underlying connection. But when you return it again, then the body is already depleted, so you only ever get the headers.

The body of a response could be the incoming stream of a TCP connection or the body of an IncomingResponse (which would be the case for proxies), so it's not always possible to just "rewind" the response.

I will see about how I can get the API to be more intuitive. But in the meantime, please simply avoid returning the very same response twice.

As a side note: Future.sync has lower overhead then creating a trigger and triggering it immediately.

[back2dos]

To clarify, this will work:

function (x) {
  var trigger = Future.trigger();
  trace('new request');
  var response: OutgoingResponse = 'it works';
  trigger.trigger(response);
  return trigger.asFuture();
}

[benmerckx]

Thanks, that makes sense. I think I got most of it by looking through the foxhole source, but I couldn't figure this one out.

I wonder what your future plans are with tink_http? I'd like to do more of our projects in haxe (mostly doing php now). Since most of our clients only supply us php hosting, we're limited. However more and more we set up hosting, and so are free in choice of backend (neko, nodejs). The only thing missing was a decent abstraction over the different server backends. Your library comes as a solution. I'm wondering if you have plans for a higher level router/middleware kind of framework over tink_http?

[back2dos]

Oh, I have plans for everything, but I wanted to build a relatively unopinionated base first, so that everyone can put their stuff on top and leverage the portability without being overly constricted by my religious beliefs. I hope that when Haxe for the web gains traction, it'll be less of a battle of the monoliths than it is with gaming frameworks.

My next step is to get the FS API right (not that much of a big thing) and to get the OS API right (processes, environment, etc.). Then I will move on to persistence (SQL and maybe MongoDB too, if I can find the time).

So by all means, go ahead and build something! FWIW I suggest using tink_template for the views ;)

[benmerckx]

Well, I'm going to have a go at it :) I can look at foxhole for most of the essential stuff.

Other things I think are necessary for almost any basic website, and lacking in haxe, are: databases (spod is ok, but also not really in all situations, and isn't async - I look forward to your ideas), images - basic resizing/cropping (should be possible to get an interface for libgd on all backends) and outgoing email (I think ufront-mail fixes this, but I haven't tested yet).

For the views part, I'll first try to finalize my thoughts on my ithril lib first :) It works well for the projects in which we've used it and it now renders html on the server, but I'm not really set on the syntax yet. It's a bit of a struggle against valid haxe syntax, and I keep looking to simplify things.

[back2dos]

Oh, that's right, you were the ithril-guy! Well then, please disregard what I said. You got the one thing right I really care about: proper compiler integration to leverage all of Haxe's features.