Reader fields for large user populations (Extreme Edition 2.0)

The last attempt to work with large number of entries in reader fields didn't work that well, so I try again. Andre suggested to limit the number of entries for performance (and after all if there is any breathing human inside the little yellow bubble understanding Domino performance it is him): " The other thing to think about is performance. When a user opens a view, the server has to decide which documents they have access to. So it takes a list of their groups and roles, and compares each of them to the Readers list of each document. If the user is in 30 groups and there are 500 values in the Readers field, that's 6000 string comparisons to determine that the user doesn't have access to one document. Multiply that by the number of documents in the view." So here is the plan:

• The class signature stays the same as in the previous version. Signature means: the properties and methods and their parameters
• Every application gets an unique identifier, so distinct group names can be build
• Once the number of entries reaches a threshold automatically groups are created in the NAB (That group creation for sure could be subject to great debate. Here are the options I was thinking about:
  • Allow direct access to the NAB to create/update groups. This option is feasible when the class is used for a web query save agent and the agent signer has sufficient rights
  • Store the names in Names fields and have a separate "When documents have been created or changed" agent process the changes
  • Use a "Run-on-server" agent and provide the document via the agent context (This also requires to "buffer" the names in Names fields
  • Use a web service to update the NAB
  • Use a mail-in database to handle request
• The DocumentUniqueIDs of all documents in use are recorded, so access becomes much faster (getDocumentByUniversalid vs. getFirstDocumentByKey)
• Not considered: check for duplicate groups - as in: check if a group with the same members. That would open a Pandora's box of checks: what to do if one document alters the group?

I updated the class and implemented "direct NAB update" and "mail-in a change request". The class picks on the basis of access to the NAB. Currently it works for server databases only (not local replicas, some more logic needed there) and it doesn't capture the UNIDs of the group documents. Further more it is lacking better error handling and documentation. Have a look at the modified class.
As usual: YMMV.