IBM®
Skip to main content
    Country/region select      Terms of use
 
 
   
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks  >  Lotus  >  Forums & community  >  Best Practice Makes Perfect

Best Practice Makes Perfect

A collaboration with Domino developers about how to do it and how to get it right in Domino

... means something different to Domino developers than it does to the general populace.

I've been having a look at the Replication Conflict Management tool on openntf.org, and it looks like a nice tool for administrators and database owners. There is one problem I see, though, and that's that there's no side-by-side comparison of the documents themselves. If you want end users to resolve their own replication conflicts (they being the ones who know best what's supposed to be in the documents), it would help to be able to scroll them together, edit one of them, and copy-paste information from one to the other, as well as having the display of which fields are different to help them find the changes. The problem with a text-only compare, is that not all content is necessarily text.

side-by-side main and conflict docFor an internal application, I've been working on a tool to do this. I've got it set up as a separate database. I can select or open a replication conflict document in any database, click a toolbar button, and I've got this nice UI that lets me browse the differences and edit one (or both). The bottom of the screen shows a list of the different fields and their values. You can scroll them separately using their scroll bars, but there are action buttons at the top that let you scroll the two sides by the same amount, making it simple to visually search for differences such as a picture being in one but not the other...

external diff toolOne of the action buttons, labelled "diff", exports both documents into text files and launches an external tool (you can configure the launch command line). I use WinMerge, which is open-source and free.

There are also action buttons to choose one document as the "winner" (perhaps after editing). This would flag the other one for soft-deletion, or take another action as appropriate to the application in which they appear -- for instance, users don't have access to delete documents, so we set a field to flag it for an agent. This depends on embedding the conflict resolution screen into the application so that there's a place to write the application-specific coding, rather than the current implementation of a separate local database.

All this is useful, but there are a couple of things I'd like to improve. The list of field differences just displays the different values, and I'd like to highlight which words are different. I know there are lots of algorithms for doing this efficiently, but I didn't find one already in VB/LotusScript, and I don't have time to translate one at the moment. If someone already has such a script, I'd appreciate a pointer or copy.

Second, the buttons to scroll the sides together use an OS-dependent implementation of SendKey, which at the moment is only implemented for Windows. I published this library years back as part of Domino Design Library Examples, and have always meant to figure out an implementation for Mac (and now, Linux). Is there anyone out there familiar with the equivalent OS functions for these platforms? (Or, even better, does anyone have an idea how to implement the together-scrolling without using SendKey?

Once I get it working the way I like, I will of course post it in the Sandbox or on openntf.org.

Andre Guirard | 31 July 2007 08:09:07 AM ET | Plymouth, MN, USA | Comments (12)


 Comments

1) $ConflictItems
Rami Jundi | 7/31/2007 11:45:24 AM

Replication conflicts are the bane of our existence in the application I am responsible for. Fortunately over time we have learned to add logic to make an application Notes ID in $Updated an automatic loser and use a "soft-deletion" to remove it.

I accidentally ran across the field $ConflictItems in the document properties and this field seems to document the field(s) that caused the replication conflict.

Do you have any background on this field?

2) re: $ConflictItems
Andre Guirard | 7/31/2007 1:14:36 PM

I accidentally ran across the field $ConflictItems in the document properties and this field seems to document the field(s) that caused the replication conflict.

Do you have any background on this field?

Not really, except I can tell you it doesn't appear to be populated in a save conflict -- presumably only in replication, and then it might depend on the replication conflict handling selected for the form.

The problem with handling a conflict by just deleting one of the documents, is that there is presumably a reason for the conflict -- some information in the document you want to delete that's not in the one left behind. So you're losing some information, and there's an assumption that the information isn't of value, which might not be true in all cases.

3) re: $ConflictItems
Rami Jundi | 7/31/2007 4:11:52 PM

We are using the merge conflicts option.

