Mike did the problems with SQLite occur during concurrent(multi thread/
process) read/write access  to the db or was this a single instance
app?
I ask because i'm in the process of evaluating which embeded (r)dbms i
should use in an app i'm working on and SQLite is my default fav
since i used it in my C++ days without any issues.

Thanks for any input on this,

Regards,
Mayowa.


On Mar 12, 9:18 pm, "Mike Orr" <[EMAIL PROTECTED]> wrote:
> On 3/11/07, iain duncan <[EMAIL PROTECTED]> wrote:
>
>
>
>
>
> > > So far we've done some initial tests with Py2exe (Windows) and Py2app
> > > (Mac) and put it on the back burner.  I've tried to stay away from
> > > that part because I'm more of a Linux guy.
>
> > > If I did it again I'd still go the web route because the differences
> > > between a web framework and a GUI application are so big I don't see
> > > how can avoid writing essentially two applications.
>
> > I think for me it would depend on the nature of the needed web app side.
> > In most of my ( limited ) work so far, the only complicated stuff as far
> > as validation and persistancy goes has been on the admin side. Even with
> > an ajax shopping cart, the public web side is not that much compared to
> > the admin. So, I think if the admin side was way more complex than the
> > web side, I would lean towards a gears and/or pylons web side
> > ( depending on the needs in question ) and seriously entertain the
> > notion of a wx app that updates the db for the admin. If both sides were
> > already going to be web-complex, then I think you'd be right, it would
> > be needless duplication of work.
>
> If the standalone is an admin interface, you're already talking about
> different functionality between it and the website.  In which case
> it's really two separate applications sharing the same model.  But
> your question brings up the point that different kinds of sites have
> very different requirements, so a GUI interface may make more sense
> for some than others.
>
> In my case the website (cameochemicals.noaa.gov) and standalone (not
> yet implemented) are identical.  The database is read-only and a copy
> will be bundled with the standalone.  We needed the web app for the
> website anyway, so it really is a choice between zero work for HTML vs
> lots of work for a GUI.  Also, we're hoping the standalone will be
> obsolete in a few years when wireless Internet access becomes more
> ubiquidous, so we're not eager to put resources into a GUI with a
> short lifespan.  In the meantime we're distributing an existing
> FileMaker standalone with updated data, which is less searchable but
> it gets the job done.
>
> There is no admin interface because the data is imported offline.  If
> there were an admin interface we might be more favorable to a GUI.  My
> other public site (incidentnews.gov -- which I'm currently converting
> to Pylons as part of its upgrade) is fed from a larger private site
> which handles any admin'ing it needs.
>
> By the way, the other work unique to the standalone is to:
>     - choose a database backend. I went with Durus because it proved
> fastest and most reliable with our dataset, can be included in the
> py2exe executable, and can run equally well on the server and
> standalone.  MySQL has installation and licensing issues (GPL), and I
> couldn't get its embedded mode to work (it's poorly documented).
> SQLite hung regularly (due to threading issues in the C library).
>   - design the Windows and Mac installers and launchers.
>   - make sure the app doesn't write any local files (log or session)
> during runtime  -- making it more acceptable to local IT staff.
>   - decide how to update the data.  Easiest is to make the user
> reinstall from scratch (10 MB, but originally 40 MB).  I considered
> some semi-automatic checking for updates and modifying the db in place
> via a web service, but rejected those as too complicated and
> error-prone, especially since the laptops are in the hands of naive
> users we can't support long-distance.
>
> --
> Mike Orr <[EMAIL PROTECTED]>


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to