Lan Barnes wrote:
On Sun, Apr 10, 2005 at 02:54:56AM -0700, boblq wrote:
On Sunday 10 April 2005 02:20 am, Gabriel Sechan wrote:
There's still a difference between browsers. Different browsers render
differently, and always will.
So what? No one said that the rendering had to be identical.
Simply intelligible is fine. If the rendering of different browsers
of the obvious standards PGA recommended is not intelligible
then "their bad."
But it's not always intelligible, even in really good browsers. My
netflix account works for firefox, but the movie titles are almost
unviewable in the text entry boxes.
As for "their bad," don't be silly. Try telling your boss that the
reason accounting can't access their data base with your program is
because they have for-shit browsers. That's as lame as "works on my
machine."
The universality of web interfaces is a myth.
Web interfaces can be very good, but:
- state is kludged
- performance is for-shit
- simplicity is enforced by lack of tools
- they ain't universal
- the bulk of developers and all PHBs think 100% of the world uses IE
Again, this is why we have W3C and standards, and schools now teaching
those standards (I just went through a slew of classes all of which taught the
correctness of following standards and the wrongness of developing only for M$
and IE, or any other proprietary platform). Now, to touch on a few points in
several e-mails within this thread.
The applications I've written that use web front ends actually generate dynamic
web content. They have used Perl CGIs and C baseed applications as the back
end. They've also used databases (Sybase, Oracle, MySQL, and DB2). The web
interface is linked to the back end using a defined API. So, essentially I do
have a CLI, but I spent little time developing a GUI in YAPL (Yet Another
Programming Language) that may or may not port to another platform. I used a
web browser to do it for me. Installing a web server is no more difficult than
installing the application itself, and if the developer is any good at all, a
web server installation utility (script) can be written to make it even more
painless (even for grandma). BTW, not many grandmas I know of install their own
programs. Most users have someone install programs for them, and the programs
they do install have automagical configuration. You could put a mail server,
web server, file server, and ftp server in a game application
and the average user would never even know it was there unless you or the
application told them. There's also using a cut down HTTP application to take
the requests and respond to them as needed.
Web interfaces are generally slow because the developers use all the bandwidth
serving up cute graphics, sounds, animation, music, etc. They don't use CSS.
They use something rediculous like Word, Dream Weaver, or Frontpage to create
the pages and in turn generate more useless HTML than is necessary. They don't
conform to the standards as they should. All this is a design problem, not a
core technology problem. The applications I have written using web front ends
looked essentially the same on IE, Netscape, and Opera. The main problem I have
today (meaning right now with things I am working on now) is that IE does not
properly support PNG. The next version is supposed to, but no version in
existence now does. This is M$ bad because Mozilla has had proper support for
years now (not sure about Opera and others). So, I can't use my preferred image
format for my pages.
For an application that will *easily* port from platform to platform (and I
don't just mean Windows and Linux), there really are very few choices in
language. Java will if NOT developed on a Windows system, and often will if
developed on a Windows system (if done with care). Perl, PHP are a couple
options for interpreted languages. For GUIs there aren't many universal tools
either. Gus mentioned a couple, but they do not encompass as wide a range of
platforms as Perl, Java, and web interfaces do and he mentions some other
issues as well.
I have recently installed Bugzilla on my server. It uses Perl and the Template
Toolkit (Template module for Perl) for the front end and MySQL for the back
end. This module allows Perl CGI scripts to create web pages for Bugzilla.
Through the use of them I have been able to quickly build a bug tracking system
tailored to my company. It's fast, it has a GUI, it's compliant to standards,
it'll run on anything Perl, MySQL, and Apache will run on.
Java applications can be deployed with the applicable JRE included. Any
properly deployed application includes all necessary components for running the
application.
As I always say, the right tool for the job. So what is the right tool for your
particular job (whoever you are)? :)
(I see now that there are even more posts in this thread. I guess I'll have to
get back to it later :) )
PGA
--
Paul G. Allen
Owner, Sr. Engineer, Security Specialist
Random Logic/Dream Park
www.randomlogic.com
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
