What changes would interest people?

[Will Ware]

One obvious thing is a much richer test suite. The reason for writing so much of the code in C was for performance, but I never wrote a test to actually measure performance, or characterize how it's affected by network topology.

Another thing would be to document the byte formats used for sending tuples and tuple requests over the network.

Network performance will primarily be a function of sending information with as few bytes as possible - this code doesn't need to be in C. Actual code performance probably matters most when searching the tuple space for a tuple. I think this could be done in Java. A Java version would make unit-testing really easy. Anybody care to express an opinion about scrapping C and Python in favor of Java?

[Philippe]

My #1 wish is 64bit support.

Compiling 32bit on a 64bit system is not possible with Python, as I discovered it's difficult to have a python 32 bit when the system's default is 64bit (at least on Ubuntoo).

Aside from the usual printf format and other casting issue, the main problem I found is the wire format to send tuples over sockets. the current code assumes the word length and the padding inside the "element" struct and these assumptions are not correct on 64bit architectures. this only affect string fields, for which the individual fields of the struct are send. (tuple.c, line 524-542)

I was able to work around the issue by modifying the "ptr" member to make the pointer relative and sending the struct as-is instead of sending the indiivual fields. that way, padding and alignment are never an issue, assuming both client and server are the same arch.

I'm happy to contribute a patch if you'd like.

p.