Conference iosg::all-in-1_v30

    Fiona, I would probably opt for (2).  If I were installing your
    application on my node I wouldn't want your stuff to overwrite:
    	1. The existing ALL-IN-1 IOS-supplied code, or
    	2. My local customizations.
    
    By using a separate application area, you allow me to:
    	1. Merge my customizations to your code after installation (warn me
    	   about this in the installation guide) and
    	2. Choose to make your application code available to all or a subset
    	   of users.
    
    In the installation guide, if you provide a list of standard (OA) parts
    that you have customized, it will let me migrate these to their proper
    place (if I choose to move them there) using CM.  My system needs to
    operate as it has been after a new application is installed.  To get
    the new application working properly, I should read instructions (and
    follow them).
    
    All this is IMHO, of course ;*)
Dan

    As you provide lots of new elements with a small number of changes to
    standard code I would use a separate area.  That would allow you to
    upgrade your application without affecting ALL-IN-1.
    
    Tony

>    Fiona, I would probably opt for (2).  If I were installing your
>    application on my node I wouldn't want your stuff to overwrite:
>    	1. The existing ALL-IN-1 IOS-supplied code, or
>    	2. My local customizations.

Don't get this wrong. If you packaged an application (Package/Restore) we'll 
only overwrite Base elements (as would an ALL-IN-1 installation), and 
overwrite local customizations after saving the original ones. 

>    By using a separate application area, you allow me to:
>    	1. Merge my customizations to your code after installation (warn me
>    	   about this in the installation guide) and
>    	2. Choose to make your application code available to all or a subset
>    	   of users.

Indeed, it gives you the flexibility of making the code available for a subset 
of users, but keep in mind that a change to the original customized element 
also needs to be made to the element supplied by the application. 
One of the first notes in this conference dealt with the same situation of the 
same element appearing in multiple application areas. The potential problems 
for DO, BLP and SCP are there. E.g.:

	OA				New Application
	A.SCP (Base & Site)		A.SCP (Base)

Although A.SCP is compiled first, users of the New Application will use the 
A.SCP of 'OA' as that one appears in the CMTXL (Site TXL), unless they run 
$ ALLIN1/NOCUSTOM.

So, from a maintanability point of view I would opt for 1, from a flexibility 
point of view (that is, allowing to have subsets of users using an application,
and you are prepared to do some additional work for maintanance) I would opt 
for 2.

Ciao,

	Simon

    Thank you, thank you, thank you, Simon!  With such a strong pro-(2)
    contingent, I was beginning to feel like a real dork for having asked
    at all.  But now I am a little confused.
    
> Don't get this wrong. If you packaged an application (Package/Restore) we'll 
> only overwrite Base elements (as would an ALL-IN-1 installation), and 
> overwrite local customizations after saving the original ones. 
    
    Notes 1408.* indicate that Package/Restore puts application elements in
    the Development area (and the one I did today of OA elements certainly
    did).  Is that only the case when the application has been packaged
    from Live rather than Base?  Or only when the application is OA?  It
    doesn't seem logical, for the reasons Tony gave.
    
>Indeed, it gives you the flexibility of making the code available for a subset 
>of users, but keep in mind that a change to the original customized element 
>also needs to be made to the element supplied by the application. 
>One of the first notes in this conference dealt with the same situation of the 
>same element appearing in multiple application areas. The potential problems 
>for DO, BLP and SCP are there.
    
    Putting OA customizations in another application's Base area doesn't
    lead to flexibility if they are compilable elements.  They end up in
    A1TXL and all users can access them unless the site happens to have
    already customized the OA Base versions.  But if that is the case, then
    no-one can access them (unless they use /NOCUST) until you re-apply the
    site's customizations to your elements, and then they end up in CMTXL
    and everyone can still access them!  I just re-read 141.* and 160.*, so
    I realise moves are afoot . . .
    
    In the meantime, since our application's customizations to OA elements
    are mostly for the purpose of preventing users from accessing our
    application's data from outside the application, it doesn't really
    matter if non-application users get them too.  I can still see
    arguments for either approach, so I will probably make up my mind
    closer to release time!
    
    FS

    Elements are always restored into the development area if you ask for
    them to be placed into APPLICATION rather than RECEIVE.  We have made
    recommendations that you always use APPLICATION in V3.0 due to the fact
    that there's no easy way to select elements in a receive area at the
    moment.
    
    The logic behind putting elements in development is that we never take
    an action that affects the running system (that users see) without the
    say-so of the system manager, who, of course, must eventually move the
    elements into the live area when he/she processes marked elements.
    
    I think the point that Simon was making is that if an element is
    overwritten (superseded) by an incoming element it will be "saved" into
    the application's receive area.  This is a little known feature and
    certainly one that I was blissfully aware of until Simon told me about
    it last week.  All the things you learn about your own subsystem....
    
    So even if you restore elements from your own application (rather than
    OA) you can expect to find them placed into the development location
    rather than directly into the live area.
    
    Tony