Renaud Manus wrote: > 2.1 DTD extensions > > The prop_pattern example is confusing: > why do you specify <internal_separators> if <cardinality> is set to 1 ?
That's exactly what you'd need for a property which encodes multiple settings in one value and doesn't look for additional values defined in the property. > 2.5 Manifest updates > > Are the updated manifest supposed to replace (delete/import) or upgrade > (import) the old ones, in case of a system upgrade ? > The later is probably safer but it loses customizations... Upgrade, just like all manifest updates anyone delivers in Solaris. There's no new code for this part. We just deliver the manifests as updated in the source base. If there's something specific you're concerned about, please let me know. > Can you comment a little bit more on svc:/system/svc/global and SMF-wide > templates? Sure. The general idea is it defines things that the SMF framework needs in general. i.e. the format of the templates repository representation, and the "general" property group. > > Is it started before svc:/system/svc/restarter ? Wasn't planning on it. It currently will be a transient service with ':true' as the start method. > What if an entity already defined in svc/global is redefined in another > service (with a different meaning) ? There will be a warning on import and on subsequent validations for that service with the conflicting definition. However, the most specific template match for a given property group will be used. (This is defined in the smf_template(5) manpage: http://cr.opensolaris.org/~lianep/templates-0306/smf_template_5.new ) > > Can you customize svc/global entities from within a service (eg. change > the 'description' to be less generic for a specific service) ? svc/global will be defining things that have specific meaning to SMF globally. That's very few things, so I expect the places where people would generically want to do so are limited. (e.g. customizing the description for general/enabled seems like the wrong place to give more service-specific information.) If people want to do so commonly for something defined, we can look into a way to augment the information. > 2.6.2 > > internal_separators astring[] optional > list of separator characters for values > > Can you mix the separators ? I'm not sure what you mean here. > Why not just astring instead of astring[] (it seems over complicated) ? I didn't want to limit the possibility that the separator was not a single character. Then you'd need separators for separators, and that'd limit the character set. Thus, it seems best to put the separators in multiple values. Really, though, most uses of this will just have a single value that works as a separator. Few people say that - or : works. Their app just uses one separator character. > Is there a default value ? Nope. We're not looking to encourage this type of encoding. Using multiple values is usually more appropriate than encoding multiple values into a single string. If a program requires it, though, people will need to use the ones the program defines, not a default we define. liane
