Date: Sun, 20 Nov 2005 03:00:58 +0000 From: Danny Pansters <danny@ricin.com> To: freebsd-ports@freebsd.org Subject: Re: GoFigure project Message-ID: <200511200300.59072.danny@ricin.com> In-Reply-To: <200511191729.07905.vizion@vizion.occoxmail.com> References: <200511191729.07905.vizion@vizion.occoxmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday 20 November 2005 01:29, Vizion wrote: > Hi > In the past I have discussed my interest in trying to build a viable web > interface for documenting and maintaining configurations for freebsd. IMHO that should include the (ways of) configuration itself because that's as much part of it working or not. > I now have a specific project in mind that I have labelled GoFigure and > would value some feedback from this list of reactions to the proposal and > opinions about GoFigure's viability, appeal, extensibility and the degree > of collaboration that could be anticipated. > > The basic concept is simple in concept but will require a lot of work and > collaboration. I suggest that GoFigure_1.0 would represent the achievement > of the following five loosely described stages: > > 1. Creation of XML schema to cover the definition, validation, > interpretation, documentation, & editing rules for configuration files in > freebsd ports. Hmm perhaps an API first, and an XML schema later? > 2. Building a parser to generate an XML version of configuration files. That would be nice but I again think that would require having a unified api first and at the end pour that into a formalized xml format (and perhaps also a simple text format which represents configuration as-is now. That would really make a bridge from what is to what you'd like to I think) > 3. Building an XSLT based processing system that also converts XML versions > of configuration files into the configuration file(s) required by each > port. Ok, if an XML format proves to be better than the "flat format" that's in use now. > 4. Creating a mysql database for storing and manipulating the data. If a database is needed. Current solutions use flat hashes and such, and as long as they're categorized by the port catagory and after that flat it's pretty much a flat database altogether and any use of any db that has super duper indexing wont help. IMHO ports/packagers should be indexed in some way that's not obvious in human context but which is in the context of the underlying system, e.g. by dependency. > 5. Creating a web application that uses the XML versions of the > condiguration files to provide a sysadmin interface to inspect, validate, > maintain, edit, track, document and finally generate configuration file > updates using the tools built in stages 1>4. Now here's where you should use xml until the very detailed rendering end because it's a way to get to not only web but also qt/gtk/.. front GUIs. > In the long term I see some potential for dynamic use of the metadata and > data in the XML files for XML based applications to manipulate and manage > updates and for comparing different system configurations. Could you explain how? Because this is the interesting part... can you get ports/packages metadata and corresponding handling in a nicer more general frame (with xml or not, start with an api). > If I decide to proceed with this project I have a limited amount of time > that I can devote to it and my enthusiasm for it will, I think, largely > depend upon how useful a contribution others feel it would be to freebsd > and how willing committers might be to collaborating with it. > > comments please There you go, IHMO. Greets, Dan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200511200300.59072.danny>