Lotus Notes internal stuffs

Developing an antivirus for Domino vs. Exchange

2010-08-02T03:16:00.000-07:00

If a development company needs to write an antivirus for Domino and for Exchange there will be significant differences that will be analyzed in this article.

First the developers need to choose which technology should be used here. For Lotus Domino the only choice is Notes C API with Extension Managers. For Exchange 2000/2003 they should use store event sinks + CDO + ExOLEDB + ADO or WebDav. For Exchange 2007/2010 they should use transport agents.

One important note here is that in the Domino case, although they should support multiple platforms (Microsoft, AIX, ...) the extension manager and Notes C API did not suffer important modifications since R4. So an antivirus written for R4 can be easily migrated to R8.5 (of course some modifications will be needed). However for Microsoft this is not the case, Exchange 2010 removed CDO, event sinks, ExOLEDB, ADO and WebDav leaving only Tansport agent so the antivirus should be rebuilt from scratch.

Basically talking in Domino the antivirus is an extension manager (a library) that intercepts all messages updated in the mail.box and each msg is put in dead state so later this message will be scanned by a server task which will remove the dead state to let the router route it. It must be written using C/C++ that is a language that consumes less CPU and memory than scripting languages. The Notes C API is the native API (lower level) and it is the same API used to write Domino itself... so it has a very good performance. Here the antivirus is fully integrated to Domino and it is like a native component (like another addin task like the router, indexer, agent manager, ...)

In Exchange there are two implementations:
For Exchange 2000/2003 a wide store event sink must be written and it will intercept each email written in the store (notice that this is a kind of storage notifier and not a delivery notifier). The event sink is triggered for each action performed on each email of all the users.
If you send an email to 10000 users then the antivirus will be triggered 10000 times... in practice you only scan the first email putting a flag and the remaining 9999 emails will not be scanned because the flag is already present... but analyzing 9999 emails for the flag existance takes time. CDO, Event sink, ADO, and WebDav are just wrappers... they are not the native API. You can still write C++ code but all the calls must pass through these wrappers so the performance is poor. You are called for each email and at the time you are called you must scan the email (no dead state approach can be used here). Comparing it with Domino, it is like if an extension manager analyzed each email modified in each user DB instead of intercepting emails directly in the mail.box (that is by far faster).

For Exchange 2007/2010 transport agent should be used. A transport agent is a a piece of code that is called each time an email is routed / submitted by Exchange. It has better performance since is a delivery notifier rather than a store notifier. It must be written in managed language (.net framework). However in practice the real virus checking is done in C++ and the .net library communicates with the C++ library to see if a given attachment is a virus.

So Micosoft did a good job in removing CDO, ExOLEDb, and all this stuff and introducing transport agent + EWS.

Now, as a developer I see that IBM (in fact IRIS on its origin) did a very good job with the Notes C API since the core architecture is the same since R4... As a developer I feel more comfortable developing under Domino. The problem of Microsoft is that they never expose any native API but only wrappers and these wrappers gets improved version by version. They needed so many years to discover that the event sink were not working properly in Exchange and they introduced a new technology in a mature product. Even more, transport agent have significant improvements introduced in Exchange 2010.

My feeling is that Microsoft is not really helping developers to do good components, while Domino does a better job by providing the native API (documenting some more stuffs would be great!).

I don't really know the reason why Microsoft does not expose the native API exposing wrappers that are in theory easier to use but in practice have more limitations. Maybe because they suffer more cracker "attacks" and exposing the native API would be more dangerous, or maybe because they want to do all by themselves and not to let other vendors to do components.

On the top of that they force you to use the .net framework that is a good framework but it is still a scripting language. I wonder whether they use .net in their own core components of Exchange...

Administrators should not panic: Antirivus for Domino and Exchange are working just fine but when evaluating them they must see in Domino that no Lotus script code neither java code are used (due to internal limitations) because for some vendors it's easier to use Lotus script / java than C++. For Exchange any component that uses vbscript is not really serious (poor performance + very easy to attack).

I think that Microsoft should evaluate providing a native access to the transport layer and to the database store too. If they still want to provide wrappers like EWS + transport agent then it's OK but for advanced components a native API access will really help.

Lotus Traveler scalability

2010-02-02T02:30:00.000-08:00

