client/server design and advice

[Diez B. Roggisch]

> First off, i was wondering if this is a reasonable setup:  The entire
> process would involve a server which manages which pc is processing
> which set of data (which may be a given text file or the like), and a
> client application which i would run on a few pc's locally when they
> aren't in use.  I would have a database (sqlite) holding all calculated
> data of significance.  Each client will basically login/connect with
> the server, request a time interval (i.e. does anything need processed?
> if so what data should i look at), and then it would update its status
> with the server which would place a lock on that data set.

Don't use sqlite, use a "real" RDBMS.  sqlite is cool, but not really suited
for large amounts of data, and the concurrent access aspects that are dealt
with with an RDBMS for free are not to be underestimated.

> One thing i was wondering is if it would be worth it to use c++ for the
> actual iteration through the text file or should i simply use python?
> While i'm sure that c++ would be faster i am not entirely sure its
> worth the headache if its not going to save me significant processing
> time.  Another thing is...if i was going to work with python instead of
> c++, would it be worth it to import all of the data into an sqlite
> database before hand (for speed issues)?

I'd be putting them in the DB, yes.
 
> Lastly, as far as the networking goes, i have seen posts and such about
> something called Pyro (http://pyro.sourceforge.net) and wondered if
> that was worth looking into for the client/server interaction.

Pyro rocks for that. 

Diez