Ben Langhinrichs

August, 2014
     01 02
03 04 05 06 07 08 09
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

Search the weblog

Genii Weblog

Civility in critiquing the ideas of others is no vice. Rudeness in defending your own ideas is no virtue.

Tue 19 Aug 2014, 11:34 AM

The high fidelity email rendering provided by CoexLinks Fidelity 3.6 is often viewed as primarily about appearance, but it is also about preserving data integrity. This 4 minute demo shows a number of examples where actual data loss occurs when certain elements are sent via email and rendered by either the IBM Notes 9.0.1 client or the IBM Domino 9.0.1 server. (None of these data losses started in 9.0.1 - earlier versions were even worse). Problems shown have all been reported by Genii Software customers in rich text rendering, although the examples are contrived for effect.
Data issues fixed by CoexLinks Fidelity and shown in the demo:
  1. Image resources (disappear with both client/server rendering)
  2. Text and cell colors (light green/dark green confusion in client rendering)
  3. Table borders and cell borders (table borders disappear in both client/server rendering, cell borders rendered poorly in server rendering)
  4. Section titles (disappear completely in client rendering, render poorly in server rendering)
  5. Layout regions (disappear completely in both client/server rendering)
  6. Stored forms (not rendered by client except Body field if present)
  7. Buttons (disappear completely in both client/server rendering)
Best viewed in HD. Closed captions will be provided shortly for following in English or improved auto-translation.
To try out the new CoexLinks Fidelity including the Message Store, fill out an evaluation request or contact us for more information at

Copyright © 2014 Genii Software Ltd.

Fri 15 Aug 2014, 09:49 AM
I was very interested to read Paul Withers' article, 10 Reasons All Companies Should Use Open Source. I agree with many of its points, but wanted to bring up one caveat that seems too often ignored. If I might throw some caution on his first point, 1. Good Developers Write Good Code, Great Developers Steal Good Code, it would be to remind people that great developers can steal bad code as well.
As the Goto Fail vulnerabilty, and even more the Heartbleed Bug should remind us, the fact that code is widely used or open source, even widely used open source, does not absolve a company using it from testing. It should be assumed to be buggy, insecure and incomplete until proven otherwise. Personally, I think any open source library added to your own software should be treated as if it were written by the most junior developer. It might be great, but it also might have glaring holes that are waiting to trap the unsuspecting. As I wrote when the Goto Fail vulnerability surfaced, the great failing was not that the code had a bug. All software has bugs. The great failing was that Apple's QA didn't adequately assume it might be vulnerable and try to attack it to see if they could get through. As the Heartbleed bug proved shortly thereafter, the problem was even more prevalent when the code was open source, as it seems that many companies trusted OpenSSL when a relatively straightforward QA test should have shown that the vulnerability existed.
Trust but verify. Open source code (and your own code for that matter) may be very, very good, but you should test it as if it were buggy, insecure and incomplete. Do not trust "the crowd" to do your verification for you. In fact, with open source code you should add the element that a nefarious somebody may have planted a subtle vulnerability, so you should push the limits and assume the worst.
Note: If you find any problems, especially security issues, you should make sure the open source code is fixed and submitted to the originator as well.

Copyright © 2014 Genii Software Ltd.

Technorati tags:

Thu 14 Aug 2014, 01:51 PM
I posted another of my story videos on my channel, TheStoryTimeChannel, for those who enjoy these things. This is called Circle Back, and while it has a kid as the main character, it is not a children's story. It took me a lot longer to get to this one (because of lots of releases of our Notes/Domino related products). I played more with the production of the video, adding some effects and trying some different ways of showing the text. Of course, the story is the main thing, and while this is not a long story, it is an interesting change from ones you may have seen of mine.
Since my next two videos are in post-production right now, and are all related to CoexLinks Fidelity and Midas, consider this a breather.

Copyright © 2014 Genii Software Ltd.

