AW: httpapi.XML parse problem

[RUDAS István <Istvan.Rudas@xxxxxxxxxxxxxxxx>]

 Hello Scott, Mike, Thomas, Group, Lurkers and Confused others!


It's a wonderful discussion, when cheeks turn to red, pegasus spreads his wings and brainstorming comes to fly,  ...

....    but I am somehow confused. Aren't you too?


A week ago Mike started a question about some Error #66 in XMLGEN, then a Version came around the corner, made a project and was at least well packaged. [And yes, IBM invented that damn License thing years ago which does not serve very much, but costs a lot, if I may add this to Scotts input.] --   ;-)



- Why should a developer have more than 1 version of HTTPAPI?   why should a developer KEEP an older version of HTTPAPI, if the newer one is brought to life? you hopefully do not speak about backuping a "last copy" of the older version of HTTPAPI  for restoring if the new version fails?

- if there is a reason for the above:  thank you for explaining.

- or: does the discussion turn away from HTTPAPI itself to a higher level (generally spoken: to  non-IBM-Programs/Packages), and targets to become a Developer's Standardized "Pgm Warehouse", which could have newer look and feel than LICPGM,  offer useful and web'bed  Informations and Functions and could become the future versioning - packaging - delivering - self-updating wonderbra?  (that's something which could be really challenging)
 

keep on to discuss and to brainstorm - I just wanted to be sure, what the topic really is,, before I drop my 2 cents msg, that I would like to have different mpeg's played with every new version in it ;-)

bye
István



 





-----Ursprüngliche Nachricht-----
Von: ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx [mailto:ftpapi-bounces@xxxxxxxxxxxxxxxxxxxxxx] Im Auftrag von Scott Klement
Gesendet: Mittwoch, 21. Jänner 2009 18:28
An: HTTPAPI and FTPAPI Projects
Betreff: 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?




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