It seems, responsible development would consist of going back and cleaning up the code already developed.

This proposal doesn't address the parameter problem where a package takes it's default parameter values from the package.info file for each new instance global or not.

Why not add an optional attribute or two to the package.info parameter tag that denotes where to get the new instance value from, the .info default or a previously instanced version of the package (denoting either the first or the last case of the package's instances to cover various use cases) if available?

Either way, the one acs-global-service non-core package seems like it would be useful for other things, too. What's the big deal about having a shared service package? Each portlet has been getting it's own package designation for awhile, thereby fragmenting a package to sets of packages. An acs-global package would be a positive step in pooling these shared code and environment variables.

Now, since you found it, and I'm lazy - what TIP # was it?

Linky linky please!

Don, that global parameters feature would be a god-send for those of us that have many instances of some packages.  The way I pictured your implementation is that each package would see an uneditable value for global parameters, but that makes me wonder how you would handle any package-specific overrides.  Then, if you have admins overriding global parameters on a per package basis, they've defeated the whole point, right?

I guess what I would suggest is the admins should be able to override the values per package, but they need to see an explanation of why it's not a good habit to get into.  Additionally, it might be a good idea to have a list of packages that have overridden values on the page they set global values.

I was thinking about permissions with regards to parameters, in the context of sensitive data in ecommerce package for example.

The CONTEXT attribute solves that with the addition of your "none" suggestion.