Python and Napster

[Alex Martelli]

"Moshe Zadka" <moshez at zadka.site.co.il> writes:


> On Tue, 26 Dec 2000 19:40:14 +0100, "Alex Martelli" <aleaxit at yahoo.com>
wrote:
>
> > Python would probably let you be more productive, I suspect.  It sure
has
> > all the network functionality you need; in your shoes, I'd look into
pyro --
> > building file exchange on top of it should be easier than on sockets or
on
> > protocols such as HTTP.
>
> I'm not so sure I agree -- SimpleHTTPServer/urllib/httplib is wonderful
> for file transfers. For anyone who wants to see a practical exmple
> (supports both upload and download), have a look at PMEP in the PMS
> source distribution (http://pythonms.sourceforge.net)

HTTP (and the Python tools around it) is great for file transfer (and
suchlike) but it's not oriented to peer-to-peer at all.  Pyro knows
nothing about files, but offers cool, simple, lightweight distributed
objects in 100% pure Python; a distributed Naming System, which can
support broadcast on a LAN, or other discovery methods if more suitable,
and is slated to become persistent at next release; pretty good
'transparency' of the remoting -- including exceptions -- and, again
in the next release, mobile objects and lifetime services (remote
activation/deactivation/persistency).

Corba is of course an alternative, but it may be harder to set up and
install properly on a great variety of platforms -- Pyro should run
wherever Python does (judging from its docs & blurbs, that is).

So the issue may boil down to pragmatics.  Is it easier to build file
transfer on top of a nice, lightweight but rich, distributed object
system; or, is it easier to build what portions you need of such an
object system on top of HTTP (given that, once machine A has found
out that machine B has file X.Y it needs, the actual transfer of that
file is a piece of cake, basically already performed by the protocol
and available supporting tools).

I think that actually transferring a file's data and metadata, once
you have a proxy for a remote object, is no big issue.  It seems to
me that naming, exceptions, resuming transfer (not supported by HTTP,
is it?), finding out what files are available where and with what
metadata (to discover what version is most up-to-date, or, possibly,
that both versions are separate branches of a version tree and some
manual reconciliation will be needed), etc, are harder problems --
and maybe using an infrastructure that basically lets you think in
term of programming Python objects, rather than inventing and
implementing special-purpose sub-protocols, may make life easier.

OTOH, if one's needs include, e.g., going through firewalls, then
HTTP may well be the best solution (in which case, SOAP on top of
it might help avoid reinventing too many wheels).  But, as I had
read the original request, it seemed to me to be more likely that
the whole setup would eventually run on a LAN or intranet, so that
such things as firewalls might not be a problem...


Alex