Thinking off of the top of my head converting AMS skinny to AMS generic storage would pose these problems, all of which are not insurmountable but its reasonably tricky:
1. Postgres has a limit of the number of columns that can be in a table, so we might need to create secondary storage tables for sites with many attributes, i.e. persons, persons1, persons2, etc.
2. we would want contact and mime_type for all richtext widgets, etc. So the oclumsns do add up
3. Multiple widgets (checkbox, multiselect) would likely require a column per option (and then be true, false or null), this could mean many, many columns are needed
4. I think it would make sense to store revisions in skinny and live data in the type specific storage type, that way searches and retrieval are fast for live data and the revisions are still there and a bit slower. Speed for frequently accessed data, efficient storage for infrequently accessed data.
5. Re-writing the storage part of ams to deal with type specific shouldn't be too difficult. Re-writing the contacts searches related to this would likely be a lot more tricky (or at least time consuming).
Anyways, I can think of a lot more specific concerns but this I think sums up the main conceptual issues related to such a re-write.
