On Dec 20, 2007 10:41 PM, Dan Fandrich <dan_at_coneharvesters.com> wrote:
> In my experience, a DHCP server won't provide option 252 unless the client
> asks for it specifically, which doesn't seem to happen very often. Plus,
> many DHCP clients will just ignore the value even if it is sent. So,
> for greatest interoperability libproxy would need to have the capability
> of doing its own requests.

Its correct that DHCPd often doesn't send it and clients don't ask for
it. However, I won't implement DHCP unless they can be configured to
do so. I'm not willing to waste network traffic with subsequent DHCP
calls (not to mention the headache of making sure you match option 252
with the right lease). Hence why I said before that I might not ever
implement DHCP or SLP.

> > I'm sure I will! I'm happy to work with someone on a patch. :) The
> > learning curve for libproxy is minimal compared to libcurl (we only
> > have 3 functions). This is why we are trying to push upstream people
> > to write patches.
>
> Yang brings up a good point about licensing, although libcurl already
> supports libidn which is also LGPL. We'd never be able to get rid of the
> the existing proxy code in libcurl for that reason, or enable it by default.

If LGPL is a barrier to adoption, I'd be open to relicensing. I wrote
all the code, so its not a problem. See, no "poison pill"! :) I don't
really care about political idology, I'm just commited to having the
best solution possible.

Were you able to get the build issue resolved?

Nathaniel
Received on 2007-12-21