Added support for /etc/hosts

[jaapio]

This adds support for /etc/hosts through a HostsFileExecutor executor as requested in #10

The Factory is changed so that the Resolver looks in /etc/hosts first. The executor stack looks like this: CachedExecutor -> HostsFileExecutor -> RetryExecutor -> Executor.

Thanks to @arnaud-lb for creating the original PR reactphp/reactphp#225

[cboden]

Awesome work! However reading a file is blocking. I would suggest implementing one of the following changes:

1. loadHosts() in the __construct and save the promise to a property. If the developer is inclined to refresh later, albeit blocking, then can do so, replacing the promise property. query() would look like $this->hosts->then(...

2. Use reactphp/filesystem to asynchronously read the file

[jaapio]

will have a look at that. however that will introduce a new dependency? Not sure if that will be a problem. and resolve.conf has the same issue?

[cboden]

Yeah...just checked out filesystem...no problem with the extra lib dependency but it requires the EIO extension...so I would suggest going with 1. resolve.conf would have the same issue, yeah

[jaapio]

@cboden this is what I understood from your comment.
react is quite new for me so if I need to do any thing else I might need some more help.

[WyriHaximus]

but it requires the EIO extension

Actually, my recent work removed the dependency on it. Still fine tuning it, but it works without ext-eio 😄

[cboden]

Just call $this->loadHosts()

[clue]

👍 I'd love to see this feature in – however I'm not sure about the limitations imposed by the current implementation:

• The fopen() call is still blocking
• Only the StreamSelectLoop supports watching for file system events (the other event loop implementations will print a bunch of warnings)
• The child-process component introduces an additional dependency (which is okay), however the EIO extension it not generally available and the child-process adapter will likely have issues on Windows.

My personal vote would be: Do we really care if loading the file is blocking? The results will be kept in memory anyway, so perhaps we can make this an explicit choice so that the blocking calls can be performed before the loop runs?

[cboden]

I'm +1 for having an initial load that is blocking before the loop gets going in order to get this expected behaviour in. We can refactor to make it pure async at a later point in time.

[WyriHaximus]

@cboden that works for me 👍

[kuai6]

When it will be done?

[clue]

@jaapio Thank you for filing this PR and sparking the discussion again! 👍

Given that this PR hasn't received an update in a while, we've implemented this feature as part of #75 which landed in the last release

I believe this has been answered, so I'm closing this for now. Again, thank you for your contribution and keep it coming! 👍