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

Re: httpapi.XML parse problem

Mike,
I think that I got lost and that I did not thoroughly understand your last thought. What I do not understand is why we need different version procedures. For my understanding the version procedure of HTTPAPI could always be HTTPAPI_getVersion(). Different versions of HTTPAPI on the same System i requires different libraries for each version. Hence there are no duplicate version procedures of the same product in the same library. Therefore it is possible to dynamically bind to each version of a product by specifying the library and the product name.
I also do not understand why the <version_procedure> element overrides the <version> element because both elements specify totally different information. Given the following sample xml file I would do the following steps to check for an update. 

File on the server: httpapi.xml:

<version_info>
 <product id="*HTTPAPI">
  <name>HTTPAPI</name>
  <version>1.23</version>
  <serviceprogram>
   <name>HTTPAPIR4</name>
  </serviceprogram>
 </product>
</version_info>

Steps:

a) User: Execute command CHKVER PRODUCT(*HTTPAPI) LIBRARY(*LIBL)
b) CHKVER maps *HTTPAPI to the xml file name HTTPAPI.xml.
c) CHKVER downloads HTTPAPI.xml and retrieves the information provided
d) CHKVER locates and activates the service program specified at <serviceprogram>
e) CHKVER produces the getVersion procedure name from the product name
   and a constant '_getVersion'. For HTTPAPI it would produce 'HTTPAPI_getVersion'.
f) CHKVER retrieves a procedure pointer for the 'HTTPAPI_getVersion' procedure
   and calls the procedure.
g) CHKVER compare the version number from the xml file with the version
   number from the local service program.
h) CHKVER sends a message showing the result.
In order to add more flexibility we could add a <procedure> element to the xml file that, if present, would override the generic procedure name: 

<version_info>
 <product id="*HTTPAPI">
  <name>HTTPAPI</name>
  <version>1.23</version>
  <serviceprogram>
   <name>HTTPAPIR4</name>
   <version_procedure>http_getVersionIno</version_procedure>
  </serviceprogram>
 </product>
</version_info>
In that case CHKVER would call http_getVersionIno() instead of HTTPAPI_getVersion() to retrieve the version information from the local service program.
It may also be possible to use a single 'version_info.xml' file to hold the product information of all products that Scott provides. 

<version_info>
 <product id="*HTTPAPI">
  <name>HTTPAPI</name>
  <version>1.23</version>
  <serviceprogram>
   <name>HTTPAPIR4</name>
  </serviceprogram>
 </product>
 <product id="*ANOTHER_PRODUCT">
  ...
 <product>
</version_info>
Finally it may be a disadvantage to retrieve the name of the service program from the xml file because in that case it is impossible to retrieve the version from the local service program without any Internet connection. Sometimes it may be interesting to get the local version just for information without checking for an update. I am just thinking. 

Thomas.


Mike Krebs schrieb:

Hi Scott and Thomas (and you lurkers!),

Trying to determine version of IBM i utilities is problematic. At this point
in time, many utilities are simply a collection of programs. Oftentimes,
there isn't a service program involved.

A while back I tried to figure out how a package manager worked. I was into
PERL at the time so I looked mostly at CPAN. Besides developing a "bundle"
of code, the authors had to impose certain standards to make it work. One of
those standards is that the module was suppose to export $VERSION. This is
fairly easy in PERL, C or other argument driven languages. Doing this in a
mostly RPG world doesn't work as well. I also believe that the "bundle" has
this information and when installed, the pertinent pieces are copied to a
local file. 
My long range thoughts were that "eventually" version would be a
multi-headed beast that would work with many different techniques to know
version.

But, we need to start somewhere. For now, I would be content with extracting
version from a service program that is "hard-coded".

And, yes it definitely needs HTTP functionality.

To go to the next step...Here is an idea I've been playing with. If we could
get a "projectname.xml" file for each utility. The install process would
dump this file into a folder in the IFS or a DB file. Depending on whether
multiple versions could be installed, we would need different versions of
the version procedure. Using either the version number in the xml
<version>1.23</version> or a <version_procedure srv="HTTPAPIR4"
prc="HTTPAPI_getVersion"></version_procedure> we could retrieve the local
version. The <Version_procedure> element would always override the <version>
element. Then using something like this element
<project_website>http://scottklement.com/htttpapi.xml</project_website> we
could retrieve the remote version. In there, we only need to look for
<version>1.23</version>.

Then to pick up on Thomas' idea, a quick subfile and a couple of Xs later
and we have the new version installed and running!

Mike Krebs

-----Original Message-----
From: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-
bounces@xxxxxxxxxxxxxxxxxxxxxx] On Behalf Of Scott Klement
Sent: Wednesday, January 21, 2009 2:17 AM
To: HTTPAPI and FTPAPI Projects
Subject: Re: httpapi.XML parse problem

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
-----------------------------------------------------------------------


-----------------------------------------------------------------------
This is the FTPAPI mailing list.  To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------

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
-----------------------------------------------------------------------