Genii Weblog


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


Tue 30 Dec 2008, 09:54 PM
For reasons that I cannot explain, it drives me a bit crazy when websites and blogs leave their copyright year unchanged for days, weeks or months.  Each year I bug people about this, and this year I decided to start early, and remind you a couple of days before to change your copyright dates.  You know I'll probably be back to check in another week.

Copyright © 2008 Genii Software Ltd.

Wed 24 Dec 2008, 10:06 AM
The folks on the LotusphereBlog asked me to share my Lotusphere story.  In case you don't read their posts, here is my (poetic, of course) answer: Share your story - Ben Langhinrichs

Copyright © 2008 Genii Software Ltd.

Tags:

Fri 19 Dec 2008, 08:12 AM
One of the hallmarks of well designed software is its resilience to failure, not just its avoidance of failure as people commonly think.  Obviously, it is best if software doesn't fail, and a huge amount of time and effort and engineering goes into design, quality assurance and testing.  But what happens when there is a failure anyway?  This can be very hard to handle, as one has to imagine the situation where the unimagined happens.  If you can foresee it happening, you can usually design around it, but if you have not foreseen it happening, it is more of a challenge.

A good example of this is in the Lotus Domino mail routing.  As mail routing has been a key feature of the Lotus Notes product since before the server was even called Domino, just about everything that can be foreseen has been, but there are still failures, whether due to new challenges such as badly constructed MIME or to simple "random ionic bombardment", which is how we used to describe those bugs that are not repeatable or even explainable.  This is where the Domino maturity kicks in.  Without compromising speed, the mail router has a clever hand off mechanism to ensure that until the message has been verifiably passed on (and is now some other server's responsibility), it is not removed.  If a crash happens, the mail won't get lost.  If there is a massive power failure, the mail won't get lost.  If there is an earthquake and the data center is in California and the building sinks into the ground, the mail might be lost, but only if the server itself can't be recovered.  
 
This may seem obvious - most elegant systems do - but many mail systems don't work this way.  They send the mail on, then hope it got to the other side.  Microsoft's Exchange Connector has long been plagued with just this problem.  The Exchange Connector takes the message, thus relieving the Domino router of its responsibility, and then if the Exchange Connector machine dies or backs up or freezes, all of which happen distressingly often, the mail is lost.  Simply, irretrievably, silently lost.  (One of the huge advantages of CoexLinks over the years has been the simple fact that it works on the Domino server, and thus gets to rely on the Domino server's reliability.  It is always good to tie your cart to a strong horse.)
 
All of this is a long winded way of getting to a bit of relief I had yesterday.  Somebody used the Lotusphere Sessions db to ask a question, and a good question at that, and CoexEdit failed.  It didn't crash or do anything dire, it just happened to be using an evaluation license on Tranquility/TurtlePublic, the public server, rather than a production license.  Nonetheless, the process failed in an unanticipated way, thus giving a bit of insight into CoexEdit's resilience to failure.
 
Fortunately, CoexEdit passed the test.  The software is designed so that as a person saves, the synchronization happens between HTML and rich text, but if it doesn't happen then, it simply waits silently for the next time somebody opens up the document using CoexEdit, or runs a process with CoexEdit.  In this case, when I replicated to a local workstation with CoexEdit, the synchronization happened, and now the message saved on the system where CoexEdit failed is back and working, without any intervention.  The Turtle Partnership made sure that CoexEdit was up and running again, so the failure is unlikely to occur again, but it is a relief to know that if it does, our software will handle it even if things go wrong.

Copyright © 2008 Genii Software Ltd.

Tags:

Thu 18 Dec 2008, 10:20 AM
The preview version has been out almost a month, but today Version 1 is available with all times and dates including BOFs.  Repeat times are available as well.  Obviously, there will be additional changes to people and exhibitors and all, so you should replicate occasionally (or even schedule it) to keep up to date.  I will post more later about the Q&A feature, which has been enhanced this year

Copyright © 2008 Genii Software Ltd.

Tags:

Wed 17 Dec 2008, 07:16 PM
Update:  According to Jim Casale in the comments, they've now made the times and locations visible, so I can update the sessions db without moral qualms.

The session dates and locations were added the web a few days ago, and so I dutifully added all that data to the sessions database.  It was clearly public - Ed even announced that they were available with times and locations - but then IBM got rid of the information.  Still, I left it in my sessions database, as I had clearly gotten it as public data.  No moral dilemma there.

But now the BOFs have been added, and as you can see the time and location is not visible.  

Session details for BOF215

The moral quandary comes in because the times and locations are on each page, just hidden.  See them below.  So, do I use those hidden-in-plain-sight details to get a first guess schedule for the sessions database, or do I presume that hidden means private, even if they are not well hidden?  What do you think?  In the meantime, I guess you BOF presenters know how to get a quick idea of when and where you might be.

<input name="d_sessionid" type="hidden" value="BOF215">
<input name="d_sessiondate" type="hidden" value="01/21/2009">
<input name="d_sessiontime" type="hidden" value="5:45pm - 6:45pm">
<input name="d_sessionlocation" type="hidden" value="SW Osprey 1-2">

Copyright © 2008 Genii Software Ltd.

Tags:

Tue 16 Dec 2008, 02:04 PM
In Part 1, I showed how IBM's rendering of MIME messages could lead your customers to think you were still running Notes R5, and how iFidelity, in beta now, would allow you to send out more professional looking email, rendered as it is in Notes.  In Part 2, I showed how content rendered by Domino on the web was likely to make prospective customers think twice, or more, before buying Lotus Notes, and how CoexEdit could dramatically improve that default rendering.  In this part, I will show how rendering is made even worse when edited on the web, and how CoexEdit can improve that process as well.

In order to avoid any suggestion that I am cherry picking data, I will use a well known database, my Lotusphere 2009 Sessions DB, and do a simple Edit - Copy As - Table and make no changes, but simply copy into a rich text field.  I will use a sample database I have for editing.  This db has two identical rich text fields into which I will post the data.  The top rich text field is set to render using Domino and edit as Best Fit for OS under Domino 8.0.1 and the new Use JavaScript Control under 8.5 beta.  The bottom rich text field is set to render using CoexEdit and edit using CoexEdit's web editor (customized FCKeditor).  Take a look at the before, during and after of each.  I think you will see why customers object to the standard methods, and will not be much mollified by Notes 8.5.

1) Notes 8.0.1 (looks the same in Notes 8.5 beta as you might expect)

Notes 8.0.1 client with both fields before editing


2) Firefox 3 before editing (rendered by Domino 8.0.1 on top, CoexEdit on bottom)

