OT? : Open source development tools / programming language

[Alex Dean]

On Nov 8, 2010, at 10:57 AM, keith smith wrote:

> 
> Thank you for your feedback.  It is a web based PHP app.  It has a control panel for editing the data.  I was thinking it might be nice to have a desktop application that has the same features as the browser based application.  

If you don't have some definite requirement that can't be fulfilled by a browser I strongly recommend just adding the new features to your existing PHP application.  Same language, same codebase, more opportunity to re-use code you already have.  That "can't be fulfilled in a browser" list is shrinking all the time as browsers get more capable.  Stuff like 'needs to be functional without an internet connection' or 'heavy graphics processing' are about all i can think of at the moment.

Whatever neato-factor you get from having an installed application instead of a web app pales in comparison to the maintenance hassle your creating by splintering your codebase into multiple applications, especially if the 2 apps are in different languages and can't share library code.

If you do go ahead with a desktop application, put as little business logic as possible in it.  It should be nothing more than a client for your web application.  Expose your data as some web service, and use your web application as an intermediary between your desktop application and your database.  Data validation, SQL abstraction, etc, should all happen in the web application rather than re-implementing these things in your desktop app.  The desktop app should only need to do HTTP GET/POST/PUT/DELETE, etc, and shouldn't need to do any SQL work at all.

Using the database as the integration point between multiple applications (in this case your existing PHP application and this new hypothetical desktop application) is a huge pain.  For instance: if your desktop app is directly modifying your database, you'll have to distribute an updated desktop application every time the database undergoes some schema change.  As an alternative: if you have your web application is sitting in-between (and if your web service APIs are decent) then the desktop application doesn't need to know anything about those schema changes.  You can deploy the schema change and an updated web service at the same time, and the same desktop client should continue to work just fine.

alex