Hi David,

> > - broadcast a message to all users that the should update their version
> > of app by getting the latest and greatest version?
>
> Mind the "should". ... you run the risk of someone with a version that's not up-to-date
> thrashing the data.

Good point.  I'll be able to force all users to shut down their
connection to DB.  How about I put a ver. # in the DB (inaccessible to
users directly) and have the login screen check that the user's version
matches the version requirement in the DB; mismatch will inhibit login
if anything's amiss,  just like a bad userid or password?

> > I think this process works this way: The
> > controller tells the model to cook up some data, suitably filtered and
> > ordered, and keep it available for access by the appropriate view. [snip]
> >
> > Is my description of the process OK?  Does "push" refer to the
> > "web-server to browser" step?
>
> No. With a webapp, the process is always initiated by the web browser,
> and it's a pull.

Agreed.  I omitted the steps where the user:
- starts a local copy or WEBrick
- directs his/her browser to localhost:3000, which defaults to the
logon screen
- provides his/her credentials (and the user's app's version is check
against the DB)

> The produced HTML is the current state of the view for
> a user, and if the user doesn't poll for changes, it will go stale if a
> relevant part of the model changes.

There will be no change to the model while any user is connected to the
DB, at least not on my watch.

> The "hack" around this is ...

So I'm saving the workaround suggestions,  but not thinking about them
for a while.

Thanks for all your ideas.  Your insights, along with Suraj's,  have
boosted my confidence that I'll get my first Rails production system
running smoothly.

Best wishes,
Richard