OT? : Open source development tools / programming language

Thomas Gail Haws tom.haws at gmail.com
Mon Nov 8 16:56:15 MST 2010


My initial inclination was OpenOffice with MyODBC.  I like Alex's points
about browsers and Bryan O'Neal's remark about MS Access.  If you just think
it would be neat to have a desktop component of the Control Panel, maybe
simply exposing certain views or tables to OpenOffice.org via MyODBC would
accomplish your goal.

In the interest of full disclosure I should say I have not been impressed
with the speed of OpenOffice MyODBC connections I've worked with, but things
may be getting better.

Tom
--
"To forgive is the highest, most beautiful form of love. In return, you will
receive untold peace and happiness." - Dr. Robert Muller


On Mon, Nov 8, 2010 at 12:59 PM, Alex Dean <alex at crackpot.org> wrote:

>
> 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
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss at lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change your mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.PLUG.phoenix.az.us/pipermail/plug-discuss/attachments/20101108/7bf9708f/attachment.html>


More information about the PLUG-discuss mailing list