Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 13 May 2007 23:55:02 +0200
From:      Benjamin Lutz <mail@maxlor.com>
To:        freebsd-hackers@freebsd.org, Thomas.Sparrevohn@btinternet.com
Cc:        Michel Talon <talon@lpthe.jussieu.fr>, Kris Kennaway <kris@obsecurity.org>
Subject:   Re: DPS Initial Ideas
Message-ID:  <200705132355.05941.mail@maxlor.com>
In-Reply-To: <004301c795a1$c7e89410$57b9bc30$@Sparrevohn@btinternet.com>
References:  <20070512004209.GA12218@lpthe.jussieu.fr> <20070513202737.GA63102@xor.obsecurity.org> <004301c795a1$c7e89410$57b9bc30$@Sparrevohn@btinternet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
--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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200705132355.05941.mail>