I had the opportunity to analyze Lotus Traveler internally.
I saw how it basically works and it makes me think about scalability.
What the traveler server task does is to periodically (some times per second) call an API that will return which databases were modified since the last polling time. So it obtains the list of databases where at least one document was modified by calling the undocumented function NSFGetChangedDBs. It then exports another function _java_com_lotus_sync_dca_access_NativeAccess_jniGetChangedDbs@36 so this java native function is finally used by the server task (that seems to be coded in java).
Once it calls NSFGetChangedDBs, it calls another API to retrieve the list of modified documents for each DB since the last polling time and it exports it in the java function _java_com_lotus_sync_dca_access_NativeAccess_jniGetModifedDocList@48

The java server task pseudo-code would like something like
while( StillMustRun() ) {
DBs = GetChangedDbs();
for each db in DBs do {
  DOCs = GetModifiedDocList(db);
  for each doc in DOCs do {
   ProcessDoc(doc)
  }
}
Sleep few milliseconds
}

In my opinion, it works just fine if you have few databases that are affected by Traveler, but if you have many users using traveler then all this mechanism will just consume memory and CPU to your server.

I suggest using an approach where an Extension Manager calls a callback function when a new document is added to a database. So the extension manager itself can filter (in the callback function itself) the DB (the comparison is pretty fast since each DB has a GUID (number) and it would be just a matter of searching the current DB GUID in this sorted GUID list) and if the DB is a "traveler-aware-DB" then it would add the new created document in a global shared memory list, and the traveler server task would just poll this list periodically thus consuming by far less CPU. This approach has more scalability.
Internally talking is also easy and the traveler server task can still use java... but the API dll would just use this shared memory table instead of calling the APIs periodically.

Are Notes/Domino APIs good?

2009-12-23T07:10:00.000-08:00

I've been programming with Notes since 1996 using the Notes C API. But I also had the possibility to use other APIs like the Exchange APIs, Windows API, and many others. I also programmed in other languages like Java, VB.
People don't like programming in C++ because this language requires a large learning curve, but in fact once you learn C++, you can "come back" in ten years and this language will not change. I mean, it does not require (the language itself) you to keep updated with this language. VB or .net are different cases, each version of VB or .net requires programmers to buy new books and learn the differences (that's part the Microsoft market) to keep programmers up to date.

The Notes C API itself did not suffer modifications since many years... some few new APIs were added year past year but nothing that you cannot learn in half a day.

So being a C programmer using the C API is pretty comfortable once you have learnt it.

The Notes C API is the lowest level API you can use... the Domino server tasks and the Lotus Notes workstation themselves are written upon this API. In the Exchange world there are several APIs... although most of them can be accessed in C++ they are not really low-level APIs but wrappers. You never have low level access to the internal services of Exchange. And the worst thing is that for example in Exchange 2010 some APIs that were supported in previous version don't work anymore!!!

Developing under Exchange is by far more complex than under Domino. Let's suppose an antivirus programmer. This programmer develops the AV for Domino and for Exchange. This programmer will only have 1 version for Domino... but for Exchange they will need to have 1 ersion for Exchange 2003/2007 and another version for Exchange 2010!!!
Events in exchange 2010 is a weird stuff. You need to use COM+ components and you will be called back for each email that is processed... you cannot control when this component is loaded, you don't have controls over threads, so you cannot implement a good load-balancing model.

Even the Windows 32 API suffers more modifications than the Notes C API. Each new operating system provides new APIs (e.g. in Vista you need to learn about UAC, and the internet explorer protection mode and many other stuffs).

Last thing I want to mention is that it's a pitty that the Notes C API lotusphere session is not longer available since 2008.

IBM should provide a better "Extension Manager" support for Domino server developers

2009-12-02T03:05:00.000-08:00

There is a typical problem with Extension Managers and antivirus. As many of you may know, this is how a typical antivirus/antispam/disclaimer works in the Domino server:
When an email arrives to the mail.box, the antivirus extension manager changes the RoutingState field to "DEAD" or "HOLD". Then the Extension Manager "tells" the main antivirus server task to process this DEAD email. The antivirus processes this email and then it removes the RoutingState field so the router can deliver it.

The problem appears when you install two components doing the same approach. For example an antivirus and a disclaimer. Both will need to put the email in DEAD state and here if none of these products takes care of this situation (that is not easy to do so) then there will be emails that will not be scanned or will not have a disclaimer since there will be a synchronization problem.

The solution would be to provide another notes.ini parameter like
EmailExtMgr_Addins=antivir,disclaim
So when an email arrives Domino will put the email in dead state, then it will first call "antivir" and after that it will call "disclaim" and after that Domino will remove the DEAD state so there will be no synchronization problem.

