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

Richard wrote:
>> Most of the
>> in-browser desktop mockups make me ask why not use Java Web Start /
>> ClickOnce / Flex anyway?
> 
> IMHO, Ruby + Rails is a far superior way to build both desktop and web
> apps.  Java is, too my taste,  a lousy C++, which I felt is the most
> elegant programming language ever.  But I've come to see that Ruby is
> the most economical yet powerful (in terms of programmer effort)
> languages ever.  Of course,  I'm not really qualified to make such
> judgments, despite 40+ years of professional programming experience
> with IBM mainframe assembler, Fortran, and Cobol to desktop Visual C++. 

For the client-side logic, you're still stuck to HTML and Javascript,
which are both flawed in their way. While web frameworks help with that,
it's still artificially shifting logic that could as well be done
client-side (validation which only requires checking against the data
the client is already operating on already, paginating content,
formatting data, etc.) I mentioned the above technologies because they
exist, while I'm not aware of any way to easily keep a Ruby-based client
program up-to-date conveniently, or even deliver it cross-platform
easily because of the dependency on native extensions.

I'm not very sure how Rails would be suitable to make desktop
applications, the framework doesn't seem to have a discernable core for
action processing that would be unaware of web idiosyncracies. I might
be wrong.

The namedropped (in a snarky way) experience is ad verecundiam, a
logical fallacy. To respond to it any more would be stooping down to the
same level.

> I see by your disdain of some aspects of the current state of affairs
> that you've thought a lot about some of these issues,  so I'm
> interested in knowing whether you're more sanguine about the
> Ruby-Rails-WEBrick-MySQL environment.
> 

Ruby is fine if you can juggle the complexity, but it requires more
programmer competence and dilligence for the software to be robust - a
quality that grows with importance the closer to end users you get.

I'm past my "Oooh, shiny!" Rails phase. Scaffolding is nice, yet in a
way just smoke and mirrors, ActiveRecord is just way too basic as an ORM
solution and not much simpler to use once enough of its assumptions on
the data model and physical DB schema don't hold. Convention over
configuration gets hairy in complex deployment scenarios - table names
changing (having to accomodate to a weird naming convention between
prototype and production) mean a recode, and generally the magic becomes
harmful if you need to separate the object model from the tables and
columns. I don't think this applies to your scenario though.

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.

As for MySQL, I more or less share the attitude of Austin Ziegler on it.
Most of MySQL users are mentally stuck with v3.x and make data schemas
that would make an onion cry. Mentioning "no security risks" if you let
arbitrary clients access your database is debatable though, I thought
you're supposed to keep production data storage behind a firewall.
Giving end-users write-access credentials sounds like way too much
potential for a malicious user to do damage to me, unless you only allow
write access through secured stored procedures, or bend your model
backwards for table-level restrictions to be sufficient. I'll have to
disclaim though that I'm far from a security expert, so the above are to
an extend half-educated guesses.

As for the whole environment, my work experience so far has been in
scenarios where that would blow up on data schema brittleness, or the
generations-of-maintaining-interns syndrome. As for any such solution
template, there are assumptions that must hold before the solution can
be an effective one. The "we have a hammer, now every problem is a nail"
approach is a very destructive self-delusion (to wit: J2EE's rap of
being overcomplex after hype led to it being used for the wrong range of
problems.) Since I don't know your problem, and the umpty other factors
that have to be considered when creating a software system's
architecture (the target audience, the deployment requirements, the
performance requirements, how well does the domain model map to being
handled over the web), I can't judge whether the approach you outlined
is a good fit.  This is hugely digressing from the original topic though.David Vallner


--------------enig36636D50971CEC13CA4D3BBB
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)

iD8DBQFFha0Jy6MhrS8astoRAnOKAJ49BwY0dQjHqukGvT9R2PawXT1RgwCfbsfk
gF5NeWnIBXi4srJHR8byLBw	py
-----END PGP SIGNATURE-----

--------------enig36636D50971CEC13CA4D3BBB--