[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: httpapi.XML parse problem
Hi Mike,
To get started, I think it's probably worth noting that IBM i already
has a package manager, so to speak. IBM calls them licensed program
offerings (LPO or LICPGM). If you do a GO LICPGM you get a menu where
you can view the installed licpgms, add more, remove them, etc.
IBM provides APIs whereby folks like us can create our own licpgms if we
want to. However, I do find this method restrictive:
a) It has no facility to check versions against the Internet.
b) Everything revolves around the OS version. You have to have a SAVF
that's compatible with the current OS version.
But, I thought it would be remiss to not mention that this option exists.
Assuming that it's best to develop our own, we need to start with some
sort of a "repository" (database or other data file) that contains
information about all of the installed packages. XML files in an IFS
directory would certainly work. As would a PF.
When a package is installed, it would have to write the appropriate info
into the repo. This could include the project's web site, the library
you installed into, the service program name that contains the version
information, etc. It could actually contain the version information
itself, as well. What data is placed in this file, vs what data is
exported from a service program is really a design decision -- so those
of us who are interested in the project would want to hash that out.
Anyway, the repo should somehow have a way to contact the "mother ship"
(site where the package is hosted) so it can compare versions.
Other things could(??) also be in the repo, such as any options the user
selected during installation so that they could be repeated on
subsequent installs... or info about whether one release is
backward-compatible with another release, stuff like that...
Thoughts?
Mike Krebs wrote:
> 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
> -----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubscribe, please go to:
http://www.scottklement.com/mailman/listinfo/ftpapi
-----------------------------------------------------------------------