[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: HEADS UP: FTPAPI list change



DITTO to Scott whose unselfish, tireless contributions to this community
-ARE- very appreciated by 99.9999999999999999 % of us RPG members.


John B.
Senior P/A
Taylor Dev.


> -----Original Message-----
> From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-
> bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of lgoodbar@xxxxxxxxxxxxxx
> Sent: Friday, July 14, 2006 7:53 AM
> To: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
> Subject: RE: HEADS UP: FTPAPI list change
> 
> Wow. Words just fail.
> 
> Scott, I just want to add my support as a user of several of your
projects
> -
> socket utilities and the *APIs. I wish that network programming was a
> skill
> I possessed to help you in these projects.
> 
> I'm with Larry - the quality of your work, and your generous support
and
> professionalism underscores your value to the RPG community at-large.
> You've
> shown the rest of us how to efficiently utilize RPG in a modern
networked
> environment. I'm extremely grateful for the services you provide.
Thank
> you.
> 
> Loyd Goodbar
> Senior programmer/analyst
> BorgWarner
> E/TS Water Valley
> 662-473-5713
> 
> -----Original Message-----
> From: Larry Ducie [mailto:larry_ducie@xxxxxxxxxxx]
> Sent: Friday, July 14, 2006 01:04
> To: ftpapi@xxxxxxxxxxxxxxxxxxxxxx
> Subject: Re: HEADS UP: FTPAPI list change
> 
> I knew copyright theft existed, but did I just witness daylight
robbery??
> If
> 
> that is the way people wish to repay RPG community leaders such as
Scott
> for
> 
> their efforts then we've gotten to a pretty miserable state of
affairs. I
> will certainly NOT be migrating from Scott's original project.
> 
> Cheers
> 
> Larry Ducie
> 
> 
> 
> ----Original Message Follows----
> From: Christian <chrisv5@xxxxxx>
> 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 07:11:20 +0200
> 
> 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
>
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------