Ushahidi Mailing Lists

On 16 July 2012 17:58, Bill Morris <bill.boykinmorris@...> wrote:
> A thought has been bouncing around my head since I started using
> Ushahidi a year ago:
>
> Why maintain the connection to MySQL?
>
> I understand the deep integration with PHP, and that most of the
> original developers probably come from that kind of background.
> However, the MySQL backend is a real drag on the overall
> responsiveness of the system. No app I've deployed has taken longer to
> load up a map than my ushahidi instances, and I can lay much of the
> blame on the fact that spatial data is an afterthought for MySQL,
> buckled on instead of built from the ground up. As much as it's an
> industry standard, MySQL is being lapped in speed by PostgreSQL,
> SQLite and any number of NoSQL options. And it doesn't have anywhere
> near the spatial processing and analysis capabilities of PostGIS.
>
> You have acres of code fully-formed. I get that. But while everyone's
> talking about a reboot for 3.0, why not explore a basis in PostGIS or
> CouchDB? Why not jump out of the PHP/MySQL box completely and build
> with jekyll or node.js - something that represents the new paradigm
> for speed in delivering managed content?
>
> This has been a voice from the peanut gallery, and you may have
> already covered this at length. I've piped up now because I want to
> see Ushahidi improve. It's still an amazing tool.
>
> -Bill Morris
> Burlington, VT USA
>
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~
> List Archive: http://list.ushahidi.com/
>
> Would you like to receive list mail batched in a daily digest instead? Send a message to:
> developers-digest-subscribe@...
>
> To remove your address from the list, just send a message to
> the address in the "List-Unsubscribe" header of any list
> message. If you haven't changed addresses since subscribing,
> you can also send a message to:
> developers-unsubscribe@...
>
> For addition or removal of addresses, we'll send a confirmation
> message to that address. When you receive it, simply reply to it
> to complete the transaction.
>
> If you need to get in touch with the human owner of this list,
> please send a message to:
> developers-owner@...
>

By way of introduction, I'm new to the list but was amazed &
overwhelmed at how Ushahidi was used to help my home town,
Christchurch, during the big quake in 2011. Hopefully I can
find a way to contribute something back in future.

I'm also a CouchDB committer (bias & relevant experience)
and I always wondered whether CouchDB might have made
collecting, sharing & managing data easier after the quake,
especially in the early days with limited or no network access.

The core strengths of CouchDB in my opinion are:
- document DB with native JSON
- HTTP interface
- really easy replication model & offline support

Which for me means, extending or integrating CouchDB with
partially connected devices is straightforwards, and moving
that out to the edge of the web with mobile is a piece of cake,
even if the connection is not down. Return to base, sync up.

There's a geocouch extension which is being plumbed up
to the same library that drives PostGIS, although it's not got
the same featureset yet nor extensive testing that PG already has.

I don't know your project's history but there's got to be a reason
to move to a document DB, and it's not plain sailing. For example
CouchDB doesn't do FTI, if you want that we recommend plugging
into Apache Lucene. Our replication model comes at a cost if
you want to update the same document repeatedly, and we use an
append-only storage model that requires compacting regularly.
And we use an arcane mix of Erlang/OTP and JavaScript. You
can't deploy that without some expertise. PHP and MySQL are
very well known, for coding, deployment, and operations.

I'm happy to share more detail if its of interest, and if there's at
least some idea of a problem statement to work against.

A+
Dave