[crossfire] good http library for new metaserver?

[Mark Wedel]

Nicolas Weeger wrote:
> Hello.
> 
>>   There is also libwww.  I'm sure there are others.
>>
>>   So this is really just a question to see what is out there.
> 
> Here is my checklist for that:
> * works under Linux, Windows, Mac (ok, no Mac client for now, but well, it'll 
> come some day). The more portable, the better
> * can do other things than http. There have been talks about ftp transfers for 
> eg music. Since we're deciding on a library for http, let's decide for a 
> library for everything :)

  How about curl/libcurl:
http://curl.haxx.se/
http://freshmeat.net/projects/curl/ (this shows all supported OS's)

  It appears to meet your criteria, and is somewhat standard it seems (several 
other tools use it, so it is probably on a fair number of systems).  It was at 
least on my system already, which is a hopeful sign.

> 
>>   I'd also suggest this handling if the library is missing:
>>
>> For the server, this is OK, unless the user has turned on the metaserver
>> notification setting.  If that is set, then program terminates with error -
>> either install the library, or turn of metaserver notification.
> 
> I'd require the library unless a configure flag is set. It's easier to build 
> with library and not use than don't build and need to rebuild later :)

  To be consistent, I then think that should be a standard for all 
libraries/features, but I'm not sure that is the correct approach if a library 
isn't need for operation.

  One of the points of configure is to find what capabilities the OS has in 
order to create a binary that supports as many features as the OS has easily. 
Somehow it seems wrong to me for configure to fail if you don't use a bunch of 
--disable-... options.

  Many current features of crossfire currently use this behavior - if library is 
not found, you don't get that feature, and not configure doesn't fail.  I'd 
argue that the metaserver is least critical of these (plugins almost should be a 
requirement).  And as a data point, there is what, 20 servers that report to the 
metaserver, but according to sourceforge, there has been 437 downloads of the 
server package.  It's hard to say how many of those downloading are actually 
compiling, but at the same point, those numbers don't include any mirrors.

  All that said, configure does print out a message at the end about what 
features it will be building.  Adding in a line about metaserver seems 
completely reasonable, so you're not forced to recompile.  OTOH, it doesn't take 
too long to compile crossfire.

  Adding a note to the settings file in the metaserver section about making sure 
you're server has support could also be used as a hint.  Because as of right 
now, the server as distributed has metaserver support turned off.  So for a good 
number of people, they'd probably never notice/care about missing this (whether 
it finds the library or not would not change the behavior of their server at all).

> 
>> For client, maybe shouldn't be a fatal error?  Or maybe it is a fatal error
>> unless something is passed into configure (configure --no-metaserver or
>> something) - it would seem that for most people, this is pretty core
>> functionality, but there could be some that don't need it (own server,
>> inside company firewalls, whatever)
> 
> Then you need to handle this case where there is no metaserver listing. And 
> previous argument applies :)

  no metaserver listing is basically the same as it is now if you can't get to 
the metaserver for some reason (firewall, down, whatever) - you just don't see 
many choices.

> Again, I think the library is mandatory, and requires a --no-metaserver flag 
> to bypass.

  For client, I'd tend to agree, because not having metaserver support is likely 
to be more critical.  And by default right now, the client tries to contact the 
metaserver, so there is some implied requirement for it.