The Intellog Blog

Recently, I had to organize a meeting which included  participants who were on the road, and hence the need to host a web conference for the first time.  There’s a plethora of web conferencing products out there – GoToMeeting and Webex are the names most recognize – but an open source alternative was what I had in mind for this particular situation.  A number of products were identified as candidates*, and Dimdim was eventually chosen as the first product to try.  It’s a bit of a silly name – memorable, at least – but good software.

The free version of Dimdim supports meeting of up to 20 participants, and has the basic capabilities expected from this type of product; desktop sharing, slide presentations, document sharing, text chat, audio chat, broadcast with webcam, meeting scheduling, meeting recording & playback and the like.  They all work more-or-less as advertised.  However, here are some limitations I encountered — although it’s entirely possible these are merely a reflection of my current, rather limited knowledge of  Dimdim;

• Only two types of documents are supported for sharing; PowerPoint and Portable Document Format (PDF).  Of course, if there are other types you absolutely have to share, you can convert them to PDF, and share them that way.  
• With PowerPoint, you can share them as described above, but you won’t get any fancy animations or other effects incorporated into your material.  There’s an easy workaround, however — share the presenter’s desktop with the audience, and then simply start the PowerPoint slide show (ie. F5 from within PowerPoint.)  For that matter, the same technique can be used for any dynamic document, such as a spreadsheet, which you wanted to share with the web conference participants.
• When a meeting is set up for a future date and time, and you specify meeting participants, it seems like notifications don’t go out as expected.  You have to re-invite them once the meeting has started, and that notification they seem to get without difficulty.
• Dimdim can record the meeting, for playback after the fact.  I thought I had the meeting set up to be recorded, but the recordings did not show up as expected.  This was even after waiting the prescribed 24 hours Dimdim says it can take to process a recording after a meeting has concluded.
• I forgot to plug in the webcam (a nice, new Logitech® C905) prior to the web conference starting, and while there was no problem with the microphone, the video portion never did come up.  It worked just fine during the test, immediately prior.   Easy workaround – just don’t forget to plug the webcam in!
• Dimdim notes all of its functionality can be delivered through a browser, with no requirements for downloads and/or installs.  This is true, with one significant exception; in order to share the desktop, it’s necessary to install the Screencaster Plug-in version 5.1, which is available on the Dimdim website.  It’s small, and installed without difficulty, but if others in the web conference are going to share their desktop with the web conference, this plug-in should be installed and tested well in advance of the meeting.
• Dimdim does not currently support Safari 4 running under Windows, although I expect that’s a limitation which will evaporate in the near future.

But overall, it went well.  With some additional experience, I expect there will be a lot of value derived from the use of Dimdim.

*Yugma, Mikogo, and ShowDocument were candidates, and I’m sure there are many others.  Please leave a comment below if you have other suggestions.

In the interest of providing customers and prospects with useful information about staff capabilities, an updated LinkedIn profile has been posted for Terence Gannon, Founder and CEO of Intellog.

There was a time when a cable with DB-9 connectors (pictured, left) was the near universal method of connecting two devices, using a serial interface.  Those days a long gone, superceded by USB and various IP-based networking methods which are vastly superior in virtually every respect.  However, the Arago project demands the use of serial ports, given that the display and a variety of other devices will implement this technology for quite some time to come.

It was therefore necessary to configure Eclipse (running on Windows XP) to support this effort, and this exercise started with Java Communications product page.  Communications programming is considered an ‘extension’ to Java (really?) , so a download of javax.comm 3.0 appeared to be in order.  But the download page reports (ominously); "Sun no longer offer’s the Windows platform binaries of javax.comm, however javax.comm 2.0.3 can be used for the Windows platform, by using it in conjunction with the Win32 implementation layer provided by the RxTx project. To use that, download javax.comm for the ‘generic’ platform (which provides the front-end javax.comm API only, without platform specific back-end implementations bundled). Then acquire the Windows binary implementation rxtx-2.0.7pre1 from http://www.rxtx.org."  Baffling and scary all at the same time.

But it turns out it’s actually pretty straightforward. When you visit the RXTX download page, it indicates rxtx-2.0.7pre1 has been superceded by rxtx 2.1-7r2 (stable), so that was the version downloaded and unzipped.  In this package, the two files of interest were RXTXcomm.jar and rxtxSerial.dll.  There are a variety of instructions on how to ‘install’ these, but the preferred option for this effort was to utilize the native facilities included in Eclipse to integrate them with the rest of the Intellog/Arago project code.  After some experimentation, this was accomplished.  For those who want to approach it the same way, here are the steps;

1. Right-click on the project to which the reference is going to be added.
2. Select Properties — it’s right at the bottom of the menu.
3. Select Java Build Path from the menu on the left.
4. Select the Libraries tab.
5. Click the Add External JARs… button.
6. Navigate to the location of RXTXcomm.jar, select the file, and click the Open button.
7. Expand the hierarchy for the newly-added RXTXcomm.jar reference by clicking the + sign to the immediate left.
8. Click on the Native Library Location: node of the expanded tree
9. Click the Edit button.
10. Navigate to the folder containing rxtxSerial.dll, and then click OK.
11. Click on on OK button for the Properties for [projectNm] dialogue box.

That’s it, and it takes much longer to explain than to do.  The API Users Guide provides some good examples, and SimpleWrite.java seemed like a reasonable, Hello World-ish application which would establish whether the basic functionality was in place, or not.  Assuming the configuration steps above were successfully completed, there was just a couple of changes required to the SimpleWrite.java code to get it to compile and run.  The original code;

import java.io.*;
import java.util.*;
import javax.comm.*;

had to be replaced with with;

import gnu.io.CommPortIdentifier;
import gnu.io.PortInUseException;
import gnu.io.SerialPort;
import gnu.io.UnsupportedCommOperationException;
import java.io.*;
import java.util.*;

Sharp-eyed readers might wonder why import.gnu.io.* was not used instead of the explicit imports shown above.  If it is, a series of ambiguous references are flagged, and the explicit references are the quick fixes suggested by Eclipse.  There is likely a more streamlined way of resolving these, but this approach was sufficient for the time being.  One other change was made, which was to change the default serial port referenced in the code to COM5, or whatever port you are trying to program.  Don’t forget that port identifiers are case sensitive.

Code Shavings  Interestingly enough, it’s possible to run RXTXcomm.jar directly.  Using Eclipse’s Project Explorer, right-click on the RXTXcomm.jar node created with the steps above.  From the context menu, select Run As…, and then select Java Application.  A dialogue box is display which configures gnu.io.rxtx.properties.