Tue 5 Aug 2014, 08:58 AM
If your company uses Notes/Domino for email, you have probably learned that in spite of years of customer complaints, emails sent from Notes are iffy at best. On a good day, all the information gets through. On a bad day, data is misformatted, missing or just plain messed up.
But it is just for such concerns that we at Genii Software tilt at the windmills of email fidelity and data integrity. Now, since the release of CoexLinks Fidelity 3.6, more and more companies are getting their windmills served up just the way they want them. (No point in tilting at something if you can't serve it for supper.) If you want a short technical explanation, see the bottom of this post. If you just want to try it for yourself, request an evaluation license.
In 2014, using IBM Notes 9.0.1 Social Edition, you send the following email:.

Original email in Notes 9.0.1 rich text
With native client rendering, it arrives in Gmail as:

Email as sent to Gmail after Notes 9.0.1 MIME rendering
With CoexLinks Fidelity rendering, it arrives in Gmail as:

Email as sent to Gmail after CoexLinks Fidelity MIME rendering
With native client rendering, it arrives in Outlook 2007/2010/2013 (no rendering changes in years!) as:

Email as sent to Outlookl after Notes 9.0.1 MIME rendering
With CoexLinks Fidelity rendering, it arrives in Outlook as:

Email as sent to Outlook after CoexLinks Fidelity MIME rendering
and it is not just the client rendering. What if you view the same email (still in rich text) via your Notes client or your iNotes client? Note that while the images work here, they will fail if mailed from here, unlike the images with CoexLinks Fidelity.
In IBM iNotes on Domino 9.0.1:

Email in rich text viewed through iNotes 9.0.1 with native rendering
In IBM iNotes on Domino 9.0.1 with CoexLinks Fidelity:

Email in rich text viewed through iNotes 9.0.1 with CoexLinks Fidelity rendering
A brief technical explanation of the specific areas which fail here:
1) Image resources in emails are converted to relative URLs by the client MIME rendering, which means they fail unless the email is read on the server where it was sent. The same issue means that the iNotes native rendering will work when viewed, but fail when sent. Real life scenarios: Note that while image resources are seldom added directly to emails, they are sent frequently when a document is forwarded. The images will look fine for the sender but be missing for the recipient. There is no easy way for the sender to know if images are inline or image resources. CoexLinks Fidelity solution: Image resources are brought inline before rendering. To avoid large sizes, the same image resource is only included in the MIME once even if it is displayed multiple times.
2) Table width. This problem surfaced due to a customer's confusion about why a table that was small and fixed in size was spreading across the entire width of an email. It turned out that a nicely constructed email newsletter had a table where the table was set to "Fit with margins", but every column was a fixed width. When that happens, the Notes/Domino rendering simply sees it as a variable width table. CoexLinks Fidelity solution: When all columns are fixed width, the table is treated as a fixed width table.
3) Non-uniform cell borders. Toward the end of the last millennium, a table in HTML either had borders or did not. After the introduction of CSS in 1996, tables in HTML with CSS could be on or off depending on the cell, something that had been true in Notes rich text for a long time already by then. Unfortunately, IBM has been slow to convert the non-uniform cell borders in Notes to non-uniform cell borders in HTML+CSS. To be fair, the Notes 9 client rendering does finally accomplish this, but the Domino 9 rendering does not. Thus, you can see the borders in the two samples above that were sent with Notes 9.0.1 rendering, but not in the iNotes rendering. Real life scenarios: Both newsletters and forms often use cell borders to make the appearance more sleek and professional. When these are sent or forwarded, the sender may not anticipate how the tables will look to the sender. CoexLinks Fidelity solution: CSS is used to match the non-uniform cell borders in Notes.
4) Table borders. Separate from cell borders, there is a table border which is often used for drop shadows but also for framing. Both Notes 9.0.1 and Domino 9.0.1 seem to ignore it in all their rendering engines. Real life scenarios: Newsletters, forms, and reports often use table borders, both for a professional look and, sometime, to separate out small tables. All is lost when these are rendered by Notes/Domino, no matter which rendering engine is used. CoexLinks Fidelity solution: Table borders are used, as well as inner and outer padding. As you can see in the Outlook example, not all email systems will recognize the inner and outer padding.
5) The color of green. In an odd quirk, the Notes client rendering confuses light green and dark green, so that both appear as dark green in emails. (I first reported this to IBM in 2007, fwiw.) This can lead to tables that don't look as they should, and occasionally to the perception of missing data as in this example. Real life scenarios: As two of the sixteen basic colors in Notes, both light and dark green are used more frequently than other colors. I have seen customer examples with the light green lettering on the dark green background which leads to this, which is why I added it to the demo. CoexLinks Fidelity solution: RGB colors are used to ensure consistency.

Copyright © 2014 Genii Software Ltd.

Thu 31 Jul 2014, 11:56 AM
One of the challenging aspects of describing issues with Notes/Domino rich text rendering is that there seem to be so many engines. Even on IBM Domino 9.0.1, there are multiple rendering engines that render rich text differently (different ones fail in different ways). See below an example of Notes rich text rendered by three of the different engines, or at least they appear to be different engines given the results. (Traveler may have yet another engine, but these are all built into the core Domino server.) I used screen shots for the Notes content and the iNotes rendering, as I couldn't find any good way to frame them, but the Domino web rendering is happening live and the Domino SMTP rendering is pass through HTML which I captured from an email rendered by the server. (I thought about adding the Midas LSX rendering, but wanted to focus on core Domino.)

Copyright © 2014 Genii Software Ltd.

Technorati tags:

Sun 29 Jun 2014, 10:58 AM
I finished up my story video, and it is now up on Youtube. I put it on a new channel, TheStoryTimeChannel, as I felt like it was sufficiently far removed from the IBM Notes and Gimp and product videos I do on my channel. Of course, that means I am starting with zero subscribers and zero view, so if you like this, it would be great if you could share it and subscribe. Plus maybe let me know what you think. This one took a lot, as I am trying to learn something about music mixing, and for this story, I wanted the illustrations to be derived from classic art. The next should be a little easier, as I have a different sort of illustration in mind.

Bonus: There's a subtle Garfield without Garfield effect for those who watch closely.

Copyright © 2014 Genii Software Ltd.