After the success of last year's GSOC project with Drupal, I thought it would be a great idea to see if we could take what we did there (server-side encryption) and do something similar on the client side. The benefit of this approach is that unencrypted content/data is never seen by the hosting server. So it's not necessary to trust it to the same degree.
The problem with most encryption strategies nowadays is that they require third-party software and/or services, require maintenance of additional keys and/or secrets, and provide an awful user experience.
Drupal's strength as a content management framework is in its ability to effectively manage and display structured content through its Web user interface. However, the out-of-the-box system assumes all data is local (stored in the database). This can present challenges when attempting to integrate remote data stored in other systems. You cannot, by default, display non-local records as pages. While setting this up is in itself a challenge, it is an even bigger challenge to manipulate, aggregate and display this data through Views.
In Drupal 7, there's no forward-looking native method for managing hierarchical data. We do have the Book module, but it's old and hard-codes things that can be done in a more general way. For example, it's using its own database table instead of using the Field API.
We can do a better job of creating book sections and subsections, say, with some contributed modules and a little bit of recursion.
Versionable content in Drupal has always suffered from inefficient storage. Each new revision of a content item (historically a "node", but now anything that's fieldable, an "entity") is stored in its entirety in the database. For sites with lot of content, and continuous updates (new revisions) of that content, the database size can grow extremely large over time. This becomes a serious problem for maintenance and disk usage.
