Duh!ble Storage

It came to me in a flash! The problem, as described earlier is that I use response docs in the aggregator database to represent stories pulled from each feed (represented by the parent doc), but "aging" the stories (via a nightly agent) to provide the web UI with the capability for filtering the last X days' articles screws up unread marks, which interferes with the Notes UI. I was figuring on the solution being using a different data structure for the web UI, I.e.., I was going to create a table in the main docs containing summary information for the last 30 days worth of articles for the feed represented by the main doc. The much better solution is so obvious.... I can't believe I didn't see it right from the beginning.

I just modified the function that creates the response "Article" docs to create both "Article" and "wArticle" docs. The "wArticles" don't show in any Notes client views. The aging agent doesn't touch the "Article" docs. I have the same data structure for both web and Notes UIs, at the cost of double storage -- but that's a cost I'm willing to pay. The huge advantage is that I can use views instead of code to build the article index display in the web UI. The ony downside is that the unread count for the database will be useless, but I think this is also an acceptable price to pay.

This is, by the way, not the first time I've designed an architecture that uses "shadow" storage in order to create the necessary data structures for two different UIs to operate in a natural and efficient fashion. Some might think that doing this is bad for scalability, but I believe they are wrong. The code I would write to do the presentation work based on a single compromise data structure would never be as efficient as Domino's own indexing and view presentation code, and (despite what so many people think) Domino does scale very well.