The first mistake is that he told me about this. The second mistake is that he showed it to me. The third mistake is that he let me get my digital camera out to get proof of it. The other mistake should be painfully obvious. Can you identify the mystery man in this photo?
…and do the fine folks at Advisor Media have any comment on this?
As part of my role in the local user group, I volunteered to get a box up and running for the site. I’d intended to replicate what I’d setup in our own environment over the last few years, a Red Hat OS and the latest Domino version on it. As I dug out some Red Hat 8 cd’s and got it setup, I remembered the CA key expiration issue with RH 8 and went to their site to remember what to do. Now, I’ve known about RH enterprise server for awhile, but I’d totally missed the discontinuing of any “standard” RH version…yeah, I’ve been busy. Not only that, but 7, 8, and 9 are either no longer maintained or won’t be soon. So what are the options now for a Domino server on Linux? And what are the implications for RH ES? So, I did a little more digging…
First, Red Hat’s table comparing RHES, Fedora, and Red Hat. With April being the end of the line for security support for 9, that introduces a maintenance and support problem for continuing to use that. And while the table claims a range of pricing starting from $179 for RHES, I’ve not seen anything under $350. Still, that’s doable.
However, if you’ve read through the forums, there are some problems with using RHES and Domino. Multi-processor support is still a problem. And the issue apparently won’t be resolved quickly. Moving into the Domino 7.x timeframe, this post on notes.net indicates that for a “scalable production environment”, Domino on Red Hat is basically dead for about a year or so.
This seems to leave only 3 viable alternatives:
- keep an old “standard edition” linux around and play small ball
- go with United Linux 1.0
- use Linux on an IBM platform
. Not a big deal…unless you happen to have more than a few systems running on Red Hat already. Migration could be interesting 😉
I tend to agree with some sentiments expressed in the forum about this complicating the Express/CEO offerings. We finally get a SMB Notes solution that can be widely cast, only to have the picture muddied at the OS level. At this point, I’d probably have to point customers to a complete IBM solution (hardware+os+domino), or a Microsoft OS. As an IBM partner, of course I’m pleased with the opportunity to pitch a one stop service here, however many SMB clients might see it a bit differently.
Sandy, our Sales and Marketing Director, and her daughter were coming home from a Dallas Stars game friday night when some drunk rear-ended them on the highway at high speed. They flipped, and spun across the highway, ending up facing traffic. It’s amazing neither of them were hurt. The guy kept on going. Unfortunately, there were no close witnesses, so no description of vehicle or license plate number. If you happened to witness it, I’m sure Sandy would love to talk to you. Here are the pics, http://www.workflowstudios.com/SandyCar/index.html
I’d seen this problem before but neglected to tell David about it. Poor David, nothing like putting him on the spot. Anyway, for any of you’ve dealt with the LotusXSL.jar and XML4J.jar files, you’ll probably see where I’m going with this immediately. The problem revolves around the order in which Notes loads things onto the classpath. For more details…
When the jvm loads up, it looks for classes in the following order:
- Is there a JavaUserClasses variable in the Notes.ini file. Load those first.
- Look in the domino/java directory. Load those next.
- Has the agent or library included other jar files, load those last.
When dealing with XML classes, the LotusXSL.jar and XML4J.jar files are in the domino/java directory. So a vanilla setup of Notes will find those first (b/c there isn’t a JavaUserClasses variable by default). However, these packages are a bit, shall we say, dated. So, it’s entirely likely that you might go out to apache.org and get yourself the latest and greatest versions of xalan or xerxces. This would be ok, except many of the classes in these packages are also duplicated in the LotusXSL.jar or XML4J.jar set. So when a call is made to a Node or Document, the jvm will look into the IBM supplied versions first and find those. The method signatures or implementations of these might have changed from the earlier IBM version to the current Apache version.
The other gotcha is around Factory or Builder classes. In these cases, the default class that these factories want to use are in the xerxces package, which is NOT part of the IBM supplied packages. This will cause a run-time failure, not a compile time failure. Fortunately, the Factory class will take a non-default argument where a specific parser implementation can be specified. This is where you can route back to an XML4J supplied version. The line of code looks something like this:
org.apache.xalan.xslt.XSLTProcessor processor = org.apache.xalan.xslt.XSLTProcessorFactory.getProcessor(new XML4JLiaison4dom());
Now, could we have done this another way? Certainly. But our goal was to use what is supplied by IBM, and not have to require any special configuration items, like adding a JavaUserClasses variable. Joshua suggested that we take the lightweight approach and just write our own parser. Steve DeVoll (our CTO) would certainly have concurred with him, but again, not our goal. I think people who use OpenNTF code are just as interested in the application of IBM/Lotus technology within the solution as they are in the solution itself. So, it is that end we have pursued.
If you’ve ever wanted to make use of the LotusXSL and XML4j packages and had trouble locating the API docs, look no more. Here are some pointers:
Sadly, neither of these links is at a Lotus or IBM site. Perhaps they still exist there as well, but I haven’t found them. I kinda’ stopped when I found what I needed.
First, I’d like to thank all the people who stopped by our pedestal at Lotusphere to talk with us about the Blog Reader. While we were able to demo, we weren’t able to distribute. In addition to your empathy, you also had some great feedback for features that should be part of the reader. Below is a list of the features that we are working on to include in the first release of the reader, and then future items we’d like to see in it. I don’t have an exact release planned (since we’re working on this in our free time), but we’re looking hard at having a releasable version next Monday. So without further adieu, the feature list:
- Channel creation
- Scheduled feed update
- UI for Notes client
- UI for Web client
Working on for current release
- OPML import/export
- Moveable Type/Blogsphere integration XML-RPC capability (Click “Blog this” button to create entry for external blog tool)
- Individual Profiles (to specify user specific settings)
- Story Ranking (Click a rating indicator for each story)
- RSS Feed for “Ranked” category
- Add controls in UI for “Read cached” or “read live” from abstract summary
- UI visibility for unread stories
- Admin profile (settings for determining “what’s new” for Anonymous users)
- Automated story relevance scoring (Andrew Pollock’s NCTSearch or some such device)
- Google It for trackback threading (thx to John Rollins)
- Capability to add comments to stories (not published back to author, just to Notes db)
- UI for stories that others have read (ala IBM Donut project)
- “opt in” checkbox for user’s inclusion in “stories I’ve read”
- OpenNTF mail plugin capability (thx Bruce)
- CSS skinning interface (I know, everyone wants their own special ui)
- IBM Donut-like visual ranking display (can’t explain easily, go see Donut)
- Feed agent (higher performing feed agent via threading)
- Auto-discovery of channel info
That’s it for now. I’m off to OpenNTF to see how we submit this as a project. Hope Bruce and Nathan will still let us play 😉