The Future of ComCenter

I've released the first .5 versions of ComCenter to both RiaForge.org and osflash.org. Halfway to 1.0, this seems to be a good time to consider where ComCenter is and where its going.

For starters, the release schedule is going to slow down slightly-the first 5 point releases were completed in less than two months. As the code gets more complex, and more complicated features get added, I can't see knocking off the next 5 point versions in roughly two months time.

For the immediate future, the next version of ComCenter (0.6) will mostly be about filtering. It will contain a better way to filter search results, as well as some basic image filters.

For the long term, what's really missing is a persistence model-so images, and data associated with images (locations, events, people, etc.) can be managed from within ComCenter and stored. The next version (0.6) will be the last version without data persistence.

The question of course, is how to provide it. There seems to be two options:

1) As a typical web application. In this model, ComCenter calls back to a back-end application server (via XML, binary sockets, or whatever) and data is maintained there. There aren't a lot of unknowns here which is a plus, but this option would require a web/application server to be installed and a choice of a back end language will be needed (although odds are it would be Java because that's what I'm most familiar with).

2) As an Apollo application. In this model, data can be stored locally(through updates to the XML file). This seems to be convenient from an installation standpoint, but I don't know nearly enough about Apollo(the Alpha was only released last week). You could create an Apollo app that pulled the data remotely I realize, but to me one of the true advantages of Apollo is the extended API that allows you to access local resources.

Anyone have opinions about developing for local data storage with Apollo vs. a remote data storage model?

0 comments: