TSS Article: Rich Internet Applications

Discussions

News: TSS Article: Rich Internet Applications

  1. TSS Article: Rich Internet Applications (134 messages)

    Vic Cekvenich thinks that the promise of JSF will come to fruition; however, it won't come from JSF, but rather from JDesktop Network Components (JNDC). This article builds the case, and gives examples of using RIAs in your solutions.

    Read Rich Internet Applications

    Threaded Messages (134)

  2. Not that fast[ Go to top ]

    It does not make sense anymore to develop additional HTML legacy applications; HTML is done for.
    I do not agree with that. The businesses are not that fast, many of them still use text-based applications, which in case of PC platform meaning DOS-based. Take a look at POSes in stores or restaurants. The regular consumers want fancy stuff you are right, but they do not like ads. I personally hate ads. With plain HTML it is possible to parse it on the client side and remove these annoying banners and popup scripts. Too bad my filter cannot remove flash scripts, and MSIE does not allow to turn off only certain plugins. So I turned off all ActiveX controls, I do not have Acrobat reader now which is bad, but I do not have Flash as well, which is mucho good.

    If a web site requires Flash, I simply do not go there. If they do not want to have business with good old HTML folk, this is their problem, not mine.
  3. TSS Article: Rich Internet Applications[ Go to top ]

    For a rich internet application the link leads to a mighty blank page ...
  4. It does. I'm using Netscape 7.1.
  5. Blocking Flash[ Go to top ]

    FYI: "AvantBroser" blocks Flash + Popups + Ads
  6. Flash, Flash Remoting[ Go to top ]

    My company has 2 intranet applications that we built using Flash + Flash Remoting + J2EE.

    Instead of buying Macromedia's Flash Remoting Gateway product, we decided to use OpenAMF ( www.openamf.org )

    In the future, we plan to evaluate Macromedia Flex (MXML) and maybe Sun's JNDC.

    Disclaimer: I am one of developers on the OpenAMF project
  7. Flash, Flash Remoting[ Go to top ]

    ... to use OpenAMF ( www.openamf.org )..
    That link is VERY unappealing, too small on my screen and does not scale with CTRL+...

    UI must be scalable, period.
  8. Open-jACOB worth a look[ Go to top ]

    The primary goal of the jACOB Framework is to handle web applications with CRUD (create, retrieve, update, delete) with little or no Java programming. Instead of telling the application how to retrieve and how to display the data. The developer creates the Web-UI with a point&click eclipse UI-Designer. jACOB's major benefit is that the layout of the user interface is separate from the Java classes of the application. Open-jACOB is a good Framework for "back office" web applications see on Open-jACOB greetings Andreas
  9. Re: Open-jACOB worth a look[ Go to top ]

    Hi Andreas Do you know where I can get a hold of some documentation. At the moment there's nothing on sourceforge.net and the open-jACOB web site just has a very basic demo. Just the main fundamentals which would save a lot of trial and error time. Then I could evaluate and provide feedback on this very interesting looking tool. Thanks
  10. Umm... I'm confused[ Go to top ]

    I came to this article hoping to learn more about what JNDC could offer, and how I could integrate it into what we've been doing with Spring Rich Client, a major ongoing movement to simplify building professional-looking rich client apps built on Swing.

    I must admit I'm leaving it feeling quite perplexed. The article was literally all over the map; what is the message again?

    I even think our project (Spring Rich Client) was mentioned (something about complex? hmmm...), but to be honest, I'm not exactly sure!
  11. RiA via JDNC[ Go to top ]

    Keith,

    It's not a demo of everything JDNC can do, but a hello world, plus IDE.

    JDNC simplifies writing Java Web Start applications. I provided a link to a download a hello world, together with integrated Tomcat+Eclipse+JDK+more so that it runs for you.
    There are 3 files needed to get it to work.
    The java realizer code shown, and ant script to place the code in a war file shown and a launcher.

    The point of the article is that some people think HTML/HTTP is done for. To fund development in '04 for html and then have it go live in '05 and operate in '06 just does not make sense. As soon as a few critical competitors go rich, you have to follow. So html and portlets and jsf project, will not give you ROI imo, so I feel bad for developers that have to deal with html/http.
    There are some example ria apps on www.portalvu.com. I plan to post more advanced examples and have a place for people that are into RiA/SoA at www.portalvu.com.

    To your question: My view of Spring is that it uses a lot of AOP, IoC, xml config files and getters/setters, relative to using CoR and collections.

    .V
  12. RiA via JDNC[ Go to top ]

    To your question: My view of Spring is that it uses a lot of AOP, IoC, xml config files and getters/setters, relative to using CoR and collections..V
    Could you elaborate on what you mean minus the buzzwords? What advantages are you talking about when you say CoR and collections?

    Have you evaluated the spring-rich project in any detail? I would recommend that, to help build an informed opinion, and hopefully one we can use as good feedback.

    The #1 thing our users like about Spring-rich is how it facilitates building a well-layered rich client app with a clear separation from the UI and the business layer. It can greatly reduce the amount of code you have to write to manipulate a fine-grained POJO-based domain model using a Swing-based UI.

    The other "killer" feature people talk about is the ability to quickly and declaratively define the visual configuration of your APP; from things like look and feel, to the placement of GUI commands accross multiple command bars such as menus, toolbars, context menus, and status bars. The framework handles bootstrapping the entire APP and instantiating/configuring the underlying controls for you. Since we're built on Spring, we're able to leverage it's powerful IoC container for configuration.

    We already integrate several JGoodies projects; notably Forms and Looks, and are parterning with Karsten to help leverage what we do well with his excellent, fine-grained (and now open source!) libraries. We're quite keen on working and integrating with the JDNC effort as well, and I am looking forward to learning much more about what it can do!
  13. RiA via JDNC[ Go to top ]

    Keith,

    I agree with you on jGoodies and Burlap!

    I prefer collections vs getters/setters since they are losley coupled, like in Struts one can use collectins instead of formbeans and other places, and I did. As far as CoR vs IoC, I posted that in the CoR thread here in tss, so you can see there as to why I like CoR over IoC. Your mileage may vary.

    Is there an example of a Spring RiA ? Where/when?
    I do like the JDNC examples a lot, even the one with document editing.


    .V
  14. Keith,It's not a demo of everything JDNC can do, but a hello world, plus IDE. JDNC simplifies writing Java Web Start applications. I provided a link to a download a hello world, together with integrated Tomcat+Eclipse+JDK+more so that it runs for you.There are 3 files needed to get it to work.The java realizer code shown, and ant script to place the code in a war file shown and a launcher.The point of the article is that some people think HTML/HTTP is done for. To fund development in '04 for html and then have it go live in '05 and operate in '06 just does not make sense. As soon as a few critical competitors go rich, you have to follow. So html and portlets and jsf project, will not give you ROI imo, so I feel bad for developers that have to deal with html/http.There are some example ria apps on www.portalvu.com. I plan to post more advanced examples and have a place for people that are into RiA/SoA at www.portalvu.com.To your question: My view of Spring is that it uses a lot of AOP, IoC, xml config files and getters/setters, relative to using CoR and collections..V
    Hello Vic,

    It's a fellow Struts User subscriber. Do you believe that there will be ever be a next generation Web Browser, one that delivers only XML by default? The rendering XSLT is done on the client side.

    In my experience as an independent consultant I have noticed two popular requests from business managers.

    (1) Managers do not like the fact that HTML/HTTP causes the screen to refresh.
    [Yes there are ways around it like IFRAMES and FRAMES and overflow DIV layers,
    but it is clumsy and does not fit the MVC framework such as Struts without
    shoehorning a square peg into a hole.

    (2) Manager want individual sections of the screen to refresh, but also want
    the multiple windows of the same web application. For instance a stock
    trader application might display a list of stock, you might have a graphical
    trade view in another window. As soon as the trader select a trade, the
    second graphical trace changes also. Easy to do with Swing/JDNC but not
    with just HTML / JavaScript / Struts.

    Will this second generation [XML/SVG] universal browser ever appear?

    Hmmm I wonder what Berners-Lee is doing?

    Peter Pilgrim
  15. Umm... I'm confused[ Go to top ]

    I am eager to try out the Spring Rich Client at some stage, 'cause if its half as good as Spring it will be great.

    At the moment though I have been trying out Flex, and am incredibly impressed. I've got to say that even though the JNDC example was only a hello world, Flex components look a hell of a lot better than Swing components! The Halo theme they use is outstanding, and if I knew much about Flash I could customize my own theme. Can this be done in Swing? If so how easily?

    I know Flex is pricey, but I think it would quickly pay for itself, as the SWF file is compiled once (like a JSP), and then just served up by the server on each request.

    This has a couple of advantages that I can see, firstly the content is then static as far as the server is concerned, no CPU cycles taken up executing the JSP to produce the html to be served up, and secondly the Flash App hits the server much less frequently than a JSP solution, hitting the server for each page it wants. All in all to me this means less work for the server which saves hardware costs.
  16. Look and Feel[ Go to top ]

    People that tried XAML: can you plz launch the more advanced examples linked at end, what do you think of that relative to XAML?

    Mike S, here are some Look&Feel's for "swing":
    http://www.oyoaha.com/lookandfeel
    http://napkinlaf.sourceforge.net
    Also, you said you can't customize flash since you don't know it, but you do know Java, so yes, you can extend a lookandfell in "swing".
    (And... I did do a lot of Flex, even beta flex, then switched to Java Desktop because a slow re-sizing in Flex is not RiA, imo. You can even resize their example app on MM web site and see it)
    See how a poster above that uses Flash said they will evaluate JDNC for next project? Or you can read posts on Tapestry blog(best HTML/Javascript UI imo), saying HTML is a dead end. I know for a fact that the major Internet sites are in development of a RiA versions of their site.

    The questions is which will win after HTML: Flex, XUL, XAML or JDNC, and I cast my vote for JDNC. I am not saying there won't be more HTML legacy applications in operation, but I think we will have a mini boom in conversion to RiA. My advanced example is a portal/CMS example used to managed documents and launch external site.

    Did anyone run the "hello world" via network launcher? (sometimes hardest thing for me in sometimes is to get a hello world going). My suttle point is... you can't do that in PHP Friendster.

    .V
  17. Look and Feel[ Go to top ]

    I know for a fact that the major Internet sites are in development of a RiA versions of their site
    LOOOOOLLLLLLL!!! Which "major internet sites" would that be? The only with enough market power to gain any acceptance (apart from hardcore gaming sites, maybe) is Microsoft and maybe EBay and they are pretty stateless in what they offer. On top of that: If it does not work right away for a user, the risk is enormous, sustainable only by very few.

    Consider the total screw-up Siemens had with their all-flash site back in 1999. Or consider the amount of maintenance cost an application produces that runs on millions of subtly different computers on the internet.
  18. Karl[ Go to top ]

    Which "major internet sites" would that be?
    Google has a lot of RiA development under way. Did you click on the sample RiA links by TimesWarrner in the article , did you ever hear of iTunes?

    This reminds me of when VT100 color terminals came out, and people said they wanted green screen - what is the point of a colored text, plus the color bit is a waste of "bandwidth". But... if you disagree, then learn portlets, jsf and the like instead, and deploy a html application in your industry.

    Users LOVE rich user interfaces, end of story.

    Users have brodband more and more and larger monitors... and they want to use it. If you are targeting dial up modem users with a 15" screen, then don't do RiA.

    .V
  19. Users LOVE rich user interfaces, end of story.
    There are two issues for rich interfaces: techology and content. While techology may be new and exciting, what content do you want to fill it with? Browsers are best at displaying documents and navigation, good at showing pictures, ok at showing movies, what else? What feature to you miss?

    Is is bad technology only, like state control, like having client-side state and data, like better protocol with the server, or possibility to have detached appplications or funky 2d and 3d stuff? Or is it too much freedom that a user of a web app have, who can jump back and forth over pages and break the "normal" (from developer's point of view) flow of application? Is is lack of controls, like wizards and notebooks and trees? Is it the fact that in process of rendering a page looks ugly and deformed (I hate that too)?

    I guess that for me it is not the problem of the technology like Flash, it is problem of developers who want to brag about the huge possibilities they have now to create the rich interface. They think that they try their best, and... one can see fixed-size windows, teeny-tiny fonts, smallish scroll bars, small scroll windows, keyboard controls do not work, mouse wheel does not work, everything is blinking and jumping. Why on Earth I would like to use "rich" application which is less flexible than "old and rusty" HTML? What is the point of having 21-inch monitor if the main panel has a fixed size suitable for 17-inch screen only? What else can it provide me with? Rolling up and down content boxes, sliding panels? Why would I need all this?

    For now I have not seen not one Flash application which I would like both appearance-wise and content-wise.

    XAML and alike are another story. It is not about "providing a user with rich interface" and "throwing rusty HTML away", it is about convergence between desktop and browser, and is a very logical step. If HTTP and HTML has to change because of these changes, so it be, this is normal. But let us not mix these two orthogonal ideas: convergence of local desktop and remote resources on the one hand, and "all users want rich apps, HTML sucks" on the other hand.

    Good books often do not have pictures in them. Those who get too bored, can grab abridged version with adapted content, big glossy pictures and funny commentaries. But is it really the customer you _want_ to serve?

    Kate: If you're so bored, why don't you read?
    Doug: You mean like a book?
    Kate: That is the generally accepted format, yes. What was the last book you read? You were in college?
    Doug: The last thing I read in college was a letter canceling my scholarship when I couldn't play anymore.
    Kate: Okay, high school.
    Doug: I was a hockey player. The only thing I had to read was a scoreboard.
    Kate: And they graduated you?
    Doug: They revered me. I was a God.
    Kate: What a tragic commentary on our times.

    This huge rant was not about the technology which may be great. It was about application of this technology. Rich is good, but flashy is, well, just flashy.
  20. XAML and alike are another story. It is not about "providing a user with rich interface" and "throwing rusty HTML away", it is about convergence between desktop and browser, and is a very logical step.
    Yeap, XAML from ideological perspective looks like Jelly script to Swing which definitely makes sense.
    And Swing/QT etc is an abstraction level over XWindow/Windows UI engines. I just do not see a place for XUL engine...
    From implementation standpoint Java XUL motors reside above AWT/Swing, that does not makes sense for me because Swing oriented Jython/bsh/Jelly should work better than yet another level of abstraction….
    Mozilla’s XUL could be better of targeting Mozilla motor only and not trying to be too generic. I guess it is the case where standardization attempts do more harm than good.
  21. Karl[ Go to top ]

    Which "major internet sites" would that be?
    Google has a lot of RiA development under way. Did you click on the sample RiA links by TimesWarrner in the article , did you ever hear of iTunes?
    Did and use it. But why is it about rich user interface? iTunes (and media in general) is about monopoly and lock in, that would be the most interesting reason for them to pursue "RIA" or even better RA on your desktop
    This reminds me of when VT100 color terminals came out, and people said they wanted green screen - what is the point of a colored text, plus the color bit is a waste of "bandwidth".
    In fact one might very well argue that a lot of industries would still be better off with VT100. The main driver for the rich interface was productivity gain by integration, not productivity gain by a more productive interface. One might in fact argue that a well build text interface with trained employees gives you superior productivity. And even then there is the issue of the "controlled environment". Thinking of the subtle difference a rather primitive device like a web browser imposes on how applications look and behave, RIA apps are in for a nightmare in support, or a very slim user base indeed. They might be nice for things like airline check-in kiosks though :-).
    But... if you disagree, then learn portlets, jsf and the like instead, and deploy a html application in your industry.Users LOVE rich user interfaces, end of story. Users have brodband more and more and larger monitors... and they want to use it. If you are targeting dial up modem users with a 15" screen, then don't do RiA..V
    Well since traditional UIs scale miserably on the monitor (let alone Flash), I am very interested. Also, consider that a lot of internet users use the benign internet technology in a corporate environment. The "richer" the stuff gets, the greater the danger that mother hen (the IT security department) will pull the plug on your eBanking, Travel Booking, News Readers in much the same way they are shutting out things like, say instant messenging.

    User LOVE easy user interfaces, the LOVE fast interfaces, they love interfaces that let them do transactions - they do not care in the slightest about an interface being "rich". Which reminds me - Maybe you are too young, but I rememb er an excellent rich user interface on the internet. This was by a bank called "first-e" available all over Europe in about 1999/2000. They went bust, not least because they had huge maintenance issues, locked out a huge user base and so on..... The german sparkassen (sort of cooperative bank) used to have an excellent RIA in the form of a pretty nice applet - unmaintable, gone!
  22. Liquid layout[ Go to top ]

    Well since traditional UIs scale miserably on the monitor (let alone Flash)
    I would say that traditional _MSWin_ UIs scale miserably on the monitor.
    XWindow interfaces scale very well and allow enormous degree of customization. Same is true for Swing, unless some MS drone has used XY layout.

    http://enlightenment.org/
    http://themes.freshmeat.net/

    Flash developers claim that Flash itself supports UI scalability and I tend to believe them because WEB designers work hard to make 800 pixels wide unscalable sites with HTML, that was designed to be scalable and fit any screens :(
  23. Look and Feel[ Go to top ]

    I know for a fact that the major Internet sites are in development of a RiA versions of their site
    LOOOOOLLLLLLL!!! Which "major internet sites" would that be? The only with enough market power to gain any acceptance (apart from hardcore gaming sites, maybe) is Microsoft and maybe EBay and they are pretty stateless in what they offer.
    fyi: Nike's web site uses Flash extensively: http://www.nike.com/
  24. Look and Feel[ Go to top ]

    I know for a fact that the major Internet sites are in development of a RiA versions of their site
    LOOOOOLLLLLLL!!! Which "major internet sites" would that be? The only with enough market power to gain any acceptance (apart from hardcore gaming sites, maybe) is Microsoft and maybe EBay and they are pretty stateless in what they offer.
    fyi: Nike's web site uses Flash extensively: http://www.nike.com/
    Fixed window size, fixed font size, predefined colors, everything flying and jumping -- this is exactly why I hate Flash web-sites.
  25. There time must come - Say no to browsers[ Go to top ]

    HTML and web browsers have served there purpose. For those building applications that demand rich functionality, something more is needed. Struts, JSP, Tapestry and the like are good attempts to put a pretty face on an ugly and primitive technology (that being HTML/Javascript).

    HTML/Javascript should be limited to content navigation. Rich applications need a new framework that takes advantage of modern technology like JDNC, JNLP, Web Services, Java security/sandbox, distributing software on the demand, .......etc

    The author does cover a lot of territory quickly but I agree with his overall thesis. Browsers must go and be replaced with a rich desktop alternative that takes advantage and leverages the best of the client and the server and with all the same benefits as current centrally hosted web browser applications but without their limitations.

    The first time I saw Java applets (limited as they were/are) and technologies like Castanet/Marimba, I thought that distributing software on demand from centrally mananged and hosted servers would be the way of the future. Well it has happened, sort of, but we are stuck with outdated technology and handcuffed by the "web browing" metaphore. We can do better and the odd thing is that the technology to do it with is all there, but oddly enough no major vendor seems to see this.

    Here is an open source project called, jThinRich http://jthinrich.grandlogic.com that attempts to change things.

    -Sam
  26. So is this supposed to be an advertisement for a new UI framework? If so, why? I followed the link and found that it isn't even available for download...just lots of teaser/hype content. From the sounds of it, it looks like it's supposed to enable a thick client to be distributed much in the same way WebStart does. If this is the case, what advantages and differentiating factors does it have w/ WebStart?

    PS: If you're affiliated w/ a given technology and are advocating it, it's standard practice/courtesy to issue a disclaimer indicating that you are a biased/influenced party.

    PS2: You may also wish to run a spell/grammer check on the rest of the content for grandlogic.com. I was curious about other projects that might be available and found a number of both spelling and grammatical errors on other pages of the site.
  27. WebStart is just one enabler. By itself WebStart is just a wrapper for JNLP and for creating a sandbox by which Java applications can run on the desktop.

    What is missing is an application framework to allow developers to build secure and robust applications using a Java software distribution model while leveraging webservices to communicate with a centrally hosted system. jThinRich applications are tightly coupled to the server for session management, persistence, and for some if not all their business logic. The client side is primarly for rendering what is stored and managed on the server and providing the user with a rich application experience.

    If all you want to do is build a word processor or email client that resides on the desktop then for the most part all you need is webstart and good GUI components. There are several products out (some based on JNLP) that help you manage software distribution on your local intranet and tracking patches and updates and the like. jThinRich is not aimed at such applications.

    My goal is to motivate discussion around the topic. Currently, jThinRich is a concept with some rough design and early code fragments - I hope to have more soon.
  28. jThinRich applications are tightly coupled to the server for session management, persistence, and for some if not all their business logic. The client side is primarly for rendering what is stored and managed on the server and providing the user with a rich application experience.
    Looks exactly as purpose of XWindow server :) even wording is similar. ( for MSWin people: XWindow -server- runs on _CLIENT_ )
  29. jThinRich applications are tightly coupled to the server for session management, persistence, and for some if not all their business logic. The client side is primarly for rendering what is stored and managed on the server and providing the user with a rich application experience.
    Looks exactly as purpose of XWindow server :) even wording is similar. ( for MSWin people: XWindow -server- runs on _CLIENT_ )
    AFAIK, XWindows doesn't allow you to have a "distributed" application talking to a central server, in the way jThinRich is aiming for. XWindows allows you to "export" the display to a remote computer, but everything else in the application remains the same. For example, you can run Word on one computer, and have its diplay (and keyboard, and mouse) on another computer, and it will execute on the remote as if it was local, transparently to the user. But if you open 10 word applications, there will be 10 distinct remote sessions to the remote "server", which in turn will have 10 different processes, one for each instance of word running. So it is not like a client-server communication, where you heve 1-n relationship between server and clients. The load on the "server" will be unnaceptable in such case.

    Now, it is been a long time since I worked with XWindows, Motif, C and Unix, so I don't know if things have changed since then... One problem with XWindows was its very complex non-OO C API. I still have those complete ref books, 6 volumes, 2Kg of paper each... :)
  30. There time must come - Say no to browsers[ Go to top ]

    What is missing is an application framework to allow developers to build secure and robust applications using a Java software distribution model ...
    That is the part JDNC is trying to solve. I don't think it is that difficult without a framework (I've been using a technique instead) but a good framework would help.

    Burlap seems to also - http://www.caucho.com/burlap/
  31. There time must come - Say no to browsers[ Go to top ]

    JNDC is a move in right direction but for the most part it builds on Swing and trys to fill the missing holes in Swing. The goal of jThinRich is to enable applications that need tight coupling between client and server (in an internet/http environment) where the client, for most part, only does GUI rendering, and the server handles persistence and complex business logic. Even the JNDC XML markup does not really address this directly.

    If you are building a Java/WebStart word processor you may not need jThinRich. WebStart and some good Java UI components might be all you need. But let's say you wanted to convert a commerical home banking online internet/browser/html application to a rich Java application that can also be offered over the internet. What would you need jThinRich to do? Here are some of the things that you might need:

       - Java desktop software is distributed from a central server with dynamic and seamless updating of software. The only thing you need to have installed on your desktop is the JDK. For example, if the product is updated while users are using the application, on the next client request the user is informed that they need to logout to get the updated software.

        -Java desktop applications can run in a secure sandbox.
        
        - Server tools and APIs for managing the upgrading process of both the server and client software.

        - Client API for managing GUI application state like window closing when application times-out from server session, offline vs online usage options for application or sub application screens, API for viewing backgrounded server requests and active requests, ability to terminate long running requests, etc.

        - Lightweight HTTP based messaging API for managing communication between server including session management and authentication.

        - Smart cache management API to allow client to keep recently used data local for easy access by MVC components. Caching related listener API also allows GUI screens to know when their data "may have" changed such that they can request refreshes only when needed thus minimizing server hits. For example, navigating back and forth between screens should not always require server hits unless there is a known change to the data model or some timing threashold has been reached.

        - Standard way to log, view, and track request errors between client and server.

        - Convienient threading model so that user has option of background server requests and asynchronously updating UI when request complets while keeping GUI responsive.

    The benefits of this model are not just for the GUI client experience. Server load will be significantly decreased allowing centrally hosted services to support large concurrent users. Every button click will not require an expensive round trip. Servers no longer have to format and generate HTML.
  32. There time must come - Say no to browsers[ Go to top ]

    The benefits of this model are not just for the GUI client experience. Server load will be significantly decreased allowing centrally hosted services to support large concurrent users. Every button click will not require an expensive round trip. Servers no longer have to format and generate HTML.
    And no session management.
  33. The benefits of this model are not just for the GUI client experience. Server load will be significantly decreased allowing centrally hosted services to support large concurrent users. Every button click will not require an expensive round trip. Servers no longer have to format and generate HTML.
    And no session management.
    If you work with a remote database, say online store or trading system, how can you get rid of session management? If you have centralized storage and model, you would want to know what resources are locked and by whom. I am not talking about "user preferences" state, like color scheme or password caching, which can be stored on a client. I am talking about real data. You cannot create system utilizing pessimistic data locking without session/state management. You need some kind of identification anyway, which means client/session/user/whatever. Do I miss something?
  34. And no session management.
    If you work with a remote database, say online store or trading system, how can you get rid of session management? If you have centralized storage and model, you would want to know what resources are locked and by whom. I am not talking about "user preferences" state, like color scheme or password caching, which can be stored on a client. I am talking about real data. You cannot create system utilizing pessimistic data locking without session/state management. You need some kind of identification anyway, which means client/session/user/whatever. Do I miss something?
    Not every technique is right for every situation. This may be one that requires a bit more work (i.e. keeping some state on the server). Maybe part of the answer is don't think of it as data. My question to you is how then do you cluster these sessions?
  35. If you work with a remote database, say online store or trading system, how can you get rid of session management? If you have centralized storage and model, you would want to know what resources are locked and by whom. I am not talking about "user preferences" state, like color scheme or password caching, which can be stored on a client. I am talking about real data. You cannot create system utilizing pessimistic data locking without session/state management. [..]
    [..] This may be one that requires a bit more work (i.e. keeping some state on the server). Maybe part of the answer is don't think of it as data. My question to you is how then do you cluster these sessions?
    Most app servers today support some form of clustering of session data out of the box. If that isn't enough (e.g. scalability, availability) then use Coherence*Web. Coherence also handles the challenges of clustered in-memory transactional state and resource locking.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  36. Most app servers today support some form of clustering of session data out of the box. If that isn't enough (e.g. scalability, availability) then use Coherence*Web. Coherence also handles the challenges of clustered in-memory transactional state and resource locking
    Thanks Cameron. I knew. ;) What I was trying to accomplish was to get the poster to share how, if they were, solving this issue and show that if that can be done with out-of-the box session management there is no reason the rich client couldn't do it themselves. But of course not every situation is the same and one will need to decide which tough nut to crack. Most apps put too much work on the server - at least all the ones I have seen. It is funny how many "web apps" work till you try to cluster them (with out-of-the-box clustering). Especially if it is a good OO app. :)
  37. Most app servers today support some form of clustering of session data out of the box. If that isn't enough (e.g. scalability, availability) then use Coherence*Web. Coherence also handles the challenges of clustered in-memory transactional state and resource locking
    Thanks Cameron. I knew. ;) What I was trying to accomplish was to get the poster to share how, if they were, solving this issue and show that if that can be done with out-of-the box session management there is no reason the rich client couldn't do it themselves.
    I did not really get your clarification of your own question. Yes, sessions can be clustered, but this is implementation detail. It is still something stored on the server (or cluster of servers, whatever). Are you saying that rich client is going to store the session on the server automatically? Whatever, I just responded to the note that rich clients do not need session management at all, while I think they DO need it especially if they use centralized datastore with pessimistic transaction control. If rich client can do it for me, this would be great.
  38. With a rich client, some of the responsibility of session management can be shouldered by the client. For example on initial autentication and session creation the client will pass along to the server the usual information to get authenticated and has the option of requesting a perferred session timeout interval. After authentication the server will pass back to the client (if authentication is accepted of course) various information including the the "actual" timeout it has granted to the client. The client will then use this timeout window to locally track and manage the inactivity timeouts.

    The client will typically track the timeout and locally close the session on the local desktop app when the user has not been active for the given timout interval. The server however still needs to track the session for various reasons including making sure that the client does not violate its contract. While the client may have been downloaded via JNLP from the server's web site the client can't be fully trusted. The server still has final control over terminating the session (for whatever reason). If the client does not terminate the session the server will on the clients next http request.
  39. IAB Studio - live in browser[ Go to top ]

    Web browsers served for over 12 years and will do their work yet for long time... the fundamental JS/DHTML apparatus may be used in different forms, IAB Studio is a good example; look here: http://www.iabstudio.com. Try it and feel the powerful this technology is. Download IAB Studio from http://www.worcsnet.com for free.
  40. slow[ Go to top ]

    Demo site ist VERY slow.
  41. Re: IAB Studio - live in browser[ Go to top ]

    Web browsers served for over 12 years and will do their work yet for long time... the fundamental JS/DHTML apparatus may be used in different forms, IAB Studio is a good example; look here: http://www.iabstudio.com. Try it and feel the powerful this technology is. Download IAB Studio from http://www.worcsnet.com for free.
    "free" in this case meaning "our products are free for non-commercial use". RC
  42. Yes you would still need session management. Like in the browser world the client would still send a session token during each and every request to the server. The server would then also still need to manage and track the session in all the same ways. From authenticating the user and issuing the inital session id to terminating it after timeout threashold is hit or explicit user logout request, session management is very central to jThinRich.

    So somewhat similar to how cookies work in the browser world, jThinRich would give developers a simple session API for use on the client and server side. Details on how the sessions are managed on the server side would still be an implementation detail for the server(db vs memory cache etc) and one can work with standard J2EE appservers to do this.

    As an example of how jThinRich desktop applications differs from web/html applications consider this example. With html/browser apps, since just about every operation you perform in the GUI will hit the server (weather you like it or not), the server typically has current status information one what the user is doing and the fact that user is actively using the application. So if the user has a 15 minute session timeout and they actively click through pages they will not timeout unless they do not click on anything for 15 minutes or more. With networked Java applications this is not necessarly the case. If I navigate to an application screen the first time I will most likely make a server call to get the data needed to populate the GUI. But since jThinRich apps trys to reuse cached data, when they can, to avoid uncessary server hits, the user can be prematurely timed out of there session even though they are actively clicking and using the GUI (for example performing GUI sorting functions). So to avoid this, jThinRich apps have a background utility thread that monitors if the user is actively using the GUI and will send a keep-alive type of request to the server whenever it notices the timeout window is approaching and the user has not made an explicit server request. The keep alive is only made when the session is about to expire and user has not made any server requests to explicitly keep the session alive. And this all happens in the background without the user knowing anything about it.

    There are other examples but as you can see there are differences between the needs of web/html applications and the needs of centrally hosted client side Java applications. Other issues include logging out controls, multiple application instance management running on the same desktop, multiple session authentication support by the same user, client side preference configuration and options, .......
  43. Hi Sam,

    Thanks for the post.Where can i find jThinRich?
  44. TSS Article: Rich Internet Applications[ Go to top ]

    XUL, specifically, Mozilla XUL. Very interesting stuff.
  45. XUL, specifically, Mozilla XUL. Very interesting stuff.

    Allow me to highlight the XUL Challenge 2004 Counter Gallery that showcases more than 15+ XML UI language (XUL) formats side-by-side including Mozilla, Flex, Avalon, Luxor, Thinlet, Beryl, FormsPlayer, SwiXml and many more.

    Note, if you want to see the full monty, that is, all code-behind sources, scripts, readme docs and more browse the CVS repository online @ http://cvs.sourceforge.net/viewcvs.py/xul/challenge

      - Gerald

    -------------
    Gerald Bauer
    The Thinlet World | http://thinlet.blog-city.com
  46. You don't know Jack![ Go to top ]

    I find it quite interesting that nobody seems to wonder, why HTML was so successful and why it has - indeed - still not long been encompassed by Applets or by Flash(MX). I think the basic reason is, because it is fairly simple and its usage metaphor is - apart from the actual pictures - more or less the same. You click a picture, you get another page. Simple as that. In fact, simple pages have enjoyed heavier usage than a lot of interactive complex pages.

    In addition the applications are stable, appeal to the broadest possible audience, are fairly easy to maintain, perform fairly good, have a very good metaphor for accessability and device support etc., etc. Then there is the question, how many of the site on the web are actually "programs" as opposed to "content" not only in the way they work but in there interaction metaphor? Altogether I don't see a particular drive to adopt any of these new technologies.....
  47. This whole hype about RIAs may be true to a certain degree in data-centric applications. The user experience will definitly become richer in webshops, internet banking etc.

    But what would be your usecase for reading and searching in document-centric information services? The linking over hypertext and images has prooven as such a powerful approach for building networks of information that it's hard to believe that this simplicity would be replaced by building webstarts or flash-clients.

    In my opinion at least for information-workers the concepts of semantic web are much more interesting. These technologys merged with approaches that combine your secure data (based on its fulltext information and metadata) with information in public spaces and for example gives you hints on documents that you need to research while typing a report will be the great business opportunity for information services. And in this domain - once again - microsoft will be a brutal threat for other players since they own the desktop right now and - with longhorn, xaml and winFS - they are getting the tools in place that'll make it possible to do exact these things in between your desktop, office applications and the internet. Hopefully Sun, IBM and so on will have an answer... Or maybe at the end of the day looking glass may look wonderful, java web start may be a great platform independent RIAF but the content rules once again on M$.
  48. I think the big success of web interfaces is seemless integration of multiple applications in one and only client. True, HTML/Javascript has enormous limitations, but, from a user standpoint, it is very intuitive to click on *external* links the same way as on *application* links/commands.

    As of today, we have 2 approaches here to enhance the user experience : either you build *applications* outside the browser (using rich client, via Webstart if needed) with a limited scope and not integrated with THE central place (Internet), or you try to enrich the browser (the Mozilla way with XUL, and Microsoft's with XAML) and try to create a seemless integration between HTML content/applications and those extensions for a rich GUI.

    To me, the approches are radically different. I tend to believe that both are of course necessary in specific situations, but the second will be favored in the long run. The users' needs (and wishes...) are so diverse today that it will be hard for the industry to get them back into multiple, non integrated applications...

    Hugues.

    PS: to me, applets are part of the second category, as they stay within the browser. They surely would deserve better consideration...
  49. I agree that the existing HTML technology works well for document-centric content, and that there is a different category of application which doesn’t work well with a page based UI metaphor (management / monitoring applications for example). I believe that providing a more appropriate technology for that second class of application that can optionally be hosted within a web browser is important so user can access both types of applications from the same place.

    Java Web Start is doing a lot of the right things, but it forces the decision of not using a web browser. At Nexaweb, for example, we provide technology that gives you the benefits of a rich desktop style application, and leaves the decision on hosting in a browser or not to you, the application builder.

    The point is that web browsers and HTML aren't going away any time soon, nor should they for many types of applications. Its a great piece of technology that has proven value.

    Different technology is needed for those applications that have avoided the web and remained client/server because the HTML paradigm doesn't work for them. Those applications need technology that can leverage the existing Internet infrastructure, including web browsers where appropriate, and offers a non-paged based, stateful Java client that works better for many enterprise applications.

    My two cents.

    Scott Cranton
    Nexaweb Technologies
  50. Quick Post - for things that are better used via the browser see - JDIC - jdic.dev.java.net
  51. Mark

    I took a quick look at the link you posted, but I don't see the hosting in web browser bit.

    It looks like JDIC is a technology for your Java applications to integrate with native desktop applicaitons like email, web, etc. It looks good in that it means you wouldn't have to exec native applications from your Java code, which becomes a maintence problem as you support more platforms. But I don't see how JDIC helps the 'host your java app in a browser' problem.

    Am I missing something?

    Thanks

    Scott Cranton
    Nexaweb Technologies
  52. Did you see the info about the browser in the middle of the page? (If you are using FireFox, got to the page, click in some white space and type "br". It will jump to the link in the area)

    JDIC is more than one thing, but I was specifically refering to the browser. It is a widget that uses your native browser. Sure, there are widgets that are pure java and they might be the solution.

    The concept is this - Server up the application via WebStart. Things that are applicationish - use Swing (or SWT). If part of the appliction is document based, then use the web widget. Basically turn the tables. BTW, IMHO, I believe this is the direction that Microsoft is going and has to go (to retain control of the desktop).

    Sorry if this is not clear. I'm forming a headache this morning. :(
  53. Mark - Now I understand your point - sorry to hear about your headache.

    Driving a web browser from an application certainly helps, but I think it’s still an awkward solution.

    At Nexaweb, we started with the assumption that many app builders wanted to stay primarily within the browser, but wanted the advantages of a stateful client, Java as the programming language, and two-way communication between client and middle-tier. We also wanted to support Java 1.1 (or better) including the Microsoft VM, to get the broadest platform coverage possible out of the box. And (hopefully not starting a flame war) we make it easier to define Swing-like UIs with a XUL-like XML syntax while allowing programmers to code up their logic in Java.

    Sorry for the product pitch, but I'm trying to use our product design goals to make a point about an application centric approach versus a web approach. The right answer is probably somewhere in the middle (and moving).

    Scott Cranton
    Nexaweb Technologies
  54. Driving a web browser from an application certainly helps, but I think it’s still an awkward solution.
    I guess it depends on what you do. It seems to work in Eclipse.
    At Nexaweb, we started with the assumption that many app builders wanted to stay primarily within the browser ...
    I'm sure some do. I'm not one of them. I've always felt something was wrong developing apps that run in the browser (being mostly HTML and Javascript). I'm not talking about Web Sites, but web apps. I've coded apps in COBOL, ASP, VB, ASP.Net, C#, VB.Net, Java - Swing, JSP, Echo, Struts ... . I've discovered that "traditional" web apps are not as easily created, deployed, maintained and modified as purported to be.

    What your product does, from what I can tell, is currently a good solution. I would need to investigate it more to compare. But I think when Longhorn hits, you might have some issues. But I'm no fortune teller.
  55. United XAML, XAML4J and More[ Go to top ]

    Microsoft's with XAML

     Allow me to note that Extensible Application Markup Language (XAML) is just a technique and not a language lets say like W3C HTML 4.01. The XAML markup (tagset) depends on what libraries you plugin (e.g. Avalon/Windows 2009, Windows Forms, etc.).

     For alternative free open source XAML projects see the United XAML site.

      Also note one can argue that Jelly is more or less XAML4J. See the Richmond Post story titled "XAML4J Tutorial - Let's Swing, Shall We?" for more.

       - Gerald

    -------------
    Gerald Bauer
    The Memphis Sun | http://luxor-xul.sourceforge.net/sun
  56. I think the big success of web interfaces is seemless integration of multiple applications in one and only client.
    I agree. I think this one of the problems of Webstart. It confuses users because, it is neither web-like nor a real desktop app. Applets on the other hand just start too slow to realy fit in the web-feel.

    Maybe this could be solved with a multi-tab browser based on Eclipse. You could install your favorite plugins for bookmarks, history, RSS, e-mail etc. I miss that with current browsers. Of course you could also install your custom fat applications like you currently install desktop apps.

    On the other hand the browser would also support a sort of JNLP, which would download a 'transient' application and start it like a web-page in its own tab. Like a webpage this app could than be bookmarked, placed in history and so forth. All in all it should appear to be just a richer form of a web-page.

    I think such a browser would finaly give Java a real desktop-enviroment and if the plugins are good (I am sure they would be quite soon) users would have the JRE installed not just because because of some agreement.
  57. On the other hand the browser would also support a sort of JNLP, which would download a 'transient' application and start it like a web-page in its own tab. Like a webpage this app could than be bookmarked, placed in history and so forth. All in all it should appear to be just a richer form of a web-page.
    Sounds like Applet wrapped in Java Web Start does exactly that: http://www.vamphq.com/jnlpref.html#applet-desc
    can be delivered today... What is wrong with JWS wrapped Applet on subsequential page visits? It should start quickly as it is in JWS cache....
  58. Thank you for the link.

    But what I was thinking of is the start of the VM - this takes time. During a normal web-session a user sees an applet or JWS once if ever and than nothing loads as slow as Java and the natural conclusion is that Java is just slow - avoid it.

    The trick of course I dream of is that you start of slow with browser loading, where users are more used to slowiness and than be fast in Java apps launching.

    I suggested Eclipse not because I favour SWT. Just because Eclipse is the only Java fat-client-app which ever impressed my friend - a MS fan.
  59. Thank you for the link. But what I was thinking of is the start of the VM - this takes time. During a normal web-session a user sees an applet or JWS once if ever and than nothing loads as slow as Java and the natural conclusion is that Java is just slow - avoid it.
    Try this:
    http://thinlet.sourceforge.net/demo.html
    Can't get any faster than that. The first time may be slower, but after the applet is donwloaded, it gets lightning fast everytime you go back to that page! Better yet: it runs on any JVM v1.1 (MS', Sun's), so you will hardly need to install any runtime, it is a small jar (38Kb), very simple API...

    Regards,
    Henrique Steckelberg
  60. Try this:http://thinlet.sourceforge.net/demo.htmlCan't get any faster than that. Better yet: it runs on any JVM v1.1 (MS', Sun's), so you will hardly need to install any runtime, it is a small jar (38Kb), very simple API...
    Indeed what Robert Bajzat packed in 38Kb is fantastic. I think it is the best mass RiA 'platform' there is currently. Some things are missing (date chooser, not so sure about Dnd) but it looks good, is fast, is super small and you can do logic in Java. JavaScript just sucks if you want to do a bit more on the client.

    But the main disadvante is that it is an Applet. It starts slow and it is restricted to a fixed width (which is normally much lower than the space available).

    When I said Eclipse based browser I actually meant a client Java platform where normal user could associate something (positive) they see with java and which would give Java an independent 'desktop'.
  61. Try this:http://thinlet.sourceforge.net/demo.htmlCan't get any faster than that. Better yet: it runs on any JVM v1.1 (MS', Sun's), so you will hardly need to install any runtime, it is a small jar (38Kb), very simple API...
    But the main disadvante is that it is an Applet.
    It _may_ be an applet. You can also create a normal WebStarted desktop application with thinlet the same way you can create an applet.

    Regards,
    Henrique Steckelberg
  62. But the main disadvante is that it is an Applet. It starts slow and it is restricted to a fixed width (which is normally much lower than the space available).
     Tip 80: Resize applets within browser frames
    http://www.javaworld.com/javaworld/javatips/jw-javatip80.html

    Personally I do not see much advantage in Thinlets these days as Swing comes with Java 1.3-4-5 and it can be scripted directly with jython, jelly, bsh or Java's XMLencoder/decoder. As for Applet slowness: wrap them into JWS.
  63. But the main disadvante is that it is an Applet. It starts slow and it is restricted to a fixed width (which is normally much lower than the space available).
     Tip 80: Resize applets within browser frameshttp://www.javaworld.com/javaworld/javatips/jw-javatip80.htmlPersonally I do not see much advantage in Thinlets these days as Swing comes with Java 1.3-4-5 and it can be scripted directly with jython, jelly, bsh or Java's XMLencoder/decoder. As for Applet slowness: wrap them into JWS.
    IMO, the big advantage is when you have little or no control over the user's machine. Downloading and installing a JRE might not be that difficult, but to force a user to do this to run your application is often too much to ask. It's a different matter if it's an internal app and you can count on all user's having web start or an updated JRE.

    Mike
  64. to force a user to do this to run your application is often too much to ask
    Like ITunnes?
    .V
  65. Resize applets within browser frames[ Go to top ]

    So is expecting them to have up-to-date browsers.

    Funny how these same people will drive to Best Buy, pay $50 for a game, go home and install it. Then drive back to Best Buy to get the right video/sound card. :)
  66. Resize applets within browser frames[ Go to top ]

    Thanks for the tip with resizing.
    So is expecting them to have up-to-date browsers.Funny how these same people will drive to Best Buy, pay $50 for a game, go home and install it. Then drive back to Best Buy to get the right video/sound card. :)
    Users pay but they are not stupid to download a fat JRE, just to run a small application. Microsoft realized that when they intruduced Windows 3.1 through Excel. Thinlet for an application is beside the obvious technical restrictions just exaclty the step in the other direction (a dead-end everywhere).

    Currently there is a circle: Because there is no general useful fat application no user is amazed what the fat JRE by now provides (and that's a lot also in the graphics area) and does not install it. Smaler applications (plugins - which I think are the future) can not rely on a width JRE base.

    IMO a Browser based on Eclipse could be a way to break that. Everyone needs a browser, the market is taff but more open than in other areas and much of the base technology has been build with Eclipse.

    Maybe IBM is one more time so nice to the Java community to give a striped down open version of their Lotus client.
  67. Resize applets within browser frames[ Go to top ]

    Users pay but they are not stupid to download a fat JRE, just to run a small application.
    So how about a large application? Why is is stupid? It is great. They get access to lots of cool stuff for this free and easy download. Any NASCAR fans here? Check out their PitCommand.
  68. Resize applets within browser frames[ Go to top ]

    Users pay but they are not stupid to download a fat JRE, just to run a small application.
    So how about a large application? Why is is stupid? It is great. They get access to lots of cool stuff for this free and easy download. Any NASCAR fans here? Check out their PitCommand.
    Users are not stupid they know much better than most developers what they like. And certainly no app which breakes the ice and makes the user to download the JRE is stupid. Contrary it has to be very clever to make the user take the burden.

    However until the ice is broken it is stupid to implement a client in Java where there is a competing nativ alternative. Mabe a web-browser is not the real answer, but it would just have a bigger potential audience and could give Java a face on the client. (Not many NASCAR fans here in Europe ;-))
  69. No NASCAR? How about Football?[ Go to top ]

    No NASCAR? What does your neck do for exercise? :)

    While not as cool as Pit Command - http://www.world-cup-info.com/match_reports.htm
    I think there was something cool during the World Cup. - http://www.javalobby.org/threadMode3.jsp?message=518676&thread=4235&forum=61
  70. No NASCAR? How about Football?[ Go to top ]

    Thanks for the links.

    Seems that we Europeans prefer the slower sports - much flash there :).
  71. No NASCAR? How about Football?[ Go to top ]

    Thanks for the links.Seems that we Europeans prefer the slower sports - much flash there :).
    Yeah. If we could just find a Cricket Applet. :)
  72. Flex still rules for me for RIAs[ Go to top ]

    I took a look at Thinlets and I was quite impressed with the look of them, although I still find it frustrating that we can't use all the post JDK1.1 features without expecting the user to download a big new JRE, which as one guy pointed out, it depends on your target audience as to whether they will bother or even be capable of doing so.

    I like the idea of using WebStart but again its applicability probably depends quite a lot on your target audience and getting them to download the application + JRE.

    For me the downsides of using Flex are having to program in Actionscript instead of Java. It is pretty much OO, but I miss all the Java collections and other APIs, as well it would be nice to be able to pass POJOs directly to the client.

    All in all though, I think in a lot of RIA development projects Flex would be worth looking at, as I think it has a lot more pros than cons. A few messages on this thread have voiced a dislike of Flash and have said that its too 'flashy'. Wasn't this a problem with html in the beginning with too many flashing headings, animated GIFs everywhere etc.? The same goes for Flex/Flash, you can make a great looking site by using a bit of restraint and subtlety.
  73. Flex still rules for me for RIAs[ Go to top ]

    I completely agree.

    I started off with Thinlets and was impressed but disappointed. Not in the product itself but with the fact of so many versions of java that it could possibly run on. Although I did write an in house app for administering my application servers.

    I know for a fact that my audience, mostly retired people or government workers looking to retire, would most likely not take the time to go and download a jre, too big too long.

    I chose flex after reading about it. When I first came to it I thought "ugh, annoying ads," but after reading their documentation I thought to give it a chance. Took me very little time to write an application in it, and what do you know it was intuitive to use and was very clean. I think that's truly the new word for Flex/Flash, "clean." In fact I've written other examples for other divisions in my company and the one word that everyone has said has been "clean."

    ActionScript can sometimes be difficult to program in, however it isn't completely alien and once you get syntax down it's actually easy to get through.

    I have a release date of Monday for my first production Flex application, an issue tracker for vendors. It does the handling of displaying the data and trapping updates, but some of the features I think are cool are the fact that it has a spell check (using jazzy on the server side) for textinput and textarea as well as a network file browser and the ability for an end user to generate a report in pdf or excel. Now the report generation has nothing to do with Flex, but it was cool to do and quite fun. The biggest excitement from my user community was "...spell check? I need spell check!"

    I really think that it won't be MS to directly pull everyone into RIAs it will be the massive user community they have. MS will build office online and change it's licensing where you can use exactly what you need when you need it but the main functionality won't reside on your desktop but the UI might. If/When they move to this their community will once again chant to every developer across the world "Why doesn't this work like MS XXXXXXX?" Let's face it an unsmart user community is the chain that binds us. I should say an unsmart user community and the unsmart management is the chains that bind us. I really do see MS moving to this just so they can check your licensing when you first start up your MS software. Or they might have pay as you go licensing, something like Cellular plans, you get 500 minutes a month to use MS software for $120 after your plan minutes are used up it'll be $.30 a minute. It also would allow for MS to upgrade their software without having to worry about having the user do it. The end user might only notice an update if the client actually changed. Can you imagine the big brother syndrome then, the ability for the government to go to one place to know every letter anyone using this software has written. So glad I'm on a MAC and I'm a big fan of openoffice and NeoOfficej.
  74. IMO, the big advantage is when you have little or no control over the user's machine. Downloading and installing a JRE might not be that difficult, but to force a user to do this to run your application is often too much to ask. It's a different matter if it's an internal app and you can count on all user's having web start or an updated JRE.Mike
    Thinlet IS an Applet therefore requires JRE too, so, I still do not get why not using Swing and where advantage is.
    With Swing I have mature library with known number of bugs and unlimited abilities to extend, create and customize components.
    With Thinlets: unknown quality, extendibility, etc.
  75. Thinlet IS an Applet therefore requires JRE too, so, I still do not get why not using Swing and where advantage is.With Swing I have mature library with known number of bugs and unlimited abilities to extend, create and customize components.With Thinlets: unknown quality, extendibility, etc.
    Thinlet requires JRE 1.1 (including MS'), which comes installed with almost all MS desktops, so it doesnt require you to donwload and install a >20Mb JRE. And it is NOT an applet, you can create "pure" desktop applications with thinlet too. The biggest advantage is its simplicity and very small size (which translates into lean, fast and responsive applications). BTW, you can create rather complex applications with it, despite its small size and simplicity... it is a beauty!

    Regards,
    Henrique Steckelberg
  76. jvm 1.1 ...[ Go to top ]

    So it will work till Longhorn comes out. :)


    Of course its small size comes at a price - it isn't very OO.
  77. an alternative to Mono #gtk[ Go to top ]

    Or why not convert them to J# Browser Controls and use them even after Longhorn.

    Being in Java 1.1 Thinlet.java and AppletLauncher.java compile nicely to CLI code that runs under both Mono and .NET. As Henrique says it doesn't have to be applets even. When Mono gets ClickOnce (soon), "Mono thinlets" can be used in zero install scenarios.

    Regards
    Rolf Tollerud
  78. Or why not convert them to J# Browser Controls and use them even after Longhorn. Being in Java 1.1 Thinlet.java and AppletLauncher.java compile nicely to CLI code that runs under both Mono and .NET. As Henrique says it doesn't have to be applets even. When Mono gets ClickOnce (soon), "Mono thinlets" can be used in zero install scenarios.RegardsRolf Tollerud
    When Longhorn this, when Mono that... Do it today with Java, you don't have to wait for its clones.

    Zero install scenarios? Are we talking about Xwindows again? ;)

    Regards,
    Henrique Steckelberg
  79. Henrique: "Do it today with Java, you don't have to wait for its clones"
    "Are we talking about Xwindows again?"

    No, do it today with Mono/.NET. For ClickOnce on Windows you only need .NET Framework 2.0 which is available. I just pointed out that thinlets (a beauty as you say!) works with Mono and .NET, Applets or standalone.

    Regards
    Rolf Tollerud
  80. an alternative to Mono #gtk[ Go to top ]

    Henrique: "Do it today with Java, you don't have to wait for its clones""Are we talking about Xwindows again?"No, do it today with Mono/.NET. For ClickOnce on Windows you only need .NET Framework 2.0 which is available. I just pointed out that thinlets (a beauty as you say!) works with Mono and .NET, Applets or standalone.RegardsRolf Tollerud
    Sure. Alienate those who don't use Windows. Kind of opposite of what we are trying to do.
  81. At the risk of being flamed, aren't IBM/Lotus the first out of the gate with such an application. Their Lotus Workplace Rich Client edition is based upon Eclipse and hooks into the Websphere Portal Server. Later this year, early next they'll be releasing an SDK to allow third-party developers to use the Workplace APIs to develop their own rich client plug-ins.
  82. aren't IBM/Lotus the first out of the gate with such an application. Their Lotus Workplace Rich Client edition is based upon Eclipse and hooks into the Websphere Portal Server.
    Thank you. Would be great if IBM steps in this direction. Do you have any further info. How open will that be? I think it will be like you set just client for Lotus and not for the average users.
  83. aren't IBM/Lotus the first out of the gate with such an application. Their Lotus Workplace Rich Client edition is based upon Eclipse and hooks into the Websphere Portal Server.
    Thank you. Would be great if IBM steps in this direction. Do you have any further info. How open will that be? I think it will be like you set just client for Lotus and not for the average users.
    They've more than stepped.

    http://www.lotus.com/products/product5.nsf/wdocs/workplacehome

    You can do the same with Eclipse RCP.

    http://www-106.ibm.com/developerworks/edu/os-dw-os-rcp1-i.html
  84. hummm[ Go to top ]

    XUL
    www.xulplanet.com

    Flash is for games. Or for software companies that want to spend a *lot* of money with designers-animators-directors-muscicians-artists. And I´m sure that the client does NOT want to pay that price.
  85. XUL hummm...[ Go to top ]

    XUL pushes limits further, but still it is much less powerful than good old XWindow. Have you noticed that XWindow engine happily runs UIs written with Swing, QT, TCL/TK etc.? And certain developers consider different UI frameworks to be most convenient for _them_, so any attempts to standardize UI creation with XUL are doomed because of human nature. Hell IT fails to stick even with HTML/JScript specs!
    My point: there is a definite need for Rich applications on demand, but XUL is not the answer, more precisely it is lame answer that might succeed for a while to be replaced by more logical solution.
    It is like giving a shovel (XUL) to a man who digs with a stick (HTML), but he really needs a ‘bobcat’ (probably next generation of XWindow).
  86. XUL hummm...[ Go to top ]

    XUL pushes limits further, but still it is much less powerful than good old XWindow.
    Konstantin,

    I agree with your sentiment about standards are a wonderful thing because there are so many to choose from ;-), but I believe most enterprise shops realize that having each project use a different set of standards and technoliges is problamatic.

    What do you consider missing from XUL that X Windows has?

    Scott Cranton
    Nexaweb Technologies
  87. XUL hummm...[ Go to top ]

    What do you consider missing from XUL that X Windows has?
    From what I have seen creation of custom XUL components is a great pain in the neck as opposed to Swing/Delphi, where components can be easily created/extended/used/debugged.
    Could you point me to a chart component implementation in XUL? Not that XWindow itself has a charting component, but other than XUL/HTML technologies allow easy creation of such component(s)…
  88. XUL hummm...[ Go to top ]

    What do you consider missing from XUL that X Windows has?
    From what I have seen creation of custom XUL components is a great pain in the neck as opposed to Swing/Delphi, where components can be easily created/extended/used/debugged. Could you point me to a chart component implementation in XUL? Not that XWindow itself has a charting component, but other than XUL/HTML technologies allow easy creation of such component(s)…
    Good point. I agree that XUL alone isn't enough to do everything needed to create enterprise apps.

    However, XUL/XML makes it easier to specify the user interface, and when combined with Java code to handle the events, you've got a powerful combination. For example, Nexaweb has a chart component that is specified (layout) in the UI markup as <chart/>, with the event handling logic (and needed debugging) done in Java.

    (Shameless product plug coming) You can see for yourself at the Nexaweb demo site http://www.nexaweb.com/demo.htm.

    I've certainly done my share of X Windows (and Swing, Windows, Display Postscript, ASCII Art, etc.) programming and I like those technologies. However, I always found it a real pain to programmatically layout UI widgets, even with GUI IDEs. And UIs are, IMHO, better designed by UI folk versus us programmers who are better at interacting with computers :-). UI folk aren't always comfortable futzing with Java code, even with GUI tools - I think that is part of the appeal of HTML is that it’s a less "scary" technology for many who are good interacting with people and not code.

    Any who, I think separating the two - UI design and event logic - is a good thing, and allows people with the right skills sets and technologies to do the right thing.

    My two cents.

    Scott Cranton
    Nexaweb Technologies
  89. XUL hummm...[ Go to top ]

    Nexaweb has a chart component that is specified (layout) in the UI markup as <chart/>, with the event handling logic (and needed debugging) done in Java.
    (Shameless product plug coming) You can see for yourself at the Nexaweb demo site http://www.nexaweb.com/demo.htm.
    Hate to register to see a demo, kind of a red flag for me...
    I always found it a real pain to programmatically layout UI widgets, even with GUI IDEs. And UIs are, IMHO, better designed by UI folk versus us programmers who are better at interacting with computers :-).
    ???? Have you used Delphi? Or even NetBeans UI editor?? What do you call programmatic?

    However, programmatic UI manipulation is exactly what is most efficient and convenient in certain cases, and Swing/Delphi allow doing it effortlessly.
    I think separating the two - UI design and event logic - is a good thing,
    Agreed, and it is long time since I saw a person who thinks opposite.
    and allows people with the right skills sets and technologies to do the right thing.
    Yeap, and with right tool technology we(developers) can build good UIs from paper sketches or nice pictures in no time.

    UI is more than Look (designer/BA realm) it is also a great deal of Feel: shortcuts, hints, field updates on demand, masks,local validators, etc. and all that is realm of developers, not UI designers or BAs.
    Tapestry uses right approach in this regard.
  90. XUL hummm...[ Go to top ]

    I think we're in basic agreement relative to philosophy of designing and maintaining GUIS - though we differ a little over tools and the exact location of that seperation line.

    My point is that X Windows and HTML based applications err too much on the side of server-side processing for certain categories of applications. There are a number of (great) technologies that make it easier to create and maintain HTML web apps, but certain apps really need more processing to be down on the client to make them productive and useful. This leads back to the discussion of how far back towards pure desktop applications does one need to go.

    My original contention is that where as JNLP and JNDC make it easier to deploy and network Swing applications, you've still lost one of the benefits of HTML, which is a cleaner seperation of UI specification and event handling logic. My belief (and what puts food on my table) is that there is a middle ground that allows appliations to be created which have a HTML like seperation of UI and event logic with the benefits of distributed processing and state management that Swing like applications have. RIA vendors are in that middle ground fighting over whose got the right balance between these two needs.

    I could be bold and argue that some RIA technology follows IoC principles in using XML UI definations to declaritively wire event logic code together... though I'd probably be crossing the market-ware / buzzword / pain-point threshold ;-)

    Scott Cranton
    Nexaweb Technologies
  91. XUL hummm...[ Go to top ]

    My original contention is that where as JNLP and JNDC make it easier to deploy and network Swing applications, you've still lost one of the benefits of HTML, which is a cleaner seperation of UI specification and event handling logic
    If one so desires this ability or needs it then JDNC markup language allows it. One could use something like swixml too.

    In my experience most UI dev is done by a developer not a UI person. Or a UI person tries to do both. Seems to be a lose-lose.
  92. XUL hummm...[ Go to top ]

    I like Amy Fowler's general rationale in JDNC Overview (can't get the article URL to work correctly in this post - guess the interfaces isn't rich enough ;-) though I wonder about the intentional limiting of the markup language. It will be interesting to see how this technolgy evolves as it move towards version 1.0 status.

    I share your (bad) experiences with developers or worse UI people doing both UI and code, which is why I say there needs to be a better seperation. The fact that JDNC has a delcarative markup capability says that we're really looking at the need for a middle ground technology.

    Scott Cranton
    Nexaweb Technologies
  93. XUL hummm...[ Go to top ]

    I like Amy Fowler's general rationale in JDNC Overview (can't get the article URL to work correctly in this post - guess the interfaces isn't rich enough ;-) though I wonder about the intentional limiting of the markup language. It will be interesting to see how this technolgy evolves as it move towards version 1.0 status.I share your (bad) experiences with developers or worse UI people doing both UI and code, which is why I say there needs to be a better seperation. The fact that JDNC has a delcarative markup capability says that we're really looking at the need for a middle ground technology.Scott CrantonNexaweb Technologies
    Just as long as the separation isn't required. :)
  94. XUL hummm...[ Go to top ]

    Just as long as the separation isn't required. :)
    Fair point. I meant a logicial seperation that would allow (though not require) two individuals (or one with multiple personalities) to perform their respective tasks.

    Scott Cranton
    Nexaweb Technologies
  95. Could you point me to a chart component implementation in XUL? Not that XWindow
    > itself has a charting component, but other than XUL/HTML technologies allow easy
    > creation of such component(s)…

      Allow me to highlight the Luxor Bar Chart XUL Tag Tutorial titled "Create Your Own XUL Tags" online @ http://petra.sourceforge.net/tutorial.html

      Note, that Luxor also allows you to turn applets into XUL tags that you can use along with all built-in XUL tags without writing any Java glue code. Reuse your applets today in your very own apps without calling in any browser machinery. How's that for a start? See http://petra.sourceforge.net/applet.html

       - Gerald

    -------------
    Gerald Bauer
    The Richmond Post | http://xul.sourceforge.net/post
  96. Allow me to highlight the Luxor Bar Chart XUL Tag Tutorial titled "Create Your Own XUL Tags" online @ http://petra.sourceforge.net/tutorial.html
    LOL: that is HTML grade charting that works fine for ages, see for example pure HTML charting in awstat http://awstats.sourceforge.net/ .
     Note, that Luxor also allows you to turn applets into XUL tags that you can use along with all built-in XUL tags without writing any Java glue code. Reuse your applets today in your very own apps without calling in any browser machinery.
    More interesting, but I would rather reuse applets in the browser with Java Web Start... or plug them into a Swing application....
    btw. Swing UI could easily be scripted/skinned with Jelly( for XML addicts), or Jython, or bsh, etc....
  97. Reusable Swing Components[ Go to top ]

    More interesting, but I would rather reuse applets in the browser with Java Web Start... or plug them into a Swing application....btw. Swing UI could easily be scripted/skinned with Jelly( for XML addicts), or Jython, or bsh, etc....
    You cannot write a reusable swing component that works the same in an applet or a Frame because you cannot create a modal child dialog in an applet. You cannot access the system clipboard in an applet. You cannot.... in an applet.

    Galaxy always was better, check it out! Springs&Struts layout means you never code GridBag again. UI components are resources.

    http://jutland.kgbinternet.com/

    Mark Nutall, would you do me the favor of checking out my stuff. I respect your web presence.
  98. Reusable Swing Components[ Go to top ]

    More interesting, but I would rather reuse applets in the browser with Java Web Start... or plug them into a Swing application....btw. Swing UI could easily be scripted/skinned with Jelly( for XML addicts), or Jython, or bsh, etc....
    You cannot write a reusable swing component that works the same in an applet or a Frame because you cannot create a modal child dialog in an applet. You cannot access the system clipboard in an applet. You cannot.... in an applet.Galaxy always was better, check it out! Springs&Struts layout means you never code GridBag again. UI components are resources.http://jutland.kgbinternet.com/Mark Nutall, would you do me the favor of checking out my stuff. I respect your web presence.
    Did a quick read through. Looks pretty good. What is the license?
  99. Reusable Swing Components[ Go to top ]

    I'm ready to go open with it. Sun SHOULD HAVE CONSIDERED PRIOR ART!

    garykeim@pacbell.net
  100. RIU - Isn't it great: competition[ Go to top ]

    Is it not great that the rich Java UI's are now being considered? Only took 6 years. Write once, test... ;^)
  101. Luxor Bar Chart XUL Tag Tutorial titled "Create Your Own XUL Tags" online @ http://petra.sourceforge.net/tutorial.html
    I guess http://bigcharts.marketwatch.com/ is very good site to compare RIA with HTML(XUL?) based applications, just try to use interactive charting ( which is HTML, and I suspect that XUL based solution will be almost equal ) and then do same things with Java charting Applet... See and feel the difference
  102. XUL hummm...[ Go to top ]

    For example, Nexaweb has a chart component that is specified (layout) in the UI markup as <chart/>, with the event handling logic (and needed debugging) done in Java.
    Seems like iFrame could be a good replacement for this and many other cases if it was supported better and was more aware of its content ( if it allowed specifying its size depending on its content also).
    Such extended iFrame in conjunction with server wide single-sign-on might render portlet technology obsolete or at least provide good alternative …
    It could be used even today ….
  103. hummm[ Go to top ]

    i don't think you should join discussion when you don't know enough about the problem space. With flash you can use either remoting or the newer flex to create application without resorting to the traditional, design-driven flash sites.

    I think that flash, like applets, is an good technology, but they are both suffering from reputations of their previous versions. Anyone who is seriously considering a rich client *must* consider these technolgies, even if only for the sake of comparison.
  104. Flash + XUL[ Go to top ]

    If you're curious about a free Flash+XUL alternative, have a look here: http://zulu.netspedition.com

    Cheers,
    Ovi
  105. Flash + XUL[ Go to top ]

    If you're curious about a free Flash+XUL alternative, have a look here: http://zulu.netspedition.comCheers,Ovi
    Unscalable == Unusable. Period.
    I think health care insurers should sue makers of unscalable interfaces for intentionaly harming user eyes.
    And glass and contact lenses makers should sponsor them.
  106. Flash + XUL[ Go to top ]

    Unscalable == Unusable. Period.
    Right click, Zoom In is a crude solution. The product will evolve and I'm sure a refined alternative will be provided since the platform has this capability built-in.
  107. Aaah, but the browser and HTML is not going to go away. There is little or no chance for something else to come and 'replace' the web no matter how legacy the HTML stuff is. Sure, there might be a couple of richer web apps out there in the coming years, but by large it is only going to be a barely visible blib on the radar, if even that. If you really need a richer GUI, you can go with the way of good ol' desktop app and embed some good ol' web stuff into it - there are many examples of doing this successfully.
  108. Aaah, but the browser and HTML is not going to go away. There is little or no chance for something else to come and 'replace' the web no matter how legacy the HTML stuff is. Sure, there might be a couple of richer web apps out there in the coming years, but by large it is only going to be a barely visible blib on the radar, if even that. If you really need a richer GUI, you can go with the way of good ol' desktop app and embed some good ol' web stuff into it - there are many examples of doing this successfully.
    The hypertext technology would not go away. But the HTML as an implementation of this technology, would change. Convergence between local desktop and remote resources seems like a logical step to "The Net is a computer" idea.

    MS has now about 90% of the browser market and how much? 70-80% of OS base. They have not updated MSIE much since 5.0. Why? I am sure they are cooking something. I am pretty sure that new Windows which will come with XAML/Avalon, will have massively upgraged MSIE, integrated with the desktop even tighter than it is now. And I am sure that MS already have ideas of how to update HTML standard, so it can be seamlessly integrated into their new presentation system. Considering their market share, they can do HTML overhauling in a year.
  109. . And I am sure that MS already have ideas of how to update HTML standard, so it can be seamlessly integrated into their new presentation system. Considering their market share, they can do HTML overhauling in a year.
    I even think they would do it in such a way that it is a "requirement" to use their platform to develop any thing more than basic web pages to be viewed on their platform.

    It kills me, in more than one way, to see "apps" developed with non-Microsoft technologies but only target IE.
  110. MICROSOFT WILL DECIDE[ Go to top ]

    WHEN MICROSOFT LAUNCHES LONGHORN AND THE ALTERNATIVE TO THE OLD BROWSERS AND HTML WITH JAVASCRIPT,RIA WILL BE HERE, THEY ARE THE ONLY WHO CAN CHANGE THE LANDSCAPE IN LESS THAN A YEAR,AND THEY ARE PLANNING TO DO IT ON A MASSIVE SCALE, AS SOMEONE POINTED HERE. TAPESTRY,JSF,WEBSTART,XUL,PIM,PAM,PUM..WILL SIMPLY VANISH.
    BUT IN THE MEANTIME, WE ALL MAY TALK, WE WON'T DECIDE.
    YOUR WELCOME
  111. MICROSOFT WILL DECIDE[ Go to top ]

    http://news.netcraft.com/archives/web_server_survey.html
    Above tells you how important MS is relative to open standards in production and in market share, so feel free to develop for a smaller and shrinking poool.

    MS continues to be a player in deparmental solutions by corparate developer, but when you site grows , licensing costs can go 6 or 7 digits, so people just port to open standards like (LAMP or) Postgresql, Tomcat, JDNC and Burlap for example, to save on profit margin and improve security.

    JDNC has a chance to steal the desktop from MS(not like anyone is awake at Sun). VB does not have a network laucher technology, AFAIK, and XAML samples are toys compared to JDNC samples, so I would use JDNC for heavy lifting and large apps. Like what is the use case where the answer is: we should use VB?

    Gov. issued a warning not to use IE and most banks ban IIS, both due to security.

    .V
  112. MICROSOFT WILL DECIDE[ Go to top ]

    http://news.netcraft.com/archives/web_server_survey.htmlAbove tells you how important MS is relative to open standards in production and in market share, so feel free to develop for a smaller and shrinking poool.MS continues to be a player in deparmental solutions by corparate developer, but when you site grows , licensing costs can go 6 or 7 digits, so people just port to open standards like (LAMP or) Postgresql, Tomcat, JDNC and Burlap for example, to save on profit margin and improve security. JDNC has a chance to steal the desktop from MS(not like anyone is awake at Sun). VB does not have a network laucher technology, AFAIK, and XAML samples are toys compared to JDNC samples, so I would use JDNC for heavy lifting and large apps. Like what is the use case where the answer is: we should use VB?Gov. issued a warning not to use IE and most banks ban IIS, both due to security..V
    we are talking different things
  113. http://news.netcraft.com/archives/web_server_survey.html ("that Apache has 70% market share!" :)

    Vic: "Above tells you how important MS is relative to open standards in production and in market share, so feel free to develop for a smaller and shrinking pool."

    Above stat include users that share computers, for example 500 per computer with separate IP addresses - has absolutely no relevance to what we are doing here in TSS. If we count only companies that have their own server computers, in Enterprise systems; IIS is 4 or 5 times as common as Apache.

    The only thing the Java world/Open Source can do is to hope that RiA never will be a major factor, because if it will be Longhorn/XAML/Avalon will take first, second and third place.

    Regards
    Rolf Tollerud
  114. Apache 70% market share[ Go to top ]

    Longhorn/XAML/Avalon will take first, second and third place
    Show me a XAML example app. url that you think is superior in some way to JDNC examples linked in the article.

    Place you bets, place your bets.
    I place my chips behind JDNC.

    .V
  115. Apache 70% market share[ Go to top ]

    Longhorn/XAML/Avalon will take first, second and third place
    Show me a XAML example app. url that you think is superior in some way to JDNC examples linked in the article.Place you bets, place your bets.I place my chips behind JDNC..V
    It is a crap shoot. One can't depend on everyone being sensible. One would think everyone would want freedom. Or at least the most freedom one can get. (I'm not just refering to technical matters)
  116. the drama unfolds, why not enjoy[ Go to top ]

    Vic: "Place you bets, place your bets"

    There is an old curse from China that goes like this: "May you live in interesting times" The meaning is that it is better to live in un-interesting times (quite and peaceful and so on). I do prefer to live in interesting times anyhow, and you must admit that it have never been more action and fascinating times than now.

    "MS against the rest of the world"

    Regards
    Rolf Tollerud
  117. the drama unfolds, why not enjoy[ Go to top ]

    Rolf,
    this is a xaml example I found.
    http://www.joemarini.com/tutorials/tutorialpages/xamlblogexplorer.php
    Can this be compared to the JDNC links I have in the article?

    Anyway, I think cost of security and downtime will fail and open standards and competition will win. Coming in 2nd is just the 1st looser.

    For sure: A year from now, there will be demand for people that have at least 1 year of RiA experience, so pick a horse for you carer.

    .V
  118. the drama unfolds, why not enjoy[ Go to top ]

    Vic,
    You are confusing two things IMO.

    1) How to make your application
    2) How to deploy

    About 1)
    Everyone agrees that we will soon develop with the help of some kind of declarative markup, call it XUL or XAML or whatever. While this is nice it is not any revolution direct, only something that make life a little easier for us developers. I don't think MS XAML will stand back for any other variant; on the contrary it will probably set the standard.

    About 2)
    MS has their own technique comparable to Java Desktop/Net Launcher, it is called ClickOnce. I do not believe that a good Java Desktop Net Launcher is included in the latest Java 1.5 is it? ClickOnce is included in next version of .NET Framework 2.0.

    Any kind of .NET application can be distributed via ClickOnce (except that you can not write to registry or access files etc). Aside from that, the app does not have to be "ClickOnce" aware.
    So when you say "Can this be compared to the JDNC links I have in the article" it only means that you have not found any nice enough application yet. (An embedded browser will probably be common in future RiA applications).

    So how will Longhorn be better that Linux?

    1)Avalon has a richer, more comprehensive and consistent API (cost more than a trip to the Moon according to BG)
    2)XAML + "SVG functionality" will be directly tied and optimized to Avalon.
    3).NET Framework 2.0 (with ClickOnce) integrated and available by default.

    On Linux gtk and qt will be far behind Avalon not to speak about Linux XUL/XAML that is split into more than 20 different and íncompatible versions, all made by the kitchen-bench (=Open Source that always lack this little touch that is called "finishing the product").

    Regards
    Rolf Tollerud
  119. the drama unfolds, why not enjoy[ Go to top ]

    With Longhorn delayed, Flash/Flex and other rich app technologies now have a better future. MS made a present to Macromedia...
  120. the drama unfolds, why not enjoy[ Go to top ]

    "MS against the rest of the world"
    I'm glad you finally understand that it's not "the rest of the world against MS."

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  121. it is all the same[ Go to top ]

    "MS against the rest of the world" or, "The rest of the world against MS"

    amounts to the same thing Cameron, namely:

    "The gifted individual against the unwashed stupid masses".

    Regards
    Rolf Tollerud
  122. it is all the same[ Go to top ]

    "MS against the rest of the world" or, "The rest of the world against MS"amounts to the same thing Cameron, namely:"The gifted individual against the unwashed stupid masses".RegardsRolf Tollerud
    They seem to attend "Midvale School for the Gifted". :)
  123. Do you think Cameron attended?
  124. Definitely not. It refers to you refering to MS as the "gifted individual". In their case - yes they should.
  125. Midvale School for the Gifted ...[ Go to top ]

    I tried to find the Far Side comic online. One of my favorites.
  126. Midvale School for the Gifted ...[ Go to top ]

    Is this the one you were refering to?

    http://www.dennisglass.com/Graphics/Jpegs/gifted45.jpg
  127. Midvale School for the Gifted ...[ Go to top ]

    Yes. Thanks!
  128. Above stat include users that share computers, for example 500 per computer with separate IP addresses - has absolutely no relevance to what we are doing here in TSS. If we count only companies that have their own server computers, in Enterprise systems; IIS is 4 or 5 times as common as Apache. The only thing the Java world/Open Source can do is to hope that RiA never will be a major factor, because if it will be Longhorn/XAML/Avalon will take first, second and third place.RegardsRolf Tollerud
    The point you miss though is that companies who host 500 sites per physical box are choosing Apache to do it. The fact that they don't have 500 physical machines per site doesn't invalid the statics they are gathering . The statics are accurate in terms of what they are measuring which is what web server is being used per IP address, not how many physical boxes are running non-virtual homed Apache, IIS, etc. instances.

    I also have no idea how you can measure whether the systems behind the web server are considered "Enterprise" or not. Care to post where you aquired the knowledge that IIS is 4 to 5 times as common as Apache?

    You can try to spin this all you want, but at the end of the day, Apache still is spanking IIS in the number of websites that leverage it for pushing content.
  129. RIA Builder[ Go to top ]

    What would you say about this one...
    www.iabstudio.com; you can get it for free from www.worcsnet.com
  130. MICROSOFT WILL DECIDE[ Go to top ]

    WHEN MICROSOFT LAUNCHES LONGHORN AND THE ALTERNATIVE TO THE OLD BROWSERS AND HTML WITH JAVASCRIPT,RIA WILL BE HERE, THEY ARE THE ONLY WHO CAN CHANGE THE LANDSCAPE..
    Yeah, if that were true we'd all be writing apps for the MSN ("blackbird") platform.

    All your rich clients are belong to us.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  131. I think one of the arguments against Swing development is complexity. At least this is what I hear. Building HTML applications is simple compared to building a complete application in Swing. If you are an experienced Swing developer, you love it, if you need to get started, you most likely hate it.

    Building J2EE applications with a HTML interface is simple, as far as the layout is concerned, because the options aren't that many: TableLayouts.

    In addition to this, applications, like those for content and information browsing, as mentioned in some of the replies, don't need to be build with Swing. HTML definitively does a far better job here.

    There is a need for desktop integrated applications, which is what Swing applications are good at and that HTML technologies have still a way to go for.

    I am happy to see that eventually something happens around Swing as it looked like a forgotten world. JDNC definitively is a good thing.

    Frank
  132. I think one of the arguments against Swing development is complexity. At least this is what I hear. Building HTML applications is simple compared to building a complete application in Swing. If you are an experienced Swing developer, you love it, if you need to get started, you most likely hate it.
    Coding in HTML is simple if your needs are simple. As the application becomes more complex, then complexity to build and maintain in HTML is not linear.
  133. Just to let you know that I kicked off a JDNC mailinglist a couple of weeks ago. I invite you to join the discussion and ask questions or share tips and tricks about Sun's new Java Desktop Network Components project/initiative.

    More @ http://groups.yahoo.com/group/jdnc

    - Gerald

    PS: I've also kicked off a Web Start mailinglist a while ago. See http://groups.yahoo.com/group/webstart for details.

    -------------
    Gerald Bauer
    The Thinlet World | http://thinlet.blog-city.com
  134. Part 2:[ Go to top ]

    in Dallas on 10/13:
    http://www.javamug.org/mainpages/2004Meetings.html#Oct

    .V
  135. Part 2:[ Go to top ]

    and http://www.sandrasf.com/training

    .V