On Saturday 01 March 2008 18:07:59 David Jensen wrote: > TheOldFellow wrote: > > On Wed, 27 Feb 2008 16:06:41 -0700 > > > > Gerard Beekmans <[EMAIL PROTECTED]> wrote: > >> What if LFS wasn't in book form anymore. What if it's an interactive > >> program instead. A 100% merge of LFS, BLFS, ALFS, <any>LFS.
After some thought, I think it is ok to post some thoughts of mine regarding this, since not only I am interested but I am working on this. The increased verbosity of such a format, poses a series of considerations related to how things should be done. For example, the book would have to be transformed into an abstract base, from which different "streams" could be streamed out in both LFS "subflavor" and different content. This would equate to transforming the XML "book" into an XML database. This means that the entire design should focus on the fact that you are dealing with a database by itself, not a book. Include the mandatory internationalization of the project and you are to spend quite some time into figuring out how to do this. XML databases are quite different from a book template in both design, implementation, and use. > > <snip> > > > > I like this. > > > > The design could be quite difficult as it probably will > > need to run in a number of environments (X11 and not, for instance), and > > could allow for various multimedia presentations during the > > installation - sound, flash, html, as well as text, come to mind. Not if you rely on an XML "database" for everything. There are two problems in this approach that can be easily solved though: First, implementation wise, PHP is not up to the task, alone, so this means that you will be adding up into the dependencies of the project. More dependencies create more variables for possible flaws to emerge and maintenance to become stagnant. Don't use PHP alone then. But that will create a maintenance hell due to the dependencies. > The easiest interface would be adding a .alfs handler to Firefox. > Configuration of defaults done the same way. I'm not sure about text > browsers. > > > There needs to be a non-interactive switch, a quiet switch, and a > > dummy-run switch too. The interface is quite a trivial matter that can be solved easily as well. > Buttons could be added? > > > How to handle upgrades? The discussions on PM's have been interesting, > > I favour using an existing PM, but other than that, I'm easy. See a proposal below. > Also handling overlapping dependencies between modules requires a PM > that checks what is already installed. Actually, what is necessary is to have a system that deals with dependency resolution outside and over any package manager involved in this process, for obvious reasons. Transforming the content from a new "book" format into RPM, DEB, TGZ or <any other package management here> requires a system comprised of filters so that we have the following: xmldatabase (XML contents) --> RPM filter --> rpm build instructions xmldatabase (XML contents) --> DEB filter --> deb build instructions ... xmldatabase (XML contents) --> A filter --> A package manager filters. but also: xmldatabase (XML contents) --> xhtml filter --> xhtml format for instructions. xhtml filter => can be customized by the end user. In a few words, the essential representational unit of this problem is the following: XML Database --> filtering() --> Filter result Where one important aspect is that the various filtering() calls can cooperate with each other before final output. What is important is that they dump to a format that can be understood by a package manager, a browser, a text editor or a video player (to make an extreme but unpurposeful example). Providing means to create these filters waives the need from the community to have to do support on different dependency resolvers, resulting in further LFS fragmentation. However, it also allows end users to refine the process if the xml database upon which the system relies is complete enough. The single link then, is the verbosity of the XML to be used. In a few words, the engineering and design tasks you are to undertake are not resolvable by a script - oriented language without resorting to multiple dependencies that will cause maintenance break ups. Not to mention the performance issues. Relying on a more suitable language like C++ about this also has the advantage that it is possible to reuse the same code and craft it into an Apache module ( http://www.zarfmouse.us/apache-cplusplus/ ). This can have several consequences on the design of a web platform and stand - alone. In stand - alone for example, because of its nature, it is easy to make it interact via the right bindings with other more "user friendly" languages for a quick end result. Many projects use bindings for this. Through JNI you could work with Java as well if you want to do that. And if you want to work with the terse but efficiently put Haskell flavours, you will be welcomed to do so, if anyone is interested in providing these bindings. In web - oriented mode, and we are talking about web applications, the same can be said with the use of apache dedicated modules. Use everywhere, easily. Rapid development. And of course, performance. One solution to all the problems is would be to have a single implementation for these things that makes things easy to develop further once there is a need, without having to rewrite everything. This is what I am trying to do, firstly, with odreex. Tell me what you think. > --- > David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
