PyQT app accessible over network?

[Alec Taylor]

Monte: I noticed you mentioned web2py; that would be my recommendation.

You also mention different features being available to different
users; perfect use-case for web2py's built-in RBAC.

Scalability: Go with Postgres, MySQL; or considering how much data
you're talking about, even SQLite would be a close enough fit!

Another advantage of sticking to the web that hasn't been mentioned so
far is agnostic interoperability.

E.g.: you can CRUD on your TV (e.g.: if it runs Android); or on your
phone (e.g.: if you use twitter-bootstrap; which web2py comes with out
of the box; but is usable in any framework)

On Sat, Feb 23, 2013 at 3:50 AM, Monte Milanuk <memilanuk at gmail.com> wrote:
> Yes, I am looking at a database-centric application.  I know that the
> 'larger' databases such as PostgreSQL, MySQL, etc. would not have any
> problem handling that small amount of traffic.
>
> My concern is that using postgres or mysql for this would be akin to using a
> sledgehammer to swat a fly, when sqlite could most likely handle the load
> well enough (I think) since the handful of people doing data entry would
> rarely (if ever) be trying to write to the same record. That would be the
> whole point of having multiple people doing data entry in this situation -
> each one handling a different competitors entry form or submitted scores.
>
> My other reason for wanting one 'central' app is that there are various
> functions (setting up the tournament, closing registration, editing scores,
> finalizing results) that I really *don't* want the satellite/client apps to
> be able to do.  My personal view is that sort of thing needs to be handled
> from one point, by one person (the match director or chief stats officer,
> depending on the size of the event).
>
> That is why I was looking at things in terms of having one central app that
> handles the database, whether locally via sqlite or postgres or whatever,
> but have the clients access go through that main application in order to
> ensure that all they have is a limited set of CRUD abilities for competitor
> registration and entering scores.
>
> Thanks for the links... some of those I was already aware of (Camelot, Dabo)
> but some of the others are new (QtAlchemy, etc).  Should make for
> interesting reading!
>
>
> Thanks,
>
> Monte
>
> --
> http://mail.python.org/mailman/listinfo/python-list