How to recognize a good Notes component...

2009-10-28T04:08:00.000-07:00

I will discuss here how to recognize a good component. By component I mean an external software that is installed as a module and it extends Lotus Notes or Lotus Domino. For example an antivirus, or a disclaimer.

A good component will always meet the expectations without giving too much work to the administrator.

Here are some tips that are useful when you evaluate a Lotus Notes/Domino component:

* It must be built using the Lotus Notes C API: Many components uses Lotusscript or formula or java or the C++ API. Lotusscript has serious disadvantages for example agents in the server have a time limit and it consumes CPU. The java API or the C++ API are just wrappers of the Lotus Notes C API.... so it's just another layer that makes the development of the component easier. Developing a component in Lotusscript or Java or even the C++ API is by far easier than developing it in Lotus Notes C API. Again, for the vender it's easier (and cheapest) NOT to use the Notes C API since development is faster. The Lotus Notes client and the Lotus Domino server themselves are written using the Lotus Notes C API... the indexer, the replica task, the Notes client and all internal components uses this API. As you can see if the component uses this API then it will be at the same level than the Notes client or the Domino server. It's a native API. The C++ API for example will be discontinued (it is already discontinued) by IBM... they said it in Lotusphere 2009. The Notes C API is the lowest-level API so it provides with with full capabilities. If you as a customer wants your vendor to do an enhancement to a product, if your vendor uses the C API then it will for sure be able to implement this enhancement.

* The component should not modify any Lotus Notes DB template. It's easier for deployment purposes to modify the DB templates. However when it's time to do an upgrade or to modify the template then here problems start. Consider migrating from 8.0.2 to 8.5.1... templates will need to be also migrated so you will loose the vendor components, or you will need to do extra work to also migrate the vendor component. If you have two components from two different vendors that modifies the templates then you will be in serious problems. Uninstalling code from templates is a mess if you have modified the same template for other purposes...

* Ask to other customers to see if the component is well working. Usually in the site of the vendor you will find the customers... feel free to contact them to ask about post-sales services. If you go to notes.net you will find many questions from customers using antivirus from serious vendors where they don't answer their questions or they say "wait 6 months and in the next release it will be fixed".

* A recent version number with many nice features does not mean that it's more stable than a previous one. The more things they provide in new releases, the more complex the component. As you know, Domino 7.0.3 is more stable than R 8.0.1 for example.

* A crash during the testing phase is a REAL OPPORTUNITY!!! A crash does not mean that the component is really bad. All components crashes... even Domino itself crashes as you already know. So if you find a crash during testing phase then this is a opportunity since you will be able to ask the vendor for a solution and you will evaluate the support. Don't interpret a crash as a fatal bug, it's a bug that affected the memory and it caused a crash... the same bug could have affected other things than the memory. Again, take into account the time it takes to the vendor to solve the problem.

* Deployment. Deploying a server component is straightforward. But depoying a client component is harder. There are many ways to deploy a client component. Sending emails to the users to ask them to execute an attachment, sending an email to all users with a stored form that silently deploys the software, modifying the DB template, and so on... a good component's vendor is not the one that tell you "this deployment method is the best, bla bla bla". A good vendor will ask you "which deploying method from the following list do you prefer?". Again, a good vendor invest time and effort in software to make administrators happier.

* Compatibility with other components. Making one component compatible with another is not easy. There are things that cannot be always covered. For example if you have an antivirus and an antispam (usually they are joint but just for the example purpose) from different vendors then you will usually have a synchronization problem. The best component will provide you with a mechanism to configure itself in such a way that it can recognize the other component. For example an antispam can recognize that an antivirus is installed... so it will wait for the antivirus to do its job and then the antispam will do its own job. In this case the antispam is a "better component" than the antivirus since it implements all the synchronization mechanisms.

I hope it helps you to evaluate a component. Evaluating a third party solution is not an easy task...

Main Lotus Notes workstation dlls and their meanings

2009-07-17T11:52:00.000-07:00

If you list the .dll files that are installed in the Lotus Notes workstation, you will see that for example in R8.5 there are more than 300 dlls.

However the main (or most known) dlls are three:
nnotes.dll
nnotesws.dll
nlsxbe.dll

