Hi Ian, In share your concerns with backwards compatibility.
These are taken care of as follows: (O1) Make /etc/map location configurable The default location remains /etc/map. Thus if there is no configuration, the /etc/map structure is still read. (O2) Add support for RunModes The sling:runmode properties are optional. If a configuration entry doesn't have this property set, the entry is always used. Hope this helps. Regards Felix Ian Boston schrieb: > On 10 Dec 2009, at 10:13, Felix Meschberger wrote: > >> Hi all, >> >> In our commercial CMS application we have a mechanism where we separate >> authoring instances (where content authors fill in content) from >> publishing instances (where internet surfers hit). Content authors can >> validate the content before publishing it to the publishing instances. >> >> This all works well, except for configuration stored in the /etc/map >> structure to configure the URL to Resource mapping of the Resource Resolver. >> >> The problem is that we cannot prepare this configuration on the >> authoring instance without affecting the operation of the authoring >> instance. The reason for this is that the /etc/map location is currently >> fixed and cannot be configured. >> >> To overcome this limitation two options come to my mind: >> >> (O1) Make /etc/map location configurable >> >> This enables us to configure the /etc/map location and configure a >> publishing instance specific structure on the author instance. >> >> >> (O2) Add support for RunModes >> >> Our CMS system leverages the RunMode service from >> contrib/extensions/runmode to detect whether the system is running as an >> authoring or a publishing instance. >> >> So, we could enhance the entries in the /etc/map structure to optionally >> provide a sling:runmode property (single- or multi-value string type). >> If such a property is set, the entry is only used if the >> RunMode.isActive(String[]) returns true. >> >> >> WDYT of such extensions ? > > > I would be interested to know the differences between in the operation of > Sling in the different runmodes. As you know we are using Sling in a mode > where everyone is an author, so I would be concerned to see optimisations to > a published mode, that explicitly disadvantaged an authoring mode over where > it is now. > > I see no problem in making optimisations based on run mode that only create > an advantage for that runmode (eg change in cache expiry policy, assuming no > content modification etc) > > So in general, provided the extensions are not intrusive then I am supportive. > > > Ian > > > > > > >> Regards >> Felix > >