On Saturday 01 March 2008 20:21:19 David Jensen wrote: > George Makrydakis wrote: > > 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. > > I think you're on track. Excepting only that 'I' think XML is 'cutting > butter with a chainsaw'. XML is unambiguous and if auto-generated I > won't object.
The original idea is to have the XML autogenerated. In order to have that, one must define the minimal set of instructions that the user actually has to write about the XML itself. Let's consider the following: 1) Full internationalization support 2) Different architectures supported 3) Alternative options for the build cycle (from flags to everything else). Now, all of these are possible through XML files alone. But the verbosity of such a task is not easy for the end user to sit down and write, so how about this: Have the end XML file be a single, monolithic file with all the information necessary (languages, architectures, etc) that is generated out of different files that different people work on. For example, it would be tedious for a translator to work on the monolithic file (just like what they do in all clfs, diy-linux, and lfs), nor to mention error - prone. If he had all the text serialized properly in another file, this implementational separation also carries extra safety weight: the one does not bother the other. It also ensures that a more > That said, are you thinking a lib and or libs and implementations or > just the mod/standalone implementations. Gui? > Yes I am thinking about a library set. It is easy to make C++ code behave like everything you want, provided you know how to do it. This is why I divide odreex into 3 components: 1) odreex libraries ( or a single libodreex.so if you want to build it that way): the implementation of everything. The library aims at offering ease of use by implementing among others a DSEL (Domain Specific Embedded Language) for doing the administrative tasks on the build phase. Other things included ? : filesystem abstraction iteration, memory management (an idiom like RAII is used here, but even a garbage collector could be added as an external dependency to those who would like that. I don't need that because of RAII and other C++ idioms), xml parsing with full DTD support, compression / uncompression, package management filters, and yes .... a network stack (why? because you have to download things, don't you...) The fun part? This is a multipurpose library to be used in other projects as well. This is why I prefer calling it "component framework". 2) odreex actors ( practically client application examples that serve as a basic template for eventual users to follow easily into their own design): the client applications. 3) odreex dramatist: this would be huge to explain here easily, but it is the core from which the monolithic XML files for redistribution emerge. The dramatist is the single dedicated part to XML and it can be summed up as this: database "templates". The dramatist is the XML database, itself. And any project wanting to do its own dramatist, it does not have to interfere at all with the library. Just open up an editor and XML your heart out. One other point: actors can also use dramatist components to output interactive and non interactive bash scripts for example. This means one thing: you get a pretty good control of the script flow if you want, and even create one HUGE bash script doing all you want. A comparison? GNU autotools. Instead of you writing the Makefile, you write the Makefile.am which is a few lines. What comes out of automake though, is far from simple lines; same applies with odreex. I should have cleaned it up and released the first parts today, but in the midst of all the turmoil here, i think i am falling back for no valid reason. Let's make some points about the gui: 1) if you go the apache module way (provided people want that), what you need is just a web application, therefore the gui problem is inexisting 2) if you go the command line way you do not need anything, but you can easily build a text based interface. 3) if you want a GUI: I personally prefer Qt, but anything that works with C++ would do. And everything of use, does work with C++. Using odreex would be like calling the libraries built, not a command line via a system call. You know what? This can work on windows as well. Why? Because the process is abstracted and standard C++ is used. Writing the windows system part (for example, opendir() calls are part of POSIX, not windows) is a trivial thing for a library writer. There are many more things to discuss about this, but I feel that I could put this list offtopic. I regret not having completed this last week. Thank you for the interest. > --- > David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
