Jan S Berg wrote: > > A first draft for the MySQL ARC case is posted at: > > http://wikis.sun.com/display/WebStack/MySQL50ArcCase
A handful of comments/questions: > This case seeks Major Release Binding. This nees to be Minor (at most). > 2.1. Key objects > > MySQL objects (Server): I realize several previous cases have listed these sections but I'm finding it very repetitive. I see sections 2.1, 2.4 and Appendix 1 repeating essentially the same layout info. Having the full listing in the Appendix is nice, so I'd just suggest combining the content of 2.1 & 2.4. That'll reduce the repetition and make the doc easier to maintain. > /usr/mysql/5.0/share/mysql > /usr/mysql/5.0/share/binary-configure Can you say a bit more about these? > 2.2 Versioning The stability of the upstream code between major/minor/micro versions drives a number of decisions in the rest of the case. For that reason, I'd like to see a summary here on how compatible MySQL remains within minor & major release families. Do you expect all future 5.0.* to be fully compatible? How about 5.1? Or 6.x? Does the MySQL community make explicit promises on future compatibility? Historically, how compatible have these been? (There's 1 sentence about this in s.7.1, but more info will be helpful here.) > 2.4 Directory Naming and Structure > > The proposed directory layout for MySQL is > /usr/mysql/5.0 Provide at least a paragraph explaining the choice of versioned layout here, given the compatibility info [to be added] in 2.2. Can I infer that 5.0.* will be compatible but 5.1 won't? > /bin > /doc > /etc > /lib > /include > /info > /man/man1 > /man/man8 > /mysql-test > /share > /src > /sql-bench > /etc > /var/mysql > /datadir/ Many are obvious here, but I suggest providing a short (few words) description of what goes in each location. What goes in share? src? info? > /usr/mysql/ will expose bin, include, lib, man, share, and src > directorie s.These will be symbolic links to corresponding directories > in the highest numb ered <version>.<subversion>.<minor-subversion> > directory in /usr/mysql hence, u sers will be able to use > "/usr/mysql/bin/mysqld" to invoke the most recent vers ion. Be aware that previous cases like PHP considered and rejected this symlinking. Will the documentation recommend writing scripts which invoke /usr/mysql/bin/mysql for example? What happens when an incompatible version (be it 5.1 or 6) is installed? Other components like perl do provide this linking. So it's been done both ways. My suggestion is to consider the use cases carefully and include a paragraph in the case explaining the reasoning of your choice, whichever approach you choose. > 2.5 Configuration and Enviroment settings. > > The mysql server (bin/mysqld) uses (and clients can use) configuration fil > to start. The daemon and the client read the same config file? > The search path for thiss configuration file is as follows: > 1. /etc/my.cnf I guess that is fine, but obscurely named files in /etc are not great, IMO. I see debian, for example, creates /etc/mysql/my.conf, which makes obvious what it is. Have you considered this approach? > 2. $MYSQL_HOME/my.cnf > 3. specified on command line with --defaults-extra-file=<path> > 4. in user home: ~/.my.cnf Do these apply to the server as well or just the client 'mysql'? What does #3 mean to the server if it is started (as is the default) via smf? Which user will mysqld run as? root? So it reads /.my.cnf? Not the best place for mysqld configuration ;-) Is the order in which you listed these significant? Does it stop as soon as one is found or does the last one found override or does it read all of them and try to merge config from each? > For MySQL we will provide a sample configuration file which can be > used by users in one of these search paths. The sample configuration > file will be in /usr/mysql/5.0/etc/s ample_my.cnf One of the goals of web stack is easy out of the box experience. I'd like to see this project deliver a working configuration in somewhere under /etc, tuned as necessary to work best on OpenSolaris. When creating the default config also keep in mind safe & sane defaults, for example for "bind-address" you'd probably want 127.0.0.1, etc. If you decide it is useful, you could also deliver the sample config file from the upstream distribution as-is, possibly in the /usr/mysql/5.0/etc/sample_my.cnf location shown above. But do deliver a tuned, working copy under /etc. >3. Core Modules > > These are the proposed (statically linked) modules enabled by initial > integration. > > MySQL server > InnoDB - ACID storage engine > MyIsam - non-ACID storage engine Are the just ./configure time options or external modules? Is the "statically linked" comment just a detail? Would anything be different if they were dynamically linked? > 4.1. Manual Pages. > > MySQL provides a man page, which will be delivered in the > appropriate m an directory. > [/usr/mysql/[<version>.<subversion>.<minor-subversion>]/man], with an Maybe a typo, but here the versioning is inconsistent with rest of doc? > SUNWmysql50src - MySQL src The source lives in opensolaris, why a package for it? Or is this something else entirely, like src for modules customers need to recompile or such? > 7.3. Exported Interfaces > > NAME STABILITY NOTES > E01 MySQL Server Volatile Server deamon The daemon itself isn't an interface, just a process that runs. Can you expand on the intent for this line? > E02 MySQL C API Volatile - A Volatile API isn't very useful... (more below). > E06 Utilities Volatile Database management ut Does this cover everything in the bin directory? > E10 MySQL Server config file Volatile Sample config file The interface is the syntax of the config file, not the sample per se. > E11 MySQL Data/Log Directory Volatile - It's location? Or format? Is the data file format public at all? Logs are probably Not An Interface? > E20 TCP listen port Volatile - Which is it? > E21 PID file Volatile database deamon pid fi Does this really need to be public? (since smf is the public interface for start/stop). > E30 Man pages Volatile I wouldn't bother listing this, it is for human eyes only. > E31 Error messages Volatile I18N Messages (like logs) are probably Not An Interface (unless the MySQL community specifically documents them). Error codes might be documented? > As this is OSS, we have no control over the stability of the > interfaces, an d hence the classification as "Volatile" for most > interfaces. Volatile is undesirable. Basically it means nobody can rely on MySQL since the interfaces break every time there a few bug fixes. But more to the point, you're saying you might overwrite /usr/mysql with incompatible versions at any time. If so, why provide versioning in the form of /usr/mysql/5.0/? A benefit of the versioned layout is that you can keep the content of /usr/mysql/5.0/ compatible; if an incompatible 5.1 comes out you can place it in /usr/mysql/5.1 instead. > /usr/mysql/5.0/lib/libdbug.a > /usr/mysql/5.0/lib/libheap.a > /usr/mysql/5.0/lib/libmyisam.a > /usr/mysql/5.0/lib/libmyisammrg.a > /usr/mysql/5.0/lib/libmysqlclient.a > /usr/mysql/5.0/lib/libmysqlclient.la > /usr/mysql/5.0/lib/libmysqlclient_r.a > /usr/mysql/5.0/lib/libmysqlclient_r.la > /usr/mysql/5.0/lib/libmystrings.a > /usr/mysql/5.0/lib/libmysys.a > /usr/mysql/5.0/lib/libvio.a > /usr/mysql/5.0/lib/libz.a > /usr/mysql/5.0/lib/libz.la How are these used, by whom? -- Jyri J. Virkki - jyri.virkki at sun.com - Sun Microsystems
