From: David Vallner <david@...>
Date: 2006-12-21T09:40:01+09:00
Subject: Re: does Ruby generate WINDOWS and dialog boxes?

--------------enigB2ADD3CD8C7B992BA5D7D0E9
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Richard wrote:
> - broadcast a message to all users that the should update their version=

> of app by getting the latest and greatest version?
>=20

Mind the "should". It's a bit too late at night for me to try to go over
such scenarios in my head, but there's always users that can't be
bothered (me, on any occasion I can get away with it, for instance), and
you run the risk of someone with a version that's not up-to-date
thrashing the data. Somehow. Just a point to watch out for. Either keep
more stringent checks on the DB-side, or make sure that updates to users
happen automatically, transparently, and preferrably fast - depending on
how controlled your user base is, you might or might not get away with
the app "calling home".

Of course, odds are that's just me being paranoic and that wouldn't
really happen with a proper data model design in the first place.

> 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.
> Then the contoller tells the appropriate view to do its thing with the
> data,  namely produce HTML with the data suitable tagged plus embedded
> Ruby and send that amalgam  to the web-server.  The web-server invokes
> Extended Ruby to process the "enriched" HTML and send the resulting
> vanilla HTML to the browser.
>=20
> Is my description of the process OK?  Does "push" refer to the
> "web-server to browser" step?
>=20

No. With a webapp, the process is always initiated by the web browser,
and it's a pull. 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. The "hack" around this is having the
browser regularly poll for updates (in a JS loop), and more or less cook
your own event loop using Ajax, as-known-from-GUIs. (Which you do if, in
fact, you expect asynchronous changes rendering someone's view state
obsolete and that is an undesirable thing.) The one problem there is
lag, HTTP has bad performance characteristics for this - otherwise it's
semantically the same you do in GUIs, except you have to implement it
yourself (or look into an Ajax support library for help). So I'd take
frequency of necessary updates and the connection quality into account
too, if you need either more "realtime" behaviour, or you want to
service sluggish connections, you might want to do something against it.
Comet comes to mind if that's the case.
[http://alex.dojotoolkit.org/?p=3D545]. I'm not sure if Rails /
Prototype.js support that though, so you might end up having to use
Dojo, which Rails didn't have special support for last time I checked.

>> Nothing that's really a showstopper from this point of view, just the
>> request / response / sessions clutter that's not really essential to t=
he
>> way I would model a rich GUI application.
>=20
> Gotcha.  But all the request/response stuff is on a single box,  so the=

> processing time should be a few milliseconds,  don't you think?
>=20

Yes. It's just clutter from the elegance point of view, not a
performance one.

[Stuff I didn't have anything to add to snipped.]

David Vallner


--------------enigB2ADD3CD8C7B992BA5D7D0E9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFFidfby6MhrS8astoRAhFCAJ0S28r/ozIrGGj8UvubAzH9YqZJlQCfbVCA
tg31nZl7ZcEfE/BpT7IQXJU=
=ZW19
-----END PGP SIGNATURE-----

--------------enigB2ADD3CD8C7B992BA5D7D0E9--