4) Repl Conflicts are a sign...
Nathan T. Freeman | 7/31/2007 9:06:06 PM

...of a deeper logic or architectural problem in your application. They should cause you to look closer and how your app works.

What would be great is a tool that would offer better trace information on the source and replication path of replication conflicts. Like, something that could tell me what series of users/servers have lead to the conflict being present in a given NSF.

5) re: Repl Conflicts are a sign...
Andre Guirard | 8/1/2007 8:36:19 AM

......should cause you to look closer and how your app works.

I agree that it makes sense to evaluate any application that's having save/replication conflicts to see whether there's a design issue. On the other hand, I can easily think of applications where it makes sense to allow offline editing by multiple people (you can't get a definite lock, if you're using locking) and just deal with the consequences after. Also, of course, I'm a user of many applications that I don't have access to edit the designs of, so a tool that helps me deal with conflict docs as a user, is helpful.

What would be great is a tool that would offer better trace information on the source and replication path of replication conflicts. Like, something that could tell me what series of users/servers have lead to the conflict being present in a given NSF.

Interesting idea. Of course, there's the $UpdatedBy in the two documents, and that will give a clue, but we don't record server information by default, so the application would have to do that -- or a DSAPI add-on on the replicating servers. I would hope that recording the two servers involved at the time the conflict is detected is enough, since having each server that receives it add its own name as it stores it during replication, is likely to cause further replication conflicts.

6) It would be enough
Nathan T. Freeman | 8/1/2007 5:34:14 PM

The main thing is to be able to look at a complex infrastructure and go "how did this conflict get here?" Right now, $UpdatedBy and $Revisions don't cut it. We need more details at the time of conflict creation.

7) Anxiously Waiting
Les Zatony | 8/2/2007 5:34:33 AM

This sounds great and very timely since we desperately need to have users manage the conflicts in their applications. I'm really looking forward to seeing your final product.

Thanks!

8) Conflict resolution
Basir Noutash | 5/9/2008 8:03:25 AM

Hi Andre - Is this database uploaded anywhere yet?

9) Conflict resolution
Andre Guirard | 5/9/2008 2:15:19 PM

Yes -- see my entry of 9/11/07

10) Conflict resolution
Kjell Holen | 9/17/2008 9:47:27 AM

Hi, re database upload, you say entry 9/11/07 but I can not find that. Could you repost where it is uploaded

thanks

11) Code reuse
Jan Schulz | 2/9/2009 7:07:57 PM

I had a look at this DB on how you did the diff and found that there is a whole LS Diffing code in there. Is it possible to share this code under a open source license? I've already played with it (adapted it to spit out non html coded diffs) and I'm just amazed :-)

This could also be a really great addition to the domino wiki...

Kind regards,

Jan

jasc -at- gmx.net or on the bleedyellow IM

12) Conflict resolution
Andre Guirard | 2/9/2009 11:33:02 PM

I don't know whether the diff algorithm is particularly clever; I made it up myself because the lawyers make us jump thru hoops to take anyone else's stuff and adapt it.

We are looking into putting this and other examples on openntf under an apache license, so you would then be able to use it in the way I think you want. Watch this blog for an announcement.

13) Thanks!
Jan Schulz | 2/10/2009 9:18:18 AM

Looking forward to it :-)

I use it to diff text fields on save, so I can write the diff to the history. Works pretty well there! Only thing I had to work around (couldn't figure out how to change it in the algorithm) was some spacing: the space in front and after a word got included in the changes, so diffing

111 222 333

111 444 333

resulted in something like this (I did this two month ago...)

111- 222 -+ 444 +333

It's not a problem in html (colored space = space...) but in plain text like above you see it.

Jan

 Add a Comment
Subject:
   
Name:
Comment:  (No HTML - Links will be converted if prefixed http://)
 
Remember Me?     Cancel

Search this blog 

Disclaimer 

    About IBM Privacy Contact