new remoteHost field in Hack Env

[Jinjing Wang]

A new remoteHost field is to be added in Hack (release within next week).

This is commonly requested by hack users.

Comments?

--
jinjing

[Michael Snoyman]

Sounds great. What's the data type going to be?

Michael

[Jinjing Wang]

String?

This change won't affect any code in use, except possible naming clash
(this particular remoteHost name).

The default remoteHost is an empty string, a handle is expected to
fill it, if this information is available.

Preview can be checked at git repo.

* http://github.com/nfjinjing/hack

--
jinjing

[Michael Snoyman]

Sounds perfect. I wasn't sure if you were going to go for some complicated data type to represent IP lookup or some such... I like simplicity here.

BTW, I remember a while ago you posted to cafe about changing the name from Hack to something. Are you still looking for replacement names? I think Hack is just fine the way it's named now to be honest.

Michael

[Jinjing Wang]

AHWSGI isn't a lot better i guess.... If not too many people complain,
it might just be called hack ...

--
jinjing

[Jinjing Wang]

There's also something hyena addresses well but not in hack, i.e. the
iteratee style IO.

It's about constant space usage of memory when serving a request.

Hack is not suited at this task, since lazy IO will eventually consume
memory used for the entire request body, and it seems reliance on the
GC isn't always ideal. Running out of file handles is another problem,
but can be solved in various way by strictness hints, so it's not that
much an issue.

A backword compatible workaround is to add this iteratee IO in body as
a Maybe (Iteratee x) type, so those handler that can handle it will
use it. It at least makes it possible to use hack to write, e.g. a
streaming server.

Another progress in Happstack is the fileserve module, which essential
solves the same problem.

So hopefully hack will eventually incorporate this constant space IO
ability with an almost backward compatible way (on a condition of only
do customization on the request / response object with def, rather
then using them directly).

--
jinjing

[Michael Snoyman]

I'm not sure how important backwards compatibility is at this point. I don't no what the iteratee style is, but I'm interested to see it.

As far as backwards-compatibility goes, maybe you should change the version scheme to major.minor.release, with changes in the major number being breaking changes?

Michael