Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search

[REBOL] Re: using Rebol for mail client app

From: boris:garbuzov:marketingtips at: 19-Apr-2002 9:41

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: 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: 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: ... Now, an sample of this iframe remote scripting: 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: 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: 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: 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 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 S