GoFigure project

Vizion vizion at vizion.occoxmail.com
Sun Nov 20 03:31:40 GMT 2005


On Saturday 19 November 2005 19:00,  the author Danny Pansters contributed to 
the dialogue on-
 Re: GoFigure project: 

>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
Thanks for your input 

I am on my way out so I have not had time to study it carefully.

I will get back to you

thanks again

david

-- 
40 yrs navigating and computing in blue waters.
English Owner & Captain of British Registered 60' bluewater Ketch S/V Taurus.
 Currently in San Diego, CA. Sailing bound for Europe via Panama Canal after 
completing engineroom refit.


More information about the freebsd-ports mailing list