The more important is nnotes.dll that is the Lotus Notes engine. This dll is also present in the Lotus Domino server installation. This dll contains all backend functions that are used by Lotus Notes. This dll exports all NSF and other backend functions.
In fact the Notes C API is in fact a documentation of some functions exported from this dll. This dll exports nearly 13.300 functions from all these functions only 1100 are documented in the Notes C API reference.
The Lotus Notes workstation in fact is just a program that uses this dlls and provides services in a graphical way.
The server tasks (update, amgr, ...) are just programs that uses functions from these dlls.

Now the nnotesws.dll implements all visual aspects belonging to the Lotus Notes workstation. It renders the view, the forms, the workspace and so on... it is like the shell32.dll file in Windows. The nlnotes.exe program delegates most of the visual aspects to this dll. When you select files from a view and you drag them into another place all is managed by this nnotesws.dll. When you open an attachment, it is managed by this dll.
To put a single example. Suppose that you copy part of the email you are viewing. In this case nnotesws.dll calls the OleSetclipboard API filling the information.

nlsxbe.dll is all about programming in Lotus Script and formula.
It is like a kind of wrapper that translates the Lotus script code (or formula code) into Notes C API calls.

There are many other dlls, all of them are important... but these 3 dlls are known by many people but not all them know what they are related to.

Copy-paste in Notes is sometimes "native"

2009-06-01T04:54:00.000-07:00

When you copy something in an application, the application calls the OleSetClipboard or SetClipboardData APIs to really fill the clipboard content so other applications can use them when you do a paste operation.

Usually you fill the clipboard using many formats and it's OK that the "more representative" format is a native format. For example in Notes when you select things from a RichText field and you copy them, the "Notes Editor Internal" or "Notes Private Data" formats are used.... thus when you paste it inside the same Notes application then Notes will really paste the real content without loosing information. But Notes also copies the "Rich Text Format" that is also known by Word or Notepad.

This behaviour is typical and it's OK.

Problem is when you copy a document from a view. Here the above APIs are not used... Notes fills an internal buffer and it does not use the clipboard. For example if you copy a text (e.g. from Notepad) into the clipboard, then you go to Notes and you select few docs and you copy them then if you go to Notepad again and you paste the content, the original content you copied from Notepad is still in the clipboard! And you can paste the documents in the view at the same time.
The same if you first copy a document from a view, then you copy text from Notepad... you can paste text inside Notepad again and the document inside Notes again: It's like if Notes has a pararell clibpard.
However if instead of Notepad as the source app, you use Notes and you copy text from a Notes rich text field then here the clipboard behaviour is like any other standard application and you loose the last clipboard content.

I think Notes should use the clipboard and among than copying an internal reference (propietary format) that is OK, it should also copy an .ndl file, and the columns concatenated by "," as CF_TEXT.

$KeepPrivate is worse in R8.5

2009-05-29T20:04:00.000-07:00

It is known that the $keepPrivate is easy to crack. Remember that the $KeepPrivate flag is a field in a document and if this field is set then when a user sees this document, this user should not be allowed to "share" the content of the document. So the user will not be able to forward, print, copy doc/content, or export.

The internal implementation of pretty basic. In fact the Notes client will give an error when the user tries to perform any of the forbidden operations.

Now you can (as you may know) write a simple agent that removes this field and after that any user can do whatever he/she wants.

Also you can make print-screen...

You can also access the content using backend access (Lotus script, Notes API, COM classes, java, ...).

But with R8.5 there is a clear bug and you can do the following to extract information:
* Open the document that is supposed to be protected (e.g. Doc A)
* Select the content of this document
* Create another document (e.g. Doc B)
* Drag the selected information from Doc A to Doc B and the content will be copied!!!
You can drag the content to Winword for example...

So it seems the Notes client team missed this point.

My opinion is that the $KeepPrivate should be reimplemented in a stronger way:
+ Attachments should only be viewed and the content of the viewer should not be copied. It has no sense to only protect the content of the document and leaving users opening or saving attachments
+ This described drag issue should be fixed
+ Print screen should not be allowed. This is not an easy point but it can be implemented with some tricks.
+ The $KeepPrivate internal implementation should be quite similar to the $UpdatedBy... so this field should be mantained in the Notes backend (nnotes.dll). When a document is updated, it should reset $KeepPrivate to 1 if when opening it it already had this value.
+ Does it makes any sense to allow user to select part of the doc content if the user is viewing a document having the $KeepPrivate set to 1?
+ To cover the case where extern process access the content, this content could be encrypted and be decrypted only by the following modules:
* Notes client (since it needs to show the content)
* Updater task (to full text index)
* http task (so DWA can keep showing it)

