SPARCConfDB TODO List
If you think you can help with any of these don't hesitate to contact us at sparcconfdb-developers@lists.sourceforge.net. Although much of the direction of this project is going to come from the PPCConfDB TODO list. You can contact that team at: ppcconfdb-developers@lists.sourceforge.net
Most important
- Get everything into production!
- Merge site content into a SQL db
- Make a cgi or shell script to receive user tarballs and merge them into the website
- Lots of people are never going to send us their configs in our format, however there are lots of configs floating around the web. Make some "rag-tag" section with stuff found in varius places
Less important
- Get debian/yellowdog testers to check if make-db script works for them
- Always open bug: Find more files to merge into the tarballs
New features
- Diffing of two files
Website Bugs
- the whitespace in the middle doesnt extend all the way down
This is a stupid bug, looks like it cant be solved atm. The current workaround is a dirty hack, we use height: 800% for the height - Get new logo
Other stuff
Here are some miscellaneous design plans for varius parts of the site which were used for the basis of 2.0 (this site).
Design debate:
This is a test page, a sample of what I think can be possible to make the Jeedo's idea easier to use.
So here is the first page, it would be a good place to list news about the conf files, and state of the unstable tree.
Check the "imac" item in the menu to see an exemple.We can also imagine something better with dynamic content ... But this is just an idea to make things easier and more friendly. Tell me what you think about it.
Here are ideas for the 2.0 version of the Jeedo conf files db (1.0 (Jeedo box, not up all the time)).
This site is the base layout I would like to use for the example #3.
1. Keep the current layout (1.0)
- + It's known to "work" (obviusly not well enaugh since a 2.0 is even under concideration)
- + Easy to upgrade, self generating (the apache index stuff.)
- + Works extremely well in text browsers, good for people who have only lynx or wget.
- - Scales badly, ending up with multiple identical or almost identical configuration files (the ibook 500 & 800 really) could be merged into one now couldnt they, but as of now any tweaking of the configuration files would have to be done by the maintainer of the site, causing unpredicteble breakage since i dont have access to all the machines here.
- - Manual insertation of everything.
2. Make it cuter - Keep the current layout in the backend
- + It will be just that, cuter, perhaps some limited support could be brought in to upload tarballs and the like
- - It will still have all the flaws of method 1 ..
- - ..but the additional trauble of maintaining a backend AND a wrapper plust scripts and stuff to parse the configure files, display them and rewrite in html, str_replace("\n","<br/>",$txt) and so on.
3. using a php/sql based layout
a public part with a "stable" tree which can be browsed like the 1.0 onea "private" part for authenticated users, with an unstable tree whichcan be browsed and conf files edited threw a "wiki like" interface.
- + using a "stable" and an unstable config file trees, can help to get "perfect files"
- + better scalability, can easely link one configuration file to one or more mac if identical
- + using a wikki style web site with version management of the files
- + can easely create and use search engine to get config files
- + new tar balls can be uploaded through the website and then managed byscripts to be inserted in the unstable tree
- - more complex to keep up to date
- - need to code a complete website and scripts
- - gentoo_release may implies multiples and complexes sub trees
- - need to keep people watching new files, merging some in the stabletree, removing others from the trees, ...
Features:
- Edit mode, a mode where users can edit current files and upload their diffs.
- File handling, diff -u new files and handle sent tarballs.
- A good look, draft : http://www.librium.org/~ange/ppc_config/index.html
- Search feature, search the database
- No-Bs-mode - tarball mode where users can download a tarball with their configs
- Cron deamon? - perhaps make a cron deamon which would run on users machines and upload configs every other month to be intercepted by a cgi script.
Proposition for a database layout:
Here is the differents table type we can found in the database : - mac_type : just to separate ibook, powerbooks, G4, G3, ... - mac_version : differents versions of the macs - conf_file table : each conf file type got its own table : XF86Config-4 got its own, as make.conf ... - kernels : a table for the kernel configurations - link_table : allow to do associations between rows of the different table there will be nine table based on the "conf_file type" : fstab, gentoo-release, make.conf, sysctl.conf,yaboot.conf, XF86Config-4, mac-fdisk, cpuinfo, lspci. Tables : mac_type : _id : id of the row _name : name of the mac type (ibook, poweerbook, ..) mac_version : _id : id of the row _name : name of the version (hum, may be optionnal) _releaseyear _cpu : G3, G4, G5 ... _freq : cpu freq conf_file type : _id _name : optionnal, because in the table we only got conf files of the same type _rec_date : revision date _content : the configuration _kernel : _id _version : kernel version _release_nb : r0, r1 ? _configuration : the content of the configuration file _modules : the content of the modules file link_table : _id _mactypeid _macversionid _kernelversionid _XF86Configid _fstabid ...