Bugs for Sorcery are reported here

[bugzilla-daemon AT metalab.unc.edu]

http://bugs.sourcemage.org/show_bug.cgi?id=342

msasgl AT msa-enterprises.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |msasgl AT msa-enterprises.com



------- Additional Comments From msasgl AT msa-enterprises.com  2002-10-16 09:27 
-------
Reading this, a lot of the examples sound like the things I have in mind with 
the bash database library and hardware detect stuff. Particularly being able 
to "store" and "lookup" variables in a spell independant way.

The sort of things I am thinking of:

Bootloaders - store the settings in a generic format in the database and let 
the bootloader spells pickup configuration details from there. This allows 
foreign boot sections to easily be added to the sourcemage system, extra 
options to be appended and allows for easy swapping of the bootloader for a 
different one.

Roll out distros - prefill parts of the database to setup preconfigured 
custom 
sourcemage installs. e.g. ask for IP Address, but LAN, gateways, DNS etc are 
prefilled.

hardware detect routine identifies cd writers and puts them into the 
database. 
cdrutils spell can then lookup variables from the database to ask things 
like "Should I set your SAMSUNG CD-R/RW SW-240B as the default CD recorder?" 
and setup cdrecord.conf appropriately.

Of course that leads to the possibilities of being able to have the cdrecord 
spell "depend" on the cdwriter hardware being available, which opens another 
massive topic for thoughts. Like whether there should be a variation of 
triggers for when variables change...

Foreign casts - swap out the hardware section of the db & you have an easy 
way 
to create ports and hardware upgrade install ISOs. This would need the 
depends 
on hardware stuff to be relatively reliable. This is where the "cast -target 
zaurus tuxracer" idea came from ;-) 

This swap out idea could be applied to any section of database. So we could 
have different base systems by swapping out the preserved section etc..
Handy for embedded devices, consoles and so on.

I could go on and on here, but I'm sure you get the idea that I think we need 
a 
far more comprehensive system for managing system variables than the one 
suggested here.

And I'm already working on parts of it ;-)




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.