Re: Designing a monthly software and database update for a web app

You have some payment scheme for your packages, but your design does not incorporate any enforcement of that. You do mention IP address validation, but that is a very weak reed. How is that to work with the CD distribution you next mention?

I don't understand why the intermediate xml steps are necessary. Why not write the db updates as a MySQL batch file?

You should consider the system patch and make utilities, as well as version numbering instead of date-based upgrades. There are well-known perl modules which can help with each stage of your design.

After Compline,
Zaxo

Comment on Re: Designing a monthly software and database update for a web app

Replies are listed 'Best First'.
Re^2: Designing a monthly software and database update for a web app by amonroy (Scribe) on Oct 17, 2004 at 00:26 UTC
You're right, the payment scheme doesn't fit well with the CD idea. I am still not clear on how to go about that. I was thinking in giving up the idea of the CDs and just ask people to somehow download the updates by hand if their server is not hooked to the internet. They will have to connect from certain IP though. The reason why it cannot be a MySQL batch file is because the update algorithm is not very simple, it requires a lot of perl code to analyze when a field is considered customized and when it is not. The versioning number will be in this form: YYYYMMDD, thanks for your suggestion.	[reply]

Replies are listed 'Best First'.

Re^2: Designing a monthly software and database update for a web app
by amonroy (Scribe) on Oct 17, 2004 at 00:26 UTC

You're right, the payment scheme doesn't fit well with the CD idea. I am still not clear on how to go about that. I was thinking in giving up the idea of the CDs and just ask people to somehow download the updates by hand if their server is not hooked to the internet. They will have to connect from certain IP though.

The reason why it cannot be a MySQL batch file is because the update algorithm is not very simple, it requires a lot of perl code to analyze when a field is considered customized and when it is not.

The versioning number will be in this form: YYYYMMDD, thanks for your suggestion.

[reply]