From owner-freebsd-current@FreeBSD.ORG Tue Apr 13 22:05:35 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36EDF16A4CE for ; Tue, 13 Apr 2004 22:05:35 -0700 (PDT) Received: from mail013.syd.optusnet.com.au (mail013.syd.optusnet.com.au [211.29.132.67]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A37B43D4C for ; Tue, 13 Apr 2004 22:05:33 -0700 (PDT) (envelope-from akm@theinternet.com.au) Received: from theinternet.com.au (c211-30-103-113.carlnfd1.nsw.optusnet.com.au [211.30.103.113]) i3E55IV24288; Wed, 14 Apr 2004 15:05:18 +1000 Received: from theinternet.com.au (localhost [127.0.0.1]) by theinternet.com.au (8.12.11/8.12.11) with ESMTP id i3E55J6q067529; Wed, 14 Apr 2004 15:05:19 +1000 (EST) (envelope-from akm@theinternet.com.au) Received: (from akm@localhost) by theinternet.com.au (8.12.11/8.12.11/Submit) id i3E55HlQ067528; Wed, 14 Apr 2004 15:05:17 +1000 (EST) (envelope-from akm) Date: Wed, 14 Apr 2004 15:05:17 +1000 From: Andrew Milton To: Martin Message-ID: <20040414050517.GA59412@camelot.theinternet.com.au> Mail-Followup-To: Martin , Garance A Drosihn , FreeBSD Current References: <20040413121925.GB29867@voodoo.oberon.net> <407C4035.8020609@ciam.ru> <1081896823.772.58.camel@klotz.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1081896823.772.58.camel@klotz.local> User-Agent: Mutt/1.5.6i cc: FreeBSD Current cc: Garance A Drosihn Subject: Re: Second "RFC" on pkg-data idea for ports X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2004 05:05:35 -0000 +-------[ Martin ]---------------------- | Am Tue, den 13.04.2004 schrieb Garance A Drosihn um 23:40: | | > Well, do not focus too much on whether it is "XML-like". | > | > It is just a format I dreamed up. It does what I want it to do. | > If someone has a better format, and a format which will be as easy | > for a simple program to process, I will be willing to try that | > format instead. I am not too hung up on this specific format. | | I would personally like it to use XML. I'm developing a small | application which is a kind of GUI for ports (works like a | browser). It is very difficult to parse the Makefiles to find | out which version number and which dependencies it has. Some | versions (like KDE3) are just variables and I don't have an | idea how to fetch them yet. The problem then isn't that it's not XML, it's having something well defined. Making it bad XML won't make it any better. XML is not great as a registry/database format. It turns out to be ugly to parse with code and ugly to edit by humans, and then humans try to to make it into something else that it isn't. Plus it's so easy to do a bad job in XML. | With a structured language like XML, it would make the parsing | process for such utils like mine easier. Right but harder for shell scripts, or awk, or simple things without every language needing a validating XML suite installed. | Furthermore, if you pack more information into the XML-files | about a port, many things can be automated by using XSLT | stylesheets (future ideas), like e.g. the Makefiles for the | ports can be created by a stylesheet. A structured XML file | is an ideal place for the pkg-descr, distinfo etc. | You have a centralized resource where you can pick the | information from you need. Right and now it's some crazed monster, not just package meta-data. And you need a specific tool to maintain this data, and all the port maintainers need to use it on all their platforms. | I'm not good in XML either, but I would get some more information | what can be done and if you really want to do it. What's important then is to; o first define exactly what data is going to be stored, o what it is going to be used for, o who NEEDS to use it o keep it consistent. People who WANT to use it aren't important right now, if it's easy enough to use for the people who NEED it, then the WANTers won't have a tough time building whatever it is they want to build. | I see. In my opinion, it's generally not a good idea to parse | XML with custom parsers. Writing out XML to a file is simple. | XML should be validated during the reading process. In this | way you can prevent errors and, of course, extend the testing | process (e.a. make the life easier for some people). Well this doesn't make sense. If you're using XML is SHOULD be validated when it's written, because it's probably going to need to conform to a DTD or an XML-schema. This shouldn't only be detected on read. The fact you need to validate both the data and the layout of the data should be a key indicator that this is a heavy-duty process. You need to weigh up whether or not this cost is worth it. This is way beyond just checking for simple formatting mistakes. | > That is what I was thinking of when I picked this specific format. | > With this strict, limited format, it should be easy to write a | > program that can do all the processing we want to do (at least | > for now). | | Before using XML, you should really ask people who have an | idea about both, ports and XML. Yeah well, the reasons people give for wanting to use XML, usually turn out to be the reasons they stop (well they never stop, they just wish they never started d8). After they have to publish a 60 page document explaining their XML schema, which is never up to date with reality... I could go on (and you know I am).. Simple is always better. You can build a lot of things with simple building blocks. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | M:+61 416 022 411 | ACN: 082 081 472 ABN: 83 082 081 472 |akm@theinternet.com.au| Carpe Daemon