What if the book wasn't a book anymore

[David Jensen]

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