On Sun, 26 Nov 2006 03:05:36 +0100, Mark Stosberg <[EMAIL PROTECTED]>
wrote:
...
Obviosly GUI would be handeled by their browser of choice ...
Did anyone did something similar?
Yes. Michael Peters did this with "Smolder". It bundles Apache, SQLite
and many Perl modules into a solution that is failry stand-alone and
easy to install. (Although it doesn't go as far as PAR).
Smolder is in turn built on "Matchstick", which is a framework to build
applications in a similar manner. I would probably still consider
"Matchstick" to be alpha quality, though.
The aplication would be comercial - well not really application but they
would
pay for the service - and application would come as part of that service.
So I will have to check out the legality stuff too.
Of course if something (like MySQL for instance) can't legaly be part of
the
package - it could be listed as pre-requirement and install version of
mysql
shiped on same (or another with all GPL stuff) disk ...
I'm also investigating the posibility to relese the code as OpenSource
(tm)...
As of Matchstick - I was thinking more along the lines of CGI::App with
some
web_server::in_module solution - mostly because that would mean same code
(mostly finished) can be re-used ... As it would be for one person usage,
performance doesn't matter that much.
Application itself would need to connect to main server from time to
time and sync the DB's - any sugestion on that would also be welcome.
Two-way sync'ing is tricky, because there can be conflicts. In that
case, you either have to blindly to decide one or the other is correct,
or have a human look at the conflict to choose.
I would either try to avoid 2-way sync'ing, or use a standard tool for
this, like "unison", which I use for desktop/laptop sync'ing. However,
unison wouldn't be helpful for binary database files.
Sorry for not making myself clear - it would be many to one relation.
But only one "person" (creator) would be able to change it's records.
At this point I still think there would only be one way updates from
clients to server - but there might be a need for one client to be able
to see records from all the other clients (read only).
I was thinking of adding a filed for time of last change of that record,
and then resend everything since the last time sync was done.
If you are going to use a "real db", then they might also have
third-party sync'ing tools to consider. For example there is "Slony" for
PostgreSQL, but it is only one-way sync'ing.
Unfortunately I'm not too familiar with PostgreSQL - actualy closest thing
was that I've used Oracle on the labs at university.
As project is already mid-way I don't think switching now would be wise
anyway.
Mark
Thanks for sugestions,
--
Aleksandar Petrović
www.techcode.net
Web Design & Development
Skype techcode.net
Yahoo! IM johndoeyu
ICQ 75863829
MSN [EMAIL PROTECTED]
AIM tchcode
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
