Desktop publishing tools and PENS

I've written before about how PENS can be used to enable one-click publishing from a publishing system (authoring tool or LCMS). Herewith, some notes on using PENS with desktop, as opposed to web-based, tools.

PENS requires that, when a publishing system sends a request to the LMS to “collect” a content package, it supplies a URL (typically using one of http, https or ftp for the URL scheme) from which the package can be collected. If the publishing system is web-based, then this URL will typically refer back to the publishing system itself.

For a desktop publishing system, this requirement effectively means that there needs to be a server, separate from the desktop software, to which the content can be uploaded prior to being collected by the LMS. Typically this will be an FTP server, although it could in principle be a web server.

Ideally, the desktop software will enable the user to configure details of this FTP server (including host, user name and password) in addition to the LMS details. When a course is published, the software should perform the following actions:

• package the content into a zip file;
• upload the content package to the FTP server using the configured host, user name and password; and
• send a PENS request to the LMS instructing it to collect the content package from the FTP server.

In principle, it would be possible to manually upload the content package to the FTP server if the desktop software does not do this automatically. In practice, though, this really defeats the purpose of using PENS, since it would be simpler to create a SCORM or AICC content package on the desktop machine, and then upload the package directly to the LMS.

Another theoretical possibility would be to run a web or FTP server on the desktop machine itself. However, this would require that the desktop machine has a stable IP address and/or host name that the LMS can call back to, and that HTTP or FTP requests to the desktop machine are not blocked by hardware or software firewalls. In other words, it's almost guaranteed not to work in practice.

In summary, a desktop publishing system can theoretically “support” PENS without also supporting the automatic FTP upload step. However, without this automatic FTP upload, PENS is unlikely to provide any practical benefit.

Sun Java Plug-in bug and SCORM communication

A few users have encountered the following issue that affects tracking of SCORM courses on a small number of EKP sites.

Symptoms: SCORM courses fail to communicate with EKP, and one or more messages like the one below appear in the browser's Java console.

java.security.AccessControlException: access denied (java.net.SocketPermission www.example.com:80 connect,resolve)

Analysis: This issue is caused by a bug in certain versions of Sun's Java Plug-in. The bug was introduced in Java 6 Update 3, and is fixed in Java 6 Update 10. It affects Firefox and Safari; Internet Explorer is not affected.

Note that this problem does not affect all sites. It appears to affect a small proportion of sites, and is related to the site's DNS configuration.

Solution: Users who encounter the problem described above can apply one of the following solutions.

• Ensure that your users are using a version of the Sun Java Plug-in that is not affected by this problem. Users who currently have Java 6 Update 3 or above can upgrade to Java 6 Update 10. (Note that, as of 9 July 2008, Update 10 is flagged as “beta.” However, it is the first version offered on the downloads page.)
• Another solution that appears to be effective is to ensure that each EKP domain (e.g. ekp.example.com) is mapped (via DNS) to a unique IP address. That is, where multiple EKP instances are located on a single server, ensure that each instance on the server is associated with a different IP address.