>> If using Java Web Start would not require any Java on the back end >> whatsoever, then Marinilli on this JNLP wouldn't have dedicated a >> chapter to it ;-)
>I'm curious - what functionality is required to serve JNLP apps - is >there something more than HTTP requests? ~ for example the jardiff thing I found great and it is part of JNLP, not just HTTP ~ // __ And What About This JARDiff Stuff? ~ informit.com/articles/article.aspx?p=25044&seqNum=6 ~ JARDiff is a mechanism for updating incrementally JAR files. It is a part of the JNLP specification, but it can be used outside usual JNLP deployment as well. Figure 4 shows its mechanism. Figure 4 The JARDiff working mechanism. http://ptgmedia.pearsoncmg.com/images/art_marinilli2B_jnlptutorial2/elementLinks/marinilli2B_fig04.gif As discussed, the JARDiff format is a way to perform incremental updates to a JAR file. It consists of a special JAR file sent to the client, which describes the differences between two JAR files—OldJAR and NewJAR, for example. The differencing information is stored in the META-INF/INDEX.JD text file, which describes the copies of new or changed files in the NewJAR file relative to the OldJAR file. The file is composed of lines <command> space <value>. The first line describes the JARDiff format version (currently 1.0): version <version> And following are lines of two types: remove <fully qualified class in OldJar but not in NewJAR> move <fully qualified class in OldJAR> <fully qualified class in NewJAR >. They describe the differences between the already installed OldJAR file and the to-be-installed NewJAR file. The following sections summarize the pros and cons of using JNLP. ~ Perhaps those mobile apps are so small and selfcontained that jardiffs don't make any sense. Users would just download the new application instead of diff'ing it ~ lbrtchx --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
