Small suggestion: servlets will allow you to create a version of you application that can be run through a browser. In other words if you set up your servlets right you can have a prototype or an early access versions of features to test out before you actually implement them in Swing.
You see what I'm saying? You could go even different route and embed HTML browser in your swing application that gets downloaded to client. You could use this HTML browser to test out functionality or get feedback from people to see if they like a feature or not and then incoroprate it in Swing. This is all without knowing what your application does. d. Grace S. Aguilar wrote: > HI again! > > Thanks for all the reply. I have another question though. When it comes to > multi-threading, which is more adviseable to use with a Swing-based > applet/application front-end --- Servlets or RMI? Because in this system I'm > designing, it will be requiring disk-less PC's as client - meaning all > application (including the browser) will be be downloaded from a server. Now > I'm wondering, if I'd be using Servlets that would require the browser to be > downloaded followed by the loading of the applet. On the other hand, if I > opt to use RMI, I could be able to run the application with (using Java Web > Start) or w/out the browser. However, I read in one article that it takes > long time to perform remote method calls. > > Any input would be very much appreciated. > > Thanks in advance. > > -----Original Message----- > From: A mailing list for discussion about Sun Microsystem's Java Servlet > API Technology. [mailto:[EMAIL PROTECTED]]On Behalf Of David > Mossakowski > Sent: Friday, June 07, 2002 7:19 AM > To: [EMAIL PROTECTED] > Subject: Re: Servlets + Swing > > > Well, I don't see HTTP going away either but there is a need to use it > effectively. Ceating HTTP query strings with name=value pairs and then > parsing results based on agreement that a pipe is used to delimit values > is not sufficient. HTML returned is fine for web browser based > applications but there's more that can and should be done. Soap tries > to solve a big problem and the direction seems correct especially when > using servlets. I couldn't think of a better match. Servlets are > designed to carry out tasks and return results which can be fitted into > different formats. Getting XML formatted responses seems pretty cool to me. > > d. > > Galbreath, Mark wrote: > >>Five years ago CORBA was supposed to be the panacea for x-platform network >>data transfer; 3 years ago it was RMI; 2 years ago it was XML; and for the >>past year all we've been hearing about is SOAP. XML has become the >>configuration file standard, but as for data transport over the Net? HTTP >>is alive and well and I don't see that changing much very soon. I believe >>this is a perfect example of Alan Cooper's observation in "The Inmates are >>Running the Asylum" whereby developers are using technologies because >>they're "cool," and not because they are appropriate. I adhere to the > > KISS > >>principle. >> >>Mark >> >>-----Original Message----- >>From: ^BoyInterrupted^ [mailto:[EMAIL PROTECTED]] >>Sent: Thursday, June 06, 2002 4:41 AM >>To: [EMAIL PROTECTED] >>Subject: Re: Servlets + Swing >> >> >> >> >>>Or, if you're a glutton for over-complexified (but buzzword >>>compliant) punishment: SOAP. (google for it). Both SOAP and >>>XML-RPC have implementations that work through servlets. >> >> >>It's simply how you predict the applicability of your solution. If you > > feel > >>that your application has the capability to grow to something really big , >>traversing different implementations, SOAP would be THE way to go. >> >> > > ___________________________________________________________________________ > >>To unsubscribe, send email to [EMAIL PROTECTED] and include in the > > body > >>of the message "signoff SERVLET-INTEREST". >> >>Archives: http://archives.java.sun.com/archives/servlet-interest.html >>Resources: http://java.sun.com/products/servlet/external-resources.html >>LISTSERV Help: http://www.lsoft.com/manuals/user/user.html >> >> > > ___________________________________________________________________________ > >>To unsubscribe, send email to [EMAIL PROTECTED] and include in the > > body > >>of the message "signoff SERVLET-INTEREST". >> >>Archives: http://archives.java.sun.com/archives/servlet-interest.html >>Resources: http://java.sun.com/products/servlet/external-resources.html >>LISTSERV Help: http://www.lsoft.com/manuals/user/user.html >> >> >> > > > > -- > David Mossakowski [EMAIL PROTECTED] > Instinet Corporation 212.310.7275 > > ___________________________________________________________________________ > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff SERVLET-INTEREST". > > Archives: http://archives.java.sun.com/archives/servlet-interest.html > Resources: http://java.sun.com/products/servlet/external-resources.html > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html > > ___________________________________________________________________________ > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body > of the message "signoff SERVLET-INTEREST". > > Archives: http://archives.java.sun.com/archives/servlet-interest.html > Resources: http://java.sun.com/products/servlet/external-resources.html > LISTSERV Help: http://www.lsoft.com/manuals/user/user.html > > > -- David Mossakowski [EMAIL PROTECTED] Instinet Corporation 212.310.7275 ___________________________________________________________________________ To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff SERVLET-INTEREST". Archives: http://archives.java.sun.com/archives/servlet-interest.html Resources: http://java.sun.com/products/servlet/external-resources.html LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
