Table of Contents

These comments were kindly provided by Bevan Rudge from, and Jonathan Hunt from e


Drupal core covers everything on the list of requirements out of the box very well with a few exceptions;

  • Object relational mapping, Drupal 7 has PDO, which I think is essentially the same thing. Drupal 6 and below does not have PDO
  • Connection pooling. Drupal itself doesn't support this, but I think it can be done at the database layer. Though DB scalability is well-managed in Drupal, and I'm certain it is a manageable problem with various techniques and solutions. Memcached is one of the more popular ones in Drupal circles at the moment.
  • Error and Exception Handling. Errors are handled very well, but OO-style Exception objects are not used in Drupal. This will begin to change with Drupal 7 as PHP 4 is no longer supported, and real OO techniques can be used.
  • Backup is handled well be several external tools, both specific to Drupal and more general.
  • Unit testing with simpletest is well supported in contrib for Drupal 6 and core for Drupal 7+.
  • Web Services SOAP/ RSS / REST, There is good support in core with extended support in contrib. More of this is moving to core in Drupal 7.
  • SOA is well supported with Views or ApacheSolr integration (contrib), which Acquia now offers as a hosted solution. Drupal core search isn't half-bad either.
  • Strong geospatial capabilities. Drupal has a lot of disparate energy around geo technologies in contrib. There isn't any cohesion or central module or driving force to bring it together though. Perhaps this could be Sahana's contribution to the community? There is a of code for Drupal that can be re-used, but any mildly complex geo-apps need custom code to glue it together, at least.
  • Work flow engine. There are various options in contrib that I'm not familiar with.
  • Temporal database. I don't know what this is.

Other points where Drupal stands out very strongly in your requirements are;

  • Strong Web2.0 Support. Drupal core ships with jQuery and the communities have a lot of ties. E.g. John Resig regularly attends DrupalCons. Drupal core uses jQuery in such a way that you can also use scriptaculous at the same time.
  • Easy installation and deployability, easy to customize. Watch any demo video of CCK+Views to understand the ease of customization. Almost every webhost supports the LAMP stack, where Drupal installs easily.
  • Less bulky. Drupal core 6 weighs in at just of 1 Mb. 7 is almost 1.5 Mb but mostly got larger only because it includes simpletest framework and all core unit tests. Don't let the size affect your concept of it's power. Note core is very light on images compared to many other CMS.
  • Scalability and performance. D.o has new users and content every few seconds, plus 100s or even 1000s of content views per second. There are other Drupal websites that are similarly large and have difficult scalability issues that are managed.
  • Large developer ecosystem. It's estimated over 1000 people contributed code to Drupal 6 core. Last DrupalCon sold out months ahead at 1400, and there was an unofficial DrupalCamp in the same city at the same time to handle overflow.
  • Less complex framework. One of the reasons Drupal has a low barrier of entry is because it's easy to understand it's hook architecture. As unique as it might be, it's as powerful as a traditional OO-architecture – but different.


a. Situation mapping

b. Missing Person Registry In Drupal this would be a CCK Content Type

  • Missing Person Report This would be a View of Missing Persons. Views filter would let you customise the report dynamically.
  • Person search Either via Drupal advanced search or views filter
  • Latest updates on Found people
  • View sorted by changed date

c. Disaster Victim Registry Drupal has a group concept to which users can be attached. This might be a good way of handling the victim groups Then assign one or more people to the group. No problem attaching 1..N photos per person record.

d. Organization Registry CCK!

e. Request/Aid Management CCK/Views pattern.

f. Shelter Registry

g. Web services. Is there a reason for SOAP? Wouldn't REST be easier?

h. Inventory Management CCK for Inventories, Items. Views for reports Optimisation would be custom code.

i. Messaging Is this a webmail wrapper for a mail engine like Dovecot? Use Mail or Simple News modules. Also could use chat, twitter, etc.

j. Volunteer Management Projects, Volunteers = CCK

k. Aid Management

l. Reporting Is this very developed?

m. Import/Export XML etc.

Other comments

1. Drupal has richer user profile, user preferences handling. 2. How does Sahana to multiple languages/i18n? Drupal is getting quite strong there. 3. Is there a conceptual class model for Sahana (any docs showing the overall requirements for the app, what data is captured)? i.e what are all the classes, Location, Shelter, Victim, Person etc. There seems to be a pattern of Add/Change/Delete Object, Collection of Objects, Browse list of Objects, Map Objects? 4. Drupal would have much nicer URLs! could be Why are the current ids so non-obvious? 5. Pie chart - how is this done now? 6. Categories like Shelter Type can be easily catered for using Drupal taxonomies. 7. Many Classes need date info. Use Drupal date module. Can then view via Calendar, download iCal etc.

There's an impressive amount of stuff in Sahana, but I think it would be interesting to see a document describing the overall capabilities, then the details of what customisations are necessary. I've only reviewed things at a very high level but it seems to me that a substantial amount of Sahana's capabilities could be developed in Drupal even without code (using Views and CCK). There would need to be custom components obviously (CAP, import/export), but the Sahana community could concentrate on those instead of all the core framework elements.

Looking at GSOC 2009 projects Drupal already has cross-site search, already has a powerful theme/template system. There's plenty of working making Drupal work well with Mobile Web also.

Apache Solr

Actually, I think ApacheSolr integration could result in a really powerful tool/asset for the missing persons registry. An example scenario;

Someone leaves a message about their missing family member. A user of the database listens to their message and notes down; “John Brown from Timbuctoo, age 45” They search “John Brown” Zero results, but Solr says there are 189 results for “John” and 285 results for “Brown” They click “Brown”, since it's more likely that “John” was actually “Jon” than “Brown” was something else. They click “Age 40-50”, and are now down to about 50 results. They scan the first 7, none of them are “John” or “Jon” – nor from Timbuctoo They click “Filter results from … Timbuctoo (15)” The scan the results for a “John” or similar. They see there are only two pages of results and click through to the second page. They find a “Joan Brown” from Timbuctoo age 45 on page 2, and realize they may have mis-assumed the missing person was male, and take action to check they've found a match and re-unite the family members.

This backend and UI would take just a couple of hours to set up with CCK and Acquia's implementation of ApacheSolr. It would take longer to enter the 200 missing Browns! Of course to get it just right might take a bit longer, and integration with the whole system is obviously where time gets taken up in such a project. However you can quickly see the power in a platform like Drupal.

QR Code
QR Code dev:fk_drupal7 (generated for current page)