On Jun 29, 2011, at 6:46 PM, Brian Stansberry wrote:
I'm curious to hear other viewpoints.
The initial idea of considering <include/> being syntactic sugar was mostly
addressing
client operations with the assumption of eliminating the included profile and make it look
and
behave like one single profile at runtime.
I.e. read and write operation would simply have to work on one address. This is currently
causing most of the problems, since clients have to maintain the source reference on their
own. But conceptually you don't care if
a profile is actually a composite of many others. At the end of the day, a server group
does reference a single profile and that's how users will perceive it.
I would prefer a solution that's straight forward and easy to understand:
- <include/> is syntactic sugar
- at the end you'll address a single profile (i.e /profile=web) for read & write
operations
(even if it includes other profiles)
- the domain layer takes care it properly distinguished and persisted into each source
profile declaration
- no cyclic references are allowed. the parse should choke on this.
- subsystem overlays are not possible. This means re-declaring a subsystem in extended
profiles is not allowed
The last point is especially important to keep things simple:
If we allow to re-declare profiles, we would need to think about other implications too:
- will it replace the existing declaration?
- or will it merged with an existing one
all the other problems described earlier do also apply:
- what profile do I address in write operations
- how will this be applied to servers?
I think we prevent all this, by simple not allowing subsystem re-declarations .
Ike