Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

XWT: The Universal Client 88

Posted by timothy from the do-stuff-there dept.
adam_megacz writes "XWT is a GPLed 'universal client' -- an end run around the current state of client side OS lock-in. It lets you write applications that run on a server yet display their user interface on any client machine. Unlike VNC and X11, all UI operations are performed on the client, so it doesn't suffer from lag or freeze-ups when you lose your network connection. It also doesn't require a you to download/install/configure anything since the client is delivered as a Java Applet or ActiveX control (Linux native client also available). There are some cool demos on the site, including an email client and a widget sampler."
This discussion has been archived. No new comments can be posted.

XWT: The Universal Client More

XWT: The Universal Client

Comments Filter:

  • Problems (Score:3, Interesting)

    by Bouncings ( 55215 ) <ken@noSpam.kenkinder.com> on Tuesday June 25, 2002 @05:30PM (#3765622) Homepage
    I found some basic problems.

    Their maximize button under the "Windowing" tab in the widget demo doesn't work right under IceWM, or any X wm for that matter because X doesn't have a notion of maximize.

    Furthermore I found two places on the fonts tab where widgets overrun: the "font name" over runs the frame and the textbox, and "Sample" over runs bold.

    • Re:Problems (Score:2, Insightful)

      by spencerogden ( 49254 )
      Why would you post bug reports here? Send them where they can do some good...
      • Why would you post bug reports here? Send them where they can do some good...

        Because the project is being discussed here and people should know the ins and outs before having to invest time and effort into the project to find out these things on their own.

        Ins: XML, open source, Cross-platform
        Outs: UI not tight yet, is https supported(?), small project at the core...

        Worth a look? You bet. Are there problems? Sure. Is it evil to discuss the problems in public? Uh...

        • UI not tight yet

          Hrm, I'm not aware of any major issues with the UI; if you find any, could you please log bugs for them so that I can fix them? Thanks!

          is https supported

          Yes, HTTPS is fully supported, including certificate validation, etc.

          Hey James, I get the impression from your vague and occasionally inaccurate criticisms that you have an axe to grind or don't like me or something. I'm sorry for whatever I might have done to piss you off.

          • Hey James, I get the impression from your vague and occasionally inaccurate criticisms that you have an axe to grind or don't like me or something. I'm sorry for whatever I might have done to piss you off.

            Funny you'd make it personal, because I didn't. It's funny because one of my concerns with the project is how closely tied to you personally it is! Not because of you -- this isn't personal -- but just that it needs to grow a bit beyond a critical man.

            The vitrol in my post was directed at the a-hole who asked "why discuss problems here instead of submitting bug reports". As if no one is allowed to voice experiences with tools in public...

            • >>>Funny you'd make it personal, because I didn't. It's funny because one of my concerns with the project is how closely tied to you personally it is! Not because of you -- this isn't personal -- but just that it needs to grow a bit beyond a critical man.

              Research into Open Source development patterns has revealed most projects have a very small number of "critical" contributors. This doesn't bother me in the least. If a project is worthwhile, it will survive the loss of any individual. If it isn't, it won't. Stuff survives on it's own merits. That's healthy.
              • Good point. However, the Open Source projects that I allow to comprise my company's infrastructure (Linux, FreeBSD, Apache, Perl, Mozilla, OpenOffice, et al) are exceptions to the single-digit critical contributors rule, which is precisely why I *allow* them a key role.

                Do I use other Open Source software? Sure, but not in critical roles. Will I keep an eye on XWT--you bet. XWT is what I want to use. When it's ready.

          • > Hey James, I get the impression from your vague .. bla bla bla.

            Look dear, you are a very intelligent and bright individual (I looked at your resume when
            the story was first post) so there is no need to get emotional and ingage in flame wars. That
            is for kids, OK?

            I also think you are cute, and no, I am not gay, I am just telling you that just incase you
            are a nerd and you think chicks wont like you, etc, etc.

            Posting anonymously to presserve karma .. no wait, I forgot to post as anonymous, shoot.

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

      Althought I don't like the license, Sash is a mature platform for application development today-->as long as that platform is Windows, granted.

      I really wanted to use XWT. But real-world end users would not be able to handle the UI glitches. 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. If I showed this to a client they'd freak.

      I'll keep looking at it every once in a while, but it needs more than one developer working on its core. Oh, and the outages I experienced on the site during the end of May, beginning of June were in NO WAY an encouragement. When the front page links all led no where I thought perhaps the project was done. Of course, it's a small project and that may need to change before it will be truly useable.

      • 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 [mailto] or submit [xwt.org] 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).

        • (* [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. *)

          IBM's proposed competitor to swing (I forgot the name) decided to use navite OS wigdets if available (such as Window's tree browser DLL), or emulate them of not.

          This may reduce such problems. Besides, 90% of all users use Windows anyhow. Java Swing's goofy behavior on Windows is a top complaint of Java. The IBM-backed version should be smoother, at least on Windows.

          BTW, does Windows offer a native Grid DLL? All the Java grids I try suck eggs.
          • BTW, does Windows offer a native Grid DLL? All the Java grids I try suck eggs.

            Well, there's MSFlexGrid, but.... heh.... you don't want to use it :-)

            Actually, it could well be an Office widget, not a Windows widget, but I'm not digging around on microsoft.com to find out. Last time I did that I came out in a rash and lay twitching in bed for two weeks.

          • If you are ready to spend few bucks then try Janus Grid [janusys.com]. It has a really good interface, features, help documents, sample code and support. Above all, its fast as hell. I have used it in my projects and an totally satisfied. No I don't work for them.

            - Jalil
          • IBM's GUI library is called the Standard Widget Toolkit. It's being used in the Eclipse [eclipse.org] project.

            You can find out more here. [eclipse.org] It's about halfway down the page.

            -SS
    • Regarding bug fixing:

      Let's see who can write the simplest GUI browser using languages like Python, Tcl, Perl, etc.

      If it is simple enough, then we can fix bugs on our own, or at least let OSS friends help.

      To acheive such, one may have to keep the (server) protocol fairly close to the native API's used in those languages.
    • Maximize has been added to the Extended Window Manager Hints publicized by the X Desktop Group, and apparently used by the newer Gnome and KDE window managers.

      However they should write the program to detect if this is supported, and if not they can set the window size to the screen dimensions, which will work on older window managers.

      • The Java version of XWT will support window maximization if you are running Java 1.4 or later (Maximization was not supported in jdk1.3). The Linux native binary doesn't support maximization yet; I'm working on it.

  • Security warnings? (Score:3, Interesting)

    by jmd! ( 111669 ) <jmd@@@pobox...com> on Tuesday June 25, 2002 @05:32PM (#3765634) Homepage
    When launching the demo, I'm presenting with a "Java Security Warning". The applet is signed with a valid SSL certificate, but I've never seen a Java applet on the web pop up a dialog like this before.

    Does this mean the applet isn't running in its own sandbox, since I have to confirm starting it? A friend of mine recieved a security zone rejection for the ActiveX when trying to load the demo in MS IE.

    Sounds scary. Course, the major web browsers fashion the simple SSL warning dialog to scare the bejezus out of any vistor to a page that isn't signed by verisign, so this is probably nothing as well. Can someone with knowledge on this part of Java confirm?
    • Yes, signed applets are a Java 2 concept, much like signed ActiveX contorls. They can do anything they want to do on your computer, that's why it will complain loud and long if the applet is not signed by one of the big companies in your JRE's trusted list.
      • > it will complain loud and long if the applet is not signed by one of the big companies in your JRE's trusted list.

        Crap! You mean Java plugin has builtin companies it will run any code from with full user level access? Can I disable this "helpful feature"?

        The dialog has no mention of the applet running with more privledges then other Java apples, and no link or button for 'help' or 'more info'. Awful.
  • Hmm Well there are first off all some serious screen redraw issues. Oh well. I am just uncertain what the advantage over Swing really is. The author mentions that it is easier to create XWT interfaces in XWT then in Swing but well with Borlands JBuilder is it really that hard?

    I mean this does not seem like a bad idea. I hope it or something catches on because anything is better then long endless forms that are mangled to do things they were never intended to do.

    The mail client is wonderful though. That alone makes it worth a bookmark.
    • When you have to build a java swing client that talks to a network, keeping the networking in a different thread to the gui execution can be quite a time consuming process. With xwt, the single command you give does all the thread management for you.

      If it's an applet, you also have the advantage that you have a 0.5mb ActiveX control on windows for the user instead of a 10mb Java Runtime.

      I also find that XWT graphics runs much faster than Java Swing, even when XWT is running on top of Java! I would suggest is has something to do with the general heavyweight design of Swing, and the fact that it was layered on top of an older graphics library, AWT.
    • Wow, I thought I'd fixed that one. Could you please email me [mailto] a screenshot and a description of what you were doing at the time? Thanks.
  • This is a very interesting project, and I will be keeping a close eye on it.

    Since I am stuck in a no java environment, and .net does not seem to have mastered applet technology yet, this is probably the best choice for no hassle server based applications without all the annoying lack of HTML UI. I think I will spend the next few days looking around...and will perhaps even push this to the company since the design is quite simple -- even they will be able to understand how it works, and it will even use their precious .net web services (ughh) .....

    However one question remains, though -- how is this really different from essentially a very light java applet (no slow AWT/Swing) that just makes all calls across xmlrpc. I am not too certain that one is easier to develop than the other.

    And damn it -- how the hell did you make the ActiveX load, everytime I try to do that it gives me security issues -- I think the difference is your is signed. (And my company does not like paying money for signing controls)

    Anyway -- this could be very useful, so, many thanks go to the author. Keep up the good work!
    • By the way, I use XML-RPC personally, so the SOAP stack isn't as well-tested as it probably should be. If you have trouble getting this to work with your .NET servers, please send me wire dumps (xwt -v) and I'll fix any bugs you find.

      As for XWT vs Applets, please see this [xwt.org] question in the faq.

    • Re:Interesting (Score:3, Informative)

      by baka_boy ( 171146 )
      It *is* effectively just a "very light java applet...that just makes all calls across xmlrpc". However, the UI itself is built from JavaScript, a custom XML format, and PNG graphics, rather than Java code.

      That's both a good and bad thing; it's good it you write your interfaces by hand, or want to generate them on the fly from some external data source, but it's bad if you like to use a RAD tool to prototype your UI by dragging and moving UI elements on the screen graphically.
  • Isn't that the world wide web? Doesn't the www already run applications in the backend ... and all UI on the client ?
  • The wonderful thing about the internet is that it shows us that if you think about something (without doing it yourself) for long enough, someone else will do it for you :-)

    The differences between XWT and my thought experiments seem to be:

    (1) The renderer is monolithic: I imagined a widget-by widget system in Java: sort of an outgrowth of how NeWS was supposed to work. Can XWT be extended in this way?

    (2) The comms protocol is XML:euch. I'd imagined something compact and binary, perhaps Java's RMI. Oh, well, comms bandwidth is cheap as are parser cycles, they say.

    (3) I'd imagined being able to wrap the host side inside something that pretended to be one of the popular widget sets, like GDK. Then my favourite X applications would have a chance to go where X hasn't. I haven't dug into the XWT doco enough to know _how_ the host side looks. Does it match one of the existing windowing models?

    • 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 [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 [xwt.org], 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.

    • (* The comms protocol is XML:euch. I'd imagined something compact and binary, perhaps Java's RMI. Oh, well, comms bandwidth is cheap as are parser cycles, they say. *)

      Don't most transport mechanisms *compress* ASCII, XML, etc? Ascii compresses between about 1:3 to 1:7, depending on the algorithm and CPU devotion. I don't see binary beating it by that by much.

  • Question (Score:3, Insightful)

    by addaon ( 41825 ) <addaon+slashdot@nOsPAM.gmail.com> on Tuesday June 25, 2002 @09:13PM (#3766459)
    What are the essential advantages of this technique over Remote AWT [ibm.com]? AWT has the advantage of being the Java standard, and all most programs use it...

    • The advantage is, you don't need to write it in Java.

      /Janne
    • Wow, I had never seen Remote AWT before. Very cool idea.

      Unfortunately RAWT still operates at a lower level than XWT -- it pushes pixels, lines, and mouse clicks over the network, not widget descriptions. The result is that RAWT will perform poorly over the public backbone or a slow link just like X11 and VNC -- simply scrolling a scrollbar requires a response from the server.

      The other big difference is that XWT is much easier to code in -- you don't have to be a programmer. It's closer to the level of HTML+JS.

      Finally, XWT runs as super-fast native code on Linux and Win32. RAWT is still encumbered by the slowness of AWT and JIT JVMs.

      RAWT seems really cool though if you already have a Java app that you want to make remote and don't want to use an X Server

  • This is reasonably clever, but I don't get the point. Ideally, interactive applications should be local. If the app needs remote resources, it goes and gets them -- but it still keeps the interaction part local. People only run interactive apps from a server when the local system can't support the application. (Unix users who access a Windows terminal server to run Word; graphic terminals that are deployed instead of PCs in pursuit of the "thin client" fantasy.) But this system makes you recode everything from scratch anyway -- so compatibility is out the window. It's server computing for its own sake!
    • (* This is reasonably clever, but I don't get the point. Ideally, interactive applications should be local. *)

      That does *not* have to be the case IMO. I propose a competitor to XWT, called SCGUI (link given in another message), and it has no Turing-complete script/applet downloads (per application). It is essentially a GUI browser.

      Unlike X-windows and Citrix, its "primatives" are widgets (or widget-level commands) instead of pixels. This makes it more HTTP-friendly because every cursor and keyboard movement does not have to be transfered back and forth.

      Anything other than HTTP will hang up fire-walls. I have seen it happen.

      I have pondered the idea extensively of how simple the client can be, and still have effective GUI's. SCGUI is based on the best balance, as I see it. The XWT author came to a slightly different conclusion, and has client-side scripting.

      But I still applaud the XWT attempt. We need something like it. If XWT wins over SCGUI, so be it, as long as I don't have to deal with fricken HTML+DOM+JavaScript anymore. I like *real* GUI's. (Well, I should say that I like developing real GUI's, for I am still kind of a command-line guy in some ways.)
  • What like Terminal Services??

  • The point is... (Score:3, Interesting)

    by Anonymous Coward on Wednesday June 26, 2002 @02:05AM (#3767506)
    a little subtle, but crucial.

    DHTML/Forms do not provide enough UI "fidelity" without radical workarounds. Java Applets/Swing are too heavy, have immature and non-native UI controls (I think "lightweight" controls were a mistake, because they look weird, which seems to matter a lot, and frankly Swing doesn't approach native fidelity) and require non-standard (yes, they are "standardized", but not ubiquitous) protocols. "Convergence" technologies (Citrix, VNC, etc.) do not scale to large enough numbers, and are doomed to whatever platform they expose to the client. XWT fills the gap in between neatly.

    Business applications need something as stateless and lightweight as HTML (I know, "sessions" are state, but it scales easily and that's the point,) but with the same fidelity as native, local clients. XWT may be a good approximation of this.

    Previous posts mentioned the following deficiencies of XWT:

    o Various control problems; overrunning widgets with text, maximize button doesn't, redraw issues, etc.

    If you go to the site and read the FAQ, you'll know that the release was not intended to provide perfect widgets. It's known they still need work. The release provides a working server and client "engine". Release early, release often.

    o How is this any different than Java applets?

    The client sides deals ONLY with controls/widgets. No JDBC or other elaborate protocols. It's technically possible to do this with applets, but that's not the model applets provide. Most applets try to behave like client/server apps. No language/platform support is provided "out of the box" to achieve truly thin (HTML-like) clients. You have to roll your own.

    o Isn't this the World Wide Web (meaning HTML/Forms/CSS/DOM etc.)

    Sorta. :) It's where HTML might be 5 years from now. Still can't resize a column without elaborate piles of browser specific JavaScript. The browsers are all broken one way or another. Frames are a pain in the ass to work around. Etc, etc. The Mozilla and W3 folks have this as a vision. Problem is it'll take them to another half decade to get there.

    o The renderer is monolithic

    So are browsers. XWT at least give you the means to implement custom widgets. Java Swing or Applets are no better.

    o Interactive Apps should be local

    Tell that to the WWW.

    o It doesn't replace VNC

    Nope. Doesn't have to. VNC is a completely different problem domain. This is about cross-platform server apps, scalability and ASP distribution. VNC/Citrix/whatever do this poorly because; the application running on the server is platform specific, it requires more resources than a (near) stateless client and is unresponsive with poor bandwidth. However, if you need to crank a knob on a server in the middle of the night, VNC gets you there, as it should.

    The one major problem I see:

    There doesn't seem to be a "sandbox" notion. I read the material closely. Perhaps it's presumed. I didn't see any explicit warning about client side exposer, but I also saw nothing explicitly stating that the Turning complete UI is isolated. However, this may a feature that, if it doesn't already exist, can be added. Further, I know there are MANY applications where this is irrelevant.

    I've had in mind a browser based "universal" UI platform that would allow a large class of business applications to go pure "thin" client. CRM/ERP/Collaboration software mainly. These apps require only slightly more UI fidelity than you can achieve using the most advanced DHTML/DOM techniques. Yet every vendor has their own in-house UI solution. Bah. XWT, with a bit more maturity, but no further fundamental changes, could implement these UI's neatly.

    J.D. Edwards has a DHTML client to replace their "Fat" client. Their UI was already quite generic and the port is obvious. Siebel is about to release a DHTML UI for the CRM. Oracle went whole-hog early with a java port of their existing Forms platform. It's a bit of a mess.

    Problem is I wouldn't trust any of the DHTML apps further than I could throw the building the programmers work in. I know there will be delicate dependencies on browser versions, coupled with lag between state-of-the-art browsers and the app vendors releases. Who want's more of that crap? Say you have two apps; one needs IE 5.5084321 and the other wants IE 6.0000123. You're screwed.

    Custom, in-house apps could benefit also. Sometimes you need more UI than you can do in a browser without being a master javascript geek. So, you turn to some platform specific "development tool" mess. The runtime has to be distributed to the clients, better keep up with the tool vendor, etc, etc. XWT may have real potential because it gives you enough UI, without deviating from a near-stateless HTML-like model.

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

      Appendix B: Security Architecture and Considerations [xwt.org]

    • Sorta. :) It's where HTML might be 5 years from now. Still can't resize a column without elaborate piles of browser specific JavaScript. The browsers are all broken one way or another. Frames are a pain in the ass to work around. Etc, etc. The Mozilla and W3 folks have this as a vision. Problem is it'll take them to another half decade to get there.

      actually you can do this with html now. i've been writing applications like this using DHTML/Javascript for over a year now, and they work just fine on both ie5.5+ and mozilla. (they dont work on opera 5 because it doesnt support document.createElement(). havent tried opera 6 yet) yes, dealing directly with the DOM sucks, but if you tried to write the gimp using only xlib functions, that would suck pretty bad too. once you have a decent framework, you can write real applications dealing only with javascript. (still a horrid language, but the only one you can use in a browser without plugins)

      hopefully, i'll have an open sourced toolkit for writing js apps done by fall and then you can all take a look at it and compare it to this.

      neat looking mail client, tho.....

      • actually you can do this with html now.

        I've been toying with the idea of an XWT->HTML compiler... both environments use the same langauge (ECMA compliant JavaScript). There would probably have to be a rather large 'standard library' that translates XWT library calls to browser.* calls, but I think it's possible.

        Is there anything you see in the XWT Mail demo or the widget sampler that couldn't be done in DHTML?

        • Is there anything you see in the XWT Mail demo or the widget sampler that couldn't be done in DHTML?

          the short answer is no[1], the longer answer is that it depends on how patient you are.

          the problem is that any widget more complicated than the basic html primitives needs to be hand rolled. relisitically, in the near future you may have to hand-roll your pulldowns too, since option elements in msie dont obey z-index attributes, making them impossible to cover up, which you may want to do in an mdi application for example. while this isn't too tough from a look standpoint, even using just <DIV> tags, getting the feel right is a lot more difficult. the event handling and event bubbling mechanisms supplied in javascript make getting the desired behavior from your custom widgets rather difficult at times. in the new version i am working on, i'm planning on using a few global event handlers that will overide all of the built in event handling and event bubbling. i just hope it doesn't slow the thing down too much to be useful.

          another tricky point is that there is no IO in javascript. the only way i can do server interaction (loading files, etc.) is to load a page (it has to be from the same server as the application, due to javascript security policy) in a hidden iframe, and then grab the contents of that frame and delete it.

          the biggest hurdle i've had in all this time, though, is just the fact that prior to this i've had little experience writing gui applications, and no experience designing toolkits, so it's taking me a few iterations to get to an api that is consistent and usable.

          assuming i can get my event handling issues dealt with, there's only two serious shortcomings i see in writing low to mid complexity apps to run in a bowser. the first is the fact that you can only ever do load and save operations on the server where the application resides. (javascript security policy prevents exchanging data between frames whose content comes from different domains) this doesn't entirely rule out load and store of local data, but it does make it tricky. the second is the lack of any rich text editing facilities. the textarea widget is horribly deficient for most text editing needs. the first application i wrote was a gui ide for voiceXML, and dealing with the shortcomings of the textarea was awful. (especially in mozilla. but that was around 0.9.4. hopefully it's improved since then)

          1) having taken a second look at the widget demo, i guess i have to take this back. i haven't tried, but i doubt you would be able to do the image tranparency thing correctly with current browsers. it may be possible with netscape, but i am almost positive that ie doesnt have any real support for alpha blending. you could easily have a bunch of draggable images, but you'd be stuck with gif on/off transparency. no cool blending effects.
          • (* the problem is that any widget more complicated than the basic html primitives needs to be hand rolled. relisitically, in the near future you may have to hand-roll your pulldowns too, since option elements in msie dont obey z-index attributes, making them impossible to cover up, which you may want to do in an mdi application for example *)

            Z-indexes (overlap control) usually only make sense in coordinate-based positioning (X, Y), and not for flow-based positioning (such as HTML). A decent GUI browser or protocol should at least give the option of coordinate-based positioning (X, Y). It is easier to cram more stuff on a given screen with coordinates in my experience. (PHB's like to cram for some reason.)

  • Binary vs source (Score:2, Insightful)

    by munro ( 265830 )
    "4.1 Why are XWT applications delivered in source code form (like HTML) instead of a compiled form (like Macromedia Flash)?

    Businesses are always nervous about distributing their code in source format. The creators of Java had to invent a binary format (.class files) just to assuage these fears -- despite the fact that .class files are nothing more than highly-compressed source code (if you don't believe me, try out "jad", the best Java disassembler I've ever seen)."

    Hehe :)
    • (quote) Businesses are always nervous about distributing their code in source format. The creators of Java had to invent a binary format (.class files) just to assuage these fears -- despite the fact that .class files are nothing more than highly-compressed source code (if you don't believe me, try out "jad", the best Java disassembler I've ever seen)." (end-quote)

      One thing nice about XWT is that it allows you to have most of the business logic on the server *if* you want. I personally would rather have no app-specific code move-to and run on the client (for reasons described in other messages around her). However, enough people seem to prefer the fatter client model, or at least that option, so I guess I am out-voted.

      No matter what, I think client-side application code is going to eventually be hacked, so one should give up the idea of encrypting it somehow, other than maybe scrambling (substituting) the variable names.

      If a good browser and multi-lang IDE for XWT would just catch on now....

  • Okay.. (Score:1, Troll)

    by mindstrm ( 20013 )
    so it does what X does.

    Gotcha.

    How innovative.
  • I love this idea. I've loved it since the first time I had it in 1988.

    But unfortunately, the implementation doesn't appear to work at all with Netscape 4.7.

    I'd be willing to run a client program as a plug-in to get this feature. Unfortunately, I can't find any plug-in for this.

    -- Terry
  • www.rebol.com [rebol.com]. More stable, faster and better supported

    • Where are the demos on their site?

      I tried out rebol about 6-9 months ago and they had a pretty easy-to-access demo on their site. Now when I go to www.rebol.com, I can't seem to find it -- only some "evaluation request" form I submit for a sales rep to contact me. I'd like to see what they've been up to lately....

  • vs. Curl (Score:2, Informative)

    by hstearns ( 441907 )
    Neat stuff. I do want to straighten some things out wrt Curl [curl.com]:

    "1.8 What other technologies are similar to XWT?
    CURL Surge is a similar framework, although it requires per-use licensing fees and is a bit baroque."

    Actually, Curl offers a variety of licensing arrangements, including per user, per site, etc.

    I think XWT and Surge both aim to combine the benefits of native applications:

    responsiveness, interactivity, and so forth
    with those of server based software:

    administration: install, update, secure data storage

    "Browser as user environment"

    security for user machine and for site

    However, XWT focuses on what I might call a UI server approach. It can do more, but it is optimized for working only with an application's user interface while the application computations take place on the server. This specialization is consistent with the the separation of UI vs other design concerns, and has a lot of good characteristics, such as in the size of the initial platform download, potentially the size of the initial applet download, and the scope of learning required from developers.

    Surge can be used in exactly the same way, but it is designed to handle more complicated application logic right on the client. You can make any separation you want (between client & server; between data, logic, and presentation; between different modules or levels of any of these), but you can also combine them within the same environment when appropriate. Technically, this provides a fuller range of application richness and deployment scalability, but there are other concerns such as learning, or how universally the platform is available.

    In light of this difference in emphasis, I'm wondering which parts of Surge the author finds baroque. Let us know, Adam.

    Another slashdotter also commented on the XWT FAQ's comments on source code vs. binary. I don't know how it works out in XWT, but Curl applets are in source so that they can be compiled to very fast native instructions on the platform they'll run on. Specific client resources can be utilized (e.g., for graphics), which a byte-code-JIT would have a hard time doing unless the byte-code included some pretty darn high-level instructions. Also, source code is much more compact than low-level machine or JVM instructions. Since compilation is much faster than the network, that gives a quicker total time from http-request to execution. If people are worried about protecting their applet code, they can obscure, encode, and compress it. Surge has a pre-parsed delivery option for code that does this.


    • 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 [xwt.org].

      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 [xwt.org] 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.

      • I think we're agreeing that developers can do whatever computation they want on an XWT client. As I understand it, there are two ways:

        1. XWT UI descriptions can include Javascript. Javascript is terrific. It's well known by lots of people, and easy to learn for others. However, there's no perfect language for all purposes. Javascript was specifically designed for short scripts. As a consequence:
          • It doesn't have the programming-in-the-large support needed for large projects involving many people or organizations, or for modeling complex problems.
          • It is very difficult to build an implementation in which it executes very efficiently (e.g., on the scale of inner loops of a graphics app).
          None of this is a problem for XWT's stated design space -- UIs to applications that execute on the other end of a network connection. But suppose you do want to something fast and complex on the client? This brings us to...
        2. You can write a dedicated client app in C++ or some such, get it to the user's machine, and then communicate with it through XML-RPC. I can imagine other similar communications through the browser. This can be nice, because each part of the job is done with a tool that is designed for that domain. Different people with entirely different skill sets can work on the different parts. However, whenever you mix technologies and try to have tight communication between them, there can sometimes be problems. I'm not sure that this scenario is really the best way to deliver on the benefits that lead us to Web-based apps in the first place (see the start of my original posting, vs. Curl [slashdot.org]).

        I also agree with Adam that Surge isn't as approachable as it could be. If a Javascript-based UI-architecture starts to slip as the complexity or responsiveness requirements go up, you would think that it should be possible to approach things the other way and use just the parts of Surge you need for doing simple UI stuff? Surge was indeed designed to let simple things be simple. For example, there's an integrated layout and formatting engine that makes it easy to declare how stuff should be organized such that you don't have to write code to handle resizing of windows while avoiding horizontal scroll bars. And you don't have to include type definitions, or write procedure or class definitions.

        But as a practical matter, there is a lot there, and it is different enough that I can understand how a time-pressed developer wouldn't want to learn something new. And the "gentle slope" approach isn't perfect. For example, I'd rather see undeclared numbers use decimal or bignum integer representations than fixed size representations. (Although Javascript has the same problem. By the way, Adam, where did you count 18 int types? I count six with two more pseudonyms. Java has five, C eight, and C# nine.) Anyway, the point is that Surge is really more optimized right now more for enterprise-level programmers with big problems then for mass adoption by designers.

        So where's the dividing line today? The XWT FAQ mentions that interactive games are probably not appropriate to a Javascript-based UI-server approach. Anything else? Right now, Curl seems to be resonating most with people developing enterprise stuff with a high degree of custom business logic, tight response times, high interactivity, and changing requirements. My personal feeling is that there isn't much like this on the consumer web because there hasn't been a reliable way to develop and deliver it before. The space of simple applications hasn't yet been exhausted, and for these, UI-servers are plenty good enough. Comments?

Slashdot Top Deals

"Being against torture ought to be sort of a multipartisan thing." -- Karl Lehenbauer, as amended by Jeff Daiell, a Libertarian

Close