Only one Alert Handler allowed in Sharepoint

As you know, alerts in SharePoint are triggered when something happens on a file or on a library. An email (or an SMS) is sent for each modification. This can be customized by code by implementing an Alert Handler. Basically talking, instead of the email to be sent, the alert handler calls your code and you are responsible for sending the email (or doing whatever you want).
Here there are several problems. First is that if your alert handler raises an exception then the alert is not sent... nothing happens. So if your application does not behave OK then uses will not receive alerts. The second problem is that the email should be sent by the alert, and optionally if you want to send the alert instead, then no alert should be sent (since you will do it).
To overcome these two cases it's just enough to modify the way IAlertNotificationHandler::OnNotification behaves... if you return true then the original alert should be sent (like if the alert handler was not installed) and if you return false then it means "do not send the alert" and you do whatever you want (even sending your own alert). This is good since sometimes you only want to modify some alerts and not all them.

The third big problem is that you cannot register two alert handler at the same time. Only one alert handler can exist. This is a big problem since suppose that an alert handler is part of a third party product. It means that two third party products that use alert handlers will be incompatible each other. This is because to install the alert handler you must modify an internal XML document and only one entry can be used.

Analyzing this it seems like if when MS was thinking in the alert handler, it was only thinking in corporate programmers (that is, programmers that work directly for a company like a bank) but not in software companies.. like if they are interested in providing APIs to direct customers of MS rather than on independent software vendors.

In my opinion the alert handler should behave like an event receiver where the receiver can cancel the request, and you can have more than one event receiver at the same time.

Shredded storage does not work well when restoring a previous version

As you know in SharePoint 2013 there is a new cool feature called Shredded Storage. It basically means that when you save a document it is decomposed in shreds and in the SQL DB only these shreds are saved. So for example a 1 MB document can be decomposed into 10 shreds. Then if you do a modification on this file only the "affected shreds" are modified. So for example if in the above example you modified only a small portion of the document then only 1 shred would be affected so instead of storing 2 MB (1 MB for each version) only 1.1 MB is stored.

The technology came from SharePoint 2010 but in SP2010 the shreds were used by Office to only send the "delta" to the server... its name was different (Cobalt) but as you see, in SP2010 the focus was put on the bandwidth rather than on the storage since in the server side more IO had to be made to join the delta with the previous file version and in the storage the entire file was saved. It was not a good implementation.

In SP2013 it works fine but it suffers from what in my opinion is a big "logical leak" that is that it does not work if you are restoring a previous version.

Let me show it easily.
I have two files that are completely different. One has 1 MB and the other 5 MB. The name of these files (in both cases) is test_shreds.docx.

I first upload the 5 MB version thus creating version 1. When I go to MS SQL Server I get this:

So you see that at the SQL level it consumes 5 MB.
Then I upload a second version but using the 1 MB file and I get:

Here see that the SQL storage has increased by 1 MB. That's fine until now.
I now upload again the 1 MB file thus creating version 3 that is the same than version 2:

Here see that version 3 is the same than version 2. If shredded storage works fine then the size in SQL should not be increased. Let's try:

   
It works as expected! Now let me upload (not modify, just upload) the initial 5 MB file as version 4:

 

Remember that version 1 is exactly the same than version 4. However if I perform the SQL query I get:

 





See that 5 MB had been added to the storage. In my opinion this is not good since it would be great if shredded storage works accross ALL versions and not across the last version only. However now the situation is even worse. I will take version 3 and I will restore it. So this restore operation will create version 5:

Doing the SQL query this is what is seen:

It means that Shredded Storage does not work when restoring a new file. Just to confirm I restored version 4:

        










And I repeated the SQL query:

And here it is clear that when restoring a file Shredded Storage is not working.

When you restore a file you NEVER restore the last version but ALWAYS a previous version. So  by definition Shredded Storage NEVER works when restoring a file. Just a shame becase it means that for each file a user restore there could be 0 cost in terms of storage and now there is a 100% cost. Even more, in some organizations (maybe in most organizations) the savings that could be obtained by well implementing Shredded Storage to work when restoring a file could be bigger than what Shredded Storage saves now, because now SS (Shredded Storage) only works well if the delta between version N-1 and version N is meaningful, while when restoring a file this is always true.

In my opinion, Microsoft should enable Shredded Storage to work across ALL versions and not only on the last version.