Thanks, Anton. Below is a project description and research materials. The main usage is autoreplies and address harvesting. I guess, recruiters can use it a lot. It is not an inter-organizational thing. Since your IOS requires installation, it is not the thing to deliver the product to any machine on the web. For instance, our paid customer can not use it this way from the library, Internet Cafe or friend's house because owners of those machines won't allow them to install your thing, and I guess it is pretty technical task. But still there is a possibility to use it in a stand-alone version? I will appreciate if you let me realize the options by discussing the issue.
-------------------- If you use Rebol IOS you probably won't need to use email again, internally, at least! :) Communication is more efficiently served by the Messenger and Conference reblets and the transparent file sharing mechanism. But - What will your application do? Can you give some more details? =================== Addition to MyMailloop Spec 1. Description Under review is mail flow management system that is an upgrade of existing Mailloop5.0 Windows stand-alone application. Now it will become ASP or thin client version. Most of the processing moves to server component. The client part is hopefully to be implemented in 2 kinds - stand-alone (initially thought - Java1.1) and some web version (initially thought - applet). In this initial intention applet and 1.1stand-alone version must have some common code base. The server component is to be written in C++ by Rick and Paul in parallel to Java client team that is not yet hired. Apparently, stand-alone Java client is also not a final decision. For instance, Paul votes for native code stand-alone client, because he has experience in C++ GUI (so he can do both client and server parts). The final decision may depend on who will be hired for a client team. It can also change during development. For instance, some semi-functional prototype may be developed as initially intended and then reconsidered. 5. Client Part Design 5.1. W.X.'s note If user can build socket connections with your server, applet can use the connection to do Object or binary communication. If use is behind a firewall, they normally can not build socket connections with servers outside the firewall, so applet can check this, and use Servlet to transfer information with your server. 5.2. J.S.'s note I use the new IE, and there is no problems with supporting the Java 1.1.8, or AWT, code. The only thing is that the Java 2 runtime is not included with the browser and has to be downloaded and installed, and requires the user to grant permissions to the Sun codebase, similar to Java Webstart. I think deploying an application with Java WebStart is a secure way to build and deploy an application of this nature. Again, the problem with useful applets is that it is very hard to control who has access to them. For an example, see a homepage that I am currently working on... forgive the incompleteness, it is a work in progress, but the applets that are embedded into the page are from two different financial sources. The example here: http://24.82.118.183/futures/indexjava.html. The "Launch Chart" button at the bottom of the page opens up an applet which I "borrowed" from a financial brokerage where I have an account. This codebase is not available to the general public, but once you become a user you have access to the pages in which this code resides. JavaWebStart is not something that I have used in a production situation. I have installed and tested the applications that come with the installer package, and it works quite well. It is a good option to consider at this conception stage. More on Java Web Start here: http://java.sun.com/products/javawebstart/. I imagine that you have been hearing a lot of opinions regarding the applet development issue, and whether to use Flash or LiveConnect or something else, so I will keep my opinion brief and to the point. First, an excerpt from this page: http://developer.apple.com/internet/javascript/iframe.html ... Now, an sample of this iframe remote scripting: http://24.82.118.183/futures/index.html. In this sample, a servlet is called by the html form without submitting the page or reloading the browser. The servlet calls for a page from the internet, parses out the chart's image tag from the response, and passes the image tag back to the browser. The browser uses the document object model (DHTML) to switch the image's src reference to the remote internet host. I thought this was really neat solution for an internet application. Whatever you decide, I would be interested in working with you on it. Please feel free to contact me by email. More about the IFRAME: The IFRAME was introduced by Microsoft in Version 3 of Internet Explorer and gained acceptance as part of the HTML 4 specification from W3C. Netscape was slow to adopt this tag, but it is possible to work around this limitation with ILAYER, which is specific to Netscape 4. There is a compatibility chart here: http://developer.netscape.com/evangelism/docs/technotes/xref/html-element/ With the use of IFRAME and ILAYER, it is possible to build something that resembles a socket connection between the HTML page and the server. Data can be passed to the server and received back from the server without navigating away from the client interface that the IFRAME is embedded in. The protocol is http, and JSP / Servlets or any other script language can be used on the server side, depending on your implementation. In this model, all the data is passes into the appropriate Javascript functions, which creates element objects from the data, and dynamically places them within the page. The Document Object Model (DOM) allows access to any named element of the HTML page, including tables, forms, text, and images. This combination of the DOM and IFRAME technologies allows the web application to leverage the power of server-side scripting, while maintaining layout and design control. Other Possibilities: I am not sure if firewalls would affect socket connections. Any of the solutions that depend on them could be vulnerable to difficulties connecting. This includes Flash, Applets, and ActiveX controls. I also have had problems with applets embedded in JSP�s. Working out a request / response model is important with one team working on the client and one team working on the server. XML is the best way to send information to both the html app and the stand-alone app. In the http app the XML objects would be built in memory and queried using Javascript, and in the stand-alone app the XML object would be built and queried using java. The server would send the out the same XML regardless of which client asked for it. As an added benefit, using XML as the data structure could allow other clients to be written for cell phones and palm pilots, which could then format the data according to the device capabilities. 5.3. A.F.'s note I see Flash as the only good solution to their problem. any other method has too many flaws to be considered except for maybe JSP/HTML. For communication I would suggest SOAP/XML versus TCP because of the ease of implementation and extendibility. 5.4. J.N.'s note My main concern with applets is their "clunky" nature. They use an older version of Java, so any bugs will have to have workarounds. Second, they are not guaranteed to be supported in all browsers. IE will not support Java, so a separate plugin will have to be downloaded before the applet becomes useable. Microsoft has made it very clear that they will not support Java. Using something like Java Web Start is still a long download for anyone using a modem. Java won't handle HTML very nicely, so it would make sense to have the browser handle the rendering of HTML. Applets won't work well in this situation. A Java server app, serving HTML would be a better solution in this case. TCP connections are a problem with applets if the applet is connecting to another server (ie mail server). Then signed applets come into the picture. Since there are different permissions for Netscape and IE, the signing procedure becomes a headache. To get around signing applets, the use of servlets to communicate to other servers can be done. But this uses HTTP connections, which was mentioned as something not to be used. Firewalls are a problem as well, but this would need servlets again to communicate with other servers using HTTP. Because of the three cases above (TCP connections, HTML mail, firewalls), using a Java server app to serve HTML seems to be a better fit in this case. This would not have a shared codebase with a stand alone client though. 5.5. H.L.'s note I would suggest to use a servet to act as a bridge between browser and server program, that is a solution that use HttpURLConnection to communicate with a servlet, which staying in the server side, and have full access to server environment and resource. Because we only use HTTP protocol instead of directly opening a network connection to server using raw socket interface, firewall will not become a issue. In order to keep the applet code as smaller as possible. I don't encourage to use any other plug-in product because we need to keep Applet code as smaller as possible. How to share code with standalone application is not that critical issue, it can be done with good design. 5.6. M.O.'s note Support for Java and Java Plug-in. Because of anti-trust issues Microsoft has dropped default support of java in its newest Windows XP operating system. As the result Internet Explorer 6.0, bundled with Windows XP comes without Java Virtual Machine. The Microsoft JVM can be downloaded free of charge from the Microsoft site: http://www.microsoft.com/java/vm/dl_vm40.htm. Alternatively users can easily download and install the standard Java Plug-in from Sun, considered by many one of the best things that happened to browser-based Java: http://java.sun.com/getjava/download.html and use it either with Internet Explorer or Netscape Navigator. The installation process is pretty straightforward. Once the JRE is installed, your applet gets downloaded and cached, and then opening an HTML page with your applet is instantaneous, since everything is loaded from the client's disk. Using the common Java Plug-in from Sun has obvious advantages versus relying on a browser built-in JVM: all the users are using the same (newer, faster and better) JVM built with the same code base as JDK (currently 1.3_01, but I believe 1.4 is on its way) and by the same vendor (Sun Microsystems) regardless of the operating system and browser used. That results in application features unification and is the approach used heavily by Acterna for most of its products. Those who tried using applets in the early days of Java remember hours wasted fighting with the differences among browsers, applet download time, performance, and other problems. From my point of view using Java Plug-in clearly outweighs all additional efforts required to install the plug-in on the user�s machine, which BTW should be done only once. Moreover, considering Microsoft�s own JVM stopped at 1.1 and does not catch-up with newer versions of JDK/JRE, anyone who desires to use serious client-side Java software, for instance a product with a Swing GUI, which needless to say has numerous advantages over AWT, installs the Sun JRE plug-in anyway. Once that is installed, Java can do everything on a Windows XP system it can do on other systems. Socket Connections through Firewall. The actual communication from the client application/applet to the server application require a TCP socket, and given the issue of a client potentially located behind a firewall, we have to consider some architectural issues here. An applet is very restrictive in its use of sockets. As we know an unsigned applet is allowed to connect back to the same host it came from, and it works most of the time, except when the client applet is running behind a restrictive firewall. In some cases a fixed port can be nailed down and the problem can be solved by opening a specific port in the firewall, allowing socket connections on it, and then use that port in the client and server code. If the first approach did not work for some reason (because a free port number is assigned from the heap, the organization has the policy of keeping the ports blocked or the firewall used only accepts certain well known protocols like HTTP), you should use the java.net.HttpURLConnection class to connect to a URL that points to a Java Servlet, serving as an intermediary between client and server, using HTTP protocol. Then, the servlet opens a socket to the server and waits for the response from server. After the servlet gets the response, it sends result back to the client applet, containing the data you need to get back to the applet. The downside is that the connection can be slower than TCP, resulting in possible perceived deteriorated applet performance by the end user. Applet vs. Web Application Choosing between AWT/Swing and HTML-based GUI requires special design considerations. Each of the approaches has its pros and cons. The strongest argument choosing HTML is its wide acceptance on any platform, we don�t have to worry about client�s hardware, operating system and browser because when Java Servlets and JSPs are used to deliver HTML contents all the processing is done on the server (except client side JavaScript for on screen validations, on screen updates, etc.), and given the simplicity of HTTP/HTTPS protocols, we are also guaranteed to enjoy the predictability of programming for various network configurations and firewalls. But there is a high price to pay for an HTML-based client, considering the lack of user interaction and the necessity of making network trips to the server for every response to a user action. Although thin clients offer ways for great presentation of many noninteractive user interfaces, traditional fat clients certainly surpass them in intelligence. For example nobody can argue that email client applications are much more user friendly than Web-based email portals. To summarize, an HTML front end using servlets and JSPs is a great way to develop static content. However, this thin client doesn't score very high when you need quick responses to the users' actions and sophisticated logic that manipulates data quickly. The compromise to use Java applets in your web application sparingly and do so only when absolutely beneficial in combination with on screen HTML and DHTML yields the best all round result. However, if the requirement is to develop an application capable to run as a stand alone and in the browser leads to having a substantially different code base for the stand alone and web applications, with different look and feel, which might not be acceptable. Java applets and DHTML are not the only way to spice up the client content. There are many 3rd party technology plugins available. Some that come to mind are Shockwave Flash, Real Media, and Cosmo Player although there are many more. However using those can not be considered as the standard option and should be used only if there is a compelling reason to do so. Each front-end technology has its benefits and disadvantages when it comes to the interface to your Java applications. None of them is superior to others in all aspects. For each specific application, we must perform an evaluation of these technologies with analysis of requirements and user expectations. Here are the basic rules of thumb: Use HTML/JSP: - For relatively static content enriched by graphics and professional art - If your interface needs to work for all user types running different software - If users access your application from slow networks - If you want to quickly build an unsophisticated application Use Swing applet: - For highly interactive GUIs with built-in, interface-related logic - To reduce network traffic and provide immediate response when possible - If users have high expectations for the quality and functionality of the interface - If UI functionality is more important than aesthetics Another emerging way of deploying Java applications is by using Sun's Java Web Start. Traditional stand alone applications also have a number of problems. In particular, applications are often complicated to install, and even worse to upgrade. Java Web Start technology enables you to launch full-featured applications via any browser, on any platform, from anywhere on the Web, in a secure fashion. It provides the best of both worlds: the ease of deployment and use of HTML, as well as the power and flexibility of a full-fledged application. So from my point of view using Java Web Start should be seriously considered when the application client should be deployed to a large number of users and the upgrades must be delivered to them in a timely fashion. For more on Java Web Start see: http://java.sun.com/products/javawebstart Swing-HTML Bridge Although HTML front ends and Swing clients have their advantages and disadvantages, it is clear that the ideal solution would support both. However, because these technologies are very different in nature, only one can be typically implemented in a finished application. Even though the majority of users may prefer a fast interactive client based on Swing, downloading and installing JRE on the client's machine is not always an option. Sometimes security and firewall restrictions make it difficult to run RMI over the network. In that case, what we need is an interactive client that can run on any system, even if the only client software we can count on is the Web browser. CreamTec's WebCream -- the third deployment option -- acts as that Swing-HTML bridge. WebCream is a Java tool that provides automated Web-enabling for GUI-basedJava applications and applets. It lets you implement a GUI front end using AWT and Swing, and at the same time automatically get HTML access to the application. In a way, WebCream can be thought of as a dynamic Java-to-HTML converter that converts Java frames and dialogs to HTML on the fly. It then emulates Webpage actions as GUI events to retain the application's original logic. WebCream requires no modifications to existing forms and business logic, and does not require that you learn any new APIs. It is designed to publish existing applications and applets; it's just a matter of setting up your Web server and a property file describing the application. WebCream handles the rest. The standard edition is fully functional and available for free. WebCream does not require any installation on the client machine; in fact, it doesn't need the browser to support Java because all the browser sees is HTML. While this Swing-HTML bridge may not work for all clients, WebCream can certainly add value to Swing-based front ends by allowing access to the front end via HTML. Some 95 percent of applications typically convert to HTML seamlessly, and for the remaining 5 percent you may have to change how the data is presented or handled. For complete information on WebCream see: http://www.creamtec.com/webcream. WebCream is, to put it in just a few words, a tool, which helps to convert a Swing applet into a web application. The idea is the developer develops Swing application/applet, using a common code base, which is I understand a preferred solution for your project, and then has a possibility to convert an applet solution into a web application should a need to do so arises. In other words it puts off the decision to choose between Java and HTML later in the project lifecycle when the requirements are firmed up. Personally I haven't used WebCream, but the user interface after the conversion may look very similar to the Swing one and some Java gurus from Sun highly recommend it. 5.7. A.D.'s note I propose to use Java 1.1 applets. If AWT components will be not enough, then custom lightweight components can be used. It will allow avoiding download any kind of plug-ins or additional libraries. For Windows XP users it will require to download only the Java Virtual Machine from MS site - they have to do this anyway if they want Java on their machines. To overcome firewalls use HTTP connection instead of sockets. Applets can be complement with HTML based interfaces - where it is needed (the rather servlets and JSP are planned to use anyway). Examples of applets with lightweight components (some of my works): Bingo applet for DION Corp. (http://www.bingoleague.com/ - choose Enter Game, login: andrei, password: java, then push "I agree" button) - there is no one standard AWT component at all - all are lightweight. Interactive check for CuroCheck Corp. (http://www.curocorp.com/sites/curocorp/new_merchant/check/index.html) - it is mix of lightweight and standard AWT components. 5.8. A.P.'s note If you target general public who have all kinds of platforms, operating systems, and browsers, the portability is the most important thing. Java applets can be one of the considerations but I have hardly heard of any applet as a commercial program. Let me tell you a story about two companies who provided medical information in real-time with different technologies. They had the same information in their servers but delivered them to their clients differently: One used Java technologies, and the other Microsoft technologies, mainly VB and XML. The latter told me that they won in this competition because Java was too slow. So even though Java has portability, you have to consider performance or speed with which customers can get easily angry. Therefore, if you prefer Java technologies, I think you'd better implement a stand-alone application that connects to your server via internet. There can be many issues in the internet connection. But since the application is going to be connected to your server, you have a control over it. Another option is making a web-based application. J2EE technologies support this web service well (http://java.sun.com/blueprints/enterprise/index.html). Because your server components will be written in C++ (probably it is a good choice in terms of speed), Java (JSP, servlets, ...) and XML technologies can be used to write a client interface in the web browser. The same idea was used in my previous company (ADP). The backend or server part was written in C/C++ and the web application was written using Java technologies. Try the following web site and type "test" for Login and password: https://www.claimseditor.com/md/mdwelcome.jsp. It is a coincidence that I have developed the automated email program for instructors here at TechBC using Visual Basic 6 and MS Office XP. When you write one email message, it generates personalized emails for each recipient and sends them automatically. I'm planning to convert it to a web-version. I thought about language choice and would like to use PHP or Python and MySQL--non-Microsoft stuff. There are so many technologies out there and what to choose is very important for the future success. What I wrote above is my thought in my mind at this moment. If I'm serious to write a commercial program, I will spend more time to research to find the best technologies. Thank you. And I look forward to hearing from you. 5.9. S.L.'s note If user interface is not very complex, it is better to do web presentation in HTML. Otherwise - on JavaWebStart, but not on applet-AWT. Since server components are in C++, it is good to use SOAP for their communication. 5.10. V.S.'s note As you guys have basically covered advantages/drawbacks f all thinkable architecture solutions I get little to add. Personally, I stand for Sun's Java Web Start: provided that declared "Web Start works with any browser" is true (needs to be thoroughly checked) you could dramatically reduce the time for client development just creating one web-deployable stand-alone app instead of two. Currently I have a similar project under development. It is in Vb and is planned to have web part in ASP. But we are considering of moving to Java/Web Start solution down the road. 5.11. D.K.'s note I am not sure if I understand properly what you are trying to make. But, from the attached document, here are some suggestions. If you want GUI clients, use Swing not AWT. There are a number of books that explain why Swing (light weighted components etc), and not AWT. If you want to put clients on the web, I suggest HTML with JavaScript (it is not a poor solution, just hire some web artists to make it look cool. If some windows have controls that cannot be created using HTML, that is an extra work) with JSP, server code should be servlet + javabeans, so all code is in java. I don't think that you need SOAP, and if you want to use it, think that there are not to many people who used it and there can be a learning curve issue. Also C++ or java? I would go with java (simpler and I wouldn't mix java with C++, and you won't loose the speed, since you can pre-compile the code) Of course, if you have people who know only C++, It is your call. Database? 5.12. V.W.'s note I haven't seen the specification of the client, and don't know the requirement of the GUI richness level. If the browser clientn, a thin client, is sufficient for some or all group of users, Servlet/JSP is one good way to implement the system, including the client. Using JNI create a Java interface of the existing C++ server, so that the Java web container can communicate with the C++ server. Once a web framework is employed, the development of this implementation, in my experience, can be done in a very short period of time. At this present time, there are quite a few frameworks available (mostly are free) in the developer community (see http://www.theserverside.com/home/thread.jsp?thread_id=12750). Firewall will not a problem for this implementation method (assuming a web container, say open source Tomcat, and C++ server are in the same box, on the same side of a firewall). BTW, the JSP creates a dynamic web page, not a static one as one person described. I haven't seen any good/acceptable applet implementation for a reasonable complex application since its inception. So, applet is not my choice. If a rich GUI client is required, a standard alone, coded either C++ or Java, might not be a good option. The mailoop is an ASP and I can assume that it can have a very large number of users. The client installation, configuration, and upgrading is a nightmare for a mass users. This problem can be resolved by using Java Web Start when the client is implemented in Java. With this implementation, the communication between the client and server can be RMI, socket (if inside of a firewall), or SOAP. Either socket or RMI can be used for the communication between the server and client once a Java interface of the C++ server is built. The RMI can go through a firewall, if it is a concern using socket. RMI was known for its slow performance before. With the recent J2SE 1.4 release, the Sun claims that RMI performance has improved for more than 70%. SOAP can be a choice since the server is coded in C++ and the client likely will be coded in another programming language, Java for instance. I, however, think that SOAP may be an overkill for this application. To sum up, here is my design: web browser client, Java web container (Servlet and JSP), JNI, C++ server. Java client (launched and distributed by Java Web Start), RMI, JNI, C++ server. I know some options for your situation and able to provide a solution (build it). Other than those I have mentioned, the http protocol, for example, is another mechanism that can be employed for the communication between the client and the server, even though the client is not a browser. To have accurate, reliable information, it is better to have a face-to-face discussion. BTW, SOAP can be "more complex (how complex depends on tooling etc) to develop" (vs. RPC), not as one person claimed. 5.13. D.T-S.'s note Why is this upgrade required? Among other things the answer to this question may provide some of the requirements of the new product. Is there any requirement on porting the current GUI look and feel into the new product? The thin client model is mostly suitable for applications where the data transfer between client and server is not very large and not very often. I have worked in the past on an application (applet) where parts of a large list had to be shown to the user. We chose the thin client model. Only part of the list was sent to the client, namely as much as it could have been shown on the screen and if the user was scrolling a new data transfer was performed. This proved to make the client more complex ("thicker") than the initial plan. The requirement to have both Java stand-alone and applet may justify the evaluation of the Java Web Start (http://java.sun.com/products/javawebstart/). This solution would ensure complete common code base and Java 2 (better performance, better and more choice of widgets, etc.) instead of the older Java1.1. Java Web Start is available for Windows platforms, Solaris, Linux and MacIntosh. The maturity of Java Web Start would have to be established. One way is to check out the FAQ for Java Web Start and find out what kind of problems they have. Also as a Java Developer Connection subscriber (free) you have access to their Bug database. The latter could be browsed too, filtering on Java Web Start. If time allows a prototype could be implemented. Another solution would be application and applet, using Java 2, with common code base and the use of Java Plug-in (http://java.sun.com/products/plugin/). This is available for Windows platforms, Solaris and Linux and allows use of Netscape Navigator or Microsoft Internet Explorer. JRE1.4 includes Java Plug-in. As far as I know the Plug-in is a more mature product than Java Web Start. Java Plug-in needs to be downloaded (once) on any machine/operating system. The customers of the products of my last company (Verison, WorldCom etc.) did not complain about this. As for Java Web Start you need to also download on any machine/operating system. I think that if you chose a Java solution you should use the latest Java and not Java1.1. As for the communication GUI client/server is concerned the SOAP solution seems to be a good choice. In the client, the communication part would have to be as much as possible separate from the GUI part. I have development leading roles experience. This implied requirements analysis, design, work plans and work estimates, design and code reviews, coaching developers. Now Windows XP operating system doesn't come with a Java virtual machine which means you will not be able to run even the Java1.1 applets since Internet Explorer won't have any default JVM. So even for Java1.1 applets you would have to download "something". One option would be to use/download the Java Plug-In software. This will allow Sun's Java virtual machine to plug into Microsoft Internet Explorer as the default JVM. I don't think applets are a bad solution. But as I said you should go for Java 1.2 or higher (better the latest 1.4) so that you can use Swing and not the older Java1.1 which only gives you AWT. Another important thing is how complex is the GUI. If it's simple enough you might be better of without applet and do with HTML for example through JSP. You do not need to download Java plug-in in order to run Java1.1 applets because the browsers (at least Netscape and Internet Explorer) have their own default Java Virtual machine. But their JVM is 1.1.x, except may be for Netscape 6 (I'm not sure about this one). For Java 2 applets (that is Java 1.2 or higher) you need Java 1.2 or higher. The Java plug-in enables applets to run using Sun's Java 2 Runtime Environment, (JRE) instead of the web browser's default virtual machine. If you wonder what's the difference between Java1.1 and Java1.2, one major change was the addition of Swing (Java Foundation Classes) with many new improved widgets over AWT. The Java plug-in download/install is no trouble. It's the same for Windows XP, Me, NT, 2000, 98, or 95. The download process is able to detect whether the system configuration allows automatic installation for XP only (?). If not, manual installation is available - no trouble either. In the past the Java plug-in was a separate product. Now you actually get the Java 2 Runtime Environment (JRE) that is JVM, etc. Suppose on an NT you had Java1.1 and now you need to run Java 2 applets. You would have to download the Java plug-in that is Java 2 Runtime Environment and not an upgrade. If your applet is a Java 2 applet and those systems have the Java Plug-in installed you'll be fine. If they do not have the Java plug-in installed they may disallow any installation and therefore you won't be able to run your Java 2 applet. As for installing Java Web Start I guess you are right. As far as I know Java Web Start is as free as many other Sun Java products, but I might be wrong. If you need to use the Java Plug-in, you need to install it in a way or another. As far as I know, the only way to install it these days is to get the whole JRE. If Java Plug-in is not installed, there are ways to give the user a "click and play way" to get it. No, the Java plug-in does not come by default with Windows systems. As far as I know the difference between NT and XP is that on NT you have a default JVM (1.1.x) where on XP you have absolutely no default Java. On BOTH you would have to install the Java Plug-in. If you don't already know about it I recommend you the SUN pages on Java Plug-in "http://java.sun.com/products/plugin/";. I personally find the Sun documentation well written and informative. 5.14. D.W.'s note Based on the functional specification information presented, there are several good solutions already posted. All of the team's posts have been both functional and creative, and I have found it fun to be party to this discussion. Let me weigh in my thoughts on the best solution I have seen so far, and then suggest another viable avenue for this project. I mostly agree with M.O. and A.P.'s position on the project design. If a very rich GUI is required, then Java Web Start seems to be the answer. This approach has the advantages of one code base, easy deployments, lesser download times, cross-platform development, a rich Swing GUI, and is faster than client/server once downloaded. However, the better solution may be to create a fast HTML/Swing bridge with <a href="http://www.bitmovers.com";>Maui</a>. Similar to M.O.'s suggestion of WebCream, however Maui is a less expensive (cheaper) and possibly superior solution. Maui creates HTML from a java-programmed GUI, essentially mocking a Swing GUI in HTML while still receiving the quick response times inherent to a pure Swing GUI. It allows the client to be a web browser, a palm device, or a WAP device (or any other internet connected device). The <a href="http://http://maui.bitmovers.com/about/overview/";>overview diagram</a> suggests an email client as a possibility with Maui. Both the web application and the standalone application would have a similar interface and would share a code base. Maui could not only solidify a common interface for the applications, but also speed up development time because it will create a single code base that can interact with almost any environment. This Maui application can be deployed as a normal application (opening the default browser when it starts) or deployed via JavaWebStart, it also gives ultimate flexibility in deployment, design, and extensibility, since there is no reason that it cannot be converted to be used as a standalone, peer to peer, or client/server application. In summary, Maui offers the same if not greater functionality at a lesser cost all with the benefit of easier and faster development and deployment. 5.15. EK�s note We need to evaluate rebol.com�s modern technology. May be we can use it instead of Java as �run anywhere�. 5.16. Boris's Summary Comment All discussion points could be placed into the following list: 1. AWT versus Swing. We do not want to limit ourselves to AWT, being bereft of trees and stuff. We may use stand-alone Swing if doing no applets. Otherwise it is reasonable to have common code base. 2. Web app. We need a small one anyways to serve an applet from. Probably just a static page. If we do flash or HTML, we need dynamic pages, possibly JSP if to give choice to same java guys. 3. HTML versus applet layout. HTML is poor. But filonet.com uses exactly such a solution: stand-alone Swing client in parallel with limited HTML version. What solution is easier to adjust to partial file system manipulation - applets or HTML? 4. Dropped default java support on XP. JN brought up this point. If it is true, then on most popular desktop Windows platform applets will involve same installation overhead as JavaWebStart. 5. JavaWebStart. Kind of a plug-in that helps client run java stand-alone apps from browsers. There is no research on browsers� support and how smart it is. Also, JN thinks it is too much of download headache for a customer. V.S.�s point is that by using JavaWebStart we can develop just one client version and use it in two ways. More and more people suggest it. V.W. thinks, it helps to automate version upgrade routine. Now if to compare Java2 applet and JavaWebStart app, apart from reliability issues - what is the principal difference? I think, first of all in download cycle. Java 2 applet requires to download Java 2 VM once and applet every new browser session. Java Web Start requires to download VM once, target application also once (unless newer version detected) and some Java Web Start thing in addition. So they both download Java2, though applet may be cashed but never installed into the system, whereas Java Web Start requires more to download first time, but less all subsequent times. Some security issues may arise. For instance, if the user tries to access his system from the Kinko's, Internet Cafe or public library, those machines will surely allow applets but may disallow target app installation from Java Web Start, and disallow to install very Java Web Start. Is that right? These are just my premature guesses. 6. Mixed HTML-applet solution. Both Adrian and Jon Stoski mentioned it to be not so heavy as a whole single applet. But anyways we lose the main goal of having common code base. 7. TCP sockets versus HTTP. Sockets are faster, but probably suffer more from firewalls? 8. Firewalls. Seems, using HTTP even in applet case is a remedy. 9. Heavy libraries to download. Applets can involve frequent reload of heavy archives with text editing libraries and so on. 10. Flash. There will be less Java in this case. A.F. suggests it as an alternative to poor HTML layout if the latter is not acceptable. What kind of web app should serve it? J2EE would be good. Flash technology extends and enriches client interface experience. It is owned by Mactomedia. What is free and what is not? What is a relation to open source communities? Player is free, but not an open source. I do not think, it is open to reproduce or redistribute, perhaps, just like JDK. There is a connection to J2EE back end through Flash Gateway that is about 260k. The server connection script Salsa is available. It also connects to Cold Fusion back end that we do not need. Dot Net connections were mentioned. Gateway�s implementation is not free, but seems, allowed to be reproduced. Protocol is open free. The Gateway is included in Jrun (just expensive enterprise version?). Server connected Flash app acts like Java applet. It does not need to reload pages and to get valuable data inside the tags overhead wrapper only. There are no open source communities around it yet and no implementations alternative to Mactomedia. To have the full Flush game we need J2EE back and, so another layer between C++ services and final client. In addition, we need to purchase Gateway or the whole Jrun. Is it worth it? 11. Supported browsers - we need to specify what we need to support. Then see what we can achieve with each of 3 client solutions - HTML, Flash and applets. 12. IFRAME. This is how pages run each other's scripts and partly reload. Must be supported by all 4th generation browsers. JS knows them and brought up this point. 13. SOAP. A.F. proposed this communication protocol with HTTP carrier, and Rick approved. Then applet needs for instance Apache's soap.jar or 180k. Alternative communicational library will take some size anyways. W.V. and D.K. think SOAP is an overkill for the project. W.V. proposes RMI and JNI instead. SOAP is not so universal a thing. There are some issues of providers and clients compatibility. And having so diverse environment, we will definitely need to use different packages. Perhaps Apache SOAP in Java and MS SOAP in some native Windows code. Perhaps, we need to use org.apache.soap.providers.com.RPCProvider class if our SOAP service is Apache Java (C:\programs\soap-2_2\samples\com\readme.htm). Or if it is MS implementation, we need to adjust java client for it. People say that SOAP is slow, has lots of data overhead and therefore is rarely used on desktop or client web apps. Rather it can be used between two server machines as peers. 14. JNI (Java Native Interface). V.W. suggests using it to talk to C++ component from some intermediary Java server layer, most likely from Java Web App. Then perhaps this layer must be installed on the same machine as C++ thing. And that C++ thing does not need to be a server anymore. If to continue this thought, web app better also be not in Java, but in C++ or ASP. There is an opinion that JNI is not very clean solution. And it is not easy. 15. RMI. V.W. suggests using it to talk between stand-alone Java client and some intermediate Java Java app server. My objection is that we hardly need another server layer in Java. Instead we can do CORBA immediately between stand-alone client and C++ component. 16. Non-Java stand-alone client. P.C. suggests C++ stand-alone client and perhaps Java applet web version. Since applet is so much in question, java may be removed from the project at all. It may be a smart solution. Perhaps, just windows clients are assumed. Perhaps it will also make communication with C++ server easier. 17. Java2 versus Java1.1. D.T-S. suggests to use 2. I think, it is reasonable because now the difference in amount of download difficulties between Java1.1 and Java2 for applets is less and less significant. Java Web Start requires Java 2 to be installed first? 18. Java Plug-in. How much trouble is that to download Java2 plug-in or VM for applet? Is plug-in just a technology to download VM? Finally, is that product to be downloaded the same for on NT and on XP? Or on NT it is just some upgrade from 1.1 to 2? So Java Plug-in needs to be installed, and if it is not, user is given no click and play way to finalize it all in one session? Java plug-in does not come by default with Windows systems? Any difference for NT and XP? How much trouble is that to download Java2 plug-in or VM for applet? Is plug-in just a technology to download VM? 19. WebCream. M.O. recommends it as some Swing - HTMLwebapp wizard tool. 20. Maui. D.W. recommends it in the same capacity as WebCream, but cheaper and better. Apparently it is not just a transformation wizard of development cycle, but a real time technology. D.W. is preparing detailed proposal on it. 21. Rebol. EK recommends it as another �run anywhere� thing, but it looks to me some inter-organizational sharing environment like Lotus Notes. Can we distribute it to paid customers to join our network just for the sake of running Mailloop? Perhaps, I need to inquire Rebol on explanations. -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
