On Mon, 2008-11-03 at 16:17 +0100, Thomas Bächler wrote: > > What I'm doing now is moving: > > - the UI logic into lib-ui.sh (eg you can ask questions and inform the > > user in a mode-agnostic way. set a variable to use dialog mode or plain > > cli) > > - the backend "real work" code into libraries like lib-pacman, > > lib-network etc. > > - the flow control functionality in a (draft of) an 'interactive' > > profile (what might someday become a replacement of the current setup > > script) > > This sounds awesome to me. > Just to clarify: I'm not aiming for 100% separation of backend and ui logic anymore, because that would make it much more complicated then it's worth. The 'flow control' part however is now (supposed to be) entirely separated into the 'interactive procedure' though. (see my previous mail for detailed explanation). (But yes, it's still awesome ;-) > Just a thought: If you want to, you could also move the whole code into > a more sophisticated language (Python, C, C++) if bash is too restricted > for you. Ironically, I used to be a decent programmer and sucky at sh/bash, but being a system engineer for more then a year improved my shell scripting skills a lot, the other languages have suffered from lack of attention :-) I do think that bash is a good language for something like this though. There's a lot of interaction with other base tools and it's very accessible to end-users. As long as bash' limits are not holding back development, I think it's best to stick with it. (+ I really wouldn't want to port the current installer to another language. Refactoring it in the same language is already hard enough :P ) PS: I actually managed to install a system now with the ported interactive procedure, it breaks while finding the root device but at least we got this far :-)