My 2 cents on improving security in Notes.

How the update task internally updates the Full text search index.

2009-05-21T20:31:00.000-07:00

The update task (nupdate.exe in Windows) is a server task. The basic algorithm is quite easy. It first opens the DB:
STATUS LNPUBLIC NSFDbOpen(
const char far *PathName,
DBHANDLE far *rethDB);

Then it calls this API:
STATUS LNPUBLIC FTGetLastIndexTime(
DBHANDLE hDB,
TIMEDATE far *retTime);

The first parameter is the database that was opened, and the second parameter (output parameter) returns the last time (TIMEDATE) the index was done before.

Then it calls this API:
STATUS LNPUBLIC NSFDbGetModifiedNoteTable(
DBHANDLE hDB,
WORD NoteClassMask,
TIMEDATE Since,
TIMEDATE far *retUntil,
HANDLE far *rethTable);

This API returns the documents that were modified after a given time.
The first parameter is the DB, the second parameter is this constant: NOTE_CLASS_DATA and the third parameter (Since) is the TIMEDATE that
FTGetLastIndexTime returned. The retUntil and rethTable parameters are output parameters.

Once the server task calls NSFDbGetModifiedNoteTable it knows which are the new documents that were modified since the last time the index was done.

After that it opens each document (obtained from the rethTable parameter) and it updates the local index based on the document data.

Finally it updates the last index time (unfortunately this API is not documented) using the retUntil parameter that was filled by NSFDbGetModifiedNoteTable so next time nupdate is executed it restarts from this last time.

I showed here a brief description of the nupdate task. As you can see most part of this task is documented.

In this article I showed how to write your own indexing task (you can follow this procedure to detect which documents needs to be indexed and use a custom indexing algorithm). In a future article I will propose a custom search implementation that would use your custom index and it would reuse the full-text-search UI workstation capability so the indexing and the searching would be transparent to the end users.

NoteID, UNID, DBID, ORIGINATORID....

2009-05-21T19:59:00.000-07:00

So it main sound obvious but these IDs have significant differences.
NoteID and UNID are identifiers that apply to documents.
The NoteID is a number that uniquely identifies a document. This number is frequently represented in hexadecimal. It is a DWORD and it is a 32-bit number (even in 64 bits systems) so it can hold up to 2^32 numbers. However when you create two consecutive documents, then this number is increased by 4. It means that if at time 0 you create a document then this document will hold (for example) the NoteId 100 and if you then create another document in the same DB then this new document will now have the number 104. If you delete this document having the number 104 and you inmediately create another document, this new document will be 108 and not 104, so the NoteIDs are never reused.
NoteIDs and remaining IDs (UNIDs, DBID, ...) are always represented in hexadecimal.

Now, the NoteID identifies a document in a DB but not across replicas. If you have two replicas then each document in each replica will have its own NoteID. So how can you know if a document is the same in two replicas? Using the UNID that is also known as UNIVERSALNOTEID.
Internally talking, a UNID is composed with 2 components:
The File component and the Note component.
The File component is a DBID (see below) and the Note component is the date/time when the very first copy of the document was stored into the first NSF.
The date/time in Notes is internally represented using two DWORDs. So the Note component is in fact 2 DWORD (32 bit each DWORD).
The DBID is also a time... It means that the UNID internally occupies 4 DWORD that are 128 bits against the 32 bits of a NoteID.

If you want to choose which ID to use to identify a document in your application, the UNID is better since it will work across replicas.

Now it comes the ORIGINATORID... here things starts getting more complex.
The Originator ID (OID) for a document identifies all replica copies of the same document and distinguishes between different revisions of that document. It is composed of two parts:
- The UNID
- The Sequence Number and Sequence Time.

If one document in one database has the same UNID as another document in a replica of that database, then the two documents are replica copies of each other. The Sequence Number and the Sequence Time, taken together, distinguish different revisions of the same document from one another.

