[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: HEADS UP: FTPAPI list change
I'll put in my .02. Scott is one of if not the best source of open
source code for iSeries. I developed stuff with HTTPAPI and it runs
flawlessly. Every day. All day long. Better than most commercial
packages I've used.
It's time I give back to this project. Scott: What's on your list of
things you want done?
- Michael
On 7/14/06, [1]lgoodbar@xxxxxxxxxxxxxx <[2]lgoodbar@xxxxxxxxxxxxxx>
wrote:
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: [3]larry_ducie@xxxxxxxxxxx]
Sent: Friday, July 14, 2006 01:04
To: [4]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 <[5]chrisv5@xxxxxx >
Reply-To: HTTPAPI and FTPAPI Projects
<[6]ftpapi@xxxxxxxxxxxxxxxxxxxxxx>
To: HTTPAPI and FTPAPI Projects <[7] 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 [8]http://www.scottklement.com
>
>
>
> On Thu, 13 Jul 2006, [9]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:
> [10]http://www.scottklement.com/mailman/listinfo/ftpapi
>
-------------------------------------------------------------------
----
>
>
-------------------------------------------------------------------
----
This is the FTPAPI mailing list. To unsubscribe, please go to:
[11]http://www.scottklement.com/mailman/listinfo/ftpapi
-------------------------------------------------------------------
----
-------------------------------------------------------------------
----
This is the FTPAPI mailing list. To unsubscribe, please go to:
[12]http://www.scottklement.com/mailman/listinfo/ftpapi
-------------------------------------------------------------------
----
-------------------------------------------------------------------
----
This is the FTPAPI mailing list. To unsubscribe, please go to:
[13]http://www.scottklement.com/mailman/listinfo/ftpapi
-------------------------------------------------------------------
----
References
1. mailto:lgoodbar@xxxxxxxxxxxxxx
2. mailto:lgoodbar@xxxxxxxxxxxxxx
3. mailto:larry_ducie@xxxxxxxxxxx
4. mailto:ftpapi@xxxxxxxxxxxxxxxxxxxxxx
5. mailto:chrisv5@xxxxxx
6. mailto:ftpapi@xxxxxxxxxxxxxxxxxxxxxx
7. mailto:ftpapi@xxxxxxxxxxxxxxxxxxxxxx
8. http://www.scottklement.com/
9. mailto:chrisv5@xxxxxx
10. http://www.scottklement.com/mailman/listinfo/ftpapi
11. http://www.scottklement.com/mailman/listinfo/ftpapi
12. http://www.scottklement.com/mailman/listinfo/ftpapi
13. 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
-----------------------------------------------------------------------