Firefox 3 rendered without editing


3) Firefox 3 during editing ("Best Fit for OS" with Domino 8.0.1 on top, CoexEdit on bottom)

Firefox 3 during editing with Domino 8.0.1


4) Firefox 3 after saving (rendered by Domino 8.0.1 on top, CoexEdit on bottom)

Firefox 3 after saving with Domino 8.0.1


5) In Notes 8.0.1 client after saving with Firefox 3 (rendered by Domino 8.0.1 on top, CoexEdit on bottom)

In Notes 8.0.1 client after saving with Firefox


6) Internet Explorer 7 before editing (rendered by Domino 8.0.1 on top, CoexEdit on bottom)

Internet Explorer 7 before editing with Domino 8.0.1


7) Internet Explorer 7 during editing ("Best Fit for OS" with Domino 8.0.1 on top, CoexEdit on bottom)

Internet Explorer 7 during editing with Domino 8.0.1


8) Internet Explorer 7 after saving (rendered by Domino 8.0.1 on top, CoexEdit on bottom)

Internet Explorer 7 after saving with Domino 8.0.1

9) In Notes 8.0.1 client after saving with IE7 (rendered by Domino 8.0.1 on top, CoexEdit on bottom)


In Notes 8.0.1 client after saving with IE7

10) Firefox 3 before editing (rendered by Domino 8.5 beta, CoexEdit on bottom)

For reasons that are not clear to me, the doclinks don't show up at all in the Domino rendering, whether they are from a local replica or not.  I will report that as a bug.

Firefox 3 before editing under Domino 8.5 beta 



11) Firefox 3 during editing ("Using JavaScript Control" with Domino 8.5 beta on top, CoexEdit on bottom)

Firefox 3 during editing under Domino 8.5 beta


12) In Notes 85 beta client after saving with Firefox(rendered by Domino 8.5 beta on top, CoexEdit on bottom)

Notes 8.5 beta client after saving in Firefox


Copyright © 2008 Genii Software Ltd.

Tags: