[CF-Devel] Metaserver information.

[Mark Wedel]

Peter Mardahl wrote:
>
     
     
     >
     
      I think this is a cool idea, I'd add this though:
     
     >
     
      1)  Hostname
     
     >
     
      2)  # players
     
     >
     
      3)  Version
     
     >
     
      4)  Description
     
     
 What should the metaserver do, if anything, if the ip address the connection is
really coming from does not match the hostname?  Or should the metaserver not
even try to resolve that (I know that resolving hostname/ip can hang, so in this
case, you would need a helper process or the like that tries to resolve these. 
This could be implemented as a simple pipe/socket.  Server sends the data to
that helper, and reads it as available.)

>
     
     
     >
     
      Version is the hard part.  How about setting creating a VERSION file
     
     >
     
      which contains the current date, for people using CVS, and
     
     >
     
      a tag, for people using releases?
     
     
 The current version.h and patchlevel.h could probably be merged into one file -
there is no strong reason that they need to be separate (I don't think).  At one
point, imake might have had a reason for it when packaging releases, but now
days I beleive I just set that in the top level makefile.

 That said, you could have something like normal versions for released copies
(0.95.7 for example).  This gets hand set by me when I make a release.

 After that point, a cron could update it each night to be something like
0.95.7-2000/11/10 - the trailing date would then note it is a CVS release.

 I was thinking you could probably grab real version numbers off CVS if you
could have the file updated automatically.  All files more or less have
something like:

/*
 * static char *rcsid_config_h =
 *   "$Id: config.h,v 1.8 2000/10/16 19:26:38 peterm Exp $";
 */

 at the top of the file, and there is no requirement that these be commented
out.  In fact, many applications don't comment that stuff out, as you can then
do something like a 'strings crossfire | grep config.h' and see what version of
a particular file is being used.

 The problem is I'm not sure how useful that 1.86 version number will be other
than to get a rough idea of the build, which we get just as well with the date
(if we wanted that, we could add the $Id$ string to the CHANGES file, and grep
that out into version.h or something.)  Advantage I guess that has is that if
nothing has been checked in, at least the metaserver will show them as the same
version.   In this case, you would probably need to have it in conjuction, like
0.95.8, build 1.153 so people don't need to that starting at version 1.146 was
when it became 0.95.8 so that they are really playing on an 0.95.8 file.

 I think it would still be good for standard release servers not to have any of
that trailing information to make it more clear that that is a stock release and
not cvs update.  If there is demand to do patches for these things, then the
patch script would update that (0.95.7p1 for example).