[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: HEADS UP: FTPAPI list change
Just my opinion here -
Scott has generously put his creation (which he did on his own) out here,
free, for public use. I look at the source code, and I see there are others
who also contributed to the code. None of them have claimed anything.
Christian can "improve" it all he wants, using the same names, and so forth,
but the original concept is, indeed, Scott's, and that is the basis of the
copyright. You can customize a Volkswagen Beetle into an off-road vehicle
(indeed, many worldwide have done so), but that hardly invalidates
Volkswagen's patents. VW can't tell you how to use or modify the car to suit
your needs, but you can't clone the car and pass it off as your own original
creation, no matter how you may have improved upon it. It's still
Volkswagen's intellectual property.
Francis Lapeyre
IS Dept. Programmer/Analyst
Stewart Enterprises, Inc.
E-mail: flapeyre@xxxxxxxx
-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx
[mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Christian
Sent: Friday, July 14, 2006 12:11 AM
To: HTTPAPI and FTPAPI Projects
Subject: Re: HEADS UP: FTPAPI list change
No problem, this is my last email on this list. Btw, besides of the
names used, there's not a single line from you, so why should you have
the exclusive Copyright?
Scott Klement wrote:
> Christian:
>
> a) I never agreed that you could re-do FTPAPI from the ground up.
>
> b) I never agreed that you could take my idea, but remove my name from the
> copyright statement and release it as your own work.
>
> c) I never agreed that you could remove binary backward compatibility from
> FTPAPI.
>
> If you want to start your own open source project, I can't stop you. But
> don't derive your product from mine, and don't use my mailing list to do
> so. FTPAPI is _my_ project, you do not have the right to take control of
> it or claim it as your own.
>
> ---
> Scott Klement http://www.scottklement.com
>
>
>
> On Thu, 13 Jul 2006, chrisv5@xxxxxx wrote:
>
>> This first alpha version of my new FTPAPI supports the following API
calls:
>>
>> - FTP_OPEN
>> - FTP_LOGIN
>> - FTP_QUIT
>> - FTP_CHDIR
>> - FTP_LIST
>> - FTP_BINARYMODE
>> - FTP_CODEPAGE
>> - FTP_GET
>> - FTP_PUT
>> - FTP_MTIME (in case you wonder; I used it to test UTF-8)
>> - FTP_ERRORMSG
>>
>> Please note that FTP_CONNECT is not yet implemented, please use FTP_OPEN
>> & FTP_LOGIN instead. Just did not spend time on it yet.
>>
>> I have tested these successfully with FileZilla Server. Any other decent
>> Windows or Unix FTP server should do as well. If you really want to use
>> it with IBM iSeries FTP server, you are advised to know all the
>> limitations which apply!!!
>>
>> HowToBuild.txt contains the two commands necessary to build the SRVPGM.
>> sample.rpgle contains a minimalistic test program. Please modify as you
>> see fit. If you have any questions, please ask. Just be aware that I'll
>> be on vacation the next two weeks, thus do not be surprised if I won't
>> reply immediately.
>>
>> NOTE: please use the API header files (RECIO_H & SOCKET_H) from Scott's
>> version, I used them without a single change (but I am using Close()
>> instead of CloseF() exclusively). This was actually a request by Scott,
>> which I found very reasonable.
>>
>> Disadvantages:
>>
>> - by far not complete, thus no binary compatibility
>> - small changes in API interface, thus no binary compatibility
>> - only ASCII and BINARY file transfer of stream files
>> (database files will be implemented later)
>> - logging unconditional so far (and not very complete)
>>
>> Advantages:
>>
>> - no limit of sessions, starts with a very low number of sessions
>> (actually, this version starts with one session; just for testing)
>> - only two local variables (SessionPtr & SessionCnt)
>> - supports UTF-8 on the control channel
>> (allows international file names; not for iSeries, of course)
>> - full character set support including UTF-8, DBCS, Mixed Byte, UCS-2 BE
>> on data channel; please be advised that quite a few conversions are
>> *not* supported by iconv() (though still a lot, lot more than by
>> CPYTOSTMF, etc.); if you really need to ask me, I can tell you which
>> CCSID stands for what in most odd languages (esp. Japanese & Chinese
>> Simplified)
>> - received stream files (GET) always have the correct CCSID, no matter
>> if the file had existed already or not
>> - fully non-blocking (did not test much, though)
>> - complete rewrite (well, arguable, if that is an advantage)
>> - V5R1M0 syntax, with alternative V5R2M0 pieces; thus you get the best
>> of both worlds; modern syntax & compatibility; in about a year I'll
>> remove the V5R1M0 pieces.
>>
>> NOTE: if you convert a file from any character set to EBCDIC Mixed Byte,
>> the resulting file might look different every time. This is *not* a BUG,
>> it is an odd peculiarity of IBM's character sets and how they are
>> handled by iconv() (well, finally I understand that odd sentence in the
>> iconv() docs).
>>
>> I had to make a few tough decisions, mainly one of being 100% binary
>> compatible to the old FTPAPI. Which I am not. At the same time, I kept
>> it my version as close to the old one as possible. If anyone *really*
>> wants to achieve binary compatibility, it can be done. But not by me.
>> And you have to maintain your own fork, sorry.
>>
>> Anyone who needs the new functionality has to recompile anyway. If you
>> don't, and don't want to recompile, well... stay with the old version.
>> It served you well so far anyway.
>>
>> I do not get the point of including internal helper procedures in the
>> *SRVPGM interface, esp. as they are not listed in the header file. It's
>> those helper functions which I had to change extensively, to make them
>> clean. Read procedures just read, Write procedures just write. Open
>> procedures open files. No more hidden and inconsistent functionalities.
>>
>> This version is just for testing, the final result will be rather close
>> to the number (and type) of APIs of the original version. If you have an
>> urgent need for something, let me know and I'll implement that before
>> the rest.
>>
>> Regards,
>> Christian
>>
> -----------------------------------------------------------------------
> This is the FTPAPI mailing list. To unsubscribe, please go to:
> http://www.scottklement.com/mailman/listinfo/ftpapi
> -----------------------------------------------------------------------
>
>
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------