[kwlug-disc] GPL design question

[Chris Frey]

I don't see many replies to this, and maybe the question is too
complex.  There are 3 elements: licensing, design, and programming.
I'm not quite sure why the license side of it matters.

For the mortality calculator, it obviously won't be static, so you'll
end up with some programming language and a database.  I think your
data will be more useful to you in the future if you take the time to
import it into a real database instead of just flat files.  It's
up to you whether that future use will be needed, though.

If the webserver is not busy, then the flat file could stay in cache
most of the time, so I doubt performance will be the driving factor.
It's all about what you want to do with it in the future.

Not sure if that helps. :-)

- Chris


On Mon, Sep 21, 2009 at 02:01:09PM -0400, Insurance Squared Inc. wrote:
> I'm building a  web based php calculator that will become GPL'ed.
> 
> I need three things.  Input page, output page, and some calculations in 
> between.  Oh, and they rely on some proprietary data tables of a small size.
> 
> What's the common way in GPL stuff to handle that framework from a 
> design side?  And what's commonly accepted for handling small data tables?
> 
> I'm thinking for the design, two ways I'm considering:
> - I can have there components.  An input page (html), an output page 
> (html) and a script The input page feeds the script, the script parses 
> the output page and displays it on the fly.  That way users can just 
> edit an input and output page, and done.
> - Alternatively I can have a script with some html snippet files, like a 
> header, body, footer, and so on.  That's what some stuff does I know, 
> but seems less intuitive.
> 
> What's the common/preferred way when people need to edit the io pages 
> for a web calculator?  Certainly not embed the html in the code :).  
> I've done the first way in the past but don't see others using that.
> 
> Secondly, do I need to do a full workup of mysql, importing data into a 
> database during setup, etc.?  Or can I get away with a flat file 
> structure (it's not a lot of data).  Thoughts?  Users won't be likely 
> changing data.
> 
> Thanks!
> 
> p.s. - this is a mortality calculator; type in your age and a few 
> details about yourself and it'll tell you your life expectancy.  A US 
> actuary has done an excel version, I'm creating a web version for them 
> (and myself).  For my version, I've also got some mortality tables from 
> the early 1900's and 1800's, so mine will also calculate your life 
> expectancy if it was like 1880 today.
> 
> _______________________________________________
> kwlug-disc_kwlug.org mailing list
> kwlug-disc_kwlug.org at kwlug.org
> http://astoria.ccjclearline.com/mailman/listinfo/kwlug-disc_kwlug.org