Hi Scott, The problem with your encoder are the header variables it uses. For example, I do not need "Content-Disposition" for web service attachments but need "Content-Transfer-Encoding" and "Content-ID".So most likely a more versatile encoder should not use hard-coded header variables but let the user pass the header variables instead. However it may provide some convenience procedures to initialize header variables for different purposes such as HTML forms or web services. Beside encoding a file it should also be able to encode a buffer. I am not sure whether I can extend your encoder to match these ideas. But I will look at it. For example "peVariable" is a parameter specific to HTML forms, isn't it? For web services it should be named "peContentId". But probably that is only "semantics" and not worth to talk about.
Changing "http_url_post" the way you suggested is a great and tricky idea. On my opinion it is the way to go. I will gladly change v1.23 that way and send the changes to you. My idea was to add an operational descriptor and in case it is not there assume the old lengths. But that is not possible because some parameters are passed by value. Sometimes it is hard to understand why IBM had to put in place restrictions like this one (from the CEEDOD description):
"It is an error to use CEEDOD to test an argument that is not a reference argument. It is also an error to test an argument that is preceded in the argument list by other arguments that are not reference arguments."
Regards, Thomas. Scott Klement schrieb:
Hi Thomas,It would be nice if you could extend my existing MFD encoder to be more versatile. But, I don't understand what you're suggesting is different about mine vs. what would be required for web service attachments?Yes, the content-type parameter is too short. (As is the SoapAction parameter). In my opinion, this is a problem that needs to be fixed. But, I'm concerned about breaking backward compatibility.My thinking is that I might do the following: D http_url_post PR 10I 0 extproc('HTTP2_POST') D peURL 32767A varying const options(*varsize) D pePostData * value D pePostDataLen 10I 0 value D peFilename 32767A varying const options(*varsize) D peTimeout 10I 0 value options(*nopass) D peUserAgent 64A const options(*nopass:*omit) D peContentType 32767A varying const D options(*varsize:*nopass:*omit) D peSoapAction 32767A varying const D options(*varsize:*nopass:*omit)The general idea is that this new version of HTTP_url_post() actually calls a routine named HTTP2_POST under the covers. (Note the EXTPROC). This means that existing programs (unless they're recompiled) would call the existing HTTP_url_post(). When a program is recompiled, it'd use the new prototype. The source shouldn't have to change (other than using the new prototype) since the same values you could pass to the old CotnentType and SoapAction fields should still be valid with this prototype.That's what I'm thinking... but, then again, I'd also like to remove the 'Timeout' and 'Useragent' parameters from the prototypes and make those be separate procedure calls. They're not changed frequently, and I find having to specify them every time to be cumbersome -- but if I made THAT change, there's no way I could keep it backward compatible at the source level, you'd have to modify your code, or we'd have to use completely different procedure names (as we did with FTPAPI) which would be cumbersome as well. So I may just keep those parameters intact....
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
----------------------------------------------------------------------- This is the FTPAPI mailing list. To unsubscribe, please go to: http://www.scottklement.com/mailman/listinfo/ftpapi -----------------------------------------------------------------------