Re: Bundling CGIDEV2 - how much should be brought along?

These are good questions and I've run into it a few times with my
software. For some reason someone will name an object the same as one of
mine, or use a service program with the same name (or the same one, just an
older version).

The only real cure in that case is to fix it with the library list. Or,
change everything to bind by copy (which I actually prefer for *most*
pieces of software that I distribute).

The biggest headache I think that ISVs will find when distributing an
application that uses CGIDEV2 is setting up the web server properly.
That's the only thing holding me back from creating web applications for
some of my tools (using my eRPG SDK of course). Figuring the best way to
package it.


On Mon, Dec 10, 2012 at 11:23 AM, Mark S Waterbury <
mark.s.waterbury@xxxxxxxxxxxxx> wrote:

Hi, Vern:

I have been following this thread with some interest.

The following discussion probably pertains mainly to ISVs who want to
"bundle" CGIDEV2 into one or more of their own product(s), and may not
apply to individual ("end user") companies who are using CGIDEV2 with
their own "in house" applications.

Suppose an ISV "bundles" a copy of the CGIDEV2 tools with one or more of
the ISV's products.What happens when the ISV sells (or licenses) one of
these products to a customer who already has some version of CGIDEV2
tools installed on their system(s). How does the ISV prevent the
possibility that their "bundled" version of CGIDEV2 tools does not
"overlay" one or more parts of the customer's version of CGIDEV2(the
*SRVPGM or any of those objects in Kevin's list,or any of the "template"
stream files that are installed into IFS directories)?

ISVs might need to consider creating a (slightly) customized version of
CGIDEV2 to "bundle" with their own applications. For example, an ISV
could rename all of the objects in Kevin's list, and/or ensure they are
installed in a different library, and ensure that any stream files
needed or used are shipped and installed into different IFS directory
paths. (Note that this may require some slight source code changes and
recompiling of the CGIDEV2 objects.)

ISVs should ensure that, at run-time, when the product attempts to use
CGIDEV2 services, they are really using the version that was shipped
with that product, and not some other copy that the customer may have
installed, either before or after installing the ISV's product(s).

If the ISV just uses the standard CGIDEV2 object names (e.g. CGISRVPGM2
*SRVPGM), what happens if the customer installs a different copy of
CGIDEV2, and then decides to add those objects to some library higher in
the library list than your product library, or they decide to add that
library to the system portion of the library list?

Such ISV-related issues seem to warrant some further consideration.

Mark S. Waterbury
--
This is the Web Enabling the AS400 / iSeries (WEB400) mailing list
To post a message email: WEB400@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/web400.