Jyri Virkki wrote: > Jan S Berg wrote: > >> I think they could be useful for users as well, both for running >> sql-benchmark test as well for examples of how to use the client >> api's. >> > > Sounds good; document that in the spec. Bundling what sounds like > development tests is a bit unusual, so it's good to have a paragraph > explaining why it might be of interest to end users. > ok, I add a paragraph for this. > Given the size of the set of test files, I'd say definitely a separate > package, as you have it in the spec already. That way users who don't > need that can remove them. > > >> 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, >> > > Good to know.. > > > >>>> The user just needs to change the data directory in SMF manifest (if he >>>> is using a different data directory than default) ...and SMF will work >>>> fine. >>>> >>> To confirm, if it is the default location no change is needed? >>> >> >> The default location can be used or changed also via the config file. >> > > "Also" is bad - what if I set conflicting defaults in smf property > vs. config file? Pick one. > > If it can be set in the config file, I recommend documenting that's > where it is set. Don't create a redundant smf property. > Yes, it will be only the config file, not as smf property. > >>> That leads to the question whether there is any command line option >>> without config file equivalent? >>> >> >> No >> > > So sounds like you don't need to have any smf properties then? > Makes it easier.. > No, we should do without :) > > >> You can also start the MySQL server without smf. You could always use >> > > You can do many things ;-) > > You'll want to pick which set of interfaces you intent to support, so > that's what goes on into the exported interface table. It needs to be > controllable through smf in order to behave well within Solaris; if > you also want choose to support direct invocation, that's ok, in which > case the interface table entry makes sense. I just want to make sure. > > This probably ends up being just an implementation detail, but do make > sure that if you support both ways, that they play well with each > other. > ok, I have updated the ARC draft including changes for your comments.
Thanks, Jan S > >> The ARC case has been updated with the smf interfaces, are they sufficient? >> > > Should be, yes. If it had any properties you need to list them but > looks like it won't. > > >
