For better flexibility and modernisation, my suggestion is an API at the C++ level that returns a collections of all the properties. Yes, this could be coded for each language in turn, but I'm thinking bigger than that:
- Add the ability to ignore / include system fields - you may not want those
- Add the ability to filter on field types or anything else relevant - e.g. get all Reader fields, Names fields etc, get all text lists, get all encrypted fields
- Include the date/time corresponding to Seq Num, to make it easier to work this out. You can get it from the Item, it would be great to have that included in this API
- Filter / sort on last updated of an Item
- Extend this to identify if last modified was on a different server(let's think big!) and server name
- Return the appropriate object type - not sure what for LS to enabled filtering etc easily. For Java, a collection (not using Vectors). For DominoDB npm module, JSON obviously. But also "asJson()" methods for other languages.
- I'm not sure how Document Properties works under the hood for multiple items with the same name. That needs considering here.
- Maybe extend the Json handling methods to allow filtering via methods/functions rather than just return the basic object and let the user do it
- Add Document.compareTo(Document) to return the same object where fields are not the same value
- Add Document.compareToConflicts() to do the same kind of thing
- Developers will be able to leverage it in their own applications
- An XPages component could easily be built or delivered (by HCL or the community) to display this, similar to the File Download control. A React component could also be developed.
- It might facilitate modernisation of the Document Properties box in Notes Client. It would certainly provide opportunity to enhance it.
Document properties and Seq Num give Domino massive power over other NoSQL databases. Readers, Authors, Names fields also give benefits. An API will give the facility to bring this power to a wider audience.