[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: httpapi.XML parse problem
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
-----------------------------------------------------------------------