GoFigure project

Danny Pansters danny at ricin.com
Sun Nov 20 02:03:06 GMT 2005


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


More information about the freebsd-ports mailing list