Another thought:
Mozilla has a browser-based GUI named XUL in its current versions.
I look at brief look at the tutorial on http://www.xulplanet.org.
On first pass, I'm concerned about the bandwidth and the overhead of
communicating to the GUI via XML. However, efficiency aside, if XUL
could provide a robust GUI via a browser, then you'd have a
cross-platform client-server GUI that should work on all Lisp systems.
--
Kevin Rosenberg, M.D.
·····@rosenberg.net
In article <····················@boa.b9.com>,
Kevin Rosenberg <·····@rosenberg.net> writes:
> Another thought:
>
> Mozilla has a browser-based GUI named XUL in its current versions.
> I look at brief look at the tutorial on http://www.xulplanet.org.
>
> On first pass, I'm concerned about the bandwidth and the overhead of
> communicating to the GUI via XML. However, efficiency aside, if XUL
> could provide a robust GUI via a browser, then you'd have a
> cross-platform client-server GUI that should work on all Lisp systems.
So instead of using X for the display server because its too big a pig, you
proposed Mozilla using XML for the wire protocol instead?
Mike McDonald
·······@mikemac.com
·······@mikemac.com (Mike McDonald) writes:
> In article <····················@boa.b9.com>,
> Kevin Rosenberg <·····@rosenberg.net> writes:
> > Another thought:
> > Mozilla has a browser-based GUI named XUL in its current versions.
> > I look at brief look at the tutorial on http://www.xulplanet.org.
> > On first pass, I'm concerned about the bandwidth and the overhead
> > of communicating to the GUI via XML. However, efficiency aside, if
> > XUL could provide a robust GUI via a browser, then you'd have a
> > cross-platform client-server GUI that should work on all Lisp
> > systems.
> So instead of using X for the display server because its too big a
> pig, you proposed Mozilla using XML for the wire protocol instead?
It would probably be possible to do some sort of "compressed XUL,"
perhaps paralleling the architecture of LBX (Low Bandwidth X).
I find it vastly entertaining that SOAP gets billed as a "lightweight
protocol" when there's likely to be _spectacularly_ more parsing work
required than with just about any of its competitors.
--
(reverse (concatenate 'string ····················@" "454aa"))
http://www.ntlug.org/~cbbrowne/sgml.html
Know the list of "large, chronic problems". If there is any problem
with the window system, blame it on the activity system. Any lack of
user functionality should be attributed to the lack of a command
processor. A suprisingly large number of people will believe that you
have thought in depth about the issue to which you are alluding when you
do.
-- from the Symbolics Guidelines for Sending Mail
In article Mike McDonald wrote:
>> On first pass, I'm concerned about the bandwidth and the overhead of
>> communicating to the GUI via XML. However, efficiency aside, if XUL
>> could provide a robust GUI via a browser, then you'd have a
>> cross-platform client-server GUI that should work on all Lisp systems.
> So instead of using X for the display server because its too big a pig, you
> proposed Mozilla using XML for the wire protocol instead?
No - I'm not saying anything about X - I don't even consider it pig.
What I am saying is, rather than needing different different FFI's
for different Lisp systems, and trying to find a GUI package that can
talk to X, Win32, and MacOS systems with a fairly modern appearance,
XUL has some positive characteristics.
Since the interface is all in XML, no FFI's are needed. Also,
cross-platform support exists for all platforms on which mozilla runs.
Lastly, it has client-server architecture built-in.
However, XUL has a number of negative characteristics as well. As I
wrote, I think the XML overhead will be prohibitive for very dynamic
windows. The XUL spec seems to be changing with each release. Creating
a client only application is probably impossible. Having only very
cursily skimmed the tutorial, I expect a number of other significant
limitations exist compared to talking directly to the client window
system.
I'm running ACL 6.0 on Windows and Linux. I look forward to trying out
McCLIM in the near future. Thanks for your effort on that project.
--
Kevin Rosenberg, M.D.
·····@rosenberg.net
* Mike McDonald wrote:
> So instead of using X for the display server because its too big a pig, you
> proposed Mozilla using XML for the wire protocol instead?
That's the trick. You could use some kind of fancy compression system
to make it smaller. As a minimum you could write <foo>...</foo> as
(foo ...) which for data which is mostly-markup is a significant win.
Then rather than shipping this over the wire you could define a
language which has a syntax like this compressed-XML-format (I'll call
it LML) and define these things as some kind of procedures in this
language. Then these procedures could actually generate a really
efficient binary format which you actually ship over the wire.
There's a protocol for this out there somewhere, and it even has its
own compression standard which can eliminate redundant stuff in the
stream. I think the compressed form is called LBX, but I forget the
name of the real protool.
--tim