[kwlug-disc] Continued: OpenSource Me!]

[unsolicited]

Unless I miss my guess, think single user with laptop. Or, the broker 
sitting around the kitchen table with husband and wife. No net 
connectivity.

This started out as CRM. I suspect also, think Palm sync'ing. Sync 
laptop (if it isn't the 'server') before heading out on a call, 
particularly with respect to the e-mail's sent and received from that 
client, before leaving.

And, once around the kitchen table, an ability to show, yes, you 
instructed me to do this. And, you are now instructing me to do this 
for you (set up a policy). Think about Glenn's earlier comment about 
the regulatory environment within which he is operating.

If one thinks like a Palm sync'ing, then the hosted app / web server 
approach may well be appropriate as well. Plus the local client. Which 
may also be a local browser / mysql app.

Paul Nijjar wrote, On 12/22/2008 2:22 PM:
> --- On Mon, 12/22/08, Insurance Squared Inc. <gcooke at insurancesquared.com> wrote:
> 
>> My personal need is for the database to run on a local linux server
>> and access it via browser.  Super easy, I create the specs and our
>> developer whips it up in php/mysql.
> 
> You might be surprised at how far you can go with this. Your situation
> reminds me of the Oscar McMaster project, which is an open-source
> medical system I am wrestling with. The target market is doctors,
> who are not so tech-savvy and most of whom do not do any development.
> But an ecosystem of service providers has sprung up around Oscar setup
> and deployment. 
> 
> Having said that, doctors are accustomed to paying through the nose to
> outfit their offices, and it sounds like your target market is not. 
> 
>> It doesn't work well for independent folks running MS on their
>> desktops.  That segment of the market is actually far larger than
>> the users that have my profile.  I'm questioning the tradeoff
>> between looking after these folks and the additional work and costs
>> (remember, I'm paying for developer time, at market rates). 
> 
> A cheap way around this might be to cheat. You could do your
> development in MySQL and PHP, and then test the results both with a
> standard Linux setup and using a WAMP stack like XAMPP. That would
> increase the barrier to entry for Windows users a bit, but it would
> probably be easier on you than trying to develop natively. 
> 
> I honestly can't see how this can be a desktop-only application
> anyways, if you are thinking of tracking e-mails. There will have to
> be a server sitting around someplace to handle e-mail interactions,
> won't there?
> 
> I don't have personal experience with this, but I agree with John: the
> database abstraction is probably cheap enough that you should just go
> with it. If the abstraction layer is in place then people who use
> Microsoft databases (SQL server, Oracle or whatever) can write and
> maintain the plugins themselves.
> 
>> - Screen/output have to be *really* modular.  HTML output with
>> smarty templates, easy.  Abilitiy for one set of code to run smarty
>> templates and whatever it is that windows uses, way more complex.  I
>> guess I even have to start thinking about print functions.
> 
> Does a toolkit like wxWindows help with this? If I was in your shoes I
> would be tempted to investigate things like wxPython, which promise
> cross-platform compatibility and more rapid development than straight
> C++. 
> 
> Java might also be an option here. Oscar McMaster is a Tomcat app (not
> that I endorse this... getting this thing to run has been hideous). 
> 
>> Are these hurdles easy to overcome? Should I just do a linux system
>> and worry about MS later?
> 
> I don't know about "easy to overcome", but I am pretty sure that other
> projects have faced the same barriers and come out triumphant. But I
> think that the decision of whether to go PHP/MySQL or try for a native
> app is going to have far-reaching consequences one way or the other.