Re: HEADS UP: FTPAPI list change

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

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
-----------------------------------------------------------------------