Hi Sriram,

Sriram Natarajan wrote:
> 
> 
> Jan S Berg wrote:
>>
>>>> It is the MySQL server binary. The interface should maybe be the 
>>>> "server program command line options" ?
>>>>           
>>> How do I pass those command line options when starting via smf?  If
>>> these are needed, they probably need to be smf properties? Or can they
>>> be in config file?
>>>       
>> All options for the MySQL server can be in the default config file, 
>> also the datadir option,
>> so we don't have any use for passing the command line options to smf, 
>> but it might be that users
>> want to start the MySQL server without smf to test different 
>> configurations of MySQL f.ex.
>>  
>>>      
>>>> ok, error codes should be Commited interface while the messages can 
>>>> change as you say, so they should be UnCommited. So scripts should 
>>>> rely on the errorcodes and not messages. Should both be listed here 
>>>> as interfaces?
>>>>           
>>> Note that Uncommitted is also a relatively stable public interface
>>> type.  Volatile is closer if the messages can change, but if scripts
>>> should not rely on the exact message text anyway, it is 
>>> "Not-an-interface".
>>>
>>> For more background see
>>> http://www.opensolaris.org/os/community/arc/policies/interface-taxonomy/
>>>
>>>       
>> ok, will state the messages as Not-an-interface, and keep the 
>> error-codes as Commited.
>>
>>   
> With respect to SMF integration, I have a question - will MySQL 
> component be doing something similar to what has been discussed in large 
> during Apache integration discussion ?  For example, will Starting / 
> Stopping MySQL server either through SMF or through 'safe_mysqld' 
> command provide a consistent experience ?

Good point, I'm not sure if I have followed all the discussions on 
Apache, but using mysqld_safe and smf should give the same experience. 
Another issue I saw from the discussion was about versioning, which
we should do something similar with MySQL

Thanks,
Jan S

Reply via email to