Slashdot Mirror

I mean, even with the SunRay, it's like, whoo-hoo, we combined VNC and H.263 and you should jump for friggin' joy.

Actually, Sun Rays are really much more advanced than VNC. A bit more like Citrix ICA. Either way, it's cool technology. Just because Sun has packaged it better than everyone else doesn't invalidate their claim on the market. Personally, I'd love to have a Sun Ray network. I could take my smart card and work anywhere I want. No being tied to a desk with really bad lighting. I'll just take the comet downstairs to the Starbucks and actually get some work done! ;-)

I don't think anyone really wants this.

Actually, I think Sun's biggest problem is how expensive it is. I know of many people who would love to buy a used Sun machine and a few Sun Rays just to wire their house. But when their software costs more than the machine, you know you've got a problem. That's the same thing that killed NT Terminal Server. Citrix ICA was doing quite well with WinFrame until Microsoft pulled a fast one on them.

I think a visual protocol is too specific. The work needs to be in creating a widget/RPC API that lets you splat a standardized local GUI onto remote application servers.

Myself and others have spent a lot of time trying to figure out the best way to do this. I did some on renovating AppliWeb up until XWT showed up. So far, XWT seems to be the best option. We'll see what the future holds, though.

http://www.xwt.org/

If they ever get around to releasing it, XWT, recently renamed to Ibex, would be just that.

But I've opted to use XWT for the simple reason that browsers are NEVER 100% compatible with each other or anything else. I decided pretty quickly that until these issues are ironed out you're going to be heading for a whole bunch of trouble. XWT provides web applications on any browser by d/l a jar to the browser, it renders locally, uses xml-rpc over http for server communication and means you can reuse any java code that you have made/can find. It's not perfect, but it's a whole lot closer to what you need than trying to be "standards compliant".

I cite prior art.

Like I said in prior similar topics, for intranets, businesses really want an HTTP-friendly GUI to avoid firewall hassles. Candidates include XWT, and SCGUI (my pet). I suppose XUL could also be included. HTML forms + JS + DOM is really a pain for GUI emulation.

Ooh! Look! I can put every application known to man in a web browser!

Web browsers are turning into the Emacs of desktop computing, and it's pissing me off. If you want a front-end, write a front-end, possibly in Java. When you need to communicate with the server, open a friggin socket. Or use XWT or some other XML-RPC-based solution.

Oooh! But it's web-based! Fscking marketroids.

I've banished DHTML and all it encompasses. XWT is what I use now... No browser bugaboos, straight JavaScript, OSS, multiplatform, fast, client/server and perfectly clear separation of content from presentation.

Screw DHTML. XWT is the future.

No, no, no. Yes, things look bad (but we already know SCO loves to quote out of context). Yes, there is obviously code that is common between a version of Unix, and Linux, but the real questions become:

• What is the origin/history/heritage of the code in question?
• Who had the rights to the code in question?
• How much of the code can actually be copyrighted?

Looking at the code snippet that SCO appears to be showing: /arch/ia64/sn/io/ate_utils.c and its associated CVS history it would appear that this code first appeared in the Linux kernel courtesy of SGI (or possibly HP), as part of the Itanium kernel port. SCO/Caldera participated in the Monterey project -- what were the contractual obligations on all of the parties, before and after the breakup? IE: Did the code get there legitimately?

Keep in mind that depending upon what court you're in, there are limits to how much of software can actually be protected by copyright. Most of the UNIX header files (and therefore parts of the functions that implement the APIs) can not be protected by copyright, since you have to publish them to use them, and a competing implementation has to implement the same APIs. This is where AT&T lost to BSDI, resulting in the freeing of *BSD. For that matter, comments aren't considered to be part of the code in certain jurisdictions.

Personally, I'm more interested in seeing what non-hardware-dependent code SCO is claiming copyright over. We already know that SCO is claiming some nebulous 'rights' to SMP and RCU code, but how much and where and why?

Competitors include:

XWT

XUL

SCGUI (my pet)

This Vultus "technology" sounds like the IE version of XUL with RPC. I personally like XWT or another member of the XUL Alliance better, thanks anyway.

-antim

Try GCJ on your java sources. It does impose some restrictions, but it is capable of creating native binaries from Java source. At the XWT project we cross-compile Java source to Win32 and Linux binaries (both from Linux). The native binaries are markedly faster than the Java bytecode version. That said, there's a lot you can do to tune your JVM for your particular setup. Browse around java.sun.com and www.java.net for tips.

I'm sorry, but $1250 for 10 groupware users (unlimited mail) and $250 for 5-user groupware license packs is not "paying out the wazoo" by any stretch of the imagination.

I am currently evaluating SLOX and where my beefs are is in the integration between the mail and the groupware, and in the closed nature of the data formats and API. I've offered to sign NDAs but SuSE has been dragging their feet for over a month now getting me the contract so I'm probably just going to drop it altogether. It's unfortunate. All I wanted to do was build an XMLRPC gateway to their API so I could create my own frontend using XWT (I hate browser-based shit) and use Outlook Connector for the Win32 users for now.

It seems to have just about everything else though. Calendaring is good. Project management is there but spotty, document store is there but spotty... Project forums are there... It's almost perfect, but I can do the rest myself; I needed the core which worked 100% with Outlook and the hard stuff to be done (LDAP schemas, replication, glue between LDAP, IMAP and CAL) -- SLOX does all that already.

DHTML sucks to do stable and responsive UIs in. And even if you manage stable and responsive, you'll still end up with code like
if (netscape4) { ... }
all over the place.

XWT has put a lot of time and thought into security, and a Turing-complete language (in their case, JavaScript) has the advantage of minimising client-server communication.

SCGUI is a good idea, but XWT is much more practical for a wide variety of situations.

And when you consider their implementation has native binaries for Win32, Linux, Darwin, and Java, it looks like a good way to go.

Killer apps are those that will solve the problems we currently have with computing today. Things that *just work* and, more importantly, don't cost.

Things like java applets that promised 'work everywhere' but don't because they can't. Things that will deliver on the promise using existing technologies that are already in the martket rather than trying to sell themselves to the world.

My bet; xwt - it uses activex (available to practically every machine running Windows) and java (available and installed on most other platforms) to deliver a client that's as easy to program as a web page yet as responsive as a native application. The engine automatically updates itself and it's applications. This solves 101 nightares of the mass public deployment paradigm.

Intelligent use of existing technologies is what will make the next killer app. As one of the xwt devs I'm unashamedly pushing ours.

Speaking of Jeode -- the damn thing (evm, that is) is almost perfect for XWT -- The only class I've found that doesn't exist with evm's AWT implementation is BufferedImage. So close...

Network transparency can easily be provided by modern component object models like GNOME's Bonobo and KDE's Kparts, with the added bonus that clients are thin and so still usable over a high-latency network.

Before anyone gets confused, lets be clear and point out that this is the IT equivalent of a theory. Basically, we are told the client should be just smart enough to render controls and pass input events back to the server. This is theory because there are no implementations of this in widespread use.

The quote suggests that Bonobo or Kparts would implement the client side controls. These controls are then driven from the server via RPC or some other mechanism.

