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. That said, are you thinking a lib and or libs and implementations or just the mod/standalone implementations. Gui? --- David Jensen -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
