John Henry wrote:
> On the subject of passing things around, is there a no brainer way of
> sending files back and forth over Pyro?
>
> I am currently using a shared drive to do that. May be I missed that
> feature?
>
Sending files around is just a special case of passing large amounts
of data
On the subject of passing things around, is there a no brainer way of
sending files back and forth over Pyro?
I am currently using a shared drive to do that. May be I missed that
feature?
Irmen de Jong wrote:
> bruce wrote:
> > hi irmen...
> >
> > happened to come across this post. haven't looke
bruce wrote:
> hi irmen...
>
> happened to come across this post. haven't looked at pyro. regarding your
> 'work packets' could these essentially be 'programs/apps' that that are
> requested by the client apps, and are then granted by the dispatch/server
> app?
>
Pyro supports a limited form of
On 1 Dec 2006 10:37:39 -0800, John Henry <[EMAIL PROTECTED]> wrote:
> > Now...if only i could master python gui programming and development ;)
> You would short change yourself if you don't check out the other
> packages such as Pythoncard, and Dabo.
FWIW, Dabo has all of the database connectivi
TonyM wrote:
> > Pyro rocks for that.
>
> Awesome, ill look into it in greater detail and will most likely use
> it. Given what ive seen so far it looks like it will make the
> client/server interface fairly easy to write.
>
Correction: not "fairly easy" - make that "incredibly easy". Even
Mi
r 01, 2006 10:05 AM
To: python-list@python.org
Subject: Re: client/server design and advice
TonyM wrote:
> 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 t
TonyM wrote:
> 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.
I'm currently busy with a new version of Pyro (3.6) and it already
includes
> 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.
Would PostgreSQL be suitable in this situation? I hadn't even thought
about the
You may also want to take a look at Erlang http://www.erlang.org/ for some
ideas of how to do distributed programming.
--
http://mail.python.org/mailman/listinfo/python-list
On 1 Dec 2006 06:52:37 -0800, TonyM <[EMAIL PROTECTED]> wrote:
>I recently completed the general guidelines for a future project that I
>would like to start developing...but I've sort of hit a wall with
>respect to how to design it. In short, I want to run through
>approximately 5gigs of financial
> 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 us
I recently completed the general guidelines for a future project that I
would like to start developing...but I've sort of hit a wall with
respect to how to design it. In short, I want to run through
approximately 5gigs of financial data, all of which is stored in a
large number of text files. Now
12 matches
Mail list logo
