[ftputil] Call for votes on new features

[Stefan Schwarzer]

Hi Ido,

On 2006-07-08 02:51, Ido Abramovich wrote:
> Stefan - could you attach the license and possibly explain the
> differences between your license and the regular BSD license,
> or just direct me to an online version of it?

The license that covers ftputil is at
http://www.opensource.org/licenses/bsd-license.php . This is the
recommended version. The original BSD license had an additional
"advertisement clause" which turned out to be impractical. It's a
bit unfortunate that sometimes (often?) the two variants make the
BSD license confusing.

There's an entry about the BSD licenses in the GPL FAQ at
http://www.gnu.org/licenses/gpl-faq.html#OrigBSD .

> I'm not really
> sure if I can share my code due to my working contract...

As far as I know, at least in Germany the case is even
problematic if you developed your software in your sparetime but
do similar work for your employer. Of course, this isn't the
exact appropriate juristic wording. If you've done the work in
the work time or with tools provided by the employer, the code
probably belongs to him anyway.

If you are unsure if you are allowed to donate the code to
ftputil, it may be best to _not_ post _any_ of the code.

> Oh, and it would be nice to have a "keep alive" method,
> sometimes my connection dies in the middle due to inactivity...

There was a "keep alive" functionality in ftputil 2.1b but
contrary to what I had assumed it didn't work for file-like
objects opened for writing. (I had unit tests, but there was a
wrong assumption in one of them so it didn't really test all that
it should have.) Eventually, I removed it rather than having a
"half-working" implementation.

BTW, there's also an (unanswered) post by me on the topic on
comp.lang.python:
http://groups.google.com/group/comp.lang.python/browse_frm/thread/0297d4e4a43c162c/2b8b1b5518e54b49?#2b8b1b5518e54b49

> I just found out that it posses a problem to my rsync-like
> script and I'll have to figure out how to deal with it. a
> standard caching system gets a +3 from me - even though I'm
> quite satisfied at the moment with my current solution.

That's something I didn't consider in my post on voting: Some
things are easier to implement than others. And unless I've
missed something, the caching shouldn't be too difficult (at
least easier than adding FXP unless you are very familiar with
the file transfer protocol).

Stefan