The DBID uniquely identifies a DB. The DBID is different for each replica of the same DB.. Internally talking it is composed of 2 DWORD members that identifies the exact DB creation time (unit of time is 10 milliseconds so it's quite unlikely that two DBs are created in the exact same time).

In this document I explained the main IDs... there are other IDs like for example the RRV which uniquely identifies attachments inside a DB, but I will explain them in future articles.

How a Notes view is internally navigated

2009-03-13T06:48:00.000-07:00

A Lotus Notes view is a collection of documents. Internally talking (from the Notes API documenation) a view is also a "collection."

So what happens when the user opens a view in the Lotus Notes workstation? Does Lotus Domino server return the entire view to the Notes workstation? In fact when the user navigates a view, Domino only returns a "chunk" of documents to the Notes workstation. Else (if the entire view was read) it would take lot of time to read the view content.
So when the user opens a view, Notes requests only some documents. For example let's suppose a plain view (without categories) and in one window Notes can show 20 documents. When the user is viewing a view Notes may request for example 100 documents: the 20 documents to fit the window plus 40 documents before the first shown document plus other 40 documents after the last document being seen in the window. By this way if the user navigates the view scrolling down then the information is already in the client side and Notes does not need to ask the server for these documents... when Notes is approaching the end (or the beginning) of a chunk, it queries another chunk.

When you expand a category Notes needs to get another chunk, the same if you go to the end or beginning of a view, or if you go to a given position of the view by dragging the scrollbar control.

As you can see this is a very efficient way to navigate a view.

Notes uses the Notes API functions to navigate a view. The main used function is NIFReadEntries. This function admits 12 parameters:

STATUS LNPUBLIC NIFReadEntries(
HCOLLECTION hCollection,
COLLECTIONPOSITION far *IndexPos,
WORD SkipNavigator,
DWORD SkipCount,
WORD ReturnNavigator,
DWORD ReturnCount,
DWORD ReturnMask,
HANDLE far *rethBuffer,
WORD far *retBufferLength,
DWORD far *retNumEntriesSkipped,
DWORD far *retNumEntriesReturned,
WORD far *retSignalFlags);

IndexPos is the exact position in the view from where the chunk needs to be read.
ReturnCount indicates how many documents needs to be read (in the previous example it should be set to 100).
The remaining parameters can be found in the documentation, but what I try to show you is how Notes uses this function to navigate the view.

What does this function return? Does it return the NoteID or UNID and then Notes opens each document to retrieve the fields to be shown in the view? Not really. If Notes opened each document to retrieve, for example in an email database, the subject or the delivered date then it would loose performance. What it does is to retrieve only the information to be shown in the view (it is called Summary buffer, I will explain it later in another post). So Notes does not need to open any document to show the view content. For each row (or document) in the view, NIFReadEntries returns packed data with the subject, delivered date, size, ...

What about readers? When a document is not shown in the view (because it contains reader fields) the job is done by the server... and it is an intensive job! It moreless needs to sequentially skip each document that does not need to be shown. So suppose that you are browsing a view containing 1.000.000 of documents but you are only allowed to see the first and the last document from this view. The Notes client will simply call NIFReadEntries and the server is the one that will need to skip 999.998 documents. The CPU (and I/O) consumption will be done by the server and not by the workstation. As you can see, reading a view that is affected by reader fields causes serious performance issues.

Is there an accurate way to know how many documents are in a view? It will sound strange but there is no accurate way to know how many documents a view contains! Only if your view is plain (that is, it does not contain response documents neither categories) then you can call this Notes API function: NIFGetCollectionData. The other alternative to get the total number of documents is to fully navigate the view.

This is the reason why the scrollbar control does not have a good behaviour for views having categories (specially when they are expanded).

I will propose a new feature that could be useful and very easy to implement by the Lotus Notes client developers at IBM. Suppose you have a view that shows all the bids and this view is sorted by the bid date. Now suppose that you want to view only bids from a given date (e.g. 01/01/2008) to another given date (e.g. 12/01/2008). In this case the view object should expose a new method like "FilterView". And you can simply pass these two dates in this method. Then internally talking is pretty straighforward to implement it: It's just a matter of locating the first date by calling the NIFFindByKey API and then locating the last date by calling the same NIFFindByKey API. And here you will have the "initial" and "last" COLLECTIONPOSITIONs that will indicate the bounds of the view. The only requirement is that the view should be sorted by bid date.
This is similar to the show-single category feature but more flexible.
Suppose you have a view showing names... and the first sorted column is the surname. And you want to see all documents where the surname starts with S or T or U. In this case you can apply the same exact logic.
So with this proposal the LotusScript and Formula developers will easily filter the view dinamically without causing extra costs (like creating views with different formulas).

Well, in this article I shown how views internally works and I proposed an enhancement.