Wow, I am in the need to rant against Moss. That's how ungrateful I am.

I do not think I am asking too much of one of the flagship products from Microsoft. A product that it's meant to be (amongst 1500 other things -I feel pity for the guys writing the features document for Moss-) the web content management solution (once CMS is defunct) offer from Microsoft. Note that we are not talking about a 3-odd employee shop somewhere in a remote country serving solution for local clients doing some niche activity.

I truly think there is still a market for web content management (despite the plethora of solutions available) and I think that if Microsoft is competing somehow in that area, they have to provide a good enough solution.

I am wrong. Don't get me wrong, I think that Moss is a good product (not great, but very good for some scenarios). I might even say that it's suitable for ECM scenarios (again not great, but I don't have that broad experience with other products). But COME ON!!!

Let me elaborate a bit. We have a web content management solution (Moss). Web applications have, amongst other things, a bunch of images to display. Depending on the size of the web and its targeting, I would say that thousands of images are not that many images to handle. Applying first-grade logic:

• Microsoft have a ECM solution.
• ECM solutions usually handle lots of images.
• Microsoft's ECM solution must be able to handle lots of images.

Logic has never been one of my strengths, but I think it's more or less right. Logic lies!!!

Applied to my current project: let's imagine a not so big catalog of on thousand products. Let's say that every product has an average of 4 images (again, it's not that high). That makes 4 thousand images. According to capacity planning guidelines, if we store all images into a single library we are going to have problems. Recommended limit of a container is 2, yes, read again, two, TWO, DOS, II... thousand elements. Above that number they suggest there might be poor performance (and if they suggest so, it will happen) when listing them and that it might be better to create sub-folders or handle rendering yourself not using the out-of-the-box user interface.

Why they have to impose an artificial container (folders) hierarchy on my usage of their application which user interface allows pagination and filtering and search facilities? Why would I have to spend more money creating a new application of top of the data I store in your application?

It's not a limitation on the storage infrastructure. It's not that the API used to get those elements cannot perform. Its plain and simply sloppy programming of the application that displays the items.

And do not say that it's not, because of one of the answers on how to overcome the issue is: create your own application to handle the rendering of the elements of you "oversized" list.

Come on, Microsoft! You give us an extremely flexible and feature-full  platform and you wrap it up with a crappy web application that chokes when displaying 3000 thousand elements in a paginated manner?

Is it the image of enterprise product that you want to transmit?

Imagine telling an enterprise client: "Sorry mate, but you can't store more than 2 thousand rows in a table in our database. You better come up with a quick archiving solution or keep your sales level low in order not to make our database performance crawl".

Be serious.