[Spread-users] Python libraries for Spread

Jonathan Stanton jonathan at spread.org
Wed Jun 10 23:54:22 EDT 2009


I saw Peter's message about which versions of Spread to support where
he noted the older Python library. This brought up an issue I wanted
to see if anyone had any thoughts about --- how to make available
the various client libraries for Spread?

Here I'll just talk about the Python library, but the same issues
arise for other languages as well.

Python currently has a fairly broad set of Spread access libraries,
especially given how specialized Spread is. I know of at least 3
completely independant implementations -- and I wouldn't be surprised
if I'm missing some.

1) The original version written by Jeremy Hylton, Guido van Rossum and Tim Peters
and available on the python.org site:

http://www.python.org/other/spread/
http://www.zope.org/Members/tim_one/spread/view

But this version hasn't been updated for Spread 4 (or otherwise in 4 years). 
Bill Noon sent a patch to update it for the new Spread 4 membership apis 
on the mailing list a few years ago:

http://commedia.cnds.jhu.edu/pipermail/spread-users/2006-December/003168.html

but as far as I know the mailing list archive is the only place it can be found.

2) A more recent python library implementation available at:

http://code.google.com/p/py-spread/

which is a lightweight wrapper and claims to support Spread 4, but all of the
documentation appears to be in Chinese and it's unclear how broadly it is used
of supported. 

3) Daniel Savarese's C++/perl/python/ruby/etc library

http://www.savarese.com/software/libssrcspread/

which supports many langagues with an object-oriented API around Spread with 
really good documentation.   

So the issues I see are:

1) I'll definitely update the website to link to all of the versions I can find  
but what should be done to make it easier to find and use working versions?

For example how can the patch from the email list get merged into a new verison
of the python.org library?

2) In general is there a recommended way to provide library support for the many
different languages people program in today without creating native implementations
of the client protocol/api or using language specific C library wrappers (for example
as is done in the Spread Perl libraries)?

I'd be interested in anyone's thoughts of ideas on these issues.

Cheers,

Jonathan

-- 
-------------------------------------------------------
Jonathan Stanton         jonathan at spread.org
Spread Group Messaging   www.spread.org
Spread Concepts LLC      www.spreadconcepts.com
-------------------------------------------------------




More information about the Spread-users mailing list