Re: Export of debug_msg() and debug_write() possible?

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

My name is Scott (not Scout.)

I think keeping an array is just too complicated.  A reference count 
would be much easier, but I don't think it's really necessary either.

HTTPAPI currently opens the log anytime you write a message to it, so I 
don't think anything needs to call debug_open().  If WSDL2RPG calls 
calls debug_msg/debug_write after HTTPAPI has closed it, the file will 
be reopened and the data will be written to it, so it doesn't really do 
any harm.   WSDL2RPG will have to call debug_Close(), but debug_close() 
can be called even when the debug file is already closed, and there will 
be no error -- so it should work nicely enough.

I'm going to rename the routines http_dmsg(), http_dwrite() and 
http_dclose() since they are the same number of characters as debug_msg, 
debug_write() and debug_close() which makes it easier to do a find/replace.

So...  that's my plan.  I'll release a new beta soon.


Thomas Raddatz wrote:
> Hi Scout,
> 
> Good question! What about to add a procedure that a client (e.g. WSDL2RPG) 
> could call to register himself as a participant of the HTTP API logger?
> 
> In other words how about to also add a http_debugOpen() and 
> http_debugClose() procedure?
> 
> Now HTTP API could delay closing the log output file until the last client 
> closed the log. Actually HTTP API itself could be treated as a client of 
> the debug log.
> 
> A simple array with a few elements (e.g. 16) could be used as a handle pool 
> whereas the array index is the handle and the item value might be the name 
> of the client application.
> 
> Here is some pseudo code:
> 
>     dim g_handleArray as String[16];
> 
> 
> Pseudo code of http_debugOpen() procedure interface:
> 
>     Integer http_debugOpen([String clientApp);
> 
> Pseudo code of http_debugOpen():
> 
>     handle = findFreeHandle();
>     if (handle = 0) then return -1;
> 
>     if (isParameterAvailable(clientApp)) then {
>           allocateHandle(handle: clientApp)
>     } else {
>           allocateHandle(handle: '*N')
>     }
> 
>     return handle;
> 
> 
> Pseudo code of allocateHandle() procedure interface:
> 
>     void allocateHandle(Integer handle, String clientApp);
> 
> Pseudo code of allocateHandle():
> 
>     g_handleArray[handle] = clientApp;
>     return;
> 
> 
> Pseudo code of http_debugClose() procedure interface:
> 
>     void http_debugClose(Integer handle);
> 
> Pseudo code of http_debugClose():
> 
>     if (not isHandleAllocated(handle)) then
>        throw Exception('Invalid handle');
> 
>     freeHandle(handle);
> 
>     if (noMoreAllocatedHandle()) then closeDebugLog();
> 
>     handle = null;
> 
>     return;
> 
> Regards,
> 
> Thomas
> 
> 
> 
> Am 28.05.2010 19:41, schrieb Scott Klement:
>> Hi Thomas,
>>
>> I will go ahead and export them (under new names that start with http_),
>> however, I do have one question:
>>
>> How do we handle the timing of the debug_close()?   HTTPAPI will
>> automatically close the file when it's done, what happens if WSDL2RPG
>> wants to write to it after that?
>>
>>
>> On 5/28/2010 5:38 AM, thomas.raddatz@xxxxxx wrote:
>>>      Hi Scott,
>>>      What do you think about to export debug_msg() and perhaps
>>>      debug_write()?
>>>      Today the WSDL2RPG runtime service program opens the HTTP API debug
>>>      file in order to add WSDL2RPG replated debug information to the HTTP
>>>      API debug log. I add WSDL2RPG debug information to your log file
>>>      because I think that it is a good idea to keep the HTTP and the
>>>      WSDL2RPG debug information close together when calling a web service.
>>>      The problem is that I cannot ensure for 100% that both applications
>>>      use the same output file. Also it may happen that WSDL2RPG tries to
>>>      write to the log before the file was been created by HTTP API. So for
>>>      me it was quite easier if I could directly call your debug log
>>>      procedures.
>>>      Regards,
>>>      Thomas.
>>>
>>>      --
>>>      IMPORTANT NOTICE:
>>>      This email is confidential, may be legally privileged, and is for the
>>>      intended recipient only. Access, disclosure, copying, distribution, or
>>>      reliance on any of it by anyone else is prohibited and may be a
>>>      criminal
>>>      offence. Please delete if obtained in error and email confirmation to
>>>      the sender.
>>>
>>>
>>>
>>>
>>> -----------------------------------------------------------------------
>>> 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
-----------------------------------------------------------------------