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