Complete.Org: Mailing Lists: Archives: freeciv-dev: May 2003:
[Freeciv-Dev] Re: client/server authentication (PR#1767)
Home

[Freeciv-Dev] Re: client/server authentication (PR#1767)

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: kaufman@xxxxxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: client/server authentication (PR#1767)
From: "Raimar Falke" <rf13@xxxxxxxxxxxxxxxxx>
Date: Thu, 8 May 2003 13:19:36 -0700
Reply-to: rt@xxxxxxxxxxxxxx

On Thu, May 08, 2003 at 12:00:22PM -0700, Mike Kaufman wrote:
> On Thu, May 08, 2003 at 11:36:39AM -0700, Raimar Falke wrote:
> > > 
> > > As chris mentioned, I would be willing to go for a --password option, 
> > > which
> > > if it is used, will skip the password input step and send that password to
> > > the server. 
> > 
> > Command line options are bad since they can be viewed by the other
> > users of the system. ps shows this.
> 
> hmm, I don't like this. That password is going to have to sit in the
> client's data segment somewhere since we don't want to have it disappear
> from the rc file if we save our settings (we'll have to save that too).
> 
> If you think that's ok for the client, we can do this, but for now, the
> user is going to have to add it manually to the rc file.

If you don't like this the client can read it from another file
~/.civclient_passwords for example.

> > > > This may be an indication that the userdb/ directory isn't needed.
> > > 
> > > no. This needs to be an separate library, and building two different
> > > libraries in one directory doesn't seem great design to me.
> > 
> > > > As a side note: I think we should seperate between the user_db
> > > > interface (user.h and user_db.h) and the implementation
> > > > (user_db.c). So user_db.c should be renamed so that it contains a
> > > > "file", "reg" or "simple".
> > > 
> > > why? This seems to me one of the more pointless renames. You need a better
> > > rationale that this. 
> > 
> > A have the idea that in the default installation there would be a
> > server/libfile_userdb.a. If now someone want to build another userdb
> > for mysql this would end up in server/libmysql_userdb.a. At configure
> > time it is decided what library should be built. For freeciv it
> > doesn't matter if the mysql code files are in server/, server/userdb/
> > or server/userdb/mysql/.
> 

> Hell no Raimar. see above. one directory, one library. Since the
> plan is to make this library pluggable, it makes even more sense for
> this not to be in the server directory (and compiled by default, see
> my other post). Any you're never going to want two different
> database libraries at once, so there's no reason to have them named
> different things. And no, we're not ever going to be including
> multiple db frontends in cvs, so the the naming scheme is
> pointless. Let's think a little about bloat here. Let's think about
> how many people might use a real database for their freeciv
> implementation. One (us)? Two? Even if it is two or half a dozen,
> what makes you think that we'll want to force them to all use (for
> example) mysql? No. This is a non-starter. The point to having a
> very simple database (via registry) is to make it easy for someone
> to post their server on metaserver for a pickup game, etc without
> the issue of getting a real database. Frankly, I'm not sure why
> we're bothering with lockfiles in this particular case. The chances
> of getting locking issues using the registry lookup method, on a
> machine other than pubserver which is running _more_ than one server
> in pretty fricking miniscule.

If you don't want different names how will Paul implement the mysql
version of the userdb for pubserver? It looks like he first have to
remove the code for the registry version?!

        Raimar

-- 
 email: rf13@xxxxxxxxxxxxxxxxx
 "SIGDANGER - The System is likely to crash soon"




[Prev in Thread] Current Thread [Next in Thread]