Some argue that web browsers could do this. Perhaps. The inherent statelessness of web clients preclude large classes of GUI applications and makes others very difficult. Can you imagine a browser based implementation of, say, Paint? (activex/java doesn't count.) Lots of applications have grids with re-sizable columns, yet common browsers have never provided this without add-ons or substantial hackery.

There have been and are real attempts to make this theory work, however. An excellent example is XWT. Check it out. There are others, but they're even more obscure and even less likely to ever actually matter.

Why is this? Lots of people have this notion of half-smart clients that provide 99% of "direct" GUI fidelity by rendering controls on behalf of some server somewhere. There is nothing new under the sun. Yet it doesn't happen.

Here is my contribution: Z Windows (I think there is a Y Windows out there,) an evolution of X Windows:

- Separate the frame buffer from the window system. Graphics drivers would be "mini" drivers that abstract the hardware just enough and no more.

- It's obvious audio must be integral. Integrate it.

- TrueType won. Get over it. Integrate it. Anti-alias it out of the box. Provide a simple means to cope with font substitution just like Microsoft does. End of font problems.

- Create a standard window manager. All others accept the consequences of being weird. Life is short.

- Base the programmatic interface of the whole thing (API) on something worthwhile. Trolltech's QT would be a good place to start. Sharp did it and it works fine. Plus there is an entire suite of application software already written to it. Gnome would be fine too, I don't care.

Now you have a clean, straightforward system that has a good API, sound, good fonts and drivers that are easy(er) to implement. Applications arrive shortly thereafter because your using a worthwhile API.

What about network transparency? Well, in case you haven't noticed, the most widespread use of network transparent GUI is Citrix. It works well, thank you very much. It would work even better if it had been incorporated from the start by the underlying GUI. Citrix is nothing more than a highly optimized screen scraper, much like VNC. It turns out, despite the best thinking on the matter, that this is sufficient for 99.9999% of all remote GUI purposes, and the remaining 0.0001% (high performance graphics work) you want local anyhow.

Congratulations. You now have a worthy GUI system for the next 15 years. Now wake up.

That the idea to use it as a platform to develope portable applications (using ECMAScript + XUL) is catching on slower than some people would expect.

That's because it's not done very well. It can be done a lot better.

Agreed, XWT system solves this problem elegantly. Only one code base to maintain, optimal performance on windows. BUT you will have to rewrite your app, and probably patch the XWT client side parts for your imaging needs.

Flash also solves this problem. It is already installed on modern ( 3 yrs old) systems and Macromedia is at peace with Microsoft. But I recommend Open Source wherever practical, and maybe flash does not support your particular imaging display needs.

DHTML + Javascript + serverside image generator will work OK if you do not need 3D.

Would XWT work for you? You design your UI in an XML/JavaScript environment and then interact with a server though XMLRPC or SOAP. Very slick. I just hope the demo server is up when you look at it; they've been having some DNS issues, IIRC.

To clarify, I meant making an ActiveX app of your Java stuff. The XWT project has done this.

Something I've been putting a lot of energy in to lately is XWT -- basically it's a remote widget system that takes all the plusses of X11 without the nasty lag. It uses XMLRPC or SOAP to talk to servers, which is where you'd get your OpenGL to work, I think. Spawn a simple XMLRPC server on the client to handle OpenGL functions on behalf of the app and you're set.

I love KDE but it is a difficult task to integrate other languages with.

Um, no. any DCOP interface is scriptable through the "dcop" command line tool (or kdcop to see it visually). KDE also has an XMLRPCDCOP gateway, so you can even use something like XWT and access any method any KDE application makes available.

For a different approach to this problem, check out the XML Windowing Toolkit; its "display server" runs as a Java Applet, or ActiveX control, so there's nothing to download/install. There's also a native Linux client.

You might want to give XWT a shot. You write all your business logic in whatever you need (C++, Java, Perl, Fortran, whatever), exporting the functions you need to use as XMLRPC or SOAP connections. Then you write your user interfaces in XWT. Native clients for Linux and Win32, with everything else supported by a Java 1.2 RE. It's fast, scalable, configurable and truly multiplatform.

Forgive my inexperience with OSX programming, but some of the features you seem to be interested in are not OSX specific.

Easy IPC can be accomplished numerous ways using vanilla Java (RMI, conventional Thread communication), and you can go with CORBA for language-neutral IPC. And I think Java Threads are as good or better than BSD processes.

The UI decision is less important than the underlying program architecture and language/framework choice. Swing is the most obvious choice, but there are others.

Personally, I prefer XWT to XUL. XWT was inspired in part by XUL but it has significant differences. XWT is a very exciting project; it could make possible cross-platform network-transparent applications that are still as responsive as local applications even over modem connections. It doesn't require Mozilla; in fact it is a small plugin download for Windows, Linux, and Mac. And the best part is, XWT is 100% free and open-source, GPL and LGPL where appropriate. Try a demo, I think you'll be impressed.

Personally, I prefer XWT to XUL. XWT was inspired in part by XUL but it has significant differences. XWT is a very exciting project; it could make possible cross-platform network-transparent applications that are still as responsive as local applications even over modem connections. It doesn't require Mozilla; in fact it is a small plugin download for Windows, Linux, and Mac. And the best part is, XWT is 100% free and open-source, GPL and LGPL where appropriate. Try a demo, I think you'll be impressed.

XWT is the way to go these days. OS-agnostic, clear and simple separation of UI and business logic and totally, wholly extensible. I love this software.

I agree completely. And if you still want a rich, non-HTML GUI on your computer while still running nothing more than an HTTP server on the device, you might want to check out XWT.

For a lightweight interface system that talks XML-RPC/SOAP and is easy to port to other platforms.

It's written in Java, but natively compiles on Linux/Win32. None of the speed problems of Java (thanks to a different design tack with Box rendering).

Of course, the obvious advantage over Flash is the fact it's open source (GPL).

Why limit yourself to two platforms? Write the back-end of your chess program so that it communicates with a front-end client by passing certain messages (perhaps in XML format). You might even make the message specifications public so that others could write clients for your chess engine.

There's already a very good solution for doing this: XWT.

XWT allows you to write the interface in XML and JavaScript, and the XWT viewer then downloads and displays that interface. When computation needs to be done, the XWT interface makes an XML-RPC call to a server.

In fact, there's even a demo chess program on the XWT site, now that I think about it. :)

--Bruce

Although X has it's strengths, working well over high-lag, low-bandwidth connections is not one of them.

See that's where something like XWT would come in nicely. The home computer has the server and client components and it's fast and indistinguishable from any other app. Hit it from a remote location and it's still zippy since all the widget interaction is done on the client, unlike X.

shameless XWT plug? what does this have to do with anything?

The article is about availability. My post lets people know about an open source tool called dnsfailover that can help them improve their availability. It also mentions the XWT Cluster as a real-life example of said software in action.

The XWT Cluster has achieved some very high availability on the cheap by using machines at several mom-and-pop data centers across the country. The machines are clustered into a peered (no master) failover configuration with the open source dnsfailover package. If any machine fails, the others will remove it from the DNS records; when it comes back on line, it gets added back in.

By spreading our risk across several data centers in different cities, with no single point of failure in the cluster, we don't have to worry about incompetent network administrators, power failures, a/c failures, backhoes, or nukes. Being able to skip out on all those expensive options saves a ton of money.

The XWT Cluster has achieved some very high availability on the cheap by using machines at several mom-and-pop data centers across the country. The machines are clustered into a peered (no master) failover configuration with the open source dnsfailover package. If any machine fails, the others will remove it from the DNS records; when it comes back on line, it gets added back in.

By spreading our risk across several data centers in different cities, with no single point of failure in the cluster, we don't have to worry about incompetent network administrators, power failures, a/c failures, backhoes, or nukes. Being able to skip out on all those expensive options saves a ton of money.

I have yet to see a native java app, show me one.

Lazy, ignorant, demanding SOB, aren't you? Okay, take a look at XWT, for one. Also take a look here and here.

Of course, the executable for a native Java app isn't going to look any different to the casual file(1) command than one compiled from C, C++ or even Fortran.

Surge can be used in exactly the same way, but it is designed to handle more complicated application logic right on the client.

Just like Curl, XWT includes a turing-complete language interpreter, meaning that you can implement any amount logic you like on the client side. If you absolutely need to use other languages on the client, you can do that too.

I'm wondering which parts of Surge the author finds baroque. Let us know, Adam.

A 1028 page reference and 18 different "int" types, for starters. I dunno, I just don't think things have to be that complicated. A complete, comprehensive technical description of XWT fits on 15 pages when I print it out.

I don't know how it works out in XWT

XWT also transmits UIs as source (not binary). The JavaScript interpreter I use has the ability to compile JavaScript into Java Bytecodes (which then get JITted into native code), but I've found that because XWT operates at such a high level, all the performance-intensive stuff (layout, rendering, networking) is already running as native code in the XWT Engine, so this feature actually doesn't boost performance that much.

My empirical experiments with this have really changed my thinking on interpreted vs compiled -- if you make high-level primitives available to the interpreted code, and you make sure those primitives are hand-coded in a low level language and extremely well optimized, you really don't need to compile your code. It's the old 80/20 rule all over again.

Surge can be used in exactly the same way, but it is designed to handle more complicated application logic right on the client.

Just like Curl, XWT includes a turing-complete language interpreter, meaning that you can implement any amount logic you like on the client side. If you absolutely need to use other languages on the client, you can do that too.

I'm wondering which parts of Surge the author finds baroque. Let us know, Adam.

A 1028 page reference and 18 different "int" types, for starters. I dunno, I just don't think things have to be that complicated. A complete, comprehensive technical description of XWT fits on 15 pages when I print it out.

I don't know how it works out in XWT

XWT also transmits UIs as source (not binary). The JavaScript interpreter I use has the ability to compile JavaScript into Java Bytecodes (which then get JITted into native code), but I've found that because XWT operates at such a high level, all the performance-intensive stuff (layout, rendering, networking) is already running as native code in the XWT Engine, so this feature actually doesn't boost performance that much.

My empirical experiments with this have really changed my thinking on interpreted vs compiled -- if you make high-level primitives available to the interpreted code, and you make sure those primitives are hand-coded in a low level language and extremely well optimized, you really don't need to compile your code. It's the old 80/20 rule all over again.

There doesn't seem to be a "sandbox" notion

Appendix B: Security Architecture and Considerations

sort of an outgrowth of how NeWS was supposed to work.

Funny that you mention NeWS -- my encounter with that windowing system was what started me on the journey of building XWT! It really frustrates me that the X11 dumb-display-server model won out. You should definately join discuss@xwt.org -- sounds like we're thinking along the same lines.

Anyways, yes, the UI is divided into widgets, each of which is composed of boxes (which are atomic). Each widget appears opaque to the outside world -- it looks like a single box that happens to behave in interesting ways. As an example, you set the width of a widget the same way you set the width of a box.

To get a better idea of how this works, try downloading demo.xwar, unzip it (it's a zip archive) and poke around in org/xwt/themes/monopoly/ -- each file describes a single widget; each XML node corresponds to a single box.

The comms protocol is XML:euch.

Yeah, I hear ya. Unfortunately almost everybody wants XML-over-HTTP these days. I'm looking into some more efficient transports for large data sets. I'm also going to add gzip encoding to the HTTP layer -- this should nullify the bandwidth bloat, although all the compression/uncompression and parsing will still cost CPU cycles.

I'd imagined being able to wrap the host side inside something that pretended to be one of the popular widget sets, like GDK.

Well, XWT is completely skinnable -- you can remap the widget definitions on the fly. For example, you can instruct the XWT Engine "change all instances of org.xwt.themes.monopoly.scrollbar to org.xwt.themes.gtk.scrollbar". In doing so, XWT will preserve key properties of the widgets being reconstructed (like the position and orientation of the scrollbar).

I used to have a GTK theme, but it sort of fell by the wayside. I probably should resurrect it just to demonstrate to people how skinnable this stuff is.

sort of an outgrowth of how NeWS was supposed to work.

Funny that you mention NeWS -- my encounter with that windowing system was what started me on the journey of building XWT! It really frustrates me that the X11 dumb-display-server model won out. You should definately join discuss@xwt.org -- sounds like we're thinking along the same lines.

Anyways, yes, the UI is divided into widgets, each of which is composed of boxes (which are atomic). Each widget appears opaque to the outside world -- it looks like a single box that happens to behave in interesting ways. As an example, you set the width of a widget the same way you set the width of a box.

To get a better idea of how this works, try downloading demo.xwar, unzip it (it's a zip archive) and poke around in org/xwt/themes/monopoly/ -- each file describes a single widget; each XML node corresponds to a single box.

The comms protocol is XML:euch.

Yeah, I hear ya. Unfortunately almost everybody wants XML-over-HTTP these days. I'm looking into some more efficient transports for large data sets. I'm also going to add gzip encoding to the HTTP layer -- this should nullify the bandwidth bloat, although all the compression/uncompression and parsing will still cost CPU cycles.

I'd imagined being able to wrap the host side inside something that pretended to be one of the popular widget sets, like GDK.

Well, XWT is completely skinnable -- you can remap the widget definitions on the fly. For example, you can instruct the XWT Engine "change all instances of org.xwt.themes.monopoly.scrollbar to org.xwt.themes.gtk.scrollbar". In doing so, XWT will preserve key properties of the widgets being reconstructed (like the position and orientation of the scrollbar).

I used to have a GTK theme, but it sort of fell by the wayside. I probably should resurrect it just to demonstrate to people how skinnable this stuff is.

Many problems with the UI elements -- and these are fundamental problems that preclude me from considering the platform, currently, for development work.

Care to email or submit a bug report? Thanks!

Examples...from memory...the tree elements: when selecting a sub element, the parent element is also highlit (highlightened? highligthted?) and the highlight does not easily go away...painful.

This has been fixed.

I experienced on the site during the end of May, beginning of June were in NO WAY an encouragement.

Hrm, nobody else has reported such outages. Perhaps something is wrong with your upstream. Xwt.org is now hosted on a three-node failover cluster with machines on both coasts (US).

Many problems with the UI elements -- and these are fundamental problems that preclude me from considering the platform, currently, for development work.

Care to email or submit a bug report? Thanks!

Examples...from memory...the tree elements: when selecting a sub element, the parent element is also highlit (highlightened? highligthted?) and the highlight does not easily go away...painful.

This has been fixed.

I experienced on the site during the end of May, beginning of June were in NO WAY an encouragement.

Hrm, nobody else has reported such outages. Perhaps something is wrong with your upstream. Xwt.org is now hosted on a three-node failover cluster with machines on both coasts (US).

As for XWT vs Applets, please see this question in the faq.

1.7 Why should I use XWT instead of writing a Swing Java Applet that uses SOAP/XML-RPC?

1. Applets don't work on IE6, nor will they work on any future versions of IE (Microsoft has removed support for Java). Installing the Java2 plugin is cumbersome, complex and requires a 15MB download, compared with XWT's one-click launch and slim 500kb download.
2. Swing is ugly.
3. Writing applets requires a real programmer -- somebody familiar with computer science. XWT user interfaces, on the other hand, can be developed by designers with little programming experience.
4. XWT runs as native code on Win32 (and soon will on Linux, Solaris, and MacOSX as well), making it much faster and more responsive than applets. This is especially noticable when scrolling or smooth-resizing.
5. XWT user interfaces take much less time to develop.

Wow, I thought I'd fixed that one. Could you please email me a screenshot and a description of what you were doing at the time? Thanks.

i know it sounds like a trendy buzz-word but i think it's here to stay and some seriously cool stuff will start to happen soon (look at Google).

The web is dead.

I didn't create this tech but I am using it to replace shitty HTML+Jscript+prayers+sacrifices web-based interfaces. There are some other guys like XWT too but XWT is simple, straightfoward and fast. It essentially projects UIs -- do you forms locally (on the client machines) but all your business logic sits on a server where it belongs. Talkes XML-RPC and SOAP. Very cool. Way way way better than what I would call traditional "web services."

Sash is pretty old news... Saw it either here or on fm.net a year ago. However, a similar technology, XWT was released more recently, and may appeal to a similar crowd.