Re: Package Manager

[Scott Klement <sk@xxxxxxxxxxxxxxxx>]

Thomas,

Once again, I want to point out that you need some sort of central 
repository of packages on the system.  At least, if you want the package 
manager to be able to present a subfile with all of the packages on the 
system, you're going to need somewhere for it to find out what all of 
those packages are.

I hardly think it's practical to scan every program and service program 
on the system for a COPYRIGHT string.

My suggestion, in a previous message, was to have an IFS directory where 
you place all of the package info, including the version, site to check 
for updates, etc.  Each time you install a package, it writes it's own 
information into that IFS directory.  When you want to look for updates, 
the package manager reads all of the files in that directory to 
determine what you have, then checks teh corresponding web sites for 
updates, and puts the results in a subfile (or web page or whatever).

Seems simple.  Why do you want to use an exported subprocedure or the 
copyright information for something like this?  Seems to make it more 
complicated, and still leaves us without any information about the web 
site, etc.


Thomas Raddatz wrote:
> Hi folks,
> 
> I thought it was a good idea to rather start a new thread about a 
> "Package Manager" than continuing the discussion in the "post" thread.
> 
> @Mike:
> 
> I played a bit around with the idea of a package manager and wrote a 
> bunch of procedures to retrieve package manager related information from 
> a given service program. While playing around I had the idea to use the 
> copyright information to provide package manager related information. 
> Doing it this way eliminates the need for calling a generic procedure at 
> a first step. Here is the copyright information I used:
> 
>    V1.9 - 29.01.2009 - IFS file and directory procedures
>    PKGMGR(version=1.9; date=29.01.2009; domain=de.tools400.ifs2.)
> 
> Please notice the "PKGMGR" keyword. It is used to define attributes for 
> the package manager. In order to get the information I call a procedure 
> that uses QBNLSPGM to retrieve the copyright information, retrieve the 
> PKGMGR(...) keyword data and break it into peaces (key/value pairs). The 
> key/value pairs are stores in a property list. Now the tricky part 
> begins. I then use the "domain" value "de.tools400.ifs2." to produce the 
> following procedure name:
> 
>    de.tools400.ifs2.PkgMgr_getProperties
> 
> "PkgMgr_getProperties" is a constant that is simply added to the domain 
> name. Once that I have the procedure name I activate the service 
> programs and call the procedure to get additional properties. Calling 
> "PkgMgr_getProperties" is optional! If all properties could be defined 
> at the PKGMGR() keyword calling "PkgMgr_getProperties" is not necessary. 
> But in case there is not enough space at the copyright information to 
> define all properties, "PkgMgr_getProperties" is an option.
> 
> "PkgMgr_getProperties" takes no parameters and returns a string like that:
> 
>    'vendor=Tools/400; email=info@xxxxxxxxxx'
> 
> The properties defined in the string are also added to the property 
> list. Because of the domain prefix (in Java they call it "package") 
> "PkgMgr_getProperties" is worldwide unique. So there should be no 
> trouble with duplicate procedure exports when linking programs or 
> service programs. I think it was Scott who mentioned that problem in a 
> previous posting.
> 
> If a product does not have a service program I could also retrieve the 
> copyright information from a program or from a data area.
> 
> Regards,
> 
> Thomas.
> 
> 
> ------------------------------------------------------------------------
> 
> -----------------------------------------------------------------------
> 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
-----------------------------------------------------------------------