Re: httpapi.XML parse problem

[Scott Klement <klemscot@xxxxxxxxxxxx>]

Hi Thomas,

The VERSION command is going to need HTTP functionality in order to 
contact my web server.  Therefore, why NOT make it part of HTTPAPI?  If 
it's going to require HTTPAPI as a prerequisite, it may as well be 
included with HTTPAPI, right?

Or do you think it's going to be so complicated that it'll add a lot of 
burden to HTTPAPI?


thomas.raddatz@xxxxxx wrote:
> 
> Scott,
> 
> My understanding of 'project' is that the 'version' command is not shipped
> with HTTPAPI but is an independant project, that can be download and
> installed. It is a project that is related to your web site and the tools
> you provide and not a general purpose product. Hence it knows that the user
> wants to check HTTPAPI when he executes 'VERSION PRODUCT(*HTTPAPI)'. The
> command also knows that the name of the service program of the *HTTPAPI
> project is HTTPAPIR4. Hence it can activate that service program using the
> library list (or a specified library), build the procedure name and call
> the HTTPAPI_getVersion() procedure (or whatever you want to name it).
> Eventually the command could connect to your web site, download the current
> version information of HTTPAPI and send a message to the command line to
> show the result.
> 
> The relations between the logical product names such as *HTTPAPI and the
> name of the related service programs may be hardcoded in the 'version'
> command of may be part of the version info file on your server. If the
> later is true the command had to include the relations between the logical
> product names and the version info files.
> 
> Thomas.
> 
> 
> ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx schrieb am 20.01.2009 21:24:15:
> 
>> Hi Mike,
>>
>> Mike Krebs wrote:
>>> Is it possible to take the "local" version command one step higher
>>> and do something like:
>>>
>>> Version('project')
>>
>> It's not clear to me what 'project' would be?  Is it the name of a
>> service program?  Or the marketed name of a product/project?  If the
>> latter, how would the routine know which service program to dynamically
>> bind to?
>>
>>> For HTTPAPI, it would look like this: version('HTTPAPI') and would
> return
>>> string value 1.23.
>> But... it would have to somehow know to bind to HTTPAPIR4 and call a
>> routine named 'version'...   not sure that I like that.  How would it
>> know that HTTPAPI means HTTPAPIR4?  Not everyone uses that naming
>> scheme, obviously.
>>
>> I also don't like each service program exporting a routine named
>> 'version'.  If every service program exports a routine with the same
>> name, that's going to create conflicts.
>>
>> You could name it "packagename_version" (where packagename is replaced
>> by HTTPAPI in this example) that would be better... but still have the
>> problem of connecting HTTPAPI with HTTPAPIR4.
>>
>>
>>> A question for Scott on version numbers. Was there a version 1.9 that
> came
>>> before 1.10? Are you following any particular version numbering scheme?
>> Honestly, I didn't give much thought to it.  The first version was 1.0.
>>   Each new version I've released, I've incremented the part after the
>> dot... so it became 1.1 - 1.23, etc.
>>
>>
>>> BTW, besides the callback routines in HTTPAPI, I didn't know true
> dynamic
>>> binds were available to us. I guess I missed the a couple of
> newsletters
>>> along the way. Doing some quick googling (QleActBndPgm) opened my eyes
> to
>>> this interesting technique.
>> Shrug...   it's not usually useful.   Most of the time, if you want
>> dynamic binding, use a program instead of a service program.
>>
>> However, I've been thinking about using dynamic binding for Expat, so
>> HTTPAPI can detect at runtime if Expat is installed, and can even try a
>> few likely suspects for libraries (i.e. if not found in *LIBL, also look
>> in LIBEXPAT and LIBHTTP and use one of those.)  That way, you wouldn't
>> have to compile HTTPAPI "with XML" or "without XML", it'd figure it out
>> for you at runtime.
>>
>> But I never got around to actually doing it :)
>> -----------------------------------------------------------------------
>> This is the FTPAPI mailing list.  To unsubscribe, please go to:
>> http://www.scottklement.com/mailman/listinfo/ftpapi
>> -----------------------------------------------------------------------
> 
> 
> --
> 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
-----------------------------------------------------------------------