Genii Weblog

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

Thu 21 Jul 2011, 05:09 PM
Note: I accidentally posted this earlier without its content. I thought it was in draft, but no. Oops!

A question came in from a customer today regarding why CoexLinks did not process a message that was already in MIME, and whether there were other flags or conditions that would prevent a message from being processed. I thought I'd share and elaborate on the answer to give an idea of how CoexLinks works.

Answer (modified slightly to clarify for blog):

It is a basic assumption and requirement for CoexLinks that the message be in rich text format. There are two reasons for this. The first is that after the conversion to MIME by the native engine, some of the loss of information has already occurred. We could still read the MIME (the engine has that ability for other reasons, but it is not used), but if the information to generate a better doclink is gone, we cannot retrieve it. The second reason is that a great many messages would have to be processed that shouldn't need to be. Since every email routed through a server would need processing, all the inbound mail (already in MIME) would be processed, as well as any email already converted by a client or server that routed through your gateway. That would be a huge load added to the server for many companies, with virtually no gain.

That said, here are the tests applied to a message to determine whether to process it at all. The order is determined by the philosophy that you should do the least processing necessary to determine whether to skip, as CoexLinks scales up to very, very heavy loads. The first four checks are unlikely to apply to most people, but I added them for completeness sake. Numbers 5 and 6 are the ones which block the majority of messages that are blocked.

1) If the environment variable COEXDocLinkType is set to 0 (usually a temporary way to turn off CoexLinks), skip processing.

2) If the environment variable COEXLimitToDB is set (not common), skip if the database is not one of the specified databases.

3)  If any of the environment variables COEXExcludeHintServer or COEXExcludeHintServers or COEXIncludeReplicaID are set (not common), skip if the hint server or replica id doesn't match criteria.

4) If the environment variable COEXSkipNoLinksItem is set (only used in very heavily loaded systems with no mails created by agent), skip if the $Links field does not exist.

5) If the COEXStampDate item exists and has a time within the last five minutes, skip processing. This item is set by CoexLinks to ensure that multiple servers don't need to process the same message multiple times.

6) If the Body item is already in MIME, skip processing.

7) If the COEXDocLinkType is set to 2 (generate NDL attachments) and there are already NDL attachments, the message is skipped. This check is going away with Version 3 because there are corner cases where it does not process replies and forwards as it should.

Copyright 2011 Genii Software Ltd.


Thu 7 Jul 2011, 11:20 AM
The easy part of writing software is often "making it work." It may take a lot of time and effort, but if you plan appropriately, design carefully and develop to meet your specifications, the software will eventually work.

The hard part of writing software is "making it easy." It takes effort at every stage, from planning to design to development, and still you are likely to miss the mark. So, you re-design, re-develop and keep working. Losing patience means off-loading the effort on to your customers, who may not be interested in a harder process or less intuitive interface.

With that in mind, I am close to introducing better support for XPages and CoexEdit. First, I made it easy to handle a known template, the ND 8.5.2 Discussion database, by simply adding a Notes.INI line CoexEditRecognizeDiscussion=1. No design changes necessary, but also dedicated to a single template. 

It has been harder to make things easy for any potential XPage application. I tried various methods for identifying the custom/bespoke application, but some were too cumbersome or convoluted, while others were too draconian or resource-intensive. The current plan includes two or three steps, depending on the application.

Step 1) Add a Notes.INI line CoexEditEnableXPages=1

Step 2) Add a text field, $CoexEditXPage on any form (not XPage or Custom control) that contains rich text fields to be handled. It can be computed or set, but a value of "0" means the form does not use CoexEdit, while "1" (or higher) means it does.

Step 3) If there is more than one rich text field, or if there is one which is not named "Body", add a text field, $CoexEditFlds, which may have multiple values that are the names of the rich text fields. If the only rich text field to be handled is named "Body", you can skip this.

This may still change, but at least it is close. I might even skip Step 1, and only check for CoexEditEnableXPages=0, with 1 being considered the default. Then, in many cases, only Step 2 would be necessary for adding CoexEdit support to a custom XPage app using a Body field.

Copyright 2011 Genii Software Ltd.