From: Pratibha
Subject: How to do GUI in web-based apps?
Date: 
Message-ID: <18e1cdb3.0110151522.25d1c139@posting.google.com>
In the pre-web era, the way to do GUI was to use
some library/package/toolkit, either window system-specific
(e.g., X/Motif, Symbolics) or window system-independebt
(i.e., CLIM).

These days, it seems that the preferred design is to
have Lisp program(s) sitting behind web servers and
possibly in front of databases such as Oracle or PostgreSQL.
Users use any web browser rather than a specially written
"client" program, and are none the wiser as to
what language (and database and server infrastructure) is
used to implement the application logic.
I understand that Yahoo!Store is an example of this
architecture (as described in Paul Graham's
articles).

In this situation, how do you do (what is the recommended
way to do) the GUI?  Is it an "HTML thing"?  A "CGI thing"?
Thanks for any pointers to the relevant concepts /
software standards / technologies.

Also, how is the performance compared to traditional
"client-server"?  Although we can access our bank accounts
or shop large stores today via the web, it seems that,
IN HOUSE, the banks tellers or call center/customer service
people still use special client apps rather than web browsers to
internally access their own infosystems.  Is there a
(e.g., performance or security) reason for this dichotomy, or
have they just not gotten around to web-ifying their
internal systems even though they have web-ified their
exterior?

From: ········@acm.org
Subject: Re: How to do GUI in web-based apps?
Date: 
Message-ID: <fTKy7.6219$7Y4.1071263@news20.bellglobal.com>
··········@yahoo.com (Pratibha) writes:
> Also, how is the performance compared to traditional
> "client-server"?  Although we can access our bank accounts or shop
> large stores today via the web, it seems that, IN HOUSE, the banks
> tellers or call center/customer service people still use special
> client apps rather than web browsers to internally access their own
> infosystems.  Is there a (e.g., performance or security) reason for
> this dichotomy, or have they just not gotten around to web-ifying
> their internal systems even though they have web-ified their
> exterior?

I'd consider the following things:

1.  Within the bank, there are doubtless enough users to justify the
added cost of building tailored front ends.  If it costs an extra $1M
per year, and there are 1000 tellers, that amounts to a relatively
tiny amount per teller.  $1000/teller in software costs isn't much
compared to what the teller gets paid, for instance.

2.  Security is likely high on the list.  A tailored GUI application
using Motif, OS/2 PM, Win32, GTK, or such that has NO "generic"
network-enabled interface will be completely unable to access the
wrong systems.  On a web-based app, someone could drop in a bad link,
and redirect all the bank tellers to www.HotSexToday.com (apparently a
nonexistent domain name :-)) or, worse still, to a site that _looked_
like the bank's but which instead collected account information.

3.  Some session information can reside on the "client,"
well-controlled, and this may provide them with a better ability to
tune performance characteristics.  (Maybe.)

4.  Web applications are regarded as not offering quite as much
ability to "tune" the GUI as is offered by coding clients to use a
particular GUI.  [Note that this would imply that something
system-independent need not come to the table...]  Witness that some
banks reject connections from anyone using browsers other than
specific versions of IE or (maybe!) Netscape.

-- 
(reverse (concatenate 'string ··········@" "enworbbc"))
http://www.ntlug.org/~cbbrowne/linux.html
From a UK local newspaper, the Horsham Friday-Ad:
"Parachute for sale, once used, never opened, small stain."
From: Doug Alcorn
Subject: Re: How to do GUI in web-based apps?
Date: 
Message-ID: <87u1wzokz5.fsf@balder.seapine.com>
········@acm.org writes:

> 1.  Within the bank, there are doubtless enough users to justify the
> added cost of building tailored front ends.  If it costs an extra $1M
> per year, and there are 1000 tellers, that amounts to a relatively
> tiny amount per teller.  $1000/teller in software costs isn't much
> compared to what the teller gets paid, for instance.

true.

> 2.  Security is likely high on the list.  A tailored GUI application
> using Motif, OS/2 PM, Win32, GTK, or such that has NO "generic"
> network-enabled interface will be completely unable to access the
> wrong systems.  On a web-based app, someone could drop in a bad link,
> and redirect all the bank tellers to www.HotSexToday.com (apparently a
> nonexistent domain name :-)) or, worse still, to a site that _looked_
> like the bank's but which instead collected account information.

Practically, this is false.  Of course, security is an issue; however,
most of these type internal applications aren't happening across the
open internet.  They are nestled behind firewalls and on VPN.

> 4.  Web applications are regarded as not offering quite as much
> ability to "tune" the GUI as is offered by coding clients to use a
> particular GUI.

This is the real reason why more companies haven't switched over.  As
posted elsewhere, HTML/JS is a PITA to make cross-browser compatible.
It's doable, but it's also a lot of maintenance.  I don't think even
the sophistication of CL can alleviate that.

Also as mentioned elsewhere, the _only_ reason to do this is for ease
of deployment.  Don't underestimate this.  The cost of modifying a
user's PC is high.  Depending on how many PCs you have to deal with,
it could certainly exceed the cost of doing HTML/JS development.
That's one reason why VT100s are still in use.  It has cheaper
development without the added deployment cost.  The only downside
there is that people are becoming increasing frustrated if the
application "looks" clunky.
-- 
 (__) Doug Alcorn (···········@lathi.net http://www.lathi.net)
 oo / PGP 02B3 1E26 BCF2 9AAF 93F1  61D7 450C B264 3E63 D543
 |_/  If you're a capitalist and you have the best goods and they're
      free, you don't have to proselytize, you just have to wait. 
From: Tim Bradshaw
Subject: Re: How to do GUI in web-based apps?
Date: 
Message-ID: <nkjelo3iwi1.fsf@davros.tardis.ed.ac.uk>
Doug Alcorn <·····@seapine.com> writes:


> Practically, this is false.  Of course, security is an issue; however,
> most of these type internal applications aren't happening across the
> open internet.  They are nestled behind firewalls and on VPN.
> 

The danger is that even though people can not see in, it may be
possible for a web browser to see *out*.  Even though I'm talking to a
server over a seure network, if that machine is compromised, or if
someone merely fools me into looking at a site on an external network
which `looks like' the internal machine I may be in trouble.  Of
course the web browser should tell me this, but most of them don't do
so in a very obvious way (like sounding a siren and setting off
fireworks or something), and they especially don't do that if you want
to use COTS web browsers and you employ monkeys to do your IT support.

Two obvious solutions are (1) prevent external web access: probably a
good thing, but until recently probably not done because people would
complain and leave.  This should be different now that people are a
bit more worried about getting laid off. (2) have two machines, one on
the internal net which can not see out and one which can not see *in*
to the secure net: this works but it's very expensive.

(Note that `see out' here can be `see into any less secure bit of the
net' which might include bits of the internal company network.  This
is one of the classic secure-OS things where it's important that you
can't copy a secure thing to a non-secure thing even if you have
permissions to read the secure thing).

Given these & other considerations, I can see a lot of reasons not to
use web-based stuff.

(Actually, there's a nice opportunity here.  Most of the Lisp
deployment systems for Windows I've seen do it by making a single
executable which (if you write it slightly carefully) you can just
drop into a machine and it works.  No registry edits, no dependencies
on shared library versions, or installation directories, it just
works.  This should be a win for deploying custom applications on a
lot of Windows boxes, which is often a serious pain: in these
environments fitting on a floppy doesn't matter, not having huge
dependencies on every fine detail of the OS *does*.)

--tim
From: Thomas F. Burdick
Subject: Re: How to do GUI in web-based apps?
Date: 
Message-ID: <xcvvghfcixg.fsf@apocalypse.OCF.Berkeley.EDU>
Tim Bradshaw <···@tfeb.org> writes:

> (Actually, there's a nice opportunity here.  Most of the Lisp
> deployment systems for Windows I've seen do it by making a single
> executable which (if you write it slightly carefully) you can just
> drop into a machine and it works.  No registry edits, no dependencies
> on shared library versions, or installation directories, it just
> works.  This should be a win for deploying custom applications on a
> lot of Windows boxes, which is often a serious pain: in these
> environments fitting on a floppy doesn't matter, not having huge
> dependencies on every fine detail of the OS *does*.)

And this even integrates nicely with a company network -- you can
stick a link to a windows executable on a web page, click on it in IE,
and choose "run from this location".  If you just tell everyone to run
it this way, you don't have to worry about updating the client of
everyone's pc.

-- 
           /|_     .-----------------------.                        
         ,'  .\  / | No to Imperialist war |                        
     ,--'    _,'   | Wage class war!       |                        
    /       /      `-----------------------'                        
   (   -.  |                               
   |     ) |                               
  (`-.  '--.)                              
   `. )----'                               
From: ········@acm.org
Subject: Re: How to do GUI in web-based apps?
Date: 
Message-ID: <RHYy7.9370$7Y4.1459253@news20.bellglobal.com>
Doug Alcorn <·····@seapine.com> writes:
> ········@acm.org writes:
> > 2.  Security is likely high on the list.  A tailored GUI
> > application using Motif, OS/2 PM, Win32, GTK, or such that has NO
> > "generic" network-enabled interface will be completely unable to
> > access the wrong systems.  On a web-based app, someone could drop
> > in a bad link, and redirect all the bank tellers to
> > www.HotSexToday.com (apparently a nonexistent domain name :-)) or,
> > worse still, to a site that _looked_ like the bank's but which
> > instead collected account information.

> Practically, this is false.  Of course, security is an issue;
> however, most of these type internal applications aren't happening
> across the open internet.  They are nestled behind firewalls and on
> VPN.

Practically, it is _ambiguous_.

The problem is definitely not of Bad Guys Getting in; it's of the
teller accidentally Getting Out.

If the application uses a protocol like HTTP that is _so_ transparent
to redirection, it wouldn't be overly difficult to redirect some
tellers either outside the bank, or, _much_ worse, _accidentally_, to
a test server inside the bank.

Suppose the teller hits a test server that contains realistic, but
out-of-date data.  They might give customers cash based on incorrect
account information.  The cash goes out; the "auditing" is done in the
test system, but doesn't hit the real one.  The test system then gets
cleaned up with a fresh copy of production data (or otherwise gets
cleared off), and the data's gone.

There lies a _mess_, and that scenario doesn't involve any
inappropriate passages of data through firewalls.

And it doesn't touch on the "www.HotSexToday.com" scenario, either;
firewalls are set up to keep intruders from getting in, but permit
_some_ degree of letting users get out.  If the tellers are doing
everything "web-based," then a natural step down the road _is_ to
permit having _some_ accesses to things outside the bank.
-- 
(reverse (concatenate 'string ····················@" "454aa"))
http://www.cbbrowne.com/info/spreadsheets.html
Rules  of  the Evil  Overlord  #201.  "All  giant serpents  acting  as
guardians in underground  lakes will be fitted with  sports goggles to
prevent eye injuries." <http://www.eviloverlord.com/>
From: Paolo Amoroso
Subject: Re: How to do GUI in web-based apps?
Date: 
Message-ID: <S27MO6SuWp5Vq5ZeEktcghxU1RQD@4ax.com>
On Tue, 16 Oct 2001 00:07:39 GMT, ········@acm.org wrote:

> system-independent need not come to the table...]  Witness that some
> banks reject connections from anyone using browsers other than
> specific versions of IE or (maybe!) Netscape.

Not just banks...


Paolo
-- 
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]
From: Christopher Stacy
Subject: Re: How to do GUI in web-based apps?
Date: 
Message-ID: <u1yk4qgwn.fsf@spacy.Boston.MA.US>
>>>>> On 15 Oct 2001 16:22:49 -0700, Pratibha  ("Pratibha") writes:
 Pratibha> Is there a (e.g., performance or security) reason for this
 Pratibha> dichotomy, or have they just not gotten around to
 Pratibha> web-ifying their internal systems even though they have
 Pratibha> web-ified their exterior?

In many businesses, the preferred GUI is not even a PC; rather, a
terminal is used (CRT with keyboard, cursor addressing, protected
input blocks, blinking, and inverse video).  Something like a VT-100
or an IBM 3270 class device. This kind of "dumb terminal" has pretty
much all the functionality that can be achieved in a straightforward
web page.  This sort of interface has been common since the early 1970s.
A whole bunch of such terminals can be driven and controlled by a
single low-end PC, and there are no configuration management issues.

If you want to use a web browser as your GUI, and you're going to do
anything more than that, you must be prepared for an enourmous investment
in software development and maintenance.  Javascript and the underlying
web page object models are radically different on different browsers,
and are not even compatible across minor release versions of the same
browser.   Anything the least little bit fancy will require you to write
several different base implementations, and constantly maintain them.

Some people write web-based GUIs for their Lisp applications, but that
approach mostly makes sense when they're doing some sort of web-centeric
(eg. application service provider) system.  You might develop your own
toolkit on top of that -- for example, I think CL-HTTP has a few things
inspired by CLIM.  But web browsers are not powerful GUI platforms, so
you're still restricted to trivial HTML/Javascript interfaces, and the
attendent nightmares as you try to do more things.

Serious GUI applications are programmed using Windows (eg. Microsoft
Foundation Classes, or a particular compiler vendor's GUI library),
or, on UNIX, some toolkit on top of the X Window System.
There are also toolkits such as Tcl/Tk.

I assume that people somewhere write Swing applications in Java, 
since I see job ads for Swing developers -- but I have never 
seen any non-trivial Swing application deployed anywhere, yet.

For Lisp, most people do what C people do: they use the compiler
vendor's proprietary GUI toolkit.  This may or may not be portable
across multiple platforms (usually not).  After that, there's CLX,
CLIM, and random toolkit bindings.
From: Alain Picard
Subject: Re: How to do GUI in web-based apps?
Date: 
Message-ID: <86669grn5r.fsf@gondolin.local.net>
··········@yahoo.com (Pratibha) writes:

> 
> These days, it seems that the preferred design is to
> have Lisp program(s) sitting behind web servers and
> possibly in front of databases such as Oracle or PostgreSQL.
> Users use any web browser rather than a specially written

FWIW, that's exactly the architecture of the system I'm
working on now.

> In this situation, how do you do (what is the recommended
> way to do) the GUI?  Is it an "HTML thing"?  A "CGI thing"?

It's a JSP/Javascript thing.  The JSP classes are implemented
in terms of Java classes which talk to the Lisp engine via CORBA.

> Also, how is the performance compared to traditional
> "client-server"?

If by performance you mean user responsiveness, it _sucks_.
Why this is viewed as acceptable by both business _and_ customers
is a bit of a mystery to me.

The only real advantage this has that I agree with (you can tell
I had long, hard discussions about this choice) is that the customer
doesn't need to install any "extra" software to use our system.

That plus I don't think our manager actually believed that you _can_
developed a cross platform GUI.  Who knows, he may be right.  I certainly
have no experience in developing such a beast.  I would have attempted
a wxPython type solution, I think, left to my own devices.  It can't
be worse than the pain the Java guys are going through.

-- 
It would be difficult to construe        Larry Wall, in  article
this as a feature.			 <·····················@netlabs.com>
From: Alain Picard
Subject: Re: How to do GUI in web-based apps?
Date: 
Message-ID: <86wv1ur71i.fsf@gondolin.local.net>
Fernando <···@wanadoo.es> writes:

> On Tue, 16 Oct 2001 08:42:59 GMT, Alain Picard <·······@optushome.com.au>
> wrote:
> 
> >
> >If by performance you mean user responsiveness, it _sucks_.
> 
> Where's the bottle-neck? Corba?


No, that's essentially infinitely fast.  The problem is the page
redraw on each hit.  We use Javascript to do client side stuff
whenever we need to be highly interactive [i.e. to prepare all the
required values to marshall a request to the server] then do
1 corba hit.

-- 
It would be difficult to construe        Larry Wall, in  article
this as a feature.			 <·····················@netlabs.com>
From: Kent M Pitman
Subject: Re: How to do GUI in web-based apps?
Date: 
Message-ID: <sfwy9mamxhe.fsf@world.std.com>
Alain Picard <·······@optushome.com.au> writes:

> Fernando <···@wanadoo.es> writes:
>
> > Where's the bottle-neck? Corba?
> 
> No, that's essentially infinitely fast.

Wow.  That's something you don't hear said about CORBA every day...
From: Alain Picard
Subject: Re: How to do GUI in web-based apps?
Date: 
Message-ID: <86ofn6qzlp.fsf@gondolin.local.net>
Kent M Pitman <······@world.std.com> writes:

> Alain Picard <·······@optushome.com.au> writes:
> 
> > Fernando <···@wanadoo.es> writes:
> >
> > > Where's the bottle-neck? Corba?
> > 
> > No, that's essentially infinitely fast.
> 
> Wow.  That's something you don't hear said about CORBA every day...


Yeah.  Do you prefer this one:
"Page redraws are infinitely slow".

You get your pick.

-- 
It would be difficult to construe        Larry Wall, in  article
this as a feature.			 <·····················@netlabs.com>
From: Wade Humeniuk
Subject: Re: How to do GUI in web-based apps?
Date: 
Message-ID: <9qhkj2$ln6$1@news3.cadvision.com>
> In this situation, how do you do (what is the recommended
> way to do) the GUI?  Is it an "HTML thing"?  A "CGI thing"?
> Thanks for any pointers to the relevant concepts /
> software standards / technologies.

I do not think the preferred way is to use Web based GUI's.

One of the principles in designing a system, be it software or a water
piping system is to reduce the number of components/interactions and thus
the number of possible places where the system can fail.  The approach (of
using a client side WWW Browser(Multiple)/Javascript/(maybe Java), utilizing
multiple platforms and OSes, a server side with Apache/Lisp/PHP
/Java/Perl/Shell-Configuration-Scripts and then a Database (take your pick))
IMO has too many languages and pieces to be a robust system (capable of
error checking and recovery).  If it can reduced down to one OS, a Lisp
client/interface with maybe a Lisp Server, Lisp Admin/Configuration system
and then a DB that would be better.  Even better may be a Lisp
Server/Admin/X-windows-type-client-interface with a DB.  Terminals running X
server software, Gui's run as X clients on teller's machines, the main Lisp
server synchronizing transactions.  A lot of software developers never take
into account the error and failure situations in their system.  That type of
mentality is OK when everything works but it is a nightmare when things go
wrong (and they do).

Using HTML for a complex GUI is not a good idea.  If you visit highly
interactive web sites you will notice that they tend to use things like
Shockwave or Java.

Wade
From: Marc Battyani
Subject: Re: How to do GUI in web-based apps?
Date: 
Message-ID: <ED6377FB5A878C94.E1436ABA5074A541.FE65FD4B55652B0C@lp.airnews.net>
"Pratibha" <··········@yahoo.com> wrote in message
·································@posting.google.com...
> In the pre-web era, the way to do GUI was to use
> some library/package/toolkit, either window system-specific
> (e.g., X/Motif, Symbolics) or window system-independebt
> (i.e., CLIM).
>
> These days, it seems that the preferred design is to
> have Lisp program(s) sitting behind web servers and
> possibly in front of databases such as Oracle or PostgreSQL.
> Users use any web browser rather than a specially written
> "client" program, and are none the wiser as to
> what language (and database and server infrastructure) is
> used to implement the application logic.
> I understand that Yahoo!Store is an example of this
> architecture (as described in Paul Graham's
> articles).
>
> In this situation, how do you do (what is the recommended
> way to do) the GUI?  Is it an "HTML thing"?  A "CGI thing"?
> Thanks for any pointers to the relevant concepts /
> software standards / technologies.
>
> Also, how is the performance compared to traditional
> "client-server"?  Although we can access our bank accounts
> or shop large stores today via the web, it seems that,
> IN HOUSE, the banks tellers or call center/customer service
> people still use special client apps rather than web browsers to
> internally access their own infosystems.  Is there a
> (e.g., performance or security) reason for this dichotomy, or
> have they just not gotten around to web-ifying their
> internal systems even though they have web-ified their
> exterior?

I'm currently working on such a system for a major bank. It's an intranet
application and I use Apache+mod_lisp+LW. The application is used by humans
(HTML+IE) and by other computers (XML over HTTP).

A problem with HTML GUIs is that they are functionally more limited and slow
than WIN32 apps for instance.

Marc
From: Raymond Toy
Subject: Re: How to do GUI in web-based apps?
Date: 
Message-ID: <4nvghfi9a8.fsf@rtp.ericsson.se>
>>>>> "Pratibha" == Pratibha  <··········@yahoo.com> writes:

    Pratibha> Also, how is the performance compared to traditional
    Pratibha> "client-server"?  Although we can access our bank accounts
    Pratibha> or shop large stores today via the web, it seems that,
    Pratibha> IN HOUSE, the banks tellers or call center/customer service
    Pratibha> people still use special client apps rather than web browsers to
    Pratibha> internally access their own infosystems.  Is there a
    Pratibha> (e.g., performance or security) reason for this dichotomy, or
    Pratibha> have they just not gotten around to web-ifying their
    Pratibha> internal systems even though they have web-ified their
    Pratibha> exterior?

While, I don't have a real answer, I would have to say, if it ain't
broke, don't fix it.

Just because it's the latest and greatest new technology doesn't mean
it will work any better than the old.  My pen and pencil still work at
least as well as the fancy new digital pads and stuff, plus I don't
have to worry about the batteries ever running out. :-)

(Sorry, this is a pet peeve of mine.)

Ray
From: Paolo Amoroso
Subject: Re: How to do GUI in web-based apps?
Date: 
Message-ID: <9GzMO2gTxGyi0Z17b9rP5DotRLPX@4ax.com>
On 15 Oct 2001 16:22:49 -0700, ··········@yahoo.com (Pratibha) wrote:

> In this situation, how do you do (what is the recommended
> way to do) the GUI?  Is it an "HTML thing"?  A "CGI thing"?

This paper may be relevant:

  Adapting CLIM Applications for Use on the WWW
  ftp://ftp.ai.sri.com/pub/papers/paley-luv95.ps.Z


> "client-server"?  Although we can access our bank accounts
> or shop large stores today via the web, it seems that,
> IN HOUSE, the banks tellers or call center/customer service
> people still use special client apps rather than web browsers to
> internally access their own infosystems.  Is there a

I saw a paper discussing this issue at Dan Bricklin's site:

  http://www.danbricklin.com

Look in the writings section for a paper about the evolution of PC software
architectures, or something like that. Let me know if you have problems in
locating the paper.


Paolo
-- 
EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation
http://web.mclink.it/amoroso/ency/README
[http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/]