[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: HEADS UP: FTPAPI list change
Agree to Lapeyre, Francis's opinion.
Thank Scott for his HTTPAPI project. It help me a lot in my job.
Richard Ma
Genisys Management Solution, ULC
Mississauga, Ontario
>From: "Lapeyre, Francis" <FLAPEYRE@xxxxxxxx>
>Reply-To: HTTPAPI and FTPAPI Projects <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
>To: "'HTTPAPI and FTPAPI Projects'" <ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
>Subject: RE: HEADS UP: FTPAPI list change
>Date: Fri, 14 Jul 2006 09:29:39 -0500
>
>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
>-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------