I wrote some text above the quoted text in your message, saying:

>> If I understand correctly:

>>>> WEBrick is a development server. Probably Good Enough for a one server -
>>>> one user scenario, but I don't think it's meant to handle more.
>>> 
>>> Great: that fits my target scenario.

>> We have a one-user application...

So, whatever I wrote below, it was under the assumption that only one 
user would access the database (i.e. each user has their own DB).

Richard wrote:
>> > That's something I have to work on.  My first thought is that the
>> > MySQL server has to be on a machine whose physical security is
>> > maintained.  Then it needs network authentication for users and user
>> > machines hitting on it.  MySQL seems to support user security pretty
>> > well with access levels and encrypted passwords.
>>
>> And lots of baggage if we use a system for multi-user applications...
> 
> You think MySQL 5.0 server version is not good for multi-user
> applications?

It is fine. However, my software engr. professor said PostgreSQL is 
better because MySQL doesn't handle concurrency issues very well.

>> And security concerns about data leaking from the user's machine...
>>
>> Might I suggest:
>>
>> - use WEBrick on a firewalled port that is accessible only from the
>> local machine 0.0.0.0
> 
> I'm planning to use WEBrick server on each user's machine, as well as
> on the database server/development machine/version-control repository.
> Everybody will access their own copy of the web-server at
> localhost:3000. where localhost=127.0.0.1.  
>
> Is 0.0.0.0 superior to that, and why?

I used to think 0.0.0.0 was better (somebody told me so, long ago), but 
I've just read up on it again and there really doesn't seem to be any 
difference. Thus, I would just use "localhost" because it is more human 
readable.

>> - use the SQLite3 (http://wiki.rubyonrails.org/rails/pages/SQLite)
>> because it stores data in normal (binary) files on the machine it's
>> running on. For example, if your Rails app is located in /foo/bar, then
>> the DB files will be in /foo/bar/db/
> 
> Right now,  I have MySQL 5.0 running on my development machine, and it
> stores the data the data sub-directory of its installation directory.
> I imagine it's easy to configure it to store data wherever I wish to
> target it.

Yes, that is fine.

>> - for concerns about upgrading (i.e. it's easier to update one central
>> server than updating many individual machines), you could have each user
>> check-out your whole rails app from a version control system. Then, when
>> you do maintainance updates to your DB schema and so on, the user would
>> simply update their check-out and run "rails migrate". Done!
> 
> (I noted your "rake migrate" correction)
> 
> If confused about one thing here.  Since the databases and development
> environment are on one machine, shouldn't I:
> - run "rake migrate" only on this machine
> - update the Rails app to relating to the changes in the database
> - update my test suite to test those changes (or write the tests first
> to satisfy some purists)
> - run my entire test suite until all tests pass
> - submit my Rails app to the version control system
> - broadcast a message to all users that the should update their version
> of app by getting the latest and greatest version?

Yes, that is correct.

However, this brings up another issue. Since each user's local copy of 
your Rails app has write access to your central DB, you could lose all 
your data on the central DB if a user runs

  rake migrate VERSION=0

It's kinda silly, but possible.

Good luck.

-- 
Posted via http://www.ruby-forum.com/.