From owner-freebsd-hackers@FreeBSD.ORG Sun May 13 21:55:19 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C5D0416A406 for ; Sun, 13 May 2007 21:55:19 +0000 (UTC) (envelope-from mail@maxlor.com) Received: from popeye1.ggamaur.net (popeye1.ggamaur.net [213.160.40.50]) by mx1.freebsd.org (Postfix) with ESMTP id 5A29E13C459 for ; Sun, 13 May 2007 21:55:19 +0000 (UTC) (envelope-from mail@maxlor.com) Received: from maxlor.mine.nu (c-82-192-240-247.customer.ggaweb.ch [82.192.240.247]) by popeye1.ggamaur.net (8.13.7/8.13.7/Submit) with ESMTP id l4DLtF4P079976; Sun, 13 May 2007 23:55:15 +0200 (CEST) (envelope-from mail@maxlor.com) Received: from localhost (unknown [127.0.0.1]) by maxlor.mine.nu (Postfix) with ESMTP id D5D9B2E21F; Sun, 13 May 2007 23:55:06 +0200 (CEST) X-Virus-Scanned: amavisd-new at atlantis.intranet Received: from maxlor.mine.nu ([127.0.0.1]) by localhost (atlantis.intranet [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwrGHxVA-O-N; Sun, 13 May 2007 23:55:06 +0200 (CEST) Received: from mini.intranet (mini.intranet [10.0.0.17]) by maxlor.mine.nu (Postfix) with ESMTP id 973BA2E201; Sun, 13 May 2007 23:55:06 +0200 (CEST) From: Benjamin Lutz To: freebsd-hackers@freebsd.org, Thomas.Sparrevohn@btinternet.com Date: Sun, 13 May 2007 23:55:02 +0200 User-Agent: KMail/1.9.5 References: <20070512004209.GA12218@lpthe.jussieu.fr> <20070513202737.GA63102@xor.obsecurity.org> <004301c795a1$c7e89410$57b9bc30$@Sparrevohn@btinternet.com> In-Reply-To: <004301c795a1$c7e89410$57b9bc30$@Sparrevohn@btinternet.com> X-Face: $Ov27?7*N,h60fIEfNJdb!m,@#4T/d; 1hw|W0zvsHM(a$Yn6BYQ0^SEEXvi8>D`|V*F"=?utf-8?q?=5F+=0A=09R2?=@Aq>+mNb4`,'[[%z9v0Fa~]AD1}xQO3|>b.z&}l#R-_(P`?@Mz"kS; XC>Eti,i3>%@=?utf-8?q?g=3F=0A=094f?=,\c7|Ghwb&ky$b2PJ^\0b83NkLsFKv|smL/cI4UD%Tu8alAD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2421693.psxp62cECv"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200705132355.05941.mail@maxlor.com> X-Scanned-By: MIMEDefang 2.61 on 213.160.40.60 Cc: Michel Talon , Kris Kennaway Subject: Re: DPS Initial Ideas X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2007 21:55:19 -0000 --nextPart2421693.psxp62cECv Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sunday 13 May 2007 23:00, Thomas Sparrevohn wrote: > The on-disk format seems to be the wrong angle on the issue - The > current structure Works well - but it has a number of drawbacks - > however it no way clear whether that The answer is another > INDEX/storage structure=20 When coming up with ideas what to change INDEX's storage method to, just=20 keep in mind that=20 =2D There is very little flexibility whatsoever in the way data is stored in the file. Each entry in the INDEX has its 13 or so fields, and that's it. One of the strengths of XML, self-descriptiveness for very dynamic data structures, doesn't matter for INDEX. Basically, imho, using XML for tabular data =3D bad. =2D INDEX exists for speed. Accessing the information in it should be as fast as possible. I object to any change that increases the time needed to search for and parse INDEX entries. I've written a little searching tool (it can be found ports-mgmt/psearch). If INDEX were to be converted to XML, just because of that it would be considerably slower. If psearch then were to use standard XML parsing libs, the slowdown would probably be at least an order of magnitude. If there's any change to INDEX's format, it should make access faster, not slower. A format that allows constant-time random access would be nice, for example. =2D INDEX does not need to be portable. It'll be used on FreeBSD systems only, and by tools written specifically for the ports system. The second point is most important here. This whole thread exists=20 because people consider the existing ports system to be too slow. How=20 is using XML going to help with that at all? Cheers Benjamin --nextPart2421693.psxp62cECv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQBGR4k5zZEjpyKHuQwRAnR4AJ4p2/m6nE+FsLoLJBszN0OBszrQxgCeLc9I 69GJUSGxi3A5vtVtFZdfBcQ= =VOa2 -----END PGP SIGNATURE----- --nextPart2421693.